Federal Register, Volume 75 Issue 8 (Wednesday, January 13, 2010)

[Federal Register Volume 75, Number 8 (Wednesday, January 13, 2010)]
[Rules and Regulations]
[Pages 2014-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