[Federal Register Volume 75, Number 8 (Wednesday, January 13, 2010)]
[Rules and Regulations]
[Pages 2013-2047]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: E9-31216]



[[Page 2013]]

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

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; Interim Final Rule

Federal Register / Vol. 75 , No. 8 / Wednesday, January 13, 2010 / 
Rules and Regulations

[[Page 2014]]


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

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, Department of Health and Human Services.

ACTION: Interim final rule.

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

SUMMARY: The Department of Health and Human Services (HHS) is issuing 
this interim final rule with a request for comments to adopt an initial 
set of standards, implementation specifications, and certification 
criteria, as required by section 3004(b)(1) of the Public Health 
Service Act. This interim final rule represents the first step in an 
incremental approach to adopting standards, implementation 
specifications, and certification criteria to enhance the 
interoperability, functionality, utility, and security of health 
information technology and to support its meaningful use. The 
certification criteria adopted in this initial set 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 
(beginning in 2011) by eligible professionals and eligible hospitals 
under the Medicare and Medicaid EHR Incentive Programs.

DATES: Effective Date: This interim final rule is effective February 
12, 2010. The incorporation by reference of certain publications listed 
in the rule is approved by the Director of the Federal Register as of 
February 12, 2010.
    Comment Date: To be assured consideration, written or electronic 
comments must be received at one of the addresses provided below, no 
later than 5 p.m. on March 15, 2010.

ADDRESSES: Because of staff and resource limitations, we cannot accept 
comments by facsimile (FAX) transmission. You may submit comments, 
identified by RIN 0991-AB58, by any of the following methods (please do 
not submit duplicate comments).
     Federal eRulemaking Portal: Follow the instructions for 
submitting comments. Attachments should be in Microsoft Word, 
WordPerfect, or Excel; however, we prefer Microsoft Word. http://www.regulations.gov.
     Regular, Express, or Overnight Mail: Department of Health 
and Human Services, Office of the National Coordinator for Health 
Information Technology, Attention: HITECH Initial Set Interim Final 
Rule, Hubert H. Humphrey Building, Suite 729D, 200 Independence Ave., 
SW., Washington, DC 20201. Please submit one original and two copies.
     Hand Delivery or Courier: Office of the National 
Coordinator for Health Information Technology, Attention: HITECH 
Initial Set Interim Final Rule, Hubert H. Humphrey Building, Suite 
729D, 200 Independence Ave., SW., Washington, DC 20201. Please submit 
one original and two copies. (Because access to the interior of the 
Hubert H. Humphrey Building is not readily available to persons without 
federal government identification, commenters are encouraged to leave 
their comments in the mail drop slots located in the main lobby of the 
building.)
    Inspection of Public Comments: All comments received before the 
close of the comment period will be available for public inspection, 
including any personally identifiable or confidential business 
information that is included in a comment. Please do not include 
anything in your comment submission that you do not wish to share with 
the general public. Such information includes, but is not limited to: A 
person's social security number; date of birth; driver's license 
number; state identification number or foreign country equivalent; 
passport number; financial account number; credit or debit card number; 
any personal health information; or any business information that could 
be considered to be proprietary. We will post all comments received 
before the close of the comment period at http://www.regulations.gov.
    Docket: For access to the docket to read background documents or 
comments received, go to http://www.regulations.gov or 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 the 
contact listed below to arrange for inspection).

FOR FURTHER INFORMATION CONTACT: Steven Posnack, Policy Analyst, 202-
690-7151.

SUPPLEMENTARY INFORMATION:

Acronyms

AHIC American Health Information Community
ANSI American National Standards Institute
ASP Application Service Provider
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
GIPSE Geocoded Interoperable Population Summary Exchange
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 ICD, 9th Revision, Clinical Modifications
ICD-10-PCS ICD, 10th Revision, Procedure Coding System
ICD-10-CM ICD, 10th Revision, Related Health Problems
IHS Indian Health Service
LOINC Logical Observation Identifiers Names and Codes
MA Medicare Advantage
NCPDP National Council for Prescription Drug Programs
NCVHS National Committee on Vital and Health Statistics
NLM National Library of Medicine
NQF National Quality Forum
OASIS Organization for the Advancement of Structured Information 
Standards
OCR Office for Civil Rights
OIG Office of Inspector General
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
SDOs Standards Development Organizations
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
UNII Unique Ingredient Identifier
XML eXtensible Markup Language

Table of Contents

I. Background
    A. ONC Background

[[Page 2015]]

    B. Interdependencies With Other HITECH Provisions and 
Relationship to Other Regulatory Requirements and Related Activities
    1. Medicare and Medicaid EHR Incentive Programs Proposed Rule
    2. Health Insurance Portability and Accountability Act of 1996 
(HIPAA) Privacy Rule Accounting of Disclosures Regulation
    3. Previous Recognition of Certification Bodies and New 
Authority Under the HITECH Act
    4. Other HHS Regulatory Actions
    a. Health Insurance Portability and Accountability Act of 1996 
(HIPAA) Transactions and Code Sets Standards
    b. Electronic Prescribing Standards
    C. Standards, Implementation Specifications, and Certification 
Criteria Processes Before and After the HITECH Act
    1. ONC's Processes Prior to the HITECH Act
    2. HITECH Act Requirements for the Adoption of Standards, 
Implementation Specifications, and Certification Criteria
    D. Future Updates to Standards, Implementation Specifications, 
and Certification Criteria
II. Overview of the Interim Final Rule
III. Section-By-Section Description of the Interim Final Rule
    A. Applicability
    B. Definitions
    1. Definition of Standard
    2. Definition of Implementation Specification
    3. Definition of Certification Criteria
    4. Definition of Qualified Electronic Health Record (EHR)
    5. Definition of EHR Module
    6. Definition of Complete EHR
    7. Definition of Certified EHR Technology
    8. Definition of Disclosure
    C. Initial Set of Standards, Implementation Specifications, and 
Certification Criteria
    1. Adopted Certification Criteria
    2. Adopted Standards
    a. Transport Standards
    b. Content Exchange and Vocabulary Standards
    i. Patient Summary Record
    ii. Drug Formulary Check
    iii. Electronic Prescribing
    iv. Administrative Transactions
    v. Quality Reporting
    vi. Submission of Lab Results to Public Health Agencies
    vii. Submission to Public Health Agencies for Surveillance or 
Reporting
    viii. Submission to Immunization Registries
    ix. Table 2A
    c. Privacy and Security Standards
    3. Adopted Implementation Specifications
    4. Additional Considerations, Clarifications, and Requests for 
Public Comments
    a. Relationship to Other Federal Laws
    b. Human Readable Format
    c. Certification Criterion and Standard Regarding Accounting of 
Disclosures
    d. Additional Requests for Public Comment
IV. Collection of Information Requirements
V. Regulatory Impact Analysis
    A. Introduction
    B. Why Is This Rule Needed?
    C. Costs and Benefits
    1. Costs
    2. Benefits
    D. Regulatory Flexibility Act Analysis
    E. Executive Order 13132--Federalism
    F. Unfunded Mandates Reform Act of 1995 Regulation Text

I. Background

    The Health Information Technology for Economic and Clinical Health 
Act (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 created ``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 the Department 
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 health information technology. It also permits 
the Secretary to adopt this initial set through an interim final rule.
    The certification criteria adopted in this initial set establish 
the capabilities and related standards that certified electronic health 
record (EHR) technology (Certified EHR Technology) will need to include 
in order to, at a minimum, support the achievement of the proposed 
meaningful use Stage 1 by eligible professionals and eligible hospitals 
under the Medicare and Medicaid EHR Incentive Programs.
    Throughout this interim final rule, we routinely refer to eligible 
professionals and eligible hospitals. This is done 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. This 
initial focus is not meant to limit or preclude health care providers 
who do not meet the definitions of eligible professional or eligible 
hospital from obtaining or adopting Certified EHR Technology. To the 
contrary, Certified EHR Technology will possess the capabilities that 
can assist any health care provider to improve the quality, safety and 
efficiency of the care they deliver.
    We note that ordinarily we publish a notice of proposed rulemaking 
in the Federal Register and invite public comment on the proposed rule. 
The notice of proposed rulemaking includes a reference to the legal 
authority under which the rule is proposed, and the terms and 
substances of the proposed rule or a description of the subjects and 
issues involved. As mentioned above, however, section 3004(b)(1) 
explicitly authorizes the Secretary to issue this rule on an interim 
final basis. Moreover, section 3004(b)(1) requires the Secretary to 
adopt an initial set of standards, implementation specifications, and 
certification criteria by December 31, 2009. We have therefore decided 
to proceed directly with this interim final rule. Nevertheless, we are 
providing the public with a 60-day period following publication of this 
document to submit comments on the interim final rule.
    The following discussion provides the background information 
relevant to the Secretary's adoption of an initial set of standards, 
implementation specifications, and certification criteria.

A. ONC Background

    Executive Order 13335 (69 FR 24059) established the Office of the 
National Coordinator for Health Information Technology (ONC) on April 
24, 2004. In an effort to ``provide leadership for the development and 
nationwide implementation of an interoperable health information 
technology infrastructure to improve the quality and efficiency of 
health care,'' the President directed the Secretary to create within 
the Office of the Secretary the position of National Health Information 
Technology Coordinator (National Coordinator). The National Coordinator 
was charged with: Serving as the Secretary's principal advisor on the 
development, application, and use of HIT and directing the HHS HIT 
programs; ensuring that the HIT policy and programs of HHS were 
coordinated with those of relevant Executive Branch agencies; to the 
extent permitted by law, coordinating outreach and consultation by the 
relevant Executive Branch agencies with public and private parties of 
interest; and at the request of the Office of Management and Budget 
(OMB), providing comments and advice regarding specific Federal HIT 
programs. Additionally, the National Coordinator was required, to the 
extent permitted by law, to develop, maintain, and direct the 
implementation of a strategic plan to guide the nationwide 
implementation of interoperable HIT in

[[Page 2016]]

both the public and private health care sectors. Included in Executive 
Order 13335 as a strategic plan objective, was the goal to ``advance 
the development, adoption, and implementation of health care 
information technology standards nationally through collaboration among 
public and private interests, and consistent with current efforts to 
set health information technology standards for use by the Federal 
Government.''
    Section 3001 of the PHSA establishes by statute the ONC within HHS 
and provides the National Coordinator with additional responsibilities 
and duties beyond those originally identified in Executive Order 13335. 
Specifically, the National Coordinator is charged with, among other 
duties: Reviewing and determining whether to endorse each standard, 
implementation specification, and certification criterion that is 
recommended by the HIT Standards Committee (a Federal advisory 
committee to the National Coordinator) and making such determinations 
and reporting them to the Secretary; reviewing Federal HIT investments 
to ensure they meet the objectives of the Federal HIT Strategic Plan; 
coordinating the HIT policy and programs of HHS with those of other 
relevant Federal agencies; serving as a leading member in the 
establishment and operations of the HIT Policy Committee and HIT 
Standards Committee; updating the Federal HIT Strategic Plan in 
consultation with other appropriate Federal agencies and through 
collaboration with public and private entities; keeping or recognizing 
a program or programs to certify EHR technology; conducting studies and 
reports; and establishing a governance mechanism for the Nationwide 
Health Information Network (NHIN).

B. Interdependencies With Other HITECH Provisions and Relationship to 
Other Regulatory Requirements and Related Activities

    The HITECH Act creates multiple interdependencies between this 
interim final rule and other regulatory requirements, processes, and 
programs.
1. Medicare and Medicaid EHR Incentive Programs Proposed Rule
    In writing the provisions of the HITECH Act, Congress fundamentally 
tied the standards, implementation specifications, and certification 
criteria adopted in this interim final rule 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 includes 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. Congress further specified that Certified EHR Technology 
must be certified as meeting the standards adopted by the Secretary, 
which we adopt in this rule. As referenced in the preamble to the 
Medicare and Medicaid EHR Incentives Program proposed rule the Medicare 
and/or Medicaid incentive payments are available to certain eligible 
professionals and eligible hospitals.
    We have adopted standards, implementation specifications, and 
certification criteria in this interim final rule in part to assure 
that Certified EHR Technology is capable of supporting the achievement 
of meaningful use by eligible professionals and eligible hospitals 
under the Medicare and Medicaid EHR Incentive Programs. The 
certification criteria, adopted by the Secretary, must be used to test 
and certify that Complete EHRs or EHR Modules have properly implemented 
the capabilities required by the certification criteria and, where 
appropriate, the standards and implementation specifications adopted by 
the Secretary. ONC and the Centers for Medicare & Medicaid Services 
(CMS) have worked carefully to ensure that this interim final rule and 
the Medicare and Medicaid EHR Incentive Programs proposed rule are 
aligned.
    To inform our collaborative rulemaking processes, ONC and CMS 
received input from hundreds of technical subject matter experts, 
health care providers, and other stakeholders who provided written 
comments to, testified before, and attended meetings held by three HHS 
Federal advisory committees: the National Committee on Vital and Health 
Statistics, the HIT Policy Committee, and the HIT Standards Committee. 
After several meetings of its workgroups and the full committee, the 
HIT Policy Committee presented and recommended to the National 
Coordinator at its July 16, 2009 meeting a matrix on meaningful use of 
Certified EHR Technology that contained: Overall health outcome policy 
priorities; health care goals; draft objectives for eligible 
professionals and eligible hospitals for 2011 (beginning of meaningful 
use Stage 1), 2013 (beginning of meaningful use Stage 2), and 2015 
(beginning of meaningful use Stage 3); and specific measures for each 
of those years. With respect to this interim final rule's relationship 
to the Medicare and Medicaid EHR Incentive Programs proposed rule, we 
have adopted certification criteria that directly support CMS's 
proposed meaningful use Stage 1 objectives. The stages of meaningful 
use are described and have been proposed by CMS in the Medicare and 
Medicaid EHR Incentive Programs proposed rule as the following:
     Stage 1 (beginning in 2011): The proposed Stage 1 
meaningful use criteria ``focuses on electronically capturing health 
information in a coded format; using that information to track key 
clinical conditions and communicating that information for care 
coordination purposes (whether that information is structured or 
unstructured, but in structured format whenever feasible); consistent 
with other provisions of Medicare and Medicaid law, implementing 
clinical decision support tools to facilitate disease and medication 
management; and reporting clinical quality measures and public health 
information.''
     Stage 2 (beginning in 2013): CMS has proposed that its 
goals for the Stage 2 meaningful use criteria, ``consistent with other 
provisions of Medicare and Medicaid law, expand upon the Stage 1 
criteria to encourage the use of health IT for continuous quality 
improvement at the point of care and the exchange of information in the 
most structured format possible, such as the electronic transmission of 
orders entered using computerized provider order entry (CPOE) and the 
electronic transmission of diagnostic test results (such as blood 
tests, microbiology, urinalysis, pathology tests, radiology, cardiac 
imaging, nuclear medicine tests, pulmonary function tests and other 
such data needed to diagnose and treat disease). Additionally we may 
consider applying the criteria more broadly to both the inpatient and 
outpatient hospital settings.''
     Stage 3 (beginning in 2015): CMS has proposed that its 
goals for the Stage 3 meaningful use criteria are, ``consistent with 
other provisions of Medicare and Medicaid law, to focus on promoting 
improvements in quality, safety and efficiency, focusing on decision 
support for national high priority conditions, patient access to self 
management tools, access to comprehensive patient data and improving 
population health.''
2. Health Insurance Portability and Accountability Act of 1996 (HIPAA) 
Privacy Rule Accounting of Disclosures Regulation
    Section 13405(c) of the HITECH Act requires the Secretary to 
promulgate regulations on what information shall be

[[Page 2017]]

collected about disclosures for treatment, payment, or health care 
operations made ``through an electronic health record'' by a HIPAA 
covered entity. These regulations, which will be issued by the 
Secretary through the HHS Office for Civil Rights, must be issued not 
later than 6 months after the date on which the Secretary adopts 
standards on accounting for disclosures described in the section 
3002(b)(2)(B)(iv) of the PHSA. The certification criterion and standard 
associated with this requirement and included in this interim final 
rule are discussed in more detail below in section III.C.4.c.
3. Previous Recognition of Certification Bodies and New Authority Under 
the HITECH Act
    Among other responsibilities, section 3001(c)(5) of the PHSA 
expressly requires the National Coordinator, in consultation with the 
Director of the National Institute of Standards and Technology, to 
``keep or recognize a program or programs for the voluntary 
certification of health information technology as being in compliance 
with applicable certification criteria adopted'' by the Secretary under 
section 3004. HHS's recognition of certain bodies to conduct HIT 
certification is not new as a result of the HITECH Act. In August 2006, 
HHS published two final rules in which CMS and the Office of Inspector 
General (OIG) promulgated an exception to the physician self-referral 
prohibition and a safe harbor under the anti-kickback statute, 
respectively, for certain arrangements involving the donation of 
interoperable EHR software to physicians and other health care 
practitioners or entities (71 FR 45140 and 71 FR 45110, respectively). 
The exception and safe harbor provide that EHR software will be 
``deemed to be interoperable if a certifying body recognized by the 
Secretary has certified the software no more than 12 months prior to 
the date it is provided to the [physician/recipient].'' ONC published 
separately a Certification Guidance Document (CGD) (71 FR 44296) to 
explain the factors ONC would use to determine whether or not to 
recommend to the Secretary a body for recognized certification body 
status. The CGD serves as a guide for ONC to evaluate applications for 
recognized certification body status and provides the information a 
body would need to apply for and obtain such status. In section VI of 
the CGD, ONC notified the public and potential applicants that the 
recognition process would be formalized through notice and comment 
rulemaking.
    After reviewing the new responsibilities assumed under the HITECH 
Act and the additional purpose to which the certification of the HIT is 
now tied (qualifying for incentive payments) in combination with ONC's 
current responsibilities under the CGD, we have decided to propose in a 
separate rulemaking, processes to replace the CGD and establish HIT 
certification programs as specified by section 3001(c)(5) of the PHSA. 
We have decided to proceed with a separate notice and comment 
rulemaking (which we anticipate publishing shortly after this interim 
final rule) to establish the policies for the certification of HIT and 
the process a certification body will need to follow to become an 
authorized certification body, as determined by the National 
Coordinator.
4. Other HHS Regulatory Actions
a. HIPAA Transactions and Code Sets Standards
    The Secretary has previously adopted and modified transactions and 
code sets standards for HIPAA covered entities. Many of these same 
covered entities are now also eligible to qualify for incentive 
payments under the Medicare and Medicaid EHR Incentives Program. As a 
result, we want to assure that Certified EHR Technology positions these 
eligible professionals and eligible hospitals to qualify for incentive 
payments and comply with these transactions and code set standards. 
Most recently, in August 2008, HHS proposed through two rules (73 FR 
49742 and 73 FR 49796) the updating of electronic transaction 
standards, new transaction standards, and the adoption of International 
Classification of Diseases (ICD), 10th Revision, Related Health 
Problems (ICD-10-CM) and ICD, 10th Revision, Procedure Coding System 
(ICD-10-PSC) code sets to replace the ICD, 9th Revision, Clinical 
Modifications (ICD-9-CM) Volumes 1 and 2, and the ICD-9-CM Volume 3 
code sets, respectively. After reviewing and considering public 
comments on these proposals, in January 2009, HHS adopted in final 
rules published at 74 FR 3296 and 74 FR 3328 certain updated 
transaction standards, new transaction standards, and code sets.
    The rules established a timeline for compliance with some of these 
updated standards and code sets. For example, all HIPAA covered 
entities are required to comply with ICD-10-CM and ICD-10-PSC on and 
after October 1, 2013.
    In adopting an initial set of standards and implementation 
specifications as specified at section 3004(b)(1) of the PHSA, we have 
taken into account HIPAA transactions and code sets standards and their 
associated implementation timetables. We have ensured that our 
standards and implementation specifications are consistent with the 
previously adopted HIPAA transactions and code sets standards and with 
the established implementation timetable. Further, we intend for our 
future adoption of standards and implementation specifications for 
meaningful use Stage 2 and Stage 3 to continue to be consistent with 
the Secretary's adoption and modification of HIPAA transactions and 
code sets standards and their timeframes for compliance.
b. Electronic Prescribing Standards
    The Medicare Prescription Drug, Improvement and Modernization Act 
of 2003 (MMA) provided for, among other things, the Voluntary 
Prescription Drug Benefit Program. Under that program, electronically 
transmitted prescriptions and certain other information for covered 
Part D drugs prescribed for Part D eligible individuals must be sent in 
a manner that complies with applicable standards that are adopted by 
the Secretary. The Secretary proposed the first of these standards in a 
February 2005 rulemaking (70 FR 6256). Subsequently, on June 23, 2006 
(71 FR 36020), HHS published an interim final rule that maintained the 
National Council for Prescription Drug Programs (NCPDP) SCRIPT 5.0 as 
the adopted standard, but allowed for the voluntary use of a subsequent 
backward compatible version of the standard, NCPDP SCRIPT 8.1.
    As a result of pilot testing of six ``initial standards'' that had 
been identified in 2005, the Secretary issued a notice of proposed 
rulemaking on November 16, 2007 (72 FR 64900) which proposed adoption 
of certain standards. The Secretary also used this proposed rule to 
solicit comments regarding the impact of adopting NCPDP SCRIPT 8.1 and 
retiring NCPDP SCRIPT 5.0. Based on the comments that were received, 
the Secretary issued a final rule (73 FR 18918) on April 7, 2008 that 
adopted NCPDP SCRIPT Version 8.1 and retired NCPDP SCRIPT Version 5.0. 
In adopting an initial set of standards to meet the requirement 
specified at section 3004(b)(1) of the PHSA, we have taken into account 
these electronic prescribing standards and ensured that our standards 
are consistent with them.

[[Page 2018]]

C. Standards, Implementation Specifications, and Certification Criteria 
Processes Before and After the HITECH Act

1. ONC's Processes Prior to the HITECH Act
    Prior to the enactment of the HITECH Act, ONC's processes consisted 
of the ``acceptance'' and ``recognition'' of HIT standards, 
implementation specifications, and certification criteria for the 
electronic exchange of health information and electronic health 
records. This prior process and its participants are described in 
further detail below.
    Chartered in 2005, the American Health Information Community 
(AHIC), a Federal advisory committee, was charged with making 
recommendations to the Secretary on how to accelerate the development 
and adoption of HIT. Until its sunset in November 2008, AHIC advanced 
to the Secretary several recommendations related to standards, 
implementation specifications, and certification criteria. To structure 
those recommendations, AHIC identified ``use cases'' to prioritize 
areas in need of harmonized standards and to enable ONC to guide the 
work of organizations with specific expertise in those priority areas. 
A use case provided a description of the activity of stakeholders, a 
sequence of their actions, and technical specifications for systems and 
technologies involved when the actors engage in responding to or 
participating in such activity.
    Created in 2005 by the American National Standards Institute (ANSI) 
under a contract with HHS, the Healthcare Information Technology 
Standards Panel (HITSP)--a cooperative partnership of more than 500 
public and private sector organizations--began its work to take into 
account AHIC identified use cases, as directed by ONC. HITSP was 
established for the purpose of harmonizing and integrating a widely 
accepted and useful set of standards to enable and support 
interoperability among healthcare software systems and the 
organizations and entities that utilize the systems. HITSP also became 
a primary forum for HIT standards harmonization after the Consolidated 
Health Informatics (CHI) initiative, which began in October 2001 as a 
collaborative effort to adopt Federal government-wide interoperability 
standards to be implemented by Federal agencies, was gradually phased 
out. The CHI initiative adopted several standards that were fed into 
and reused as part of HITSP's standards harmonization processes. As a 
result, over the course of its three-year existence, AHIC sought 
testimony from HITSP representatives several times on their standards 
harmonization work in order to inform potential recommendations for the 
Secretary. In many cases, after a presentation by HITSP, AHIC would 
make recommendations to the Secretary regarding standards and 
implementation specifications for recognition. The Secretary would 
subsequently review those recommendations and determine whether to 
recognize some or all of the recommended standards and implementation 
specifications.
    Executive Order 13410 (71 FR 51089) acknowledged that the Secretary 
recognizes interoperability standards for use by certain Federal 
agencies.\1\ This Executive Order also directed those Federal agencies, 
to the extent permitted by law, to require in their contracts and 
agreements with certain organizations the use, where available, of 
health information technology systems and products that meet recognized 
interoperability standards. Executive Order 13410 was issued on August 
28, 2006, to, among other goals, ensure that health care programs 
administered or sponsored by the Federal government promoted quality 
and efficient delivery of health care through the use of health 
information technology. On March 1, 2007, January 23, 2008, and January 
29, 2009, HHS published notices in the Federal Register (72 FR 9339, 73 
FR 3973, 74 FR 3599, respectively) announcing either the Secretary's 
acceptance or recognition of certain standards and implementation 
specifications. In an effort to assist with the implementation and 
adoption challenges associated with recognized standards, the Secretary 
chose to first ``accept'' and then formally ``recognize'' one year 
after acceptance, specified standards and implementation 
specifications. This delay provided Federal agencies with additional 
time to prepare for Executive Order 13410's directive to ``utilize, 
where available, health information technology systems and products 
that meet recognized interoperability standards'' when they 
implemented, acquired, or upgraded ``health information technology 
systems used for the direct exchange of health information between 
agencies and with non-Federal entities.''
---------------------------------------------------------------------------

    \1\ Executive Order 13410 defines ``agency'' to mean ``an agency 
of the Federal Government that administers or sponsors a Federal 
health care program.'' It also defines ``Federal health care 
program'' as including ``the Federal Employees Health Benefit 
Program, the Medicare program, programs operated directly by the 
Indian Health Service, the TRICARE program for the Department of 
Defense and other uniformed services, and the health care program 
operated by the Department of Veterans Affairs.'' For purposes of 
the Executive Order, ``Federal health care program'' does not 
include ``State operated or funded federally subsidized programs 
such as Medicaid, the State Children's Health Insurance Program, or 
services provided to Department of Veterans' Affairs beneficiaries 
under 38 U.S.C. 1703.''
---------------------------------------------------------------------------

    The third participant besides AHIC and HITSP that played a role in 
ONC's prior processes was the Certification Commission for Health 
Information Technology (CCHIT). Founded in 2004, CCHIT established the 
first comprehensive process to test and certify EHR technology. After 
establishing a certification criteria development process that included 
diverse stakeholders and a voluntary, consensus-based approach, CCHIT 
began certifying ambulatory EHR technology in 2006. Since 2006, CCHIT 
has expanded its certification program to include inpatient EHR 
technology, emergency department EHR technology, as well as its 
certification criteria for EHR technology to meet specific needs of 
certain health care providers/specialists (e.g., cardiovascular, child 
health). On May 16, 2006, CCHIT presented its 2006 ambulatory EHR 
certification criteria to AHIC and after considering the criteria, AHIC 
recommended that the Secretary recognize CCHIT-identified certification 
criteria for functionality, interoperability, and security.
    This recommendation informed the Secretary's decision to recognize 
the 2006 ambulatory EHR certification criteria for use by recognized 
certification bodies in conjunction with published final rules for 
exceptions to the physician self-referral law and safe harbors to the 
anti-kickback statute for electronic prescribing and EHR software 
arrangements (71 FR 45140 and 71 FR 45110, respectively). The exception 
and safe harbor provide that EHR software will be ``deemed to be 
interoperable if a certifying body recognized by the Secretary has 
certified the software no more than 12 months prior to the date it is 
provided to the [physician/recipient].'' These provisions of the EHR 
exception and safe harbor anticipated that: (1) HHS would recognize one 
or more EHR certifying bodies, and (2) HHS would recognize criteria for 
the certification of EHRs. The Federal Register notice (71 FR 44295) 
describing the Secretary's recognition of these certification criteria 
was published on August 4, 2006.
    Section 3004(b)(2) of the PHSA provides that in adopting an initial 
set of standards, implementation specifications, and certification 
criteria in accordance with section 3004(b)(1), the Secretary may adopt 
those standards, implementation specifications, and certification 
criteria

[[Page 2019]]

that went through the process established by ONC before the date of the 
enactment of the HITECH Act. We believe that in separately requiring 
the Secretary to adopt an ``initial set'' of standards, implementation 
specifications, and certification criteria under section 3004(b)(1) of 
the PHSA, Congress provided the Secretary with the discretion to adopt 
standards, implementation specifications, or certification criteria 
which had not gone through the prior process. As described above, while 
the prior process included a significant body of work it did not 
encompass the entirety of the areas Congress requested the Secretary to 
focus on in the HITECH Act, nor did it envision the policies and 
capabilities that would be necessary for Certified EHR Technology to 
meet the proposed definition of meaningful use Stage 1 included in the 
Medicare and Medicaid EHR Incentive Programs proposed rule. As a 
result, we have, after considering the input received through the 
recommendations of the HIT Policy Committee and HIT Standards 
Committee, adopted an initial set of standards, implementation 
specifications, and certification criteria to, at a minimum, support 
the achievement of what is being proposed for meaningful use Stage 1. 
We have noted in section III of this rule, where applicable, those 
standards and implementation specifications that were previously 
accepted or recognized by the Secretary under this prior process and 
those that were not. Due to our approach of aligning adopted 
certification criteria with the proposed definition of meaningful use 
Stage 1, the Secretary has decided not to adopt previously recognized 
certification criteria developed in 2006 as any of the certification 
criteria in this interim final rule.
2. HITECH Act Requirements for the Adoption of Standards, 
Implementation Specifications, and Certification Criteria
    With the passage of the HITECH Act, two new Federal advisory 
committees, the HIT Policy Committee and the HIT Standards Committee, 
were established as specified in the new sections of the PHSA, 3002 and 
3003, respectively. Both are responsible for advising the National 
Coordinator on different aspects of standards, implementation 
specifications, and certification criteria and consequently they both 
have the potential to impact how and when standards, implementation 
specifications, and certification criteria are adopted by the 
Secretary. The HIT Policy Committee is responsible for, among other 
duties, recommending priorities for standards, implementation 
specifications, and certification criteria while the HIT Standards 
Committee is responsible for recommending standards, implementation 
specifications, and certification criteria for adoption under section 
3004 of the PHSA.
    Section 3002 of the PHSA directs the HIT Policy Committee to ``make 
policy recommendations to the National Coordinator relating to the 
implementation of a nationwide health information technology 
infrastructure.'' Section 3002(b) further specifies the type of policy 
recommendations expected of the HIT Policy Committee by requiring that 
the committee focus on ``specific areas of standards development'' and 
in so doing ``recommend the areas in which standards, implementation 
specifications, and certification criteria are needed for the 
electronic exchange and use of health information for purposes of 
adoption under section 3004.'' Section 3002(b) also requires the HIT 
Policy Committee, after determining the areas where standards, 
implementation specifications, and certification criteria are needed (a 
process and analysis that are likely to occur on a periodic basis), to 
``recommend an order of priority for the development, harmonization, 
and recognition of such standards, specifications, and certification 
criteria among the areas so recommended.'' After receipt of a 
recommendation related to a priority order, the National Coordinator is 
expected to review the priorities identified by the HIT Policy 
Committee and generally will either accept them as submitted, request 
adjustments, or reject the priority order in whole or in part. Once the 
National Coordinator accepts a recommendation for the priority order of 
standards, implementation specifications, and certification criteria, 
such priorities will be communicated to the HIT Standards Committee to 
guide its work. The HIT Policy Committee is charged with making 
recommendations in at least the following eight areas as specified in 
section 3002(b)(2)(B) of the PHSA:

    (1) Technologies that protect the privacy of health information 
and promote security in a qualified electronic health record, 
including for the segmentation and protection from disclosure of 
specific and sensitive individually identifiable health information 
with the goal of minimizing the reluctance of patients to seek care 
(or disclose information about a condition) because of privacy 
concerns, in accordance with applicable law, and for the use and 
disclosure of limited data sets of such information;
    (2) A nationwide health information technology infrastructure 
that allows for the electronic use and accurate exchange of health 
information;
    (3) The utilization of a certified electronic health record for 
each person in the United States by 2014;
    (4) Technologies that as a part of a qualified electronic health 
record allow for an accounting of disclosures made by a covered 
entity (as defined for purposes of regulations promulgated under 
section 264(c) of the Health Insurance Portability and 
Accountability Act of 1996) for purposes of treatment, payment, and 
health care operations (as such terms are defined for purposes of 
such regulations);
    (5) The use of certified electronic health records to improve 
the quality of health care, such as by promoting the coordination of 
health care and improving continuity of health care among health 
care providers, by reducing medical errors, by improving population 
health, by reducing health disparities, by reducing chronic disease, 
and by advancing research and education;
    (6) Technologies that allow individually identifiable health 
information to be rendered unusable, unreadable, or indecipherable 
to unauthorized individuals when such information is transmitted in 
the nationwide health information network or physically transported 
outside of the secured, physical perimeter of a health care 
provider, health plan, or health care clearinghouse;
    (7) The use of electronic systems to ensure the comprehensive 
collection of patient demographic data, including, at a minimum, 
race, ethnicity, primary language, and gender information; and
    (8) Technologies that address the needs of children and other 
vulnerable populations.

    The HIT Policy Committee is also authorized at 3002(b)(2)(C) to 
consider other areas to make recommendations such as the ``appropriate 
uses of a nationwide health information infrastructure, including [for] 
* * * collection of quality data and public reporting,'' 
``telemedicine,'' and ``technologies that help reduce medical errors.''
    Section 3003 of the PHSA directs the HIT Standards Committee to 
``recommend to the National Coordinator standards, implementation 
specifications, and certification criteria for the electronic exchange 
and use of health information for purposes of adoption under section 
3004.'' It also established that the HIT Standards Committee must 
recommend standards, implementation specifications, and certification 
criteria they have developed, harmonized, or recognized. We note that 
in section 3003(b)(2), the HIT Standards Committee is also expressly 
permitted to recognize harmonized or updated standards from other 
entities and as a result, we expect the HIT Standards Committee to, 
where appropriate, consider the standards, implementation 
specifications, and certification criteria from various

[[Page 2020]]

entities for recommendation to the National Coordinator. We expect that 
in determining whether to recognize harmonized or updated standards 
from other entities, the HIT Standards Committee will look to entities 
such as HITSP and the National Quality Forum (NQF). Additionally, 
section 3003(a) requires the HIT Standards Committee to focus on and 
make recommendations to the National Coordinator on the eight areas in 
section 3002(b)(2)(B) listed above. The HIT Standards Committee is 
required to update their recommendations and make new recommendations 
as appropriate, including in response to a notification sent under 
section 3004(a)(2)(B) of the PHSA.
    Section 3004 of the PHSA redefines how the Secretary adopts 
standards, implementation specifications, and certification criteria.
     Section 3004(b)(1) of the PHSA requires a one-time action 
by the Secretary to adopt an initial set of standards, implementation 
specifications, and certification criteria. This interim final rule has 
been published to meet the requirements in section 3004(b)(1).
     Section 3004(a) of the PHSA defines a process whereby an 
obligation is imposed on the Secretary to review standards, 
implementation specifications, and certification criteria and 
identifies the procedures for the Secretary to follow to determine 
whether to adopt any grouping of standards, implementation 
specifications, or certification criteria included within National 
Coordinator-endorsed recommendations. The specific elements of the 
process related to section 3004(a) will be described in greater detail 
below.
     Section 3004(b)(3) of the PHSA entitled ``subsequent 
standards activity'' states that the ``Secretary shall adopt additional 
standards, implementation specifications, and certification criteria as 
necessary and consistent'' with the schedule published by the HIT 
Standards Committee. While we intend to consistently seek the insights 
and recommendations of the HIT Standards Committee, we note that 
section 3004(b)(3) provides the Secretary with the authority and 
discretion to adopt standards, implementation specifications, and 
certification criteria without having first received a National 
Coordinator-endorsed HIT Standards Committee recommendation.
    Under section 3004(a) when a recommendation regarding a standard, 
implementation specification, or certification criterion is made by the 
HIT Standards Committee to the National Coordinator, a time limited 
statutory process is triggered. First, after receiving a recommendation 
from the HIT Standards Committee, the National Coordinator must review 
and determine whether to endorse the recommendation as well as report 
such determination to the Secretary. Upon receipt of an ``endorsed 
recommendation,'' the Secretary is required to consult with 
representatives of other relevant Federal agencies to review the 
standards, implementation specifications, or certification criteria and 
determine whether to propose their adoption. The Secretary is required 
to publish all determinations in the Federal Register. If the Secretary 
determines to propose the adoption of standards, implementation 
specifications, or certification criteria, the Secretary is permitted 
to adopt any grouping of standards, implementation specifications, or 
certification criteria. On the other hand, if the Secretary determines 
not to propose the adoption of any grouping of standards, 
implementation specifications, or certification criteria, the Secretary 
must notify the National Coordinator and the HIT Standards Committee in 
writing of such determination and the reasons for not proposing their 
adoption.
    The HIT Standards Committee issued recommendations to the National 
Coordinator on August 20, 2009, and updated those recommendations on 
September 15, 2009. In fulfilling the duties under section 
3001(c)(1)(A) and (B), the National Coordinator reviewed the 
recommendations made by the HIT Standards Committee and issued a 
determination endorsing several recommendations for the Secretary's 
consideration. As specified in section 3004(a)(3), this interim final 
rule also serves as the Secretary's formal publication of the 
determinations made regarding the National Coordinator-endorsed 
recommendations.

D. Future Updates to Standards, Implementation Specifications, and 
Certification Criteria

    The initial set of standards, implementation specifications, and 
certification criteria adopted in this interim final rule marks the 
beginning of what we expect to be an iterative approach to enhancing 
the interoperability, functionality, utility, and security of HIT. A 
number of factors including maturity, prevalence in the market, and 
implementation complexity informed our adoption of the standards, 
implementation specifications, and certification criteria included in 
this interim final rule.
    Our approach to the adoption of standards, implementation 
specifications, and certification criteria is pragmatic, but forward 
looking. While a high-level of interoperability nationwide will take 
time and be challenging, we believe that the HITECH Act has generated a 
significant amount of momentum and interest in meeting the challenges 
that lie ahead.
    We recognize that interoperability and standardization can occur at 
many different levels. For example, one organization may use an 
information model to describe patient demographic information as 
(PatientAge, PatientSex, StreetAddress), while another may describe 
similar demographic information in a different way (DateOfBirth, 
Gender, City/State). To achieve interoperability at this information 
level, these information models would need to be harmonized into a 
consistent representation.
    In other cases, organizations may use the same information model, 
but use different vocabularies or code sets (for example, Systematized 
Nomenclature of Medicine Clinical Terms (SNOMED CT[supreg]) or ICD9-CM) 
within those information models. To achieve interoperability at this 
level, standardizing vocabularies, or mapping between different 
vocabularies (using tools like Unified Medical Language System (UMLS)) 
may be necessary. For some levels, (such as the network transport 
protocol), an industry standard that is widely used (e.g., Transmission 
Control Protocol (TCP) and the Internet Protocol (IP), (TCP/IP)) will 
likely be the most appropriate. Ultimately, to achieve semantic 
interoperability, we anticipate that multiple layers--network 
transportation protocols, data and services descriptions, information 
models, and vocabularies and code sets--will need to be standardized 
and/or harmonized to produce an inclusive, consistent representation of 
the interoperability requirements. We anticipate using a harmonization 
process that will integrate different representations of health care 
information into a consistent representation and maintain and update 
that consistent representation over time. For an information model, 
this process could include merging related concepts, adding new 
concepts, and mapping concepts from one representation of health care 
information to another. Similar processes to support standardization of 
data and services descriptions and vocabularies and codes sets may also 
be needed.
    We also recognize that a sustainable and incremental approach to 
the adoption of standards will require

[[Page 2021]]

processes for harmonizing both current and future standards. This will 
allow us to incrementally update our initial set of standards, 
implementation specifications, and certification criteria and provide a 
framework to maintain them. Our decision to adopt such updates will be 
informed and guided by recommendations from the HIT Policy Committee, 
HIT Standards Committee, public comment, industry readiness, and future 
meaningful use goals and objectives established for the Medicare and 
Medicaid EHR Incentive Programs. As a result, we expect, unless 
otherwise necessary, to adopt standards, implementation specifications, 
and certification criteria synchronously with and to support a 
transition to the next stage of meaningful use in the Medicare and 
Medicaid EHR Incentive Programs. In doing so, we also anticipate 
increasing the level of specificity we provide related to standards, 
implementation specifications, and certification criteria as well as 
phasing out certain alternative standards that have been adopted in 
this initial set. Furthermore, we anticipate that the requirements for 
meaningful use will become more demanding over time, and consequently 
that Certified EHR Technology will need to include greater capabilities 
as well as the ability to exchange electronic health information in a 
variety of circumstances with many different types of health 
information technology. Finally, as will be discussed in more detail in 
the HIT Certification Programs proposed rule, it is possible that the 
certification programs established by the National Coordinator could 
certify other types of HIT, perhaps related to certain specialty 
products and personal health records. In order for that to occur, 
specific standards, implementation specifications, and certification 
criteria related to those types of HIT would need to be developed and 
adopted.

II. Overview of the Interim Final Rule

    We are adding a new part, part 170, to title 45 of the Code of 
Federal Regulations (CFR) to adopt the initial set of standards, 
implementation specifications, and certification criteria required by 
section 3004(b)(1) of the PHSA. We describe the standards, 
implementation specifications, and certification criteria adopted by 
the Secretary and the factors that contributed to their adoption. We 
anticipate that adopted standards, implementation specifications, and 
certification criteria will be used to prepare Complete EHRs and EHR 
Modules for testing and certification. In turn, eligible professionals 
and eligible hospitals that wish to position themselves to achieve the 
requirements of meaningful use Stage 1, once finalized, could adopt and 
implement Certified EHR Technology. In drafting this interim final 
rule, we considered the input of the National Committee on Vital and 
Health Statistics, the HIT Policy Committee, and the HIT Standards 
Committee and the public comments received by each committee. We invite 
public comment on this interim final rule and have posed several 
questions on topics for which we are interested in receiving specific 
public comment.

III. Section-By-Section Description of the Interim Final Rule

A. Applicability--Sec.  170.101

    This part establishes the applicable standards, implementation 
specifications, and certification criteria that must be used to test 
and certify HIT.

B. Definitions--Sec.  170.102

1. Definition of Standard
    The term standard is used in many different contexts and for many 
different purposes. The HITECH Act did not define or provide a 
description of the term, standard, or how it should be used in relation 
to HIT. As a result, we looked to other sources to inform our 
definition for the term.
    As specified in the HIPAA Rules, standard is defined at 45 CFR 
160.103 to mean ``a rule, condition, or requirement: (1) Describing the 
following information for products, systems, services or practices: (i) 
Classification of components. (ii) Specification of materials, 
performance, or operations; or (iii) Delineation of procedures; or (2) 
With respect to the privacy of individually identifiable health 
information.'' This definition includes important concepts that we 
believe are applicable and appropriate for this interim final rule and 
we have included these concepts in our definition of standard. Other 
definitions or descriptions of the term standard include ``an 
established policy on a particular practice or method;'' ``a set of 
instructions for performing operations or functions;'' or ``a published 
statement on a topic specifying the characteristics, usually 
measurable, that must be satisfied or achieved to comply with the 
standard.'' \2\
---------------------------------------------------------------------------

    \2\ This last definition is referenced in Federal Information 
Processing Standards 201.
---------------------------------------------------------------------------

    We believe the types of standards envisioned by Congress in the 
HITECH Act that would be most applicable to HIT are standards that are 
technical, functional, or performance-based. For example, a technical 
standard could specify that the structure of a message containing a 
patient's blood test results must include a header, the type of test 
performed, and the results, and further, that message must always be 
put in that sequence and be 128 bits long; a functional standard could 
specify certain actions that must be consistently accomplished by HIT 
such as recording the date and time when an electronic prescription is 
transmitted; and a performance standard could specify certain 
operational requirements for HIT such as being able to properly 
identify a drug-allergy contraindication 99.99% of the time for patient 
safety purposes. With this in mind, we have chosen to define standard 
to mean: a technical, functional, or performance-based rule, condition, 
requirement, or specification that stipulates instructions, fields, 
codes, data, materials, characteristics, or actions.
2. Definition of Implementation Specification
    The term implementation specification is defined at 45 CFR 160.103 
of the HIPAA Rules as ``specific requirements or instructions for 
implementing a standard.'' We believe that this definition conveys 
accurately the meaning of the term as used in the HITECH Act, which 
seeks consistency between these implementation specifications and those 
adopted under HIPAA. Moreover, the concept it applies complements the 
definition of standard adopted in this interim final rule. 
Additionally, this definition is straightforward, easy to understand, 
and is otherwise consistent with our goals. We have therefore adopted 
the HIPAA regulatory definition of implementation specification without 
modification.
3. Definition of Certification Criteria
    The term certification criteria is described at section 
3001(c)(5)(B) of the PHSA to mean ``with respect to standards and 
implementation specifications for health information technology, 
criteria to establish that the technology meets such standards and 
implementation specifications.'' We have incorporated this description 
into our definition of certification criteria described below and 
expanded it to also address how the term is used in various parts of 
the HITECH Act. The definition consequently encompasses more than just 
certification criteria that establish technology meets ``standards and 
implementation specifications.'' In support of meaningful use, for 
instance, there are many other capabilities

[[Page 2022]]

Certified EHR Technology will need to provide under the HITECH Act even 
though such capabilities do not require a particular standard or 
implementation specification. As a result, we believe that it is 
critical for these capabilities to be tested and certified too. To do 
otherwise would potentially make it difficult for eligible 
professionals and eligible hospitals to know whether the Certified EHR 
Technology they have adopted and implemented will support their 
achievement of meaningful use. For example, if we did not require a 
certification criterion for medication reconciliation, a proposed 
meaningful use Stage 1 objective, Certified EHR Technology under this 
scenario would not provide any assurance to an eligible professional or 
eligible hospital that the proposed meaningful use Stage 1 requirement 
could be met. On the other hand, by adopting a certification criterion 
for medication reconciliation in this interim final rule, eligible 
professionals and eligible hospitals can be assured that once they 
adopt and implement Certified EHR Technology, it includes, at a 
minimum, the medication reconciliation capabilities required to support 
their achievement of the proposed meaningful use Stage 1 requirement.
    For these reasons we have defined the term certification criteria 
to encompass both the statutory description and the statutory use of 
the term. The definition consequently also includes other certification 
criteria that are not directly tied to establishing that health 
information technology has met a standard or implementation 
specification. We have therefore defined certification criteria to 
mean: criteria: (1) To establish that health information technology 
meets applicable standards and implementation specifications adopted by 
the Secretary; or (2) that are used to test and certify that health 
information technology includes required capabilities.
4. Definition of Qualified Electronic Health Record (EHR)
    Qualified EHR is defined at section 3000(13) of the PHSA as ``an 
electronic record of health-related information on an individual that: 
(A) Includes patient demographic and clinical health information, such 
as medical history and problem lists; and (B) 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.'' We have adopted the 
statutory definition of Qualified EHR without modification.
5. Definition of EHR Module
    We have defined the term 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. Examples of EHR 
Modules include, but are not limited to, the following:
     An interface or other software program that provides the 
capability to exchange electronic health information;
     An open source software program that enables individuals 
online access to certain health information maintained by EHR 
technology;
     A clinical decision support rules engine;
     A software program used to submit public health 
information to public health authorities; and
     A quality measure reporting service or software program.
    While the use of EHR Modules may enable an eligible professional or 
eligible hospital to create a combination of products and services 
that, taken together, meets the definition of Certified EHR Technology, 
this approach carries with it a responsibility on the part of the 
eligible professional or eligible hospital to perform additional 
diligence to ensure that the certified EHR Modules selected are capable 
of working together to support the achievement of meaningful use. In 
other words, two certified EHR Modules may provide the additional 
capabilities necessary to meet the definition of Certified EHR 
Technology, but may not integrate well with each other or with the 
other EHR technology they were added to. As a result, eligible 
professionals and eligible hospitals that elect to adopt and implement 
certified EHR Modules should take care to ensure that the certified EHR 
Modules they select are interoperable and can properly perform in their 
expected operational environment.
6. Definition of Complete EHR
    The term Complete EHR is used to mean EHR technology that has been 
developed to meet all applicable certification criteria adopted by the 
Secretary. We believe this definition helps to create a clear 
distinction between a Complete EHR, an EHR Module, and Certified EHR 
Technology. The term Complete EHR is not meant to limit the 
capabilities that a Complete EHR can include. Rather, it 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 fully expect some Complete EHRs to have 
capabilities beyond those addressed by certification criteria adopted 
by the Secretary.
7. Definition of Certified EHR Technology
    Certified EHR Technology is defined at section 3000(1) of the PHSA 
as ``a qualified electronic health record that is certified pursuant to 
section 3001(c)(5) as meeting standards adopted under section 3004 that 
are applicable to the type of record involved.'' In this interim final 
rule, we have slightly revised the definition of Certified EHR 
Technology to make it more consistent with the initial standards, 
implementation specifications, and certification criteria that are 
being adopted. Certification criteria focus on the capabilities of 
Complete EHRs or EHR Modules and consequently, Certified EHR Technology 
should be defined in accordance with that approach. We believe defining 
Certified EHR Technology in that manner will provide greater clarity 
and meaning for this interim final rule.
    We have 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.
    To clarify the meaning of ``applicable certification criteria'' in 
this definition's second part, we note that Congress indicated their 
expectation that different types of HIT would be certified. Congress 
elaborated on this expectation with a parenthetical in the statutory 
definition, which references two examples, ``an ambulatory electronic 
health record for office-based physicians'' and ``an inpatient hospital 
electronic health record for hospitals.'' For a variety of reasons, 
including that certain proposed meaningful use Stage 1 objectives only 
apply to an eligible professional or eligible hospital and that these 
two types of health care providers require different capabilities from 
Certified EHR Technology, we have adopted specific certification 
criteria that are only ``applicable'' to Complete EHRs or EHR Modules 
designed for use in an ambulatory setting (e.g., by eligible 
professionals) or an inpatient setting (e.g., by eligible hospitals). 
We indicate in Table 1, and in the regulation text below, which 
certification criteria apply

[[Page 2023]]

solely to Complete EHRs or EHR Modules designed for use in an 
ambulatory setting or an inpatient setting. For example, we do not 
expect Certified EHR Technology that is adopted and implemented by an 
eligible professional to include the capability to create an electronic 
copy of discharge instructions. We do, however, expect Certified EHR 
Technology that is adopted and implemented by an eligible hospital to 
include this capability.
    We believe that by adding the word ``technology'' after ``EHR,'' 
Congress intended to convey an expectation that rather than adopt a 
complete, all-in-one solution, eligible professionals and eligible 
hospitals would likely adopt and implement some number of technological 
components or EHR Modules to extend the useful life of their legacy EHR 
technology or other HIT that may not provide all of the capabilities 
necessary to achieve meaningful use.
    In the early stages of the Medicare and Medicaid EHR Incentive 
Programs, we expect most eligible professionals and many eligible 
hospitals to opt for a Complete EHR that has met the definition of 
Certified EHR Technology. However, with the future in mind, and to 
address those eligible providers and eligible hospitals that may decide 
to implement their own Complete EHRs or EHR Modules, we have adopted a 
definition of Certified EHR Technology that we believe is flexible 
enough to account for innovations in an industry that continues to 
rapidly evolve. Additionally, we believe this definition of Certified 
EHR Technology will lead to a more competitive marketplace and allow 
those who adopt HIT to choose from a variety of offerings ranging from 
subscription services, to vendor-based products, to open source 
products. An innovative and competitive HIT marketplace needs to exist 
much like the marketplace for consumer electronics, where, for the 
purpose of setting up a home theater, a television, DVD player, and 
stereo system can be purchased from three different manufacturers, from 
a single manufacturer, or as a complete system from one manufacturer.
    To that end, we believe that it will be common in the near future 
for Certified EHR Technology to be assembled from several replaceable 
and swappable EHR Modules. For example, an EHR Module specifically 
designed to enable electronic health information exchange may be 
implemented for the purposes of interoperability and participation in a 
health information organization, regional health information 
organization, or some other consortium whose purpose is to enable the 
electronic exchange of health information. As another example, a 
subscription to an application service provider (ASP) for electronic 
prescribing could be an EHR Module and used to help meet the definition 
of Certified EHR Technology provided that the electronic prescribing 
capability the ASP enables has been tested and certified.
    As long as each EHR Module has been separately tested and certified 
in accordance with the certification program established by the 
National Coordinator (which will be discussed in a future rulemaking) 
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.
    The following are examples of Certified EHR Technology:
     A complete EHR that is tested and certified to all 
applicable certification criteria.
     The combination of three certified EHR modules that 
include all of the capabilities required by all applicable 
certification criteria. (We note that in this circumstance it is the 
user's responsibility to determine whether the combination of these 
three certified EHR Modules would meet all of the applicable 
certification criteria necessary to meet the definition of Certified 
EHR Technology.)
    The following are examples of what would not meet the definition of 
Certified EHR Technology:
     Complete EHRs that have not been tested and certified in 
accordance with the certification program established by the National 
Coordinator even though it may be claimed that such technology provides 
the same capabilities as those required by adopted certification 
criteria.
     The combination of three certified EHR modules that do not 
include all of the capabilities required by all applicable 
certification criteria. That is, if these three certified EHR modules 
were purchased by an eligible professional and none of them included 
the capability to electronically prescribe, the combination of these 
three modules would not be a proper combination of certified EHR 
Modules and would not meet the definition of Certified EHR Technology.
    It is important to note that the capabilities included in the 
definition of Qualified EHR set the floor for the capabilities that 
Certified EHR Technology must include. For example, the definition of 
Qualified EHR does not require capabilities related to privacy and 
security; however, the Secretary has adopted certification criteria for 
privacy and security. Therefore, where the Secretary has adopted 
certification criteria that require capabilities beyond those specified 
in the definition of a Qualified EHR, a Complete EHR or EHR Module will 
need to be tested and certified to those adopted certification criteria 
in order for the definition of Certified EHR Technology to be met.
8. Definition of Disclosure
    We define disclosure in this interim final rule to have the same 
meaning specified at 45 CFR 160.103--``the release, transfer, provision 
of access to, or divulging in any other manner of information outside 
the entity holding the information.'' As previously mentioned, once the 
Secretary adopts a standard on accounting for disclosures described in 
section 3002(b)(2)(B)(iv) of the PHSA, the Secretary through the HHS 
Office for Civil Rights, is required to modify (no later than 6 months 
after the date on which the Secretary adopts standards on accounting 
for disclosures) the HIPAA Privacy Rule at 45 CFR 164.528 to require 
that HIPAA covered entities account for disclosures related to 
treatment, payment, and health care operations made through an 
electronic health record and to identify in the regulations the 
information that shall be collected about each of the disclosures.

C. Initial Set of Standards, Implementation Specifications, and 
Certification Criteria Sec. Sec.  170.202, 170.205, 170.210, 170.302, 
170.304, 170.306

    The sections below describe the initial set of standards, 
implementation specifications, and certification criteria adopted by 
the Secretary to support, in part, the achievement of meaningful use 
Stage 1 (which begins in 2011). The standards, implementation 
specifications, and certification criteria adopted are meant to serve 
as the basis for the testing and certification of Complete EHRs and EHR 
Modules and they should in no way be misconstrued as additional 
detailed requirements for meaningful use Stage 1 itself. In order to 
prevent confusion, we believe it is necessary to make clear that the 
standards, implementation specifications, and certification criteria 
adopted by the Secretary in this interim final rule apply to, and 
establish the

[[Page 2024]]

required capabilities for, Certified EHR Technology. These criteria do 
not establish requirements for health care providers, such as eligible 
professionals or eligible hospitals to follow. Because certification 
criteria describe both the required capabilities Certified EHR 
Technology must include and, where applicable, the standard(s) that 
must be used by those capabilities, we discuss adopted certification 
criteria first. Table 1 below displays the certification criteria we 
have adopted. Next we discuss adopted standards and the purposes for 
their use. Tables 2A and 2B include the standards referenced by adopted 
certification criteria for a particular exchange or privacy or security 
purpose. Lastly we discuss our approach to implementation 
specifications.
    To guide our approach to adopting the standards, implementation 
specifications, and certification criteria below, we established the 
following goals:
     Promote interoperability and where necessary be specific 
about certain content exchange and vocabulary standards to establish a 
path forward toward semantic interoperability;
     Support the evolution and timely maintenance of adopted 
standards;
     Promote technical innovation using adopted standards;
     Encourage participation and adoption by all vendors, 
including small businesses;
     Keep implementation costs as low as reasonably possible;
     Consider best practices, experiences, policies, 
frameworks, and the input of the HIT Policy Committee and HIT Standards 
Committee in current and future standards;
     Enable mechanisms such as the NHIN to serve as a test-bed 
for innovation and as an open-source reference implementation of best 
practices; and
     To the extent possible, adopt standards that are modular 
and not interdependent. For example, an adopted vocabulary standard 
would not be tied to a particular content exchange standard (e.g., the 
adoption of Current Procedural Terminology (CPT[supreg]) Fourth Edition 
(CPT-4) codes would not require or preclude the use of a particular 
patient summary record standard such as the continuity of care document 
(CCD) or continuity of care record (CCR)).
1. Adopted Certification Criteria
    At its July 16, 2009 and August 14, 2009 meetings, the HIT Policy 
Committee made recommendations to the National Coordinator on policies 
for meaningful use and the certification of HIT, which the National 
Coordinator has considered. For the purposes of this interim final rule 
and the adoption of an initial set of certification criteria, we 
believe that the meaningful use matrix recommended by the HIT Policy 
Committee as modified in the Medicare and Medicaid EHR Incentive 
Programs proposed rule provides a logical way to structure our 
presentation of adopted certification criteria. Furthermore, we found 
the following recommendations on certification from the HIT Policy 
Committee to be particularly informative for the scope of this interim 
final rule and our approach to adopting certification criteria--that 
certification should focus on meaningful use and be leveraged to 
improve security, privacy, and interoperability. We agree that for this 
initial set of certification criteria, supporting the achievement of 
meaningful use Stage 1, as proposed in the Medicare and Medicaid EHR 
Incentive Programs proposed rule, is a foremost priority. As a result, 
we have adopted, based in part on the HIT Policy Committee's 
recommendation, an initial set of certification criteria to support the 
achievement by eligible professionals and eligible hospitals of 
meaningful use Stage 1, as proposed in the Medicare and Medicaid EHR 
Incentive Programs proposed rule.
    The meaningful use matrix recommended by the HIT Policy Committee, 
a revised form of which CMS has included in the Medicare and Medicaid 
EHR Incentive Programs proposed rule, includes overall health outcome 
policy priorities and health care goals that are the same for eligible 
professionals and eligible hospitals. The health outcome policy 
priorities identified in the Medicare and Medicaid EHR Incentive 
Programs proposed rule are: ``Improving quality, safety, efficiency, 
and reducing health disparities; engage patients and families in their 
health care; improve care coordination; improve population and public 
health; and ensure adequate privacy and security protections for 
personal health information.'' For each policy priority, there are also 
associated health care goals which are described in more detail in the 
Medicare and Medicaid EHR Incentive Programs proposed rule.
    The health care goals served as the bases for the proposed specific 
meaningful use Stage 1 objectives for eligible professionals and 
eligible hospitals set forth in the Medicare and Medicaid EHR Incentive 
Programs proposed rule. We have consequently used the proposed 
objectives in the Medicare and Medicaid EHR Incentive Programs proposed 
rule to identify the initial set of certification criteria adopted in 
this interim final rule and have linked the certification criteria to 
these objectives.
    Many of the proposed meaningful use Stage 1 objectives are exactly 
the same for eligible professionals and eligible hospitals. Where 
proposed meaningful use Stage 1 objectives were identical for eligible 
professionals and eligible hospitals, we adopted identical 
certification criteria for Complete EHRs or EHR Modules. However, there 
are instances where proposed meaningful use Stage 1 objective and 
corresponding meaningful use measure are specifically aimed at an 
eligible professional (e.g., electronic prescribing) or eligible 
hospital (e.g., provision of an electronic copy of discharge 
instructions). Where the proposed meaningful use Stage 1 objectives 
were worded differently or only applied to an eligible professional or 
eligible hospital, we have adopted specific certification criteria to 
assure that Certified EHR Technology includes the capabilities 
necessary to meet that objective.
    Additionally, CMS describes in the Medicare and Medicaid EHR 
Incentive Programs proposed rule a number of the terms referenced in 
this table, specifically those in the first column which align directly 
with the proposed meaningful use Stage 1 objectives. For example, one 
of the proposed meaningful use Stage 1 objectives is to ``perform 
medication reconciliation at relevant encounters and each transition of 
care.'' We have adopted a certification criterion to assure that a 
Complete EHR or EHR Module is capable of performing medication 
reconciliation. However, it is not within the scope of this interim 
final rule to specify when or how often this needs to occur. Rather, 
the proposed meaningful use Stage 1 measure for this proposed objective 
dictates the frequency, and the preamble of the Medicare and Medicaid 
EHR Incentive Programs proposed rule provides descriptions for what is 
meant by ``relevant encounters'' and ``each transition of care.'' We 
encourage any reader seeking the meaning or further explanation of a 
particular term in the objectives to review the Medicare and Medicaid 
EHR Incentive Programs proposed rule.
    To improve the readability of Table 1 and illustrate the linkage 
between adopted certification criteria and proposed meaningful use 
Stage 1 objectives, in instances where the proposed meaningful use 
Stage 1 objective was the same in concept for eligible professionals 
and eligible hospitals but differed slightly with

[[Page 2025]]

respect to wording, we provided a combined objective and referenced the 
full proposed objective in a footnote. All certification criteria are 
prefaced with the statement ``A Complete EHR or EHR Module must include 
the capability to:'' in order to create uniformity in the way each 
certification criterion is read.
    Finally, we understand that certain types of standards, 
specifically code sets, must be maintained and frequently updated to 
serve their intended purpose effectively. Code sets are typically used 
for encoding data elements, such as medical terms, medical concepts, 
diagnoses, and medical procedures. As new medical procedures, 
technologies, treatments, or diagnostic methods are developed or 
discovered, additional codes must be added or existing codes must be 
revised. In some cases, new codes are necessary to reflect the most 
recent changes in medical practice, involving perhaps revised 
medication dosage, updated treatment procedures, or the discovery of 
new diseases. In many cases, the new codes must be disseminated and 
implemented quickly for patient safety and significant public health 
purposes.
    To address this need and accommodate industry practice, we have in 
this interim final rule indicated that certain types of standards will 
be considered a floor for certification. 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. This will also enable Certified EHR 
Technology to be updated from an older, ``minimum,'' adopted version of 
a code set to a more current version without adversely affecting 
Certified EHR Technology's ``certified status.'' We intend to elaborate 
in the upcoming HIT Certification Programs proposed rule on how testing 
and certification would be conducted using standards we have adopted 
and designated as ``minimums'' in certain certification criteria.
    Because we expect to adopt additional code set standards in the 
future, we believe this approach is necessary. Moreover, we believe the 
certification of Complete EHRs and EHR Modules should be flexible 
enough to accommodate current code sets that are regularly maintained 
and updated. We also believe that this approach will enable and 
encourage eligible professionals and eligible hospitals to adopt 
Certified EHR Technology and keep it current, which will promote 
patient safety, public health safety, and more broadly, improve health 
care quality.
    That being said, we understand that this approach has certain 
limitations. In some cases, for instance, rather than simply 
maintaining, correcting, or slightly revising a code set, a code set 
maintaining organization will modify the structure or framework of a 
code set to meet developing industry needs. We would consider this type 
of significant revision to a code set to be a ``modification,'' rather 
than maintenance or a minor update of the code set. An example of a 
code set ``modification'' would be if a hypothetical XYZ code set 
version 1 were to use 7-digit numeric codes to represent health 
information while XYZ code set version 2 used 9-digit alphanumeric 
codes to represent health information. In such cases, interoperability 
would likely be reduced among Complete EHRs and EHR Modules that have 
adopted different versions of the structurally divergent code sets. If 
a code set that we have adopted through incorporation by reference is 
modified significantly, we will update the incorporation by reference 
of the adopted version with the more recent version of the code set 
prior to requiring or permitting certification according to the newer 
version.
    The following provides an example of how our approach will work. A 
proposed meaningful use Stage 1 objective specifies the capability to 
submit electronic data to immunization registries and, accordingly, we 
have adopted a certification criterion to assure that a Complete EHR or 
EHR Module is capable of electronically recording, retrieving, and 
transmitting immunization information to immunization registries in 
accordance with the standards specified in Table 2A row 8. Table 2A row 
8 references, as a vocabulary standard (code set), the CDC maintained 
HL7 standard code set CVX-Vaccines Administered. The current version of 
the CVX code set was published July 30, 2009, and includes new vaccine 
codes related to the ``Novel Influenza-H1N1.'' Continuing our CVX 
example, if the CDC were to publish a new version of CVX on February 1, 
2010, we would permit a Complete EHR or EHR Module to be tested and 
certified according to the minimum adopted version of the standard, the 
July 30, 2009, version of CVX or the February 1, 2010 version that was 
subsequently issued as part of the code set's maintenance.
    For certain certification criteria in Table 1 below, we include a 
percent symbol ``%'' superscript to indicate instances where the 
version of an adopted standard (specified in the regulation text) will 
be ``at a minimum'' the version to which a Complete EHR or EHR Module 
must be tested and certified in order to be considered compliant with 
the adopted standard.

                     Table 1--Certification Criteria
------------------------------------------------------------------------
                                                          Certification
                                Certification criteria     criteria to
                                    to support the         support the
 Proposed meaningful use Stage      achievement of       achievement of
         1 objectives           meaningful use Stage 1   meaningful use
                                      by eligible          Stage 1 by
                                     professionals          eligible
                                                            hospital
------------------------------------------------------------------------
                                    A Complete EHR or EHR Module must
                                        include the capability to:
------------------------------------------------------------------------
Use Computerized Provider       Enable a user to        Enable a user to
 Order Entry (CPOE) \3\.         electronically          electronically
                                 record, store,          record, store,
                                 retrieve, and manage,   retrieve, and
                                 at a minimum, the       manage, at a
                                 following order         minimum, the
                                 types:                  following order
                                                         types:
                                   1. Medications;         1.
                                                            Medications;
                                   2. Laboratory;          2.
                                                            Laboratory;
                                   3. Radiology/           3. Radiology/
                                    imaging; and            imaging;

[[Page 2026]]

 
                                   4. Provider             4. Blood
                                    referrals.              bank;
                                                        5. Physical
                                                         therapy;
                                                        6. Occupational
                                                         therapy;
                                                        7. Respiratory
                                                         therapy;
                                                        8.
                                                         Rehabilitation
                                                         therapy;
                                                        9. Dialysis;
                                                        10. Provider
                                                         consults; and
                                                        11. Discharge
                                                         and transfer.
                               -----------------------------------------
Implement drug-drug, drug-      1. Automatically and electronically
 allergy, drug-formulary         generate and indicate (e.g., pop-up
 checks.                         message or sound) 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 CPOE.
                                2. Enable a user to electronically check
                                 if drugs are in a formulary or
                                 preferred drug list in accordance with
                                 the standard specified in Table 2A row
                                 2.
                                3. Provide certain users with
                                 administrator rights to deactivate,
                                 modify, and add rules for drug-drug and
                                 drug-allergy checking.
                                4. Automatically and electronically
                                 track, record, and generate reports on
                                 the number of alerts responded to by a
                                 user.
Maintain an up-to-date problem  Enable a user to electronically record,
 list of current and active      modify, and retrieve a patient's
 diagnoses based on ICD-9-CM     problem list for longitudinal care
 or SNOMED CT[supreg].           (i.e., over multiple office visits) in
                                 accordance with the applicable
                                 standards\%\ specified in Table 2A row
                                 1.
                               -----------------------------------------
Generate and transmit           Enable a user to        No Associated
 permissible prescriptions       electronically          Proposed
 electronically (eRx).           transmit medication     Meaningful Use
                                 orders                  Stage 1
                                 (prescriptions) for     Objective.
                                 patients in
                                 accordance with the
                                 standards specified
                                 in Table 2A row 3.
                               -----------------------------------------
Maintain active medication      Enable a user to electronically record,
 list.                           modify, and retrieve a patient's active
                                 medication list as well as medication
                                 history for longitudinal care (i.e.,
                                 over multiple office visits) in
                                 accordance with the applicable standard
                                 specified in Table 2A row 1.
                               -----------------------------------------
Maintain active medication      Enable a user to electronically record,
 allergy list.                   modify, and retrieve a patient's active
                                 medication allergy list as well as
                                 medication allergy history for
                                 longitudinal care (i.e., over multiple
                                 office visits).
                               -----------------------------------------
Record demographics 4 5.......  Enable a user to        Enable a user to
                                 electronically          electronically
                                 record, modify, and     record, modify,
                                 retrieve patient        and retrieve
                                 demographic data        patient
                                 including preferred     demographic
                                 language, insurance     data including
                                 type, gender, race,     preferred
                                 ethnicity, and date     language,
                                 of birth.               insurance type,
                                                         gender, race,
                                                         ethnicity, date
                                                         of birth, and
                                                         date and cause
                                                         of death in the
                                                         event of
                                                         mortality.
                               -----------------------------------------
Record and chart changes in     1. Enable a user to electronically
 vital signs:                    record, modify, and retrieve a
 Height...............   patient's vital signs including, at a
 Weight...............   minimum, the height, weight, blood
 Blood pressure.......   pressure, temperature, and pulse.
 Calculate and          2. Automatically calculate and display
 display: BMI.                   body mass index (BMI) based on a
 Plot and display        patient's height and weight.
 growth charts for children 2-  3. Plot and electronically display, upon
 20 years, including BMI.        request, growth charts (height, weight,
                                 and BMI) for patients 2-20 years old.
Record smoking status for       Enable a user to electronically record,
 patients 13 years old or        modify, and retrieve the smoking status
 older.                          of a patient to: current smoker, former
                                 smoker, or never smoked.
Incorporate clinical lab-test   1. Electronically receive clinical
 results into EHR as             laboratory test results in a structured
 structured data.                format and display such results in
                                 human readable format.
                                2. Electronically display in human
                                 readable format any clinical laboratory
                                 tests that have been received with
                                 LOINC[reg] codes.
                                3. Electronically display all the
                                 information for a test report specified
                                 at 42 CFR 493.1291(c)(1) through
                                 (7).\6\
                                4. Enable a user to electronically
                                 update a patient's record based upon
                                 received laboratory test results.
Generate lists of patients by   Enable a user to electronically select,
 specific conditions to use      sort, retrieve, and output a list of
 for quality improvement,        patients and patients' clinical
 reduction of disparities, and   information, based on user-defined
 outreach.                       demographic data, medication list, and
                                 specific conditions.
Report quality measures to CMS  1. Calculate and electronically display
 or the States 7 8.              quality measure results as specified by
                                 CMS or states.
                                2. Enable a user to electronically
                                 submit calculated quality measures in
                                 accordance with the standard specified
                                 in Table 2A row 5.

[[Page 2027]]

 
Send reminders to patients per  Electronically          No Associated
 patient preference for          generate, upon          Proposed
 preventive/follow up care.      request, a patient      Meaningful Use
                                 reminder list for       Stage 1
                                 preventive or follow-   Objective.
                                 up care according to
                                 patient preferences
                                 based on demographic
                                 data, specific
                                 conditions, and/or
                                 medication list.
                               -----------------------------------------
Implement 5 clinical decision   1. Implement            1. Implement
 support rules 9 10.             automated, electronic   automated,
                                 clinical decision       electronic
                                 support rules (in       clinical
                                 addition to drug-drug   decision
                                 and drug-allergy        support rules
                                 contraindication        (in addition to
                                 checking) according     drug-drug and
                                 to specialty or         drug-allergy
                                 clinical priorities     contraindicatio
                                 that use demographic    n checking)
                                 data, specific          according to a
                                 patient diagnoses,      high priority
                                 conditions,             hospital
                                 diagnostic test         condition that
                                 results and/or          use demographic
                                 patient medication      data, specific
                                 list.                   patient
                                                         diagnoses,
                                                         conditions,
                                                         diagnostic test
                                                         results and/or
                                                         patient
                                                         medication
                                                         list.
                                2. Automatically and    2. Automatically
                                 electronically          and
                                 generate and indicate   electronically
                                 (e.g., pop-up message   generate and
                                 or sound) in real-      indicate (e.g.,
                                 time, alerts and care   pop-up message
                                 suggestions based       or sound) in
                                 upon clinical           real-time,
                                 decision support        alerts and care
                                 rules and evidence      suggestions
                                 grade.                  based upon
                                                         clinical
                                                         decision
                                                         support rules
                                                         and evidence
                                                         grade.
                                3. Automatically and    3. Automatically
                                 electronically track,   and
                                 record, and generate    electronically
                                 reports on the number   track, record,
                                 of alerts responded     and generate
                                 to by a user.           reports on the
                                                         number of
                                                         alerts
                                                         responded to by
                                                         a user.
                               -----------------------------------------
Check insurance eligibility     Enable a user to electronically record
 electronically from public      and display patients' insurance
 and private payers.             eligibility, and submit insurance
                                 eligibility queries to public or
                                 private payers and receive an
                                 eligibility response in accordance with
                                 the applicable standards specified in
                                 Table 2A row 4.
Submit claims electronically    Enable a user to electronically submit
 to public and private payers.   claims to public or private payers in
                                 accordance with the applicable
                                 standards specified in Table 2A row 4.
                               -----------------------------------------
Provide patients with an        Enable a user to        Enable a user to
 electronic copy of their        create an electronic    create an
 health information upon         copy of a patient's     electronic copy
 request 11 12.                  clinical information,   of a patient's
                                 including, at a         clinical
                                 minimum, diagnostic     information,
                                 test results, problem   including, at a
                                 list, medication        minimum,
                                 list, medication        diagnostic test
                                 allergy list,           results,
                                 immunizations, and      problem list,
                                 procedures in: (1)      medication
                                 Human readable          list,
                                 format; and (2)         medication
                                 accordance with the     allergy list,
                                 standards\%\            immunizations,
                                 specified in Table 2A   discharge
                                 row 1 to provide to a   summary, and
                                 patient on electronic   procedures in:
                                 media, or through       (1) Human
                                 some other electronic   readable
                                 means.                  format; and (2)
                                                         accordance with
                                                         the
                                                         standards\%\
                                                         specified in
                                                         Table 2A row 1
                                                         to provide to a
                                                         patient on
                                                         electronic
                                                         media, or
                                                         through some
                                                         other
                                                         electronic
                                                         means.
Provide patients with an        No Associated Proposed  Enable a user to
 electronic copy of their        Meaningful Use Stage    create an
 discharge instructions and      1 Objective.            electronic copy
 procedures at time of                                   of the
 discharge, upon request.                                discharge
                                                         instructions
                                                         and procedures
                                                         for a patient,
                                                         in human
                                                         readable
                                                         format, at the
                                                         time of
                                                         discharge to
                                                         provide to a
                                                         patient on
                                                         electronic
                                                         media, or
                                                         through some
                                                         other
                                                         electronic
                                                         means.
Provide patients with timely    Enable a user to        No Associated
 electronic access to their      provide patients with   Proposed
 health information (including   online access to        Meaningful Use
 lab results, problem list,      their clinical          Stage 1
 medication lists, allergies)    information,            Objective.
 within 96 hours of the          including, at a
 information being available     minimum, lab test
 to the eligible professional.   results, problem
                                 list, medication
                                 list, medication
                                 allergy list,
                                 immunizations, and
                                 procedures.
Provide clinical summaries for  1. Enable a user to     No Associated
 patients for each office        provide clinical        Proposed
 visit.                          summaries to patients   Meaningful Use
                                 (in paper or            Stage 1
                                 electronic form) for    Objective.
                                 each office visit
                                 that include, at a
                                 minimum, diagnostic
                                 test results,
                                 medication list,
                                 medication allergy
                                 list, procedures,
                                 problem list, and
                                 immunizations.
                                2. If the clinical
                                 summary is provided
                                 electronically (i.e.,
                                 not printed), it must
                                 be provided in: (1)
                                 Human readable
                                 format; and (2)
                                 accordance with the
                                 standards\%\
                                 specified in Table 2A
                                 row 1 to provide to a
                                 patient on electronic
                                 media, or through
                                 some other electronic
                                 means.

[[Page 2028]]

 
Capability to exchange key      1. Electronically       1.
 clinical information among      receive a patient       Electronically
 providers of care and patient   summary record, from    receive a
 authorized entities             other providers and     patient summary
 electronically 13 14.           organizations           record, from
Provide summary care record      including, at a         other providers
 for each transition of care     minimum, diagnostic     and
 and referral.                   test results, problem   organizations
                                 list, medication        including, at a
                                 list, medication        minimum,
                                 allergy list,           discharge
                                 immunizations, and      summary,
                                 procedures and upon     diagnostic test
                                 receipt of a patient    results,
                                 summary record          problem list,
                                 formatted in an         medication
                                 alternative standard    list,
                                 specified in Table 2A   medication
                                 row 1, displaying it    allergy list,
                                 in human readable       immunizations,
                                 format.                 and procedures
                                2. Enable a user to      and upon
                                 electronically          receipt of a
                                 transmit a patient      patient summary
                                 summary record to       record
                                 other providers and     formatted in an
                                 organizations           alternative
                                 including, at a         standard
                                 minimum, diagnostic     specified in
                                 test results, problem   Table 2A row 1,
                                 list, medication        displaying it
                                 list, medication        in human
                                 allergy list,           readable
                                 immunizations, and      format.
                                 procedures in          2. Enable a user
                                 accordance with the     to
                                 standards\%\            electronically
                                 specified in Table 2A   transmit a
                                 row 1.                  patient summary
                                                         record, to
                                                         other providers
                                                         and
                                                         organizations
                                                         including, at a
                                                         minimum,
                                                         discharge
                                                         summary,
                                                         diagnostic test
                                                         results,
                                                         problem list,
                                                         medication
                                                         list,
                                                         medication
                                                         allergy list,
                                                         immunizations,
                                                         and procedures
                                                         in accordance
                                                         with the
                                                         standards\%\
                                                         specified in
                                                         Table 2A row 1.
                               -----------------------------------------
Perform medication              Electronically complete medication
 reconciliation at relevant      reconciliation of two or more
 encounters and each             medication lists (compare and merge)
 transition of care.             into a single medication list that can
                                 be electronically displayed in real-
                                 time.
Capability to submit            Electronically record, retrieve, and
 electronic data to              transmit immunization information to
 immunization registries and     immunization registries in accordance
 actual submission where         with the standards\%\ specified in
 required and accepted.          Table 2A row 8 or in accordance with
                                 the applicable state-designated
                                 standard format.
                               -----------------------------------------
Capability to provide           No Associated Proposed  Electronically
 electronic submission of        Meaningful Use Stage    record,
 reportable lab results (as      1 Objective.            retrieve, and
 required by state or local                              transmit
 law) to public health                                   reportable
 agencies and actual                                     clinical lab
 submission where it can be                              results to
 received.                                               public health
                                                         agencies in
                                                         accordance with
                                                         the
                                                         standards\%\
                                                         specified in
                                                         Table 2A row 6.
                               -----------------------------------------
Capability to provide           Electronically record, retrieve, and
 electronic syndromic            transmit syndrome-based (e.g.,
 surveillance data to public     influenza like illness) public health
 health agencies and actual      surveillance information to public
 transmission according to       health agencies in accordance with the
 applicable law and practice.    standards specified in Table 2A row 7.
Protect electronic health       1. Assign a unique name and/or number
 information created or          for identifying and tracking user
 maintained by the certified     identity and establish controls that
 EHR technology through the      permit only authorized users to access
 implementation of appropriate   electronic health information.
 technical capabilities.        2. Permit authorized users (who are
                                 authorized for emergency situations) to
                                 access electronic health information
                                 during an emergency.
                                3. Terminate an electronic session after
                                 a predetermined time of inactivity.
                                4. Encrypt and decrypt electronic health
                                 information according to user-defined
                                 preferences (e.g., backups, removable
                                 media, at log-on/off) in accordance
                                 with the standard specified in Table 2B
                                 row 1.
                                5. Encrypt and decrypt electronic health
                                 information when exchanged in
                                 accordance with the standard specified
                                 in Table 2B row 2.
                                6. Record actions (e.g., deletion)
                                 related to electronic health
                                 information in accordance with the
                                 standard specified in Table 2B row 3
                                 (i.e., audit log), provide alerts based
                                 on user-defined events, and
                                 electronically display and print all or
                                 a specified set of recorded information
                                 upon request or at a set period of
                                 time.
                                7. Verify that electronic health
                                 information has not been altered in
                                 transit and detect the alteration and
                                 deletion of electronic health
                                 information and audit logs in
                                 accordance with the standard specified
                                 in Table 2B row 4.
                                8. Verify that a person or entity
                                 seeking access to electronic health
                                 information is the one claimed and is
                                 authorized to access such information.
                                9. Verify that a person or entity
                                 seeking 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 Table 2B row 5.
                                10. Record disclosures made for
                                 treatment, payment, and health care
                                 operations in accordance with the
                                 standard specified in Table 2B row 6.
------------------------------------------------------------------------

    We reiterate that adopted certification criteria identify the 
required capabilities for a Complete EHR or EHR Module to be certified. 
Adopted certification criteria do not apply to, or require actions by, 
eligible professionals or eligible hospitals. For example, to be 
certified, a Complete EHR or EHR Module must be capable of plotting and 
displaying growth charts for patients. By

[[Page 2029]]

being tested and certified, a Complete EHR or EHR Module will have 
demonstrated that this capability is available for an eligible 
professional or eligible hospital to use.
---------------------------------------------------------------------------

    \3\ For eligible hospitals the full proposed meaningful use 
Stage 1 objective is: ``Use CPOE for orders (any type) directly 
entered by authorizing provider (for example, MD, DO, RN, PA, NP).''
    \4\ For eligible professionals the full proposed meaningful use 
Stage 1 objective is: ``record demographics: preferred language, 
insurance type, gender, race, ethnicity, date of birth.''
    \5\ For eligible hospitals the full proposed meaningful use 
Stage 1 objective is: ``record demographics: preferred language, 
insurance type, gender, race, ethnicity, date of birth, date and 
cause of death in the event of mortality.''
    \6\ 42 CFR 493.1291(b) specifies that ``[t]he test report 
information maintained as part of the patient's chart or medical 
record must be readily available to the laboratory and to CMS or a 
CMS agent upon request.'' 42 CFR 493.1291(c) specifies the required 
test report information.
    \7\ For eligible professionals the full proposed meaningful use 
Stage 1 objective is ``Report ambulatory quality measures to CMS or 
the States.''
    \8\ For eligible hospitals the full proposed meaningful use 
Stage 1 objective is ``Report hospital quality measures to CMS or 
the States.''
    \9\ For eligible professionals the full proposed meaningful use 
Stage 1 objective is ``Implement 5 clinical decision support rules 
relevant to specialty or high clinical priority, including 
diagnostic test ordering, along with the ability to track compliance 
with those rules''
    \10\ For eligible hospitals the full proposed meaningful use 
Stage 1 objective is ``Implement 5 clinical decision support rules 
related to a high priority hospital condition, including diagnostic 
test ordering, along with the ability to track compliance with those 
rules''
    \11\ For eligible professionals the full proposed meaningful use 
Stage 1 objective is ``Provide patients with an electronic copy of 
their health information (including diagnostic test results, problem 
list, medication lists, allergies), upon request''
    \12\ For eligible hospitals the full proposed meaningful use 
Stage 1 objective is ``Provide patients with an electronic copy of 
their health information (including diagnostic test results, problem 
list, medication lists, allergies, discharge summary, procedures), 
upon request''
    \13\ For eligible professionals the full proposed meaningful use 
Stage 1 objective is ``Capability to exchange key clinical 
information (for example problem list, medication list, allergies, 
diagnostic test results) among providers of care and patient 
authorized entities electronically.''
    \14\ For eligible hospitals the full proposed meaningful use 
Stage 1 objective is ``Capability to exchange key clinical 
information (for example discharge summary, procedures, problem 
list, medication list, allergies, diagnostic test results) among 
providers of care and patient authorized entities electronically.''
---------------------------------------------------------------------------

    In adopting these certification criteria, we attempted to balance 
specificity with flexibility and the opportunity for innovation. 
However, in taking this approach we recognize that certain tradeoffs 
exist. On one hand, we anticipate that flexibility will allow Complete 
EHRs and EHR Modules to evolve over time to meet these criteria in 
increasingly efficient, useable, and innovative ways. On the other 
hand, any lack of specificity concerning the capabilities Complete EHRs 
or EHR Modules must include risks the possibility that Certified EHR 
Technology may inadequately support an eligible professional or 
eligible hospital's attempt to achieve meaningful use Stage 1, once 
finalized. Therefore, we request public comment on whether any of the 
adopted certification criteria above are insufficiently specific to be 
used to test and certify Complete EHRs or EHR Modules with reasonable 
assurance that the technology will effectively support the delivery of 
health care as well as the achievement of meaningful use Stage 1, once 
finalized.
2. Adopted Standards
    In fulfilling the Secretary's responsibility under section 
3004(b)(1), the following initial set of standards and implementation 
specifications have been adopted \15\ for use in Certified EHR 
Technology to support proposed meaningful use Stage 1 and to enable 
increased interoperability and privacy and security. We have organized 
adopted standards into the same four categories recommended by the HIT 
Standards Committee.
---------------------------------------------------------------------------

    \15\ Per section 3004(b)(1), we believe the standards adopted 
address all applicable ``areas required for consideration'' under 
section 3002(b)(2)(B)--the HIT Policy Committee required areas 
described above in Section I of this interim final rule.
---------------------------------------------------------------------------

     Vocabulary Standards (i.e., standardized nomenclatures and 
code sets used to describe clinical problems and procedures, 
medications, and allergies);
     Content Exchange Standards (i.e., standards used to share 
clinical information such as clinical summaries, prescriptions, and 
structured electronic documents);
     Transport Standards (i.e., standards used to establish a 
common, predictable, secure communication protocol between systems); 
and
     Privacy and Security Standards (e.g., authentication, 
access control, transmission security) which relate to and span across 
all of the other types of standards.
    As demonstrated by the adopted certification criteria, we expect 
Certified EHR Technology to be tested and certified as being capable of 
complying with adopted standards. We note that there are not standards 
required for every certification criterion adopted by this interim 
final rule. However, we have required standards as part of certain 
certification criteria when their adoption could lead to increased 
interoperability and privacy and security. We agree with the HIT Policy 
Committee's recommendation to focus on these two areas and believe they 
are the most important to emphasize for this initial set of standards. 
We discuss the adopted interoperability standards directly below and 
the adopted privacy and security standards in section III.C.2.c.
    With respect to interoperability standards we have, after 
considering the recommendations of the HIT Standards Committee, chosen 
to adopt alternative standards for certain purposes. Also, at the 
recommendation of the HIT Standards Committee, we have limited the 
adoption of specific vocabulary standards in this initial set to a few, 
important instances.
    Presently, we have only adopted a limited number of certification 
criteria that require Certified EHR Technology to be capable of using a 
specific vocabulary or code set. In certain instances, because of other 
HHS regulatory requirements, we have adopted those vocabularies and 
code sets with which the regulated community is already required to 
comply. We expect future stages of meaningful use will require 
Certified EHR Technology to provide additional capabilities as well as 
an increased capacity to exchange electronic health information 
according to specific vocabularies and code sets. To enhance 
interoperability, we believe it will be essential to adopt specific 
standards, vocabularies, and code sets in the future. We look forward 
to receiving recommendations from the HIT Standards Committee related 
to specific vocabularies and code sets to support future stages of 
meaningful use.
    The initial set of standards and implementation specifications in 
this interim final rule was adopted to support the proposed 
requirements for meaningful use Stage 1. We have added a column in 
Table 2A to illustrate the standards that we believe Certified EHR 
Technology should most likely be capable of to support meaningful use 
Stage 2 (although as explained in the Medicare and Medicaid EHR 
Incentives Program proposed rule, CMS intends to engage in rulemaking 
to adopt Stage 2 criteria for meaningful use and ONC would adopt 
standards consistent with this effort). We developed this list of 
candidate Stage 2 standards by considering the recommendations made by 
the HIT Standards Committee related to standards to support meaningful 
use Stage 2 and developing our own estimates of what it would take to 
advance interoperability. We have added a column in Table 2A to 
illustrate the standards that we believe should be included in 
Certified EHR Technology to support meaningful use Stage 2. With the 
exception of standards that are tied to other HHS regulatory 
requirements, this additional column represents our best estimate and 
does not in any way imply the Secretary's adoption of these standards 
or limit the Secretary's discretion to adopt different standards in the 
future. We look forward to receiving recommendations from the HIT 
Standards Committee to advance interoperability in line with these 
estimates and welcome comments on

[[Page 2030]]

the industry's ability to implement these candidate standards in time 
to support meaningful use Stage 2 (which is proposed to begin in 2013).
    As an example of our future expectations, currently adopted 
certification criteria do not require the use of the vocabulary 
standard, RxNorm. However, RxNorm maintains links from the RxNorm 
concept unique identifier (CUI) to the corresponding drug codes in 
other vocabularies. While we have not adopted RxNorm as a standard in 
this initial set, we have adopted as a standard for medication 
information the use of a vocabulary the National Library of Medicine 
has identified as an RxNorm drug data source provider with a complete 
data set integrated within RxNorm (additional detail regarding this 
standard is provided below). We believe this standard will establish an 
important bridge to full RxNorm adoption and will help facilitate this 
transition over time. We anticipate adopting certification criteria 
that requires Certified EHR Technology be capable of using the RxNorm 
superset in its entirety to support meaningful use Stage 2 and look 
forward to HIT Standards Committee recommendations in this regard.
    As another example, we have adopted a certification criterion that 
requires Certified EHR Technology to be capable of receiving a message 
with Logical Observation Identifiers Names and Codes (LOINC[supreg]) 
codes from a laboratory, retaining those LOINC[supreg] codes, and using 
LOINC[supreg] codes to populate a patient summary record. We do not 
require Certified EHR Technology to be capable of mapping all 
laboratory orders or tests to LOINC[supreg] codes. Rather, we require 
that Certified EHR Technology be capable of using LOINC[supreg] codes 
that are received and retained to populate a patient summary record. 
Moreover, having LOINC[supreg] codes used internally for meaningful use 
Stage 1 will prepare Certified EHR Technology for any future potential 
meaningful use Stage 2 requirements. We believe the use of 
LOINC[supreg], Systematized Nomenclature of Medicine Clinical Terms 
(SNOMED CT[supreg]), and other vocabulary standards will accelerate the 
adoption and use of clinical decision support. Requiring LOINC[supreg] 
as a vocabulary standard that Certified EHR Technology must have the 
capability to support for meaningful use Stage 1 provides an 
incremental approach to achieving these future goals.
    A final example would be, if an eligible professional uses 
Certified EHR Technology that has implemented the continuity of care 
document (CCD) standard for the exchange of a patient summary record 
and receives a patient summary record formatted in the continuity of 
care record (CCR) standard, their Certified EHR Technology must be 
capable of interpreting the information within the CCR message and 
displaying it in human readable format. We do not expressly state how 
this should be accomplished or in what format human readable 
information should be displayed (e.g., information in a CCR message 
could be converted to a text file or PDF). We only require that 
Certified EHR Technology must be capable of performing this function. 
We believe this requirement is critical and have included it to allow 
flexibility in the marketplace during meaningful use Stage 1 and to 
prevent good faith efforts to exchange information from going to waste 
(i.e., information is exchanged, but is unreadable to both Certified 
EHR Technology (machine readable) and humans).
    We discuss in more detail below the four categories identified 
above and the standards adopted for each. At the end of this section we 
provide in Table 2A the standards adopted for certain exchange purposes 
to support meaningful use Stage 1, as proposed in the Medicare and 
Medicaid EHR Incentive Programs proposed rule, as well as those 
candidate standards we believe should be adopted and required in 
certification criteria to support meaningful use Stage 2.
    Finally, and consistent with the National Technology Transfer and 
Advancement Act of 1995 (NTTAA) (15 U.S.C. 3701 et seq.) and OMB 
Circular A-119 \16\ (the circular), we have adopted voluntary consensus 
standards wherever practical. We have noted with a superscript ``+'' 
(plus sign) those standards that are not voluntary consensus standards. 
Both the NTTAA and the Circular require Federal agencies to use 
technical standards that are developed or adopted by voluntary 
consensus standards bodies, using such technical standards as a means 
to carry out policy objectives or activities. Federal agencies, 
however, are not required to use such standards if doing so would be 
``inconsistent with applicable law or otherwise impractical.'' In those 
instances in which we have not used voluntary consensus standards, we 
determined that to do so would be impractical for two principal 
reasons. First, in most cases a voluntary consensus standard that could 
meet the requisite technical goals was simply unavailable. Second, to 
the extent that 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 
marketplace. We solicit comment on our approach and the availability of 
voluntary consensus standards that may be viable alternatives to any of 
the non-voluntary consensus standards we have adopted.
---------------------------------------------------------------------------

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

a. Transport Standards
    With respect to transport standards, we have adopted Simple Object 
Access Protocol (SOAP) version 1.2 and Representational state transfer 
(REST) to provide standard ways for systems to interact with each 
other. SOAP and REST are discussed in more detail below. These 
standards are widely used and implemented by the HIT industry and were 
also recommended by the HIT Standards Committee. We understand that the 
industry is already exploring other standards beyond SOAP and REST, and 
we look forward to receiving recommendations from the HIT Standards 
Committee in this regard to help enable innovation in the marketplace 
rather than constrain it.
    We recognize, out of the four categories of standards identified 
above, that the term ``transport standard'' may be used by others to 
refer to what we have called a ``content exchange standard.'' In the 
interest of retaining the categories recommended by the HIT Standards 
Committee and to avoid further confusion, we have chosen this 
categorization and believe the following distinction can be made to 
clarify the meaning of the two terms in this interim final rule. 
Transport standards are not domain specific while content exchange 
standards are. That is, SOAP and REST can be used by other industries 
to exchange information while the CCD, for example, is specifically 
designed for the exchange of health information.
    SOAP, originally defined as ``Simple Object Access Protocol'', is a 
protocol specification for exchanging structured information in the 
implementation of Web Services in computer networks. It relies on 
Extensible Markup Language (XML) as its message format, and usually 
relies on other Application Layer protocols (most notably Remote 
Procedure Call (RPC) and HyperText Transfer Protocol (HTTP)) for 
message negotiation and transmission. SOAP can form the foundation 
layer of a web services protocol stack, providing a basic messaging 
framework upon which web services can be built. The SOAP architecture 
consists of several layers of

[[Page 2031]]

specifications for message format, message exchange patterns (MEP), 
underlying transport protocol bindings, message processing models, and 
protocol extensibility. SOAP was adopted because it is widely used and 
versatile enough to allow for the use of different transport protocols, 
is platform independent, and is language independent.
    REST is a style of software architecture for distributed hypermedia 
systems such as the Internet. Systems which follow REST principles are 
often referred to as ``RESTful''. An important concept in REST is the 
existence of Web resources (sources of specific information), each of 
which is referenced with a global identifier (e.g., a Uniform Resource 
Identifier or URI in HTTP). In order to manipulate these resources, 
``components'' of the network (user agents and origin servers) 
communicate via a standardized interface (e.g., HTTP) and exchange 
``representations'' of these resources (the actual documents conveying 
the information). A RESTful web service is a simple web service 
implemented using HTTP and the principles of REST.
b. Content Exchange and Vocabulary Standards
i. Patient Summary Record
    With respect to meaningful use Stage 1, Certified EHR Technology 
will be required to be certified as being capable of (1) using the 
Health Level Seven (HL7) Clinical Document Architecture (CDA) Release 2 
(R2) Level 2 CCD or ASTM CCR to electronically exchange a patient 
summary record; and 2) upon receipt of a patient summary record 
formatted in an alternative standard, displaying it in human readable 
format. An HL7 CCD Level 2 allows the body of the CCD to be either 
structured XML text, or unstructured text, and provides backward 
compatibility to CCD Level 1 documents as well as a migration path to 
the more complex HL7 Version 3 reference information model (RIM) based 
information found in CCD Level 3.
    For the purposes of industry readiness and to further 
interoperability in a stepwise fashion, we have decided to adopt these 
two content exchange standards as alternatives. We firmly believe one 
patient summary record standard should be adopted to support meaningful 
use Stage 2 and beyond. We believe that this is necessary to improve 
patient care and access to health information as well as 
interoperability in general. We expect the industry to move toward a 
single standard for patient summary records in the near future and 
potentially in time to support meaningful use Stage 2. We welcome 
public comments regarding these alternatives and specifically comments 
that can address the HIT industry's readiness to move to a single 
standard. We also look forward to receiving recommendations from the 
HIT Standards Committee in this regard.
    With respect to the vocabulary standards for use within a patient 
summary record, and in support of proposed meaningful Stage 1 
objectives, we expect the following fields to be populated: problem 
list; medication list; medication allergy list; procedures; vital 
signs; units of measure; lab orders and results; and, where 
appropriate, discharge summary. At this time, the Secretary has only 
adopted standards related to the use of International Classification of 
Diseases, 9th Revision, Clinical Modifications (ICD-9-CM) or SNOMED 
CT[supreg] to populate a problem list and ICD-9-CM or American Medical 
Association (AMA) Current Procedural Terminology (CPT[supreg]) Fourth 
Edition (CPT-4) to populate information related to procedures. For 
medication lists, we have adopted a standard that requires the use of 
codes from a drug vocabulary the National Library of Medicine has 
identified as an RxNorm drug data source provider with a complete data 
set integrated within RxNorm.\17\ For lab results, we have adopted a 
standard that requires the use of LOINC[supreg] to populate information 
in a patient summary record related to lab orders and results when 
LOINC[supreg] codes have been received from a laboratory and are 
retained and subsequently available to Certified EHR Technology. In 
instances where LOINC[supreg] codes have not been received from a 
laboratory, the use of any local or proprietary code is permitted 
(i.e., we do not require these local or proprietary codes to be 
converted to LOINC[supreg] codes in order to populate a patient summary 
record). Apart from the standards specified above, we do not specify 
the types of vocabularies or code sets that could potentially be used 
to populate the remaining fields of a patient summary record. As shown 
in Table 2A, we anticipate adopting vocabulary standards for many of 
the fields above to support meaningful use Stage 2. For example, we 
have not identified any code sets for medication allergies, but we 
believe there is value to integrating both medication and non-
medication related allergies using a common standard, and in providing 
ingredient-based medication allergies. These requirements would be 
satisfied through the use of the UNII standard (referenced as a 
candidate Stage 2 standard in Table 2A). We request public comment on 
the standard we have adopted to populate medication list information.
---------------------------------------------------------------------------

    \17\ According to the most recent RxNorm Release Documentation 
File Full Release (11/2/09) published by the National Library of 
Medicine, the following RxNorm drug data source providers with a 
complete data set integrated within RxNorm are identified at the end 
of section 11.1 located at http://www.nlm.nih.gov/research/umls/rxnorm/docs/2009/rxnorm_doco_full11022009.html GS--10/01/2009 
(Gold Standard Alchemy); MDDB--10/07/2009 (Master Drug Data Base. 
Medi-Span, a division of Wolters Kluwer Health); MMSL--10/01/2009 
(Multum MediSource Lexicon); MMX--09/28/2009 (Micromedex DRUGDEX); 
MSH--08/17/2009 (Medical Subject Headings (MeSH)); MTHFDA--8/28/2009 
(FDA National Drug Code Directory); MTHSPL--10/28/2009 (FDA 
Structured Product Labels); NDDF--10/02/2009 (First DataBank NDDF 
Plus Source Vocabulary); SNOMED CT--07/31/2009 (SNOMED Clinical 
Terms (drug information) SNOMED International); VANDF--10/07/2009 
(Veterans Health Administration National Drug File). We note that 
FDA Unique Ingredient Identifiers (UNII) are a component of RxNorm.
---------------------------------------------------------------------------

ii. Drug Formulary Check
    For the purposes of performing a drug formulary check, Certified 
EHR Technology must be capable of using NCPDP Formulary & Benefits 
Standard 1.0 adopted by HHS (73 FR 18918) in order to ensure in 
circumstances where an eligible professional or eligible hospital 
electronically prescribes a Part D drug for a Medicare Part D eligible 
individual, he/she can maintain compliance with applicable law. We are 
adopting this standard also to meet one of the proposed meaningful use 
Stage 1 objectives, which seeks to have an automated formulary check as 
a capability provided by Certified EHR Technology so that formulary and 
benefit information can be readily provided to advise an eligible 
professional or eligible hospital's decisions in prescribing drugs to a 
patient.
iii. Electronic Prescribing
    For the purposes of electronic prescribing, Certified EHR 
Technology must be capable of using NCPDP SCRIPT 8.1 or NCPDP SCRIPT 
8.1 and 10.6. SCRIPT 8.1 is the current standard adopted by HHS for 
specified transactions involving the communication of a prescription or 
prescription-related information between prescribers and dispensers in 
the Medicare Part D electronic prescribing drug program. While it is 
not recognized as such at this time, we expect that SCRIPT 10.6 will be 
a permitted backwards compatible alternative by the start of meaningful 
use Stage 1. Moreover, if SCRIPT 10.6 is permitted, prior to any 
modification of the provisions of this interim final rule in response 
to public comment, we

[[Page 2032]]

would expect to change our requirement to simply permit either SCRIPT 
8.1 or SCRIPT 10.6. Again, with respect to a vocabulary standard, we 
have adopted a standard that requires the use of codes from a drug 
vocabulary currently integrated into the RxNorm (see detailed 
description above). We believe that adopting RxNorm in the future will 
lead to improved interoperability and look forward to receiving 
recommendations from the HIT Standards Committee in this regard.
iv. Administrative Transactions
    For the purposes of conducting certain administrative transactions, 
Certified EHR Technology must be capable of using applicable HIPAA 
transaction standards and Medicare Part D standards adopted by the 
Secretary. This includes at least the following Accredited Standards 
Committee (ASC) X12N Subcommittee standards or NCPDP standards for the 
relevant covered transactions. Because the HIPAA transactions standards 
regulations reference the transaction standards together with the 
``implementation guides,'' which are comprised of implementation 
specifications, we have chosen to identify the adopted standards and 
implementation specifications associated with these HIPAA transaction 
standards together rather than separately in section III.C.3 below. In 
adopting these standards and the implementation specifications, we have 
referenced the CFR locations where they have been adopted for the 
relevant HIPAA transactions, and as a result the certification criteria 
will track the adopted HIPAA transactions standards requirements. 
Consequently, as the HIPAA transaction standards are updated or 
modified, Complete EHRs or EHR Modules will be certified consistently 
with the current HIPAA transaction standards requirements. We intend, 
to the extent possible, to assure that Certified EHR Technology will 
enable covered entities to conduct HIPAA covered transactions as 
``standard transactions,'' as that term is defined in 45 CFR 162.103.
    However, in pursuing this approach we note that in accordance with 
45 CFR 162.1102 and 45 CFR 162.1202, the Secretary currently permits 
the use of two versions of ASC X12N and NCPDP standards (Versions 4010/
4010A and 5010 and Versions 5.1 and D.0, respectively) until December 
31, 2011, at which point only the most recently adopted HIPAA 
transaction standards will be permitted (74 FR 3296). Unlike the 
effective date for ICD-10-CM and ICD-10-PCS which is set for October 1, 
2013, placing compliance within meaningful use Stage 2, the 5010 and 
D.0 HIPAA transaction standards are required to be used in the second 
year of meaningful use Stage 1. Consequently, in order for eligible 
professionals and eligible hospitals that adopt Certified EHR 
Technology to remain in compliance with the law for conducting certain 
administrative transactions, Certified EHR Technology must be capable 
of using both versions of applicable adopted HIPAA transaction 
standards.
     For retail pharmacy drugs and dental, professional, and 
institutional health care eligibility benefit inquiry and response 
transactions (as defined at 45 CFR 162.1201) Certified EHR must be 
capable of using the following standards:
    [cir] NCPDP Telecommunications Standards Implementation Guide, 
Version 5, Release 1 (Version 5.1), and Version D, Release 0 (Version 
D.0) equivalent NCPDP Batch Standards Batch Implementation Guide, 
Versions 1.1 and 1.2; and
    [cir] ASC X12N 270/271--Health Care Eligibility Benefit Inquiry and 
Response, Version 4010 (004010X092) and Addenda to Health Care 
Eligibility Benefit Inquiry and Response (004010X092A1) as well as ASC 
X12 Standards for Electronic Data Interchange Technical Report Type 3, 
Version 5010 (ASC X12N/005010X279).
     For retail pharmacy drugs and dental, professional, and 
institutional health care claims or equivalent encounter information 
transaction (as defined at 45 CFR 162.1101):
    [cir] NCPDP Telecommunications Standards Implementation Guide, 
Version 5, Release 1 (Version 5.1), and Version D, Release 0 (Version 
D.0) equivalent NCPDP Batch Standards Batch Implementation Guide, 
Versions 1.1 and 1.2; and
    [cir] ASC X12N 837--Health Care Claim: Dental--Version 4010 
(004010X097) and Addenda to Health Care Claim: Dental, Version 4010 
(004010X097A1) as well as ASC X12 Standards for Electronic Data 
Interchange Technical Report Type 3--Health Care Claim: Dental (837), 
(ASC X12N/005010X224), and Type 1 Errata to Health Care Claim: Dental 
(837) ASC X12 Standards for Electronic Data Interchange Technical 
Report Type 3, (ASC X12N/005010X224A1); and
    [cir] ASC X12N 837--Health Care Claims: Professional, Volumes 1 and 
2, Version 4010 (004010X098) and Addenda to Health Care Claims: 
Professional, Volumes 1 and 2, Version 4010, (004010x098A1), as well as 
ASC X12 Standards for Electronic Data Interchange Technical Report Type 
3--Health Care Claim: Professional (837), (ASC X12N/005010X222); and
    [cir] The ASC X12N 837--Health Care Claim: Institutional, Volumes 1 
and 2, Version 4010, (004010X096) and Addenda to Health Care Claim: 
Institutional, Volumes 1 and 2, Version 4010, (004010X096A1) as well as 
ASC X12 Standards for Electronic Data Interchange Technical Report Type 
3--Health Care Claim: Institutional (837), (ASC X12N/005010X223), and 
Type 1 Errata to Health Care Claim: Institutional (837) ASC X12 
Standards for Electronic Data Interchange Technical Report Type 3 (ASC 
X12N/005010X223A1).
     To perform eligibility inquiry and response transactions 
between dispensers and Part D sponsors for Part D prescription drugs.
    [cir] NCPDP Telecommunications Standards Implementation Guide, 
Version, 5, Release 1 (Version 5.1), and equivalent NCPDP Batch 
Standards Batch Implementation Guide, Version 1.1.
v. Quality Reporting
    For the purposes of electronically submitting calculated quality 
measures required by CMS or by States, Certified EHR Technology must be 
capable of using the CMS PQRI 2008 Registry XML Specification. We 
recognize that CMS has discussed in the Medicare and Medicaid EHR 
Incentive Programs proposed rule potential approaches to quality 
reporting requirements for future years of meaningful use and we 
anticipate adopting standards as necessary and in consultation with CMS 
to support future quality reporting requirements. We also understand 
that for the purposes of electronically submitting quality measures an 
upcoming standard for Complete EHRs and EHR modules may be the HL7 
Quality Reporting Document Architecture (QRDA) Implementation Guide 
based on HL7 CDA Release 2 and we request public comment on whether 
this standard is mature enough to be used in Complete EHRs and EHR 
Modules during meaningful use Stage 1.
vi. Submission of Lab Results to Public Health Agencies
    For the purposes of submitting lab results to public health 
agencies, Certified EHR Technology must be capable of using HL7 2.5.1. 
With respect to vocabulary standards for the submission of lab results 
to public health agencies, we have adopted the same standard for 
populating lab results as we do for the patient summary record above. 
We believe that enabling the use

[[Page 2033]]

of UCUM and SNOMED CT[supreg] for this exchange in the future would 
lead to improved interoperability.
vii. Submission to Public Health Agencies for Surveillance or Reporting
    For the purposes of electronically submitting information to public 
health agencies for surveillance and reporting, Certified EHR 
Technology must be capable of using HL7 2.3.1 or HL7 2.5.1 as a content 
exchange standard. This requirement is not meant to include adverse 
event reporting. At this time, we have not adopted a specific 
vocabulary standard for submitting information to public health 
agencies for surveillance and reporting, and believe that such 
standards will be determined in large part by the applicable public 
health agency receiving such information. We look forward to receiving 
recommendations from the HIT Standards Committee regarding additional 
standards that should be adopted to facilitate the electronic 
submission of information to public health agencies for surveillance 
and reporting purposes.
viii. Submission to Immunization Registries
    For the purposes of electronically submitting information to 
immunization registries Certified EHR Technology must be 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 \18\ as the 
vocabulary standard.
---------------------------------------------------------------------------

    \18\ The CDC's National Center of Immunization and Respiratory 
Diseases (NCIRD) maintains the HL7 external code set CVX http://www.cdc.gov/vaccines/programs/iis/stds/cvx.htm.
---------------------------------------------------------------------------

ix. Table 2A
    Table 2A below displays the applicable adopted standards for each 
exchange purpose specified. We have used ``Cx'' and ``V'' as shorthand 
for ``content exchange'' and ``vocabulary,'' respectively, to identify 
which standard category applies to the exchange purpose. Where a cell 
in table 2A includes the reference ``no standard adopted at this time'' 
it means that a Complete EHR or EHR Module would not be required to be 
tested and certified as including a particular standard. As a result, 
any local or proprietary standard could be used as well as the 
standard(s) listed as candidate meaningful use Stage 2 standards. 
Unless marked with the following superscripts, all of the adopted 
standards are from the ONC process that took place prior to the 
enactment of the HITECH Act or are required by other HHS regulations.
     A number sign ``'' indicates that the HIT 
Standards Committee recommended this standard to the National 
Coordinator but it was not part of the prior ONC process.
     An asterisk ``*'' indicates that the standard was neither 
recommended by the HIT Standards Committee nor part of the prior ONC 
process.
     A plus sign ``+'' as mentioned above indicates a standard 
that is not a voluntary consensus standard.

                           Table 2A--Adopted Content Exchange and Vocabulary Standards
----------------------------------------------------------------------------------------------------------------
                                                               Adopted standard(s) to   Candidate standard(s) to
     Row No.               Purpose              Category       support meaningful use    support meaningful use
                                                                       stage 1                   stage 2
----------------------------------------------------------------------------------------------------------------
1...............  Patient Summary Record..  Cx..............  HL7 CDA R2 CCD Level 2    Alternatives expected to
                                                               or ASTM CCR.              be narrowed based on
                                                                                         HIT Standards Committee
                                                                                         recommendations.
                   Problem List...  V...............  Applicable HIPAA code     Applicable HIPAA code
                                                               set required by law       set required by law
                                                               (i.e., ICD-9-CM); or      (e.g., ICD-10-CM) or
                                                               SNOMED CT[supreg].        SNOMED CT[supreg].
                   Medication List  V...............  Any code set by an        RxNorm.
                                                               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+.
                   Medication       V...............  No standard adopted at    UNII.
                   Allergy List.                               this time.
                   Procedures.....  V...............  Applicable HIPAA code     Applicable HIPAA code
                                                               sets required by law      sets required by law
                                                               (i.e., ICD-9-CM or CPT-   (i.e., ICD-10-PCS or
                                                               4[supreg]).               CPT-4[supreg]).
                   Vital Signs....  V...............  No standard adopted at    CDA template.
                                                               this time.
                   Units of         V...............  No standard adopted at    UCUM.
                   Measure.                                    this time.
                   Lab Orders and   V...............  LOINC[supreg] when        LOINC[supreg].
                   Results.                                    LOINC[supreg] codes
                                                               have been received from
                                                               a laboratory.
2...............  Drug Formulary Check....  Cx..............  Applicable Part D         Applicable Part D
                                                               standard required by      standard required by
                                                               law (i.e., NCPDP          law.
                                                               Formulary & Benefits
                                                               Standard 1.0).
3...............  Electronic Prescribing..  Cx..............  Applicable Part D         NCPDP SCRIPT 10.6.
                                                               standard required by
                                                               law (e.g., NCPDP SCRIPT
                                                               8.1) or NCPDP SCRIPT
                                                               8.1 and NCPDP SCRIPT
                                                               10.6.
                                            V...............  Any code set by an        RxNorm.
                                                               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+.
4...............  Administrative            Cx..............  Applicable HIPAA          Applicable HIPAA
                   Transactions.                               transaction standards     transaction standards
                                                               required by law.          required by law.
5...............  Quality Reporting.......  Cx..............  CMS PQRI 2008 Registry    Potentially newer
                                                               XML Specification #,+.    version(s) or standards
                                                                                         based on HIT Standards
                                                                                         Committee Input.

[[Page 2034]]

 
6...............  Submission of Lab         Cx..............  HL7 2.5.1...............  Potentially newer
                   Results to Public                                                     version(s) or standards
                   Health Agencies.                                                      based on HIT Standards
                                                                                         Committee
                                                                                         Recommendations.
                                            V...............  LOINC[supreg] when        LOINC[supreg], UCUM, and
                                                               LOINC[supreg] codes       SNOMED CT[supreg] or
                                                               have been received from   Applicable Public
                                                               a laboratory.             Health Agency
                                                                                         Requirements.
7...............  Submission to Public      Cx..............  HL7 2.3.1 or HL7 2.5.1..  Potentially newer
                   Health Agencies for                                                   version(s) or standards
                   Surveillance or                                                       based on HIT Standards
                   Reporting (excluding                                                  Committee Input.
                   adverse event
                   reporting).
                                            V...............  According to Applicable   GIPSE or According to
                                                               Public Health Agency      Applicable Public
                                                               Requirements.             Health Agency
                                                                                         Requirements.
8...............  Submission to             Cx..............  HL7 2.3.1 or HL7 2.5.1..  Potentially newer
                   Immunization Registries.                                              version(s) or standards
                                                                                         based on HIT Standards
                                                                                         Committee
                                                                                         Recommendations.
                                            V...............  CVX*,+..................  CVX.
----------------------------------------------------------------------------------------------------------------

c. Privacy and Security Standards
    We believe it is necessary for Certified EHR Technology to provide 
certain privacy and security capabilities. In that regard, we have 
aligned adopted certification criteria to applicable HIPAA Security 
Rule requirements and believe that in doing so, such capabilities may 
assist eligible professionals and eligible hospitals to improve their 
overall approach to privacy and security. In addition, some may find 
that the capabilities provided by Certified EHR Technology may 
facilitate and streamline compliance with Federal and state privacy and 
security laws. We believe that the HIPAA Security Rule serves as an 
appropriate starting point for establishing the capabilities for 
Certified EHR Technology. That being said, the HITECH Act directs the 
HIT Policy Committee, the HIT Standards Committee, and ONC to look at 
capabilities beyond those explicitly specified in the HIPAA Security 
Rule. We intend to work with both of these Committees to explore these 
areas and where possible to adopt new certification criteria and 
standards in the future to improve the capabilities Certified EHR 
Technology can provide to protect health information.
    The adopted certification criteria in Table 1 assure that Certified 
EHR Technology is capable of supporting eligible professionals and 
eligible hospitals comply with HIPAA requirements to protect electronic 
health information residing within Certified EHR Technology and, where 
appropriate, when such information is exchanged. For certain 
capabilities, we have adopted, after considering the recommendations of 
the HIT Standards Committee, specific standards to be used in Certified 
EHR Technology. These standards and their purposes are displayed in 
Table 2B. For other capabilities, we have not adopted specific 
standards because such capabilities can be appropriately addressed 
through different approaches, and we did not want to preclude 
innovation. For example, while we have adopted a certification 
criterion related to access control, we have not adopted a specific 
standard for access control because we believe that the industry will 
continue to innovate at a rapid pace in this area and better methods to 
implement this capability will be available faster than we would be 
able to adopt them via regulation. On the other hand, we have adopted 
certification criteria and standards for encryption because specific 
industry best practices and requirements exist with respect to 
encryption and the strength of encryption algorithms. HHS previously 
articulated in guidance entitled ``Guidance Specifying the Technologies 
and Methodologies That Render Protected Health Information Unusable, 
Unreadable, or Indecipherable to Unauthorized Individuals'' (74 FR 
42741) that encryption is an effective method to ``render protected 
health information unusable, unreadable, or indecipherable to 
unauthorized individuals,'' and one that can exempt a HIPAA covered 
entity from having to report a breach. To further support this 
determination, we believe a logical and practical next step and one 
that will provide eligible professionals and eligible hospitals with a 
capability they may not have had in the past is to require Certified 
EHR Technology to be capable of encryption.
    It is important to note, under 45 CFR 164.312(a)(2)(iv) and 
(e)(2)(ii), a HIPAA covered entity must assess whether encryption as a 
method for safeguarding electronic protected health information is a 
reasonable and appropriate safeguard in its environment. Consequently, 
a HIPAA covered entity could be in compliance with the HIPAA Security 
Rule if it determines that encryption is not reasonable and appropriate 
in its environment and it documents its rationale and implements an 
equivalent alternative measure if reasonable and appropriate. We hope 
that by requiring Certified EHR Technology to include this capability, 
that the use of encryption will become more prevalent. Of the 
certification criteria and associated standards we have adopted related 
to encryption, the first is for encryption in general while the second 
is specific to when electronic health information is exchanged. The 
first certification criterion and standard will assure that Certified 
EHR Technology is capable of using encryption according to user-defined 
preferences. There are several industry best practices in this regard 
and we expect that with the availability of the capability to perform 
encryption, eligible professionals and hospitals will follow suit and 
enhance how they protect electronic health information. We anticipate 
that this capability could be used by eligible professionals and 
eligible hospitals to encrypt backup hard drives or tapes, removable 
media, or portable devices. Finally, we expect other functions or 
services such as domain name service, directory access, and consistent 
time (e.g., for audit logs) to support and further enable some of the 
standards in Table 2B. However, due to the fact these functions or 
services may be part of an overall implementation of Certified EHR 
Technology (e.g., operating system, network time server) rather than a 
specific capability Certified EHR

[[Page 2035]]

Technology should be tested and certified as including, we chose not to 
adopt certification criteria or standards. We request public comment on 
whether the previously mentioned functions or services or any other 
function or service should be considered for adoption by the Secretary 
as a necessary capability for Certified EHR Technology to include.
    After considering the written and oral public comments provided to 
both the HIT Policy and HIT Standards Committees, we would like to 
clarify the applicability of the privacy and security certification 
criteria and standards adopted in this interim final rule. This interim 
final rule strictly focuses on the capabilities of Certified EHR 
Technology and does not change existing HIPAA Privacy Rule or Security 
Rule requirements, guarantee compliance with those requirements, or 
absolve an eligible professional, eligible hospital, or other health 
care provider who adopts Certified EHR Technology from having to comply 
with any applicable provision of the HIPAA Privacy or Security Rules. 
While the capabilities provided by Certified EHR Technology may assist 
an eligible professional or eligible hospital in improving their 
technical safeguards in order to meet some or all of the HIPAA Security 
Rule's requirements or influence their risk analysis, the use of 
Certified EHR Technology alone does not equate to compliance with the 
HIPAA Privacy or Security Rules. The capabilities provided by Certified 
EHR Technology do not affect in any way the analysis a HIPAA covered 
entity is responsible for performing specified at 45 CFR 164.306(b) and 
(d). Unless there are specific meaningful use measures for privacy and 
security that require the use of a particular capability, an eligible 
professional or eligible hospital may find that its security practices 
exceed these capabilities and nothing in this rule precludes the use or 
implementation of more protective privacy and security measures.

            Table 2B--Adopted Privacy and Security Standards
------------------------------------------------------------------------
       Row No.                Purpose              Adopted standard
------------------------------------------------------------------------
1...................  General Encryption and  A symmetric 128 bit fixed-
                       Decryption of           block cipher algorithm
                       Electronic Health       capable of using a 128,
                       Information.            192, or 256 bit
                                               encryption key must be
                                               used (e.g., FIPS 197
                                               Advanced Encryption
                                               Standard, (AES), Nov
                                               2001).+
2...................  Encryption and          An encrypted and integrity
                       Decryption of           protected link must be
                       Electronic Health       implemented (e.g., TLS,
                       Information for         IPv6, IPv4 with IPsec).+
                       Exchange.
3...................  Record Actions Related  The date, time, patient
                       to Electronic Health    identification (name or
                       Information (i.e.,      number), and user
                       audit log).             identification (name or
                                               number) must be recorded
                                               when electronic health
                                               information is created,
                                               modified, deleted, or
                                               printed. An indication of
                                               which action(s) occurred
                                               must also be recorded
                                               (e.g., modification).+
4...................  Verification that       A secure hashing algorithm
                       Electronic Health       must be used to verify
                       Information has not     that electronic health
                       been Altered in         information has not been
                       Transit.                altered in transit. The
                                               secure hash algorithm
                                               used must be SHA-1 or
                                               higher (e.g., Federal
                                               Information Processing
                                               Standards (FIPS)
                                               Publication (PUB) Secure
                                               Hash Standard (SHS) FIPS
                                               PUB 180-3).+
5...................  Cross-Enterprise        Use of a cross-enterprise
                       Authentication.         secure transaction that
                                               contains sufficient
                                               identity information such
                                               that the receiver can
                                               make access control
                                               decisions and produce
                                               detailed and accurate
                                               security audit trails
                                               (e.g., IHE Cross
                                               Enterprise User Assertion
                                               (XUA) with SAML identity
                                               assertions).+
6...................  Record Treatment,       The date, time, patient
                       Payment, and Health     identification (name or
                       Care Operations         number), user
                       Disclosures.            identification (name or
                                               number), and a
                                               description of the
                                               disclosure must be
                                               recorded.+
------------------------------------------------------------------------

3. Adopted Implementation Specifications
    Pursuant to section 3004 of the PHSA, the Secretary is required to 
adopt implementation specifications in addition to standards and 
certification criteria. Implementation specifications, which for HIPAA 
covered transaction standards are found in implementation guides, 
provide specific configuration instructions and constraints for 
implementing a particular standard or set of standards. Because some 
standards can be implemented in several different ways, these 
specifications are critical in some cases to make interoperability a 
reality--simply using a standard does not necessarily guarantee 
interoperability.
    Standards Development Organizations (SDOs), HITSP, and others have 
developed implementation specifications with varying degrees of 
specificity, which in turn have resulted in varying degrees of 
interoperability. In some cases, the standards used in the NHIN, for 
example, have been constrained even further and resulted in a narrow 
and unique set of implementation specifications, designed for a 
specific architecture and well-defined exchange. Based on input from 
HIT Standards Committee, we understand that very few implementation 
specifications are widely used and most are immature or too 
architecturally specific for adoption by large segments of the HIT 
industry before meaningful use Stage 2.
    Given the importance of implementation specifications and the 
analyses and field testing necessary to refine them, we do not believe, 
with the exception of the few mentioned below, that there are mature 
implementation specifications ready to adopt to support meaningful use 
Stage 1. We seek public comment on whether there are in fact 
implementation specifications that are industry-tested and would not 
present a significant burden if they were adopted. We believe that 
certain exchange purposes such as electronic prescribing and laboratory 
test results, already have available some of the most mature 
implementation specifications. We will consider adopting implementation 
specifications, though, for any or all adopted standards provided that 
there is convincing evidence submitted in public comment of the 
specifications' maturity and widespread usage.
    We have adopted a certification criterion requiring that Certified 
EHR Technology be capable of using the standard, CMS PQRI 2008 Registry 
XML Specification, for quality reporting. We have also adopted as the 
implementation specifications for this standard, the Physician Quality 
Reporting Initiative Measure Specifications Manual for Claims and 
Registry. Additionally, as we noted above we have adopted standards 
that require Certified EHR Technology to be capable of using applicable 
HIPAA transaction standards adopted by HHS for eligibility for health 
plan

[[Page 2036]]

transactions and for health care claims or equivalent encounter 
information transactions. In so doing, the specific HIPAA standards and 
``implementation specifications'' associated with these covered 
transactions have also been adopted. As a supporting implementation 
specification for the eligibility for health plan transactions HIPAA 
transaction standard we have also adopted the requirements of Phase 1 
of the Council for Affordable Quality Healthcare (CAQH) Committee on 
Operating Rules for Information Exchange (CORE). We request public 
comment on the HIT industry's experience using CAQH CORE Phase 1 with 
adopted HIPAA transactions standards.
    Finally, in preparing to adopt future implementation specifications 
to support meaningful use Stage 2, ONC plans to work with the HIT 
industry and solicit input from relevant Federal advisory committees to 
obtain further specificity in the area of implementation 
specifications. We also encourage SDOs to make widely available 
implementation specifications that can be tested and adopted by the 
Secretary in the future.
4. Additional Considerations, Clarifications, and Requests for Public 
Comments
a. Relationship to Other Federal Laws
    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. For example, Certified EHR 
Technology may be able to assist health care providers required to 
comply with the Confidentiality of Alcohol and Drug Abuse Patient 
Records Regulation, 42 CFR Part 2, but it may not provide, from a 
technical perspective, all of the capabilities necessary to comply with 
these regulations. 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.
b. Human Readable Format
    As acknowledged in prior sections of this interim final rule, the 
initial set of adopted standards, implementation specifications, and 
certification criteria are only the beginning of what we expect will be 
an incremental approach to enhance the interoperability, functionality, 
and utility of health information technology. 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 identified above in Table 2A. 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).
c. Certification Criterion and Standard Regarding Accounting of 
Disclosures
    Section 3004(b)(1) of the PHSA requires the Secretary to adopt a 
standard and certification criterion in this interim final rule that 
are consistent with section 3002(b)(2)(B)(iv) (pertaining to 
technologies that, as part of a Qualified EHR, allow for an accounting 
of disclosures made by a HIPAA covered entity for purposes of 
treatment, payment, and health care operations). This requirement is 
parallel to section 13405(c) of the HITECH Act, which requires the 
Secretary to modify (no later than 6 months after the date on which the 
Secretary adopts standards on accounting for disclosures) the HIPAA 
Privacy Rule at 45 CFR 164.528 to now require that HIPAA covered 
entities account for disclosures related to treatment, payment, and 
health care operations made through an electronic health record and to 
identify in the regulations the information that shall be collected 
about each of the disclosures. In promulgating these regulations, the 
Secretary is instructed to ``only require such information to be 
collected through an electronic health record in a manner that takes 
into account the interests of the individuals in learning the 
circumstances under which their protected health information is being 
disclosed and takes into account the administrative burden of 
accounting for such disclosures.'' Unless modified by the Secretary, 
the effective date \19\ for HIPAA covered entities that have acquired 
an electronic health record after January 1, 2009, is January 1, 2011, 
or anytime after this date when they acquire an electronic health 
record.
---------------------------------------------------------------------------

    \19\ See HITECH Act section 13405(c)(4), which also provides 
that the effective date for HIPAA covered entities that are current 
users of EHRs (i.e., acquired EHRs as of January 1, 2009) January 1, 
2014, unless modified by the Secretary.
---------------------------------------------------------------------------

    We intend for our adoption of a basic certification criterion and 
standard to account for disclosures (Sec.  170.302(v) and Sec.  
170.210(e), respectively) to provide a technical foundation for the 
information that the Secretary will subsequently determine should be 
collected for treatment, payment and health care operations 
disclosures. We have adopted a basic certification criterion that 
requires the capability to record disclosures (as defined by the HIPAA 
Privacy Rule) made for treatment, payment, and health care operations 
in accordance with the standard we have adopted. The standard specified 
in Table 2B above stipulates a functional requirement that a recorded 
disclosure for treatment, payment, or health care operations must 
include:

[[Page 2037]]

The date, time, patient identification (name or number), user 
identification (name or number), and a description of the disclosure. 
We believe date, time, patient identification, and user identification 
are all readily available data because it is the same information 
required in the standard for an audit log. We have also included the 
requirement that a ``description of the disclosure'' must be recorded; 
however, we have not required any additional specificity for what 
should be included in the ``description,'' because the Secretary has 
not yet weighed the interests of individuals with the administrative 
burden associated with accounting for such disclosures to determine 
what information shall be collected. The certification criterion and 
standard in this interim final rule are limited to disclosures for 
treatment, payment, and health care operations, as those terms are 
defined at 45 CFR 164.501. This interim final rule does not address the 
capability of Certified EHR Technology to account for other types of 
disclosures. We note that a HIPAA covered entity using Certified EHR 
Technology must continue to account for disclosures in accordance with 
45 CFR 164.528, which may require the collection of additional 
information for disclosures that are not for treatment, payment, or 
health care operations.
    We do not propose additional requirements at this time because we 
believe that several significant technical challenges will need to be 
addressed before it is possible to record additional information about 
disclosures in an efficient manner. For example, we are unaware of any 
particular technology solution that is capable of automatically 
recognizing the difference between a ``use'' and a ``disclosure,'' as 
the HIPAA regulations define these terms. Additionally, we are 
concerned about the amount of electronic storage that will be necessary 
to record three years worth of information related to treatment, 
payment, and health care operations disclosures. We welcome public 
comment, particularly from the HIT developer community, as to these 
concerns as well as about the technical feasibility of recording other 
elements of information about a disclosure. We are specifically 
interested in comments as to the technical feasibility of recording the 
purpose or reason for the disclosure, to whom the disclosure was made 
(i.e., recipient), and any other elements that may be beneficial for a 
patient to know about with respect to their health information.
    It is important to note, as discussed above, that the Secretary has 
the discretion to modify the compliance date for the revised 
accounting-for-disclosure regulations to as late as 2013 for HIPAA 
covered entities that acquire electronic health records after January 
1, 2009. The Secretary will address the compliance date for accounting 
for treatment, payment, and health care operations disclosures in a 
later rulemaking. In the interim, we again note that the standards and 
certification requirements adopted do not affect a HIPAA covered 
entity's compliance with the HIPAA Privacy or Security Rules.
    As the use of Certified EHR Technology becomes more widespread and 
technology advances, we believe the ability to account for disclosures 
will continue to evolve. Accordingly, this first certification 
criterion and standard for accounting of disclosures is intended as an 
incremental step, which will be refined as the technology develops and 
regulatory requirements are issued. We plan to work with the HIT Policy 
Committee and HIT Standards Committee to receive recommendations 
regarding the policies that should be established to address these 
standards and certification criteria requirements and with the HHS 
Office for Civil Rights to appropriately coordinate the adoption of 
policies for the accounting of treatment, payment, and health care 
operations disclosures with the capabilities that Certified EHR 
Technology must include in the future.
d. Additional Requests for Public Comment
     We are interested in public comments to inform future 
deliberations on whether specific certification criteria could be 
adopted to further promote the capabilities Certified EHR Technology 
should provide with respect to meeting the accessibility needs of 
individuals with disabilities.
     We are also interested in public comments to inform future 
deliberations on whether specific certification criteria could be 
adopted to further promote the capabilities Certified EHR Technology 
should provide with respect to the prevention and detection of 
potential fraud, waste, and abuse.
     We are interested in public comment regarding the 
``candidate standards to support meaningful use Stage 2'' listed in 
Table 2A. We are specifically interested in feedback regarding 
implementation feasibility, maturity, and prevalence in the industry.

IV. Collection of Information Requirements

    This interim final rule contains no new information collection 
requirements subject to review by the OMB under the Paperwork Reduction 
Act (PRA). The HITECH Act establishes new information collection 
requirements, but those information collection requirements are 
addressed by other regulatory and programmatic activities (e.g., the 
Medicare and Medicaid EHR Incentive Programs Proposed Rule).
    The HITECH Act applies through Section 13111(b) to ``federal 
information collection activities.'' The HITECH Act states that ``with 
respect to a standard or implementation specification adopted under 
section 3004 of the Public Health Service Act, as added by section 
13101, the President shall take measures to ensure that Federal 
activities involving the broad collection and submission of health 
information are consistent with such standard or implementation 
specification, respectively, within three years after the date of such 
adoption.'' Standards adopted in this interim final rule may affect how 
Federal agencies collect information in the future; however, the 
potential implications of this requirement will largely depend on 
actions taken by the Executive Office of the President, including how 
it interprets the terms ``consistent,'' ``broad,'' and ``health 
information.'' We welcome comments on the potential for standards and 
implementation specifications adopted in this regulation to change the 
way information is collected by Federal agencies. We will share such 
comments with the OMB.

V. Regulatory Impact Analysis

A. Introduction

    We have examined the impacts of this 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 interim final rule is not an economically 
significant rule because

[[Page 2038]]

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 interim final 
rule, we have prepared an RIA that to the best of our ability presents 
the costs and benefits of the interim final rule. We request comments 
on the economic analysis provided in this interim final rule with 
comment.
    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.\20\ 
Although the RFA only requires an initial regulatory flexibility 
analysis (IRFA) when an agency issues a proposed rule, HHS has a policy 
of voluntarily conducting an IRFA for interim final regulations. We 
examine the burden of the interim final regulation in Section V.D 
below.
---------------------------------------------------------------------------

    \20\ 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 2009, that threshold is 
approximately $133 million. This rule will not impose an unfunded 
mandate on States, tribal government or the private sector of more than 
$133 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 our interim 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 by December 31, 2009. 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. Costs and Benefits

    Throughout the following analysis we invite comments on specific 
portions of our analysis. The public, however, is invited to offer 
comments on any and all elements of the analysis and the assumption 
underlying the analysis.
1. Costs
    This interim final rule is one of three coordinated rulemakings 
(the other two being the Medicare and Medicaid EHR Incentive Programs 
proposed rule and the HIT Certification Programs proposed rule) 
undertaken to implement the goals and objectives of the HITECH Act 
related to the adoption and meaningful use of Certified EHR Technology. 
Each rule's preamble contains a RIA section. While there is no bright 
line that divides the effects of this interim final rule and the other 
two noted above, we believe that each analysis properly focuses on the 
direct effects of the provisions it creates. This interim final rule 
estimates the costs commercial vendors, open source developers, and 
relevant Federal agencies \21\ 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.
---------------------------------------------------------------------------

    \21\ All Indian Health Service (IHS) facilities and the vast 
majority of Tribally-operated facilities funded by IHS utilize the 
Resource and Patient Management System (RPMS), the IHS health 
information and EHR system that is centrally developed and 
distributed by the IHS Office of Information Technology. It is our 
understanding that IHS provides information technology support to 
over 40 IHS and Tribal hospitals as well as health care providers at 
approximately 300 ambulatory facilities. The RPMS EHR is designed 
for both inpatient and ambulatory implementations and it is IHS's 
goal to remain consistent with the certification criteria adopted by 
the Secretary. As a result, we expect IHS will the RPMS EHR for 
testing and certification to applicable adopted certification 
criteria.
---------------------------------------------------------------------------

    This interim 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. Due to the fact that the Medicare 
and Medicaid EHR Incentive Programs require (among other things) that 
eligible professionals and eligible hospitals use Certified EHR 
Technology in order to receive incentive payments, we anticipate that 
commercial vendors and open source developers of Complete EHRs and EHR 
Modules will respond by preparing such technology to meet the 
certification criteria adopted in this interim final rule. We expect 
this to occur because commercial vendors and open source developers who 
do not prepare Complete EHRs or EHR Modules to be tested and certified 
risk losing market share (i.e., eligible professionals and eligible 
hospitals seeking to achieve meaningful use will not buy Complete EHRs 
or EHR Modules that cannot outright or when combined with other EHR 
Modules meet the definition of Certified EHR Technology). It is 
important to note, however, as discussed in section 3001(c)(5)(A) of 
the PHSA, that Congress intended for the act of preparing for and 
subsequently seeking the certification of a Complete EHR or EHR Module 
to be voluntary.
    As we discuss above, our analysis only focuses on the direct 
effects of the provisions created by this interim final rule. As a 
result, we only include estimates for the costs commercial vendors, 
open source developers, and relevant Federal agencies may incur to 
prepare Complete EHRs or EHR Modules to be tested and certified. We do 
not include in this analysis the costs to eligible professionals and 
eligible hospitals that choose to: (1) Purchase new Certified EHR 
Technology, or (2) self-develop or modify their current, HIT to become 
meaningful users. These costs are addressed in the Medicare and 
Medicaid EHR Incentive Programs proposed rule because they are directly 
related to the actions taken by eligible professionals or eligible 
hospitals to become meaningful users. Additionally, the cost for 
Complete EHRs and EHR Modules to be tested and certified is addressed 
in the HIT Certification Programs proposed rule and not in this interim 
final rule.
    In conducting research to inform the estimates we make below we 
found several websites that listed, in an aggregate format, different 
types of Complete EHRs and EHR Modules designed for various types of 
health care providers as well as those that were designed primarily for 
specialists. Based on our research, we believe it is reasonable to 
assume that a few hundred unique Complete EHRs and EHR Modules make up 
the available universe of HIT for health care

[[Page 2039]]

providers, including eligible professionals and eligible hospitals. 
This estimate includes within it specialty and other niche HIT that are 
not the intended focus of this interim final rule. While certain 
certification criteria may be applicable to these other types of HIT, 
the Secretary has not adopted a specific or complete set of 
certification criteria for them at this time. Therefore, our estimates 
for the impacts of this interim final rule solely focus on what we 
believe will be the likely amount of Complete EHRs and EHR Modules that 
are prepared to be tested and certified and how much that preparation 
will cost.
    We have analyzed previously developed CCHIT ambulatory and 
inpatient certification criteria and believe that many, but not all, 
require the exact same capabilities required by the respective 
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, 
with respect to this impact analysis, we believe that a significant 
number of previously CCHIT-certified-EHRs will only incur moderate 
costs to prepare for certification. We assume, for the purposes of 
creating reasonable estimates, that previously CCHIT-certified-EHRs are 
similar to our definition of a Complete EHR. As a result, we have based 
our estimates in Table 3 with the expectation that these previously 
CCHIT-certified-EHRs will again be prepared for certification as 
Complete EHRs. To add further specificity to our estimates, we 
understand, according to CCHIT's Web site, there are 74 CCHIT-
certified-EHRs that have been certified to its 2008 ambulatory 
certification criteria and 17 CCHIT-certified-EHRs, that have been 
certified to its 2007 or 2008 inpatient certification 
criteria.22 23 24 Of these 74 and 17 previously CCHIT-
certified-EHRs we expect that 90% will be prepared for certification 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 previously CCHIT-
certified-EHRs include more capabilities than what CCHIT tested and 
certified and may be able to more easily meet the certification 
criteria adopted by the Secretary). Given this assumption we have 
created low and high ranges for the cost to prepare previously CCHIT-
certified ambulatory and inpatient EHRs.
---------------------------------------------------------------------------

    \22\ 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 effect on our estimates.
    \23\ http://www.cchit.org/products/Ambulatory--when 
certification years 2006 and 2007 are unchecked.
    \24\ 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) have been implemented and deployed in 
HIT to such a large degree that there would be little or no 
modification required to prepare Complete EHRs or EHR Modules for 
testing and certification to certain certification criteria. 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 or EHR Module for testing and certification 
taking into account the factors identified directly above. We have used 
this per certification criteria range as the basis for our low and high 
cost range estimates and for the ease of our calculations assume that 
the Secretary has adopted approximately 40 certification criteria.
    For Table 3 we have made the following assumptions: (1) In general, 
previously CCHIT-certified-EHRs will need additional preparation to be 
tested and certified to 25% of the certification criteria adopted by 
the Secretary; (2) the average low and high per certification criterion 
cost for previously CCHIT-certified ambulatory EHRs 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 cost for 
previously CCHIT-certified inpatient EHRs to be prepared to be tested 
and certified will be $75,000 and $200,000, respectively.

Table 3--Estimated One-Time Costs for Previously CCHIT-Certified-EHRs To Be Prepared To Be Tested and Certified as Complete EHRs (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
                                                        ------------------------------------------------------------------------------------------------

[[Page 2040]]

 
    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 prepared to be tested and certified as Complete 
EHRs rather than being prepared to be tested and certified as an EHR 
Module.\25\ We assume the EHR technology that falls into this category 
may require more extensive changes than previously CCHIT-certified-EHRs 
identified in Table 3. 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 \26\ 
represented by the previously CCHIT-certified-EHRs included in Table 3 
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.\27\
---------------------------------------------------------------------------

    \25\ CCHIT began testing and certifying inpatient EHRs in 2007 
and we assume that all of those EHRs are included in Table 3 which 
is why they are not included in this discussion.
    \26\ http://www.cchit.org/about--``* * * EHR products certified 
by mid-2009, representing over 75% of the marketplace.''
    \27\ This estimate includes 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 assumptions in 
our Table 4 calculations: (1) In general, out-of-date CCHIT-Certified-
EHRs and never previously CCHIT-certified-EHRs will need additional 
preparation to be tested and certified to 60% of the certification 
criteria adopted by the Secretary; (2) the average low and high per 
certification criterion cost 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 cost for Complete EHRs for eligible hospitals 
to be prepared to be tested and certified will be $75,000 and $200,000, 
respectively.

   Table 4--Estimated One-Time Costs for Never CCHIT-Certified-EHRs and Out-of-Date CCHIT-Certified-EHRs To Be Prepared To Be Tested and Certified as
                                                      Complete EHRs (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. As discussed above, we 
believe over time that EHR Modules will play an increasingly important 
role in improving the capabilities available to eligible professionals 
and eligible hospitals. It is also our belief that EHR Modules will 
lead to a more innovative and competitive marketplace. We believe that 
during meaningful use Stage 1, approximately seven types of EHR Modules 
will be practical given the current state of the HIT marketplace. We 
assume that EHR Modules will most likely be prepared to be tested and 
certified to provide the following types of capabilities: Electronic 
prescribing; administrative transactions; core clinical capabilities; 
computerized provider order entry; quality reporting; online patient 
portals; and interfacing with a health information organization to 
enable the electronic exchange of health information.
    Generally speaking, of the available universe of HIT developers we 
assume that a small percentage will prepare the previously mentioned 
types of EHR Modules for certification prior to the beginning of 
meaningful use Stage 2 (i.e., between 2010 and 2012). Furthermore, we 
assume during meaningful use Stage 1 there will be on average 7 EHR 
Modules prepared to be tested and certified for each type of EHR Module 
described above. As a result we estimate that there will be 
approximately 50 EHR Modules (number of modules X types of modules) 
prepared to be tested and certified. Again, we have provided low and 
high preparation cost estimates in Table 5 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 may 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 for the costs to 
prepare these types of EHR modules for testing and certification.

[[Page 2041]]



 Table 5--Estimated One-Time Costs to Prepare EHR Modules for Certification to Applicable Adopted Certification Criteria (3-Year Period)--Totals Rounded
--------------------------------------------------------------------------------------------------------------------------------------------------------
                                                                              One time cost per EHR module ($M)      Total cost all EHR modules over 3-
                                                                  Number   ---------------------------------------              year period
                             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
                                                              ------------------------------------------------------------------------------------------
    Total....................................................           50  ...........  ...........  ...........          5.0         25.0         15.0
--------------------------------------------------------------------------------------------------------------------------------------------------------

    We invite comments on the number of commercial vendors and open 
source developers of Complete EHRs or EHR Modules that make up the 
marketplace and the number of Complete or EHR Modules that will be 
prepared for testing and certification. Because many of the adopted 
standards and implementation specifications are already in widespread 
use and because many of the adopted certification criteria require core 
capabilities that already exist in the marketplace today we believe 
that the costs incurred as a result of voluntary actions by the private 
sector to prepare for certification will be modest. We welcome comments 
on our estimates above.
    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 about $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. We also assume that it will generally take 6 to 18 months 
for commercial vendors and open source developers of Complete EHRs and 
EHR Modules to prepare for testing and certification. As a result, we 
believe as represented in Table 6 that the costs attributable to this 
interim final rule will be distributed as follows: 45% for 2010, 40% 
for 2011 and 15% for 2012.

                  Table 6--Distributed Total Preparation Costs (3-Year Period)--Totals Rounded
----------------------------------------------------------------------------------------------------------------
                                                                                    Total high     Total average
                      Year                             Ratio      Total low cost   cost estimate   cost estimate
                                                     (percent)     estimate ($M)       ($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.3          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.
2. Benefits
    We believe that there will be several benefits from this interim 
final rule. By adopting 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 its meaningful use. The 
capabilities required by adopted certification criteria will help arm 
health care providers with 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 interim 
final rule will be a catalyst for a more competitive and innovative 
marketplace. Finally, adopted certification criteria can be used by 
commercial vendors and open source developers of Complete EHRs and EHR 
Modules as technical requirements to ensure that their HIT can be 
tested and certified and subsequently adopted and implemented as 
Certified EHR Technology by eligible professionals and eligible 
hospitals to help them qualify for incentive payments under Medicare 
and Medicaid EHR Incentive Programs.

D. Regulatory Flexibility Act 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. As noted above, although the RFA only 
requires an initial regulatory flexibility analysis when an agency 
issues a proposed rule, HHS has a policy of voluntarily conducting an 
initial regulatory flexibility analysis for interim final regulations.
    We are implementing this interim final rule as required by section 
3004(b)(1) of the PHSA. The objective of the interim final rule is for 
the Secretary to adopt an initial set of standards, implementation 
specifications, and certification criteria for HIT.
    While commercial vendors and open source developers of Complete 
EHRs and EHR Modules represent a small segment of the overall 
information technology industry, we believe that the entities impacted 
by this interim final rule most likely fall under the North American 
Industry Classification System (NAICS) code 541511 ``Custom Computer 
Programming Services'' specified at 13 CFR 121.201 where the SBA 
publishes ``Small Business Size Standards by NAICS Industry.'' The size 
standard associated with this NAICS code is set at $25 million in 
annual

[[Page 2042]]

receipts \28\ which ``indicates the maximum allowed for a concern and 
its affiliates to be considered small entities.''
---------------------------------------------------------------------------

    \28\ 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 a handful of multinational 
corporations and many national or regional businesses represent a 
significant majority of the potential Complete EHR and EHR Module 
developers and that many, if not all, exceed the specified SBA size 
standard. We make this assumption based on our understanding of the 
upfront investments necessary to develop and market HIT in a 
competitive marketplace as well as the upgrade and product modification 
costs that these businesses incur to stay competitive. However, we 
note, and request public comment on, the following constraint 
encountered during our analysis. 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 commercial 
vendors and open source developers of Complete EHRs and EHR Modules 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 at the present time to locate empirical data related to many 
of the commercial vendors and open source developers of Complete EHRs 
and EHR Modules to correlate to the SBA size standard. We therefore 
request public comment on any additional information regarding the 
business size of commercial vendors and open source developers of 
Complete EHRs and EHR Modules in the HIT marketplace to help inform our 
analysis.
    Given the discussion above, we estimate that this interim final 
rule will have effects on commercial vendors and open source developers 
of Complete EHRs and EHR Modules, some of which may be small entities. 
However, we do not believe that the interim final rule will create a 
significant economic impact on a substantial number of these entities, 
regardless of size. The Secretary certifies that this interim 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 interim final rule imposes substantial direct 
requirement 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. This interim final rule with comment period 
affords all States an opportunity to identify any problems that our 
standards, implementation specifications, and certification criteria 
would create, and to propose constructive alternatives. We welcome 
comments from State and local governments.

F. Unfunded Mandates Reform Act of 1995

    Title II of the Unfunded Mandates Reform Act of 1995 (Pub. L. 104-
4) requires cost-benefit and other analyses before any rulemaking if 
the rule includes a ``Federal mandate that may result in the 
expenditure by State, local, and tribal governments, in the aggregate, 
or by the private sector, of $100,000,000 or more (adjusted annually 
for inflation) in any 1 year.'' The current inflation-adjusted 
statutory threshold is approximately $130 million. The Department has 
determined that this rule would not constitute a significant rule under 
the Unfunded Mandates Reform Act, because it would impose no mandates.
    The Office of Management and Budget reviewed this interim final 
rule with comment period.

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, the Department amends 45 CFR 
subtitle A to add subchapter D as follows:

SUBCHAPTER D--HEALTH INFORMATION TECHNOLOGY

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

Subpart A--General Provisions
Sec.
170.100 Statutory basis and purpose.
170.101 Applicability.
170.102 Definitions.
Subpart B--Standards and Implementation Specifications for Health 
Information Technology
170.200 Applicability.
170.202 Transport standards for exchanging electronic health 
information.
170.205 Content exchange and vocabulary standards for exchanging 
electronic health information.
170.210 Standards for health information technology to protect 
electronic health information created, maintained, and exchanged.
170.299 Incorporation by reference.
Subpart C--Certification Criteria for Health Information Technology
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.

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

Subpart A--General Provisions


Sec.  170.100  Statutory basis and purpose.

    The provisions of this subchapter implement section 3004 of the 
Public Health Service Act.


Sec.  170.101  Applicability.

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


Sec.  170.102  Definitions.

    For the purposes of this part:
    Certification criteria means criteria:
    (1) To establish that health information technology meets 
applicable standards and implementation specifications adopted by the 
Secretary; or
    (2) That are used to test and certify that health information 
technology includes required capabilities.

[[Page 2043]]

    Certified EHR Technology means 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.
    Complete EHR means EHR technology that has been developed to meet 
all applicable certification criteria adopted by the Secretary.
    Disclosure means the release, transfer, provision of access to, or 
divulging in any other manner of information outside the entity holding 
the information.
    EHR Module means any service, component, or combination thereof 
that can meet the requirements of at least one certification criterion 
adopted by the Secretary.
    Implementation specification means specific requirements or 
instructions for implementing a standard.
    Qualified EHR means an electronic record of health-related 
information on an individual that:
    (1) Includes patient demographic and clinical health information, 
such as medical history and problem lists; 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.
    Standard means a technical, functional, or performance-based rule, 
condition, requirement, or specification that stipulates instructions, 
fields, codes, data, materials, characteristics, or actions.

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


Sec.  170.200  Applicability.

    The standards and implementation specifications adopted in this 
part apply with respect to Complete EHRs and EHR Modules. When a 
section of this part includes adoption of both a standard and at least 
one alternative standard, use of the specified standard or alternatives 
will be considered compliant.


Sec.  170.202  Transport standards for exchanging electronic health 
information.

    The Secretary adopts the following standards to define the common 
transport methods that must be used to electronically exchange health 
information formatted in accordance with the standards adopted under 
Sec.  170.205.
    (a) Standard. The Organization for the Advancement of Structured 
Information Standards (OASIS) Simple Object Access Protocol (SOAP) 
Version 1.2 (incorporated by reference in Sec.  170.299).
    (b) Alternative standard. A stateless, client-server, cacheable 
communications protocol that adheres to the principles of 
Representational State Transfer (REST) must be used.


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

    (a) Patient summary record.
    (1) The Secretary adopts the following content exchange standards 
for the purposes of electronically exchanging a patient summary record 
or to use in creating an electronic copy of a patient summary record:
    (i) Standard. Health Level Seven Clinical Document Architecture 
(CDA) Release 2, Level 2 Continuity of Care Document (CCD) 
(incorporated by reference in Sec.  170.299).
    (ii) Alternative standard. ASTM E2369 Standard Specification for 
Continuity of Care Record and Adjunct to ASTM E2369 (incorporated by 
reference in Sec.  170.299).
    (2) The Secretary adopts the following vocabulary standards for the 
purposes of specifying the code set, terminology, or nomenclature to 
use to represent health information included in a patient summary 
record:
    (i) Problem list.
    (A) Standard. The code set specified for the conditions specified 
at 45 CFR 162.1002(a)(1).
    (B) Alternative 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).
    (ii) Procedures.
    (A) Standard. The code set specified at 45 CFR 162.1002(a)(2).
    (B) Alternative standard. The code set specified at 45 CFR 
162.1002(a)(5).
    (iii) Laboratory orders and results.
    (A) Standard. Logical Observation Identifiers Names and Codes 
(LOINC[reg]) version 2.27, when such codes were received within an 
electronic transaction from a laboratory (incorporated by reference in 
Sec.  170.299).
    (B) [Reserved]
    (iv) Medication list.
    (A) Standard. Any 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.
    (B) [Reserved]
    (b) Drug formulary check. The Secretary adopts the following 
content exchange standard for transmitting formulary and benefits 
information between prescribers and Medicare Part D sponsors.
    (1) Standard. Drug formulary and benefits information must be 
transmitted in accordance with 42 CFR 423.160(b)(5).
    (2) [ Reserved]
    (c) Electronically transmitting prescription information.
    (1) The Secretary adopts the following content exchange standard to 
provide for the transmission of a prescription or prescription-related 
information.
    (i) Standard. An electronic prescription for a Medicare Part D 
covered drug that is prescribed for a Medicare Part D eligible 
individual must be transmitted in accordance with 42 CFR 
423.160(b)(2)(ii), in all other circumstances, if consistent with 
applicable state and other Federal law, electronic prescriptions may be 
transmitted in accordance with 42 CFR 423.160(b)(2)(ii) or using the 
NCPDP SCRIPT Standard, Implementation Guide, Version 10.6 (incorporated 
by reference in Sec.  170.299).
    (ii) [ Reserved]
    (2) The Secretary adopts the following vocabulary standard for the 
purposes of specifying the code set to use to represent health 
information included in electronic prescriptions.
    (i) Standard. Any 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.
    (ii) [ Reserved]
    (d) Electronically exchange administrative transactions. The 
Secretary adopts the following content exchange standards and 
associated implementation specifications for the following electronic 
transactions.
    (1) Standard and implementation specifications. An eligibility for 
a health plan transaction as defined at 45 CFR 162.1201 must be 
conducted in accordance with:
    (i) 45 CFR 162.1202(b) or for the period on and after January 1, 
2012, in accordance with 45 CFR 162.1202(c); and
    (ii) The operating rules specified in Phase 1 of the Council for 
Affordable Quality Healthcare (CAQH) Committee on Operating Rules for 
Information Exchange (CORE) (incorporated by reference in Sec.  
170.299).

[[Page 2044]]

    (2) Standard and implementation specifications. Eligibility inquiry 
and response transactions between dispensers and Part D sponsors for 
Part D prescription drugs must be conducted in accordance with 42 CFR 
423.160(b)(3)(ii).
    (3) Standard and implementation specifications. A health care 
claims or equivalent encounter information transaction as defined at 45 
CFR 162.1101 must be conducted in accordance with 45 CFR 162.1102(b) or 
for the period on and after January 1, 2012, in accordance with 45 CFR 
162.1102(c).
    (e) Electronically exchange quality reporting information. The 
Secretary adopts the following content exchange standard and 
implementation specification for quality reporting.
    (1) Standard. The CMS Physician Quality Reporting Initiative (PQRI) 
2008 Registry XML Specification (incorporated by reference in Sec.  
170.299).
    (2) Implementation specification. Physician Quality Reporting 
Initiative Measure Specifications Manual for Claims and Registry 
(incorporated by reference in Sec.  170.299).
    (f) Electronic submission of lab results to public health agencies.
    (1) The Secretary adopts the following content exchange standard 
for the electronic submission of lab results to public health agencies.
    (i) Standard. HL7 2.5.1(incorporated by reference in Sec.  
170.299).
    (ii) [ Reserved]
    (2) The Secretary adopts the following vocabulary standard for the 
purposes of representing lab results in an electronic submission to 
public health authorities.
    (i) Standard. Logical Observation Identifiers Names and Codes 
(LOINC[reg]), version 2.27, when such codes were received within an 
electronic transaction from a laboratory (incorporated by reference in 
Sec.  170.299).
    (ii) [ Reserved]
    (g) Electronic submission to public health agencies for 
surveillance or reporting. The Secretary adopts the following content 
exchange standards for electronic submission to public health agencies 
for surveillance or reporting:
    (1) Standard. HL7 2.3.1 (incorporated by reference in Sec.  
170.299).
    (2) Alternative standard. HL7 2.5.1 (incorporated by reference in 
Sec.  170.299).
    (h) Electronic submission to immunization registries.
    (1) The Secretary adopts the following content exchange standards 
for electronic submission to immunization registries:
    (i) Standard. HL7 2.3.1 (incorporated by reference in Sec.  
170.299).
    (ii) Alternative standard. HL7 2.5.1 (incorporated by reference in 
Sec.  170.299).
    (2) The Secretary adopts the following vocabulary standard for 
electronic submissions to immunization registries.
    (i) Standard. HL7 Standard Code Set CVX--Vaccines Administered, 
July 30, 2009 version (incorporated by reference in Sec.  170.299).
    (ii) [Reserved]


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. A symmetric 128 bit fixed-block cipher algorithm 
capable of using a 128, 192, or 256 bit encryption key must be used.
    (2) Exchange. An encrypted and integrity protected link must be 
implemented.
    (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, 
deleted, or printed; and an indication of which action(s) occurred must 
also be recorded.
    (c) Verification that electronic health information has not been 
altered in transit. Standard. A secure hashing algorithm must be used 
to verify that electronic health information has not been altered in 
transit. The secure hash algorithm (SHA) used must be SHA-1 or higher.
    (d) Cross-enterprise authentication. A cross-enterprise secure 
transaction that contains sufficient identity information such that the 
receiver can make access control decisions and produce detailed and 
accurate security audit trails must be used.
    (e) 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 part 
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) Organization for the Advancement of Structured Information 
Standards (OASIS), Post Office Box 455, Billerica, MA 01821, http://www.oasis-open.org/home/index.php, Telephone: 978-667-5115.
    (1) Simple Object Access Protocol (SOAP), Version 1.2 (Second 
Edition), parts 0-2, W3C Recommendation April 27, 2007 (SOAP version 
1.2), IBR approved for Sec.  170.202.
    (i) SOAP version 1.2 PART 0: Primer;
    (ii) SOAP version 1.2 PART 1: Messaging Framework; and
    (iii) SOAP version 1.2 PART 2: Adjuncts.
    (2) [Reserved]
    (c) 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, February 21, 2007, IBR approved for Sec.  
170.205.
    (3) Health Level Seven Implementation Guide: Clinical Document 
Architecture (CDA) Release 2--Level 2 Continuity of Care Document 
(CCD), April 01, 2007, IBR approved for Sec.  170.205.
    (d) ASTM International, 100 Barr Harbor Drive, PO Box C700, West 
Conshohocken, PA, 19428-2959 USA; Telephone (610) 832-9585 or 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.

[[Page 2045]]

    (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.
    (e) 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) SCRIPT Standard, Implementation Guide, Version 10.6, October, 
2008, (Approval date for ANSI: November 12, 2008), IBR approved for 
Sec.  170.205.
    (2) [Reserved]
    (f) Council for Affordable Quality Healthcare (CAQH), 601 
Pennsylvania Avenue, NW., South Building, Suite 500, Washington, DC 
20004; Telephone (202) 861-1492 or http://www.caqh.org/CORE_phase1.php.
    (1) Committee on Operating Rules for Information Exchange (CORE) 
Phase I Eligibility and Benefits Operating Rules Manual, April, 2006, 
IBR approved for Sec.  170.205.
    (2) [Reserved]
    (g) 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.205.
    (2) [Reserved]
    (h) 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.205.
    (2) [Reserved]
    (i) 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.205.
    (2) [Reserved]
    (j) Centers for Medicare & Medicaid Services, Office of Clinical 
Standards and Quality, 7500 Security Boulevard, Baltimore, Maryland 
21244; Telephone (410) 786-3000.
    (1) CMS PQRI 2008 Registry XML Specification, December 10, 2008 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.

Subpart C--Certification Criteria for Health Information Technology


Sec.  170.300  Applicability.

    The certification criteria adopted in this subpart apply to the 
testing and certification of Complete EHRs and EHR Modules.


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 and in accordance with all applicable standards and 
implementation specifications adopted in this part:
    (a) Drug-drug, drug-allergy, drug-formulary checks.
    (1) Alerts. Automatically and electronically generate and 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).
    (2) Formulary checks. Enable a user to electronically check if 
drugs are in a formulary or preferred drug list in accordance with the 
standard specified in Sec.  170.205(b).
    (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.
    (b) 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.205(a)(2)(i)(A); or
    (2) At a minimum, the version of the standard specified in Sec.  
170.205(a)(2)(i)(B).
    (c) 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 in 
accordance with the standard specified in Sec.  170.205(a)(2)(iv).
    (d) 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.
    (e) 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, the 
height, weight, blood pressure, temperature, and pulse.
    (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.
    (f) Smoking status. Enable a user to electronically record, modify, 
and retrieve the smoking status of a patient. Smoking status types must 
include: current smoker, former smoker, or never smoked.
    (g) 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 codes in readable format. Electronically display in 
human readable format any clinical laboratory tests that have been 
received with LOINC[reg] codes.
    (3) Display test report information. Electronically display all the 
information for a 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.
    (h) Generate patient lists. Enable a user to electronically select, 
sort, retrieve, and output a list of patients and patients' clinical 
information, based on user-defined demographic data, medication list, 
and specific conditions.
    (i) Report quality measures.
    (1) Display. Calculate and electronically display quality measures 
as specified by CMS or states.
    (2) Submission. Enable a user to electronically submit calculated 
quality measures in accordance with the standard and implementation 
specifications specified in Sec.  170.205(e).
    (j) Check insurance eligibility. 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).
    (k) Submit claims. Enable a user to electronically submit claims to 
public or private payers in accordance with the standard and 
implementation

[[Page 2046]]

specifications specified in Sec.  170.205(d)(3).
    (l) Medication reconciliation. Electronically complete medication 
reconciliation of two or more medication lists by comparing and merging 
into a single medication list that can be electronically displayed in 
real-time.
    (m) Submission to immunization registries. Electronically record, 
retrieve, and transmit immunization information to immunization 
registries in accordance with:
    (1) One of the standards specified in Sec.  170.205(h)(1) and, at a 
minimum, the version of the standard specified in Sec.  170.205(h)(2); 
or
    (2) The applicable state-designated standard format.
    (n) Public health surveillance. Electronically record, retrieve, 
and transmit syndrome-based public health surveillance information to 
public health agencies in accordance with one of the standards 
specified in Sec.  170.205(g).
    (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) Alerts. Provide alerts based on user-defined events.
    (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.
    (s) Integrity.
    (1) In transit. Verify that electronic health information has not 
been altered in transit in accordance with the standard specified in 
Sec.  170.210(c).
    (2) Detection. Detect the alteration and deletion of electronic 
health information and audit logs, in accordance with the standard 
specified in Sec.  170.210(c).
    (t) Authentication.
    (1) Local. Verify that a person or entity seeking access to 
electronic health information is the one claimed and is authorized to 
access such information.
    (2) Cross network. Verify that a person or entity seeking 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).
    (u) Encryption.
    (1) General. Encrypt and decrypt electronic health information 
according to user-defined preferences in accordance with the standard 
specified in Sec.  170.210(a)(1).
    (2) Exchange. Encrypt and decrypt electronic health information 
when exchanged in accordance with the standard specified in Sec.  
170.210(a)(2).
    (v) Accounting of disclosures. Record disclosures made for 
treatment, payment, and health care operations in accordance with the 
standard specified in Sec.  170.210(e).


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 manage, at a minimum, the 
following order types:
    (1) Medications;
    (2) Laboratory;
    (3) Radiology/imaging; and
    (4) Provider referrals.
    (b) Electronically exchange prescription information. Enable a user 
to electronically transmit medication orders (prescriptions) for 
patients in accordance with the standards specified in Sec.  
170.205(c).
    (c) Record demographics. Enable a user to electronically record, 
modify, and retrieve patient demographic data including preferred 
language, insurance type, gender, race, ethnicity, and date of birth.
    (d) Generate patient reminder list. Electronically generate, upon 
request, a patient reminder list for preventive or follow-up care 
according to patient preferences based on demographic data, specific 
conditions, and/or medication list.
    (e) Clinical decision support.
    (1) Implement rules. Implement automated, electronic clinical 
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.
    (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, 
medication allergy list, immunizations, and procedures 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).
    (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, medication allergy list, 
immunizations, and procedures.
    (h) Clinical summaries.
    (1) Provision. 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, 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).

[[Page 2047]]

    (i) Exchange clinical information and patient summary record.
    (1) Electronically receive and display. Electronically receive a 
patient's summary record, from other providers and 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:
    (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).


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 manage, at a minimum, the 
following order types:
    (1) Medications;
    (2) Laboratory;
    (3) Radiology/imaging;
    (4) Blood bank;
    (5) Physical therapy;
    (6) Occupational therapy;
    (7) Respiratory therapy;
    (8) Rehabilitation therapy;
    (9) Dialysis;
    (10) Provider consults; and
    (11) Discharge and transfer.
    (b) Record demographics. Enable a user to electronically record, 
modify, and retrieve patient demographic data including preferred 
language, insurance type, gender, race, ethnicity, date of birth, and 
date and cause of death in the event of mortality.
    (c) Clinical decision support.
    (1) Implement rules. Implement automated, electronic clinical 
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.
    (d) 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, 
medication allergy list, immunizations, procedures, and 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).
    (e) Electronic copy of discharge information. Enable a user to 
create an electronic copy of the discharge instructions and procedures 
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 summary record.
    (1) Electronically receive and display. Electronically receive a 
patient's summary record from other providers and 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);
    (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).
    (g) Reportable lab results. Electronically record, retrieve, and 
transmit reportable clinical lab results to public health agencies in 
accordance with the standard specified in Sec.  170.205(f)(1) and, at a 
minimum, the version of the standard specified in Sec.  170.205(f)(2).

    Dated: December 28, 2009.
Kathleen Sebelius,
Secretary.
[FR Doc. E9-31216 Filed 12-30-09; 4:15 pm]
BILLING CODE 4150-45-P