Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, 2014-2047 [E9-31216]
Download as PDF
2014
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
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
erowe on DSK5CLS3C1PROD with RULES_2
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
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
comments. Attachments should be in
Microsoft Word, WordPerfect, or Excel;
however, we prefer Microsoft Word.
https://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 https://
www.regulations.gov.
Docket: For access to the docket to
read background documents or
comments received, go to https://
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:
PO 00000
Frm 00002
Fmt 4701
Sfmt 4700
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
E:\FR\FM\13JAR2.SGM
13JAR2
erowe on DSK5CLS3C1PROD with RULES_2
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
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
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
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
PO 00000
Frm 00003
Fmt 4701
Sfmt 4700
2015
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
E:\FR\FM\13JAR2.SGM
13JAR2
2016
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
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).
erowe on DSK5CLS3C1PROD with RULES_2
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
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
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
PO 00000
Frm 00004
Fmt 4701
Sfmt 4700
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
E:\FR\FM\13JAR2.SGM
13JAR2
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
erowe on DSK5CLS3C1PROD with RULES_2
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 antikickback 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
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
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
PO 00000
Frm 00005
Fmt 4701
Sfmt 4700
2017
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.
E:\FR\FM\13JAR2.SGM
13JAR2
2018
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
erowe on DSK5CLS3C1PROD with RULES_2
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
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
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
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.’’
PO 00000
Frm 00006
Fmt 4701
Sfmt 4700
implemented, acquired, or upgraded
‘‘health information technology systems
used for the direct exchange of health
information between agencies and with
non-Federal entities.’’
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
E:\FR\FM\13JAR2.SGM
13JAR2
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
erowe on DSK5CLS3C1PROD with RULES_2
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
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
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
PO 00000
Frm 00007
Fmt 4701
Sfmt 4700
2019
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
E:\FR\FM\13JAR2.SGM
13JAR2
erowe on DSK5CLS3C1PROD with RULES_2
2020
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
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 Coordinatorendorsed 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
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
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 Coordinatorendorsed 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.
PO 00000
Frm 00008
Fmt 4701
Sfmt 4700
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®) 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
E:\FR\FM\13JAR2.SGM
13JAR2
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
erowe on DSK5CLS3C1PROD with RULES_2
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
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
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—§ 170.101
This part establishes the applicable
standards, implementation
specifications, and certification criteria
that must be used to test and certify
HIT.
B. Definitions—§ 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
We believe the types of standards
envisioned by Congress in the HITECH
Act that would be most applicable to
2 This last definition is referenced in Federal
Information Processing Standards 201.
PO 00000
Frm 00009
Fmt 4701
Sfmt 4700
2021
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
E:\FR\FM\13JAR2.SGM
13JAR2
2022
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
erowe on DSK5CLS3C1PROD with RULES_2
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
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
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
PO 00000
Frm 00010
Fmt 4701
Sfmt 4700
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
E:\FR\FM\13JAR2.SGM
13JAR2
erowe on DSK5CLS3C1PROD with RULES_2
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
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
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
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.
PO 00000
Frm 00011
Fmt 4701
Sfmt 4700
2023
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 §§ 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
E:\FR\FM\13JAR2.SGM
13JAR2
erowe on DSK5CLS3C1PROD with RULES_2
2024
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
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®) 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
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
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
PO 00000
Frm 00012
Fmt 4701
Sfmt 4700
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
E:\FR\FM\13JAR2.SGM
13JAR2
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
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 9digit 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
2025
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 CVXVaccines 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
Proposed meaningful use Stage 1 objectives
Certification criteria to support the
achievement of meaningful use Stage 1 by eligible professionals
Certification criteria to support the
achievement of meaningful use Stage 1 by eligible hospital
A Complete EHR or EHR Module must include the capability to:
erowe on DSK5CLS3C1PROD with RULES_2
Use Computerized
(CPOE) 3.
VerDate Nov<24>2008
Provider
14:41 Jan 12, 2010
Order
Jkt 220001
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
PO 00000
Frm 00013
Fmt 4701
Sfmt 4700
Enable a user to electronically record, store,
retrieve, and manage, at a minimum, the
following order types:
1. Medications;
2. Laboratory;
3. Radiology/imaging;
E:\FR\FM\13JAR2.SGM
13JAR2
2026
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
TABLE 1—CERTIFICATION CRITERIA—Continued
Proposed meaningful use Stage 1 objectives
Certification criteria to support the
achievement of meaningful use Stage 1 by eligible professionals
4. Provider referrals.
Implement drug-drug, drug-allergy, drug-formulary checks.
Maintain an up-to-date problem list of current
and active diagnoses based on ICD–9–CM
or SNOMED CT®.
Certification criteria to support the
achievement of meaningful use Stage 1 by eligible hospital
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.
1. Automatically and electronically generate and indicate (e.g., pop-up 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 drugdrug and drug-allergy checking.
4. Automatically and electronically track, record, and generate reports on the number of alerts
responded to by a user.
Enable a user to electronically record, modify, and retrieve a patient’s problem list for longitudinal care (i.e., over multiple office visits) in accordance with the applicable standards% specified in Table 2A row 1.
Enable a user to electronically transmit medication orders (prescriptions) for patients in
accordance with the standards specified in
Table 2A row 3.
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 (i.e., over multiple office visits) in accordance
with the applicable standard specified in Table 2A row 1.
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 (i.e., over multiple office visits).
Record demographics 4 5 ....................................
Enable a user to electronically record, modify,
and retrieve patient demographic data including preferred language, insurance type,
gender, race, ethnicity, and date of birth.
Record and chart changes in vital signs:
• Height
• Weight
• Blood pressure
• Calculate and display: BMI
• Plot and display growth charts for children 2–20 years, including BMI.
Record smoking status for patients 13 years
old or older.
Incorporate clinical lab-test results into EHR as
structured data.
erowe on DSK5CLS3C1PROD with RULES_2
Generate and transmit permissible prescriptions electronically (eRx).
1. 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. Automatically calculate and display body mass index (BMI) based on a patient’s height and
weight.
3. Plot and electronically display, upon request, growth charts (height, weight, and BMI) for patients 2–20 years old.
Generate lists of patients by specific conditions
to use for quality improvement, reduction of
disparities, and outreach.
Report quality measures to CMS or the
States 7 8.
No Associated Proposed Meaningful Use
Stage 1 Objective.
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.
Enable a user to electronically record, modify, and retrieve the smoking status of a patient to:
current smoker, former smoker, or never smoked.
1. Electronically receive clinical laboratory test results in a structured 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® 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.
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.
1. Calculate and electronically display 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.
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
PO 00000
Frm 00014
Fmt 4701
Sfmt 4700
E:\FR\FM\13JAR2.SGM
13JAR2
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
2027
TABLE 1—CERTIFICATION CRITERIA—Continued
Certification criteria to support the
achievement of meaningful use Stage 1 by eligible professionals
Certification criteria to support the
achievement of meaningful use Stage 1 by eligible hospital
Send reminders to patients per patient preference for preventive/follow up care.
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.
No Associated Proposed Meaningful Use
Stage 1 Objective.
Implement 5 clinical decision support rules 9 10
1. 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. Automatically and electronically generate
and indicate (e.g., pop-up message or
sound) in real-time, alerts and care suggestions based upon clinical decision support
rules and evidence grade.
3. Automatically and electronically track,
record, and generate reports on the number
of alerts responded to by a user.
1. 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. Automatically and electronically generate
and indicate (e.g., pop-up message or
sound) in real-time, alerts and care suggestions based upon clinical decision support
rules and evidence grade.
3. Automatically and electronically track,
record, and generate reports on the number
of alerts responded to by a user.
Check insurance eligibility electronically from
public and private payers.
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 specified in Table 2A row 4.
Enable a user to electronically submit claims to public or private payers in accordance with the
applicable standards specified in Table 2A row 4.
Proposed meaningful use Stage 1 objectives
Submit claims electronically to public and private payers.
Provide patients with an electronic copy of their
health information upon request 11 12.
Provide patients with an electronic copy of their
discharge instructions and procedures at
time of discharge, upon request.
erowe on DSK5CLS3C1PROD with RULES_2
Provide patients with timely electronic access
to their health information (including lab results, problem list, medication lists, allergies)
within 96 hours of the information being
available to the eligible professional.
Provide clinical summaries for patients for each
office visit.
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
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) accordance with the standards% specified in Table
2A row 1 to provide to a patient on electronic media, or through some other electronic means.
No Associated Proposed Meaningful Use
Stage 1 Objective.
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.
1. Enable a user to provide clinical summaries
to patients (in paper or electronic form) for
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.
PO 00000
Frm 00015
Fmt 4701
Sfmt 4700
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, discharge summary, and
procedures 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.
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 to provide to a patient
on electronic media, or through some other
electronic means.
No Associated Proposed Meaningful Use
Stage 1 Objective.
No Associated Proposed Meaningful Use
Stage 1 Objective.
E:\FR\FM\13JAR2.SGM
13JAR2
2028
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
TABLE 1—CERTIFICATION CRITERIA—Continued
Certification criteria to support the
achievement of meaningful use Stage 1 by eligible professionals
Certification criteria to support the
achievement of meaningful use Stage 1 by eligible hospital
Capability to exchange key clinical information
among providers of care and patient authorized entities electronically 13 14.
Provide summary care record for each transition of care and referral.
1. Electronically receive a patient summary
record, from other providers and organizations including, at a minimum, diagnostic
test results, problem list, medication list,
medication allergy list, immunizations, and
procedures and upon receipt of a patient
summary record formatted in an alternative
standard specified in Table 2A row 1, displaying it in human readable format.
2. Enable a user to electronically transmit a
patient summary record to other providers
and organizations including, at a minimum,
diagnostic test results, problem list, medication list, medication allergy list, immunizations, and procedures in accordance with
the standards% specified in Table 2A row 1.
1. Electronically receive a patient summary
record, from other providers and organizations including, at a minimum, discharge
summary, diagnostic test results, problem
list, medication list, medication allergy list,
immunizations, and procedures and upon
receipt of a patient summary record formatted in an alternative standard specified
in Table 2A row 1, displaying it in human
readable format.
2. Enable a user to electronically transmit a
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 reconciliation at relevant
encounters and each transition of care.
Capability to submit electronic data to immunization registries and actual submission
where required and accepted.
Electronically complete medication reconciliation of two or more medication lists (compare and
merge) into a single medication list that can be electronically displayed in real-time.
Electronically record, retrieve, and transmit immunization information to immunization registries
in accordance with the standards% specified in Table 2A row 8 or in accordance with the applicable state-designated standard format.
Capability to provide electronic submission of
reportable lab results (as required by state or
local law) to public health agencies and actual submission where it can be received.
No Associated Proposed Meaningful Use
Stage 1 Objective.
Capability to provide electronic syndromic surveillance data to public health agencies and
actual transmission according to applicable
law and practice.
Protect electronic health information created or
maintained by the certified EHR technology
through the implementation of appropriate
technical capabilities.
Electronically record, retrieve, and transmit syndrome-based (e.g., influenza like illness) public
health surveillance information to public health agencies in accordance with the standards
specified in Table 2A row 7.
erowe on DSK5CLS3C1PROD with RULES_2
Proposed meaningful use Stage 1 objectives
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
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
Electronically record, retrieve, and transmit reportable clinical lab results to public health
agencies in accordance with the standards%
specified in Table 2A row 6.
1. 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.
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.
Module must be capable of plotting and
displaying growth charts for patients. By
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
PO 00000
Frm 00016
Fmt 4701
Sfmt 4700
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
E:\FR\FM\13JAR2.SGM
13JAR2
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
erowe on DSK5CLS3C1PROD with RULES_2
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.
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
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.’’
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
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.
• 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
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.
PO 00000
Frm 00017
Fmt 4701
Sfmt 4700
2029
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
E:\FR\FM\13JAR2.SGM
13JAR2
erowe on DSK5CLS3C1PROD with RULES_2
2030
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
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®) codes from a
laboratory, retaining those LOINC®
codes, and using LOINC® 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®
codes. Rather, we require that Certified
EHR Technology be capable of using
LOINC® codes that are received and
retained to populate a patient summary
record. Moreover, having LOINC® 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®,
Systematized Nomenclature of Medicine
Clinical Terms (SNOMED CT®), and
other vocabulary standards will
accelerate the adoption and use of
clinical decision support. Requiring
LOINC® 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
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
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
16 https://www.whitehouse.gov/omb/
circulars_a119.
PO 00000
Frm 00018
Fmt 4701
Sfmt 4700
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.
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
E:\FR\FM\13JAR2.SGM
13JAR2
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
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
erowe on DSK5CLS3C1PROD with RULES_2
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
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
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® to populate a problem
list and ICD–9–CM or American
Medical Association (AMA) Current
Procedural Terminology (CPT®) 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® to populate information in a
patient summary record related to lab
orders and results when LOINC® codes
have been received from a laboratory
and are retained and subsequently
available to Certified EHR Technology.
In instances where LOINC® 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® codes in order to
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
https://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.
PO 00000
Frm 00019
Fmt 4701
Sfmt 4700
2031
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 ingredientbased 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.
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
E:\FR\FM\13JAR2.SGM
13JAR2
2032
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
erowe on DSK5CLS3C1PROD with RULES_2
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,
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
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:
Æ 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
Æ 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):
Æ 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
Æ 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
Æ 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
PO 00000
Frm 00020
Fmt 4701
Sfmt 4700
Interchange Technical Report Type 3—
Health Care Claim: Professional (837),
(ASC X12N/005010X222); and
Æ 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.
Æ 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
E:\FR\FM\13JAR2.SGM
13JAR2
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
of UCUM and SNOMED CT® for this
exchange in the future would lead to
improved interoperability.
submission of information to public
health agencies for surveillance and
reporting purposes.
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
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.
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
2033
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
Row No.
Purpose
Category
Adopted standard(s) to support meaningful use stage 1
Candidate standard(s) to support
meaningful use stage 2
1 .............
Patient Summary Record ....................
Cx ..........
HL7 CDA R2 CCD Level 2 or ASTM
CCR.
• Problem List .....................................
V ............
• Medication List .................................
V ............
• Medication Allergy List .....................
• Procedures .......................................
V ............
V ............
Applicable HIPAA code set required
by law (i.e., ICD–9–CM); or
SNOMED CT®.
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∂.
No standard adopted at this time ........
Applicable HIPAA code sets required
by law (i.e., ICD–9–CM or CPT–4®).
Alternatives expected to be narrowed
based on HIT Standards Committee
recommendations.
Applicable HIPAA code set required
by law (e.g., ICD–10–CM) or
SNOMED CT®.
RxNorm.
• Vital Signs ........................................
• Units of Measure .............................
• Lab Orders and Results ..................
V ............
V ............
V ............
2 .............
Drug Formulary Check ........................
Cx ..........
3 .............
Electronic Prescribing ..........................
Cx ..........
erowe on DSK5CLS3C1PROD with RULES_2
V ............
4 .............
Administrative Transactions ................
Cx ..........
5 .............
Quality Reporting .................................
Cx ..........
18 The CDC’s National Center of Immunization
and Respiratory Diseases (NCIRD) maintains the
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
No standard adopted at this time ........
No standard adopted at this time ........
LOINC® when LOINC® codes have
been received from a laboratory.
Applicable Part D standard required
by law (i.e., NCPDP Formulary &
Benefits Standard 1.0).
Applicable Part D standard required
by law (e.g., NCPDP SCRIPT 8.1)
or NCPDP SCRIPT 8.1 and NCPDP
SCRIPT 10.6.
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∂.
Applicable HIPAA transaction standards required by law.
CMS PQRI 2008 Registry XML Specification #,∂.
UNII.
Applicable HIPAA code sets required
by law (i.e., ICD–10–PCS or CPT–
4®).
CDA template.
UCUM.
LOINC®.
Applicable Part D standard required
by law.
NCPDP SCRIPT 10.6.
RxNorm.
Applicable HIPAA transaction standards required by law.
Potentially newer version(s) or standards based on HIT Standards Committee Input.
HL7 external code set CVX https://www.cdc.gov/
vaccines/programs/iis/stds/cvx.htm.
PO 00000
Frm 00021
Fmt 4701
Sfmt 4700
E:\FR\FM\13JAR2.SGM
13JAR2
2034
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
TABLE 2A—ADOPTED CONTENT EXCHANGE AND VOCABULARY STANDARDS—Continued
Row No.
Purpose
Category
Adopted standard(s) to support meaningful use stage 1
Candidate standard(s) to support
meaningful use stage 2
6 .............
Submission of Lab Results to Public
Health Agencies.
Cx ..........
HL7 2.5.1 .............................................
V ............
LOINC® when LOINC® codes have
been received from a laboratory.
Cx ..........
HL7 2.3.1 or HL7 2.5.1 .......................
V ............
According to Applicable Public Health
Agency Requirements.
Cx ..........
HL7 2.3.1 or HL7 2.5.1 .......................
V ............
CVX*,∂ ................................................
Potentially newer version(s) or standards based on HIT Standards Committee Recommendations.
LOINC®, UCUM, and SNOMED CT®
or Applicable Public Health Agency
Requirements.
Potentially newer version(s) or standards based on HIT Standards Committee Input.
GIPSE or According to Applicable
Public Health Agency Requirements.
Potentially newer version(s) or standards based on HIT Standards Committee Recommendations.
CVX.
7 .............
erowe on DSK5CLS3C1PROD with RULES_2
8 .............
Submission to Public Health Agencies
for Surveillance or Reporting (excluding adverse event reporting).
Submission
istries.
to
Immunization
Reg-
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.
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
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
PO 00000
Frm 00022
Fmt 4701
Sfmt 4700
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
E:\FR\FM\13JAR2.SGM
13JAR2
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
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
2035
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 Decryption of
Electronic Health Information.
2 ...............
3 ...............
Encryption and Decryption of Electronic
Health Information for Exchange.
Record Actions Related to Electronic
Health Information (i.e., audit log).
4 ...............
Verification that Electronic Health Information has not been Altered in Transit.
5 ...............
Cross-Enterprise Authentication .................
6 ...............
Record Treatment, Payment, and Health
Care Operations Disclosures.
A symmetric 128 bit fixed-block cipher algorithm capable of using a 128, 192, or 256
bit encryption key must be used (e.g., FIPS 197 Advanced Encryption Standard,
(AES), Nov 2001).∂
An encrypted and integrity protected link must be implemented (e.g., TLS, IPv6, IPv4
with IPsec).∂
The date, time, patient identification (name or number), and user 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).∂
A secure hashing algorithm must be used to verify that electronic health information
has not been 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).∂
Use of 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 (e.g., IHE Cross Enterprise User Assertion (XUA)
with SAML identity assertions).∂
The date, time, patient identification (name or number), user identification (name or
number), and a description of the disclosure must be recorded.∂
erowe on DSK5CLS3C1PROD with RULES_2
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
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
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 welldefined 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
PO 00000
Frm 00023
Fmt 4701
Sfmt 4700
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
E:\FR\FM\13JAR2.SGM
13JAR2
2036
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
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.
erowe on DSK5CLS3C1PROD with RULES_2
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,
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
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).
PO 00000
Frm 00024
Fmt 4701
Sfmt 4700
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.
We intend for our adoption of a basic
certification criterion and standard to
account for disclosures (§ 170.302(v)
and § 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:
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.
E:\FR\FM\13JAR2.SGM
13JAR2
erowe on DSK5CLS3C1PROD with RULES_2
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
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
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
date for the revised accounting-fordisclosure 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
PO 00000
Frm 00025
Fmt 4701
Sfmt 4700
2037
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
E:\FR\FM\13JAR2.SGM
13JAR2
2038
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
erowe on DSK5CLS3C1PROD with RULES_2
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.
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
20 https://sba.gov/idc/groups/public/documents/
sba_homepage/serv_sstd_tablepdf.pdf.
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
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 selfdeveloping Complete EHRs or EHR
Modules. The HIT Certification
Programs proposed rule estimates the
testing and certification costs for
Complete EHRs and EHR Modules.
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
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.
PO 00000
Frm 00026
Fmt 4701
Sfmt 4700
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
E:\FR\FM\13JAR2.SGM
13JAR2
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
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 CCHITcertified-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-certifiedEHRs 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 CCHITcertified-EHRs will be tested and
certified as EHR Modules rather than
Complete EHRs. Given these
assumptions we have estimated the
number of previously CCHIT-certifiedEHRs 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.
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
2039
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 CCHITcertified 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
Number
prepared for
certification
Type
erowe on DSK5CLS3C1PROD with RULES_2
2008 Ambulatory CCHIT-CertifiedEHR ..............................................
2007/2008 Inpatient CCHIT-Certified-EHR .....................................
14:41 Jan 12, 2010
Jkt 220001
Low
High
Total cost for all EHRs over 3-year period
($M)
Mid-point
65
$0.50
$1.5
15
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
VerDate Nov<24>2008
One time cost per EHR ($M)
0.75
2.0
$1.0
Frm 00027
Fmt 4701
Sfmt 4700
$32.5
1.38
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
PO 00000
Low
11.25
High
$97.5
30.0
Mid-point
$65.0
20.63
transactions.’’ We do not believe that these caveats
have any effect on our estimates.
23 https://www.cchit.org/products/Ambulatory—
when certification years 2006 and 2007 are
unchecked.
24 https://www.cchit.org/products/Inpatient.
E:\FR\FM\13JAR2.SGM
13JAR2
2040
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
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—Continued
One time cost per EHR ($M)
Number
prepared for
certification
Type
Total ..........................................
Low
80
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
Total cost for all EHRs over 3-year period
($M)
High
Mid-point
....................
....................
......................
market due to the market share 26
represented by the previously CCHITcertified-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
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,
Low
43.75
High
127.50
Mid-point
85.63
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–CERTIFIEDEHRS TO BE PREPARED TO BE TESTED AND CERTIFIED AS COMPLETE EHRS (3-YEAR PERIOD)—TOTALS ROUNDED
Number
prepared for
certification
Type
One time cost per EHR ($M)
Low
High
Total cost for all EHRs over 3-year period
($M)
Mid-point
8
5
$1.2
1.8
$3.6
4.8
$2.4
3.3
Total ............................................
erowe on DSK5CLS3C1PROD with RULES_2
Complete EHRs for Eligible Professionals ............................................
Complete EHRs for Eligible Hospitals
13
....................
....................
Low
....................
$9.6
9.0
18.60
High
$28.8
24.0
52.80
Mid-point
$19.2
16.5
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.
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 https://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.
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
PO 00000
Frm 00028
Fmt 4701
Sfmt 4700
E:\FR\FM\13JAR2.SGM
13JAR2
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
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)
Number
prepared
Type
Low
High
Total cost all EHR modules over 3-year
period
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 low cost
estimate
($M)
Ratio
(percent)
Year
Total high cost
estimate
($M)
Total average
cost estimate
($M)
2010 .................................................................................................................
2011 .................................................................................................................
2012 .................................................................................................................
45
40
15
$30.31
26.94
10.10
$92.39
82.12
30.80
$61.35
54.53
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.
erowe on DSK5CLS3C1PROD with RULES_2
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
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
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
PO 00000
Frm 00029
Fmt 4701
Sfmt 4700
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
E:\FR\FM\13JAR2.SGM
13JAR2
2042
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
erowe on DSK5CLS3C1PROD with RULES_2
receipts 28 which ‘‘indicates the
maximum allowed for a concern and its
affiliates to be considered small
entities.’’
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
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. https://
www.sba.gov/idc/groups/public/documents/
sba_homepage/guide_to_size_standards.pdf.
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
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 inflationadjusted 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.
For the reasons set forth in the
preamble, the Department amends 45
CFR subtitle A to add subchapter D as
follows:
■
PO 00000
Frm 00030
Fmt 4701
Sfmt 4700
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
§ 170.100
Statutory basis and purpose.
The provisions of this subchapter
implement section 3004 of the Public
Health Service Act.
§ 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.
§ 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.
E:\FR\FM\13JAR2.SGM
13JAR2
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
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
erowe on DSK5CLS3C1PROD with RULES_2
§ 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.
§ 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
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
electronically exchange health
information formatted in accordance
with the standards adopted under
§ 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 § 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.
§ 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 § 170.299).
(ii) Alternative standard. ASTM
E2369 Standard Specification for
Continuity of Care Record and Adjunct
to ASTM E2369 (incorporated by
reference in § 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®) July
2009 version (incorporated by reference
in § 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®)
version 2.27, when such codes were
received within an electronic
transaction from a laboratory
(incorporated by reference in § 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
PO 00000
Frm 00031
Fmt 4701
Sfmt 4700
2043
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 § 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 § 170.299).
E:\FR\FM\13JAR2.SGM
13JAR2
erowe on DSK5CLS3C1PROD with RULES_2
2044
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
(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 § 170.299).
(2) Implementation specification.
Physician Quality Reporting Initiative
Measure Specifications Manual for
Claims and Registry (incorporated by
reference in § 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 § 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®),
version 2.27, when such codes were
received within an electronic
transaction from a laboratory
(incorporated by reference in § 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 § 170.299).
(2) Alternative standard. HL7 2.5.1
(incorporated by reference in § 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 § 170.299).
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
(ii) Alternative standard. HL7 2.5.1
(incorporated by reference in § 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 § 170.299).
(ii) [Reserved]
§ 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.
§ 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
PO 00000
Frm 00032
Fmt 4701
Sfmt 4700
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 https://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, https://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 § 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 https://www.hl7.org/.
(1) Health Level Seven Standard
Version 2.3.1 (HL7 2.3.1), An
Application Protocol for Electronic Data
Exchange in Healthcare Environments,
April 14, 1999, IBR approved for
§ 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
§ 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
§ 170.205.
(d) ASTM International, 100 Barr
Harbor Drive, PO Box C700, West
Conshohocken, PA, 19428–2959 USA;
Telephone (610) 832–9585 or https://
www.astm.org/.
(1) ASTM E2369–05: Standard
Specification for Continuity of Care
Record (CCR), year of adoption 2005,
ASTM approved July 17, 2006, IBR
approved for § 170.205.
E:\FR\FM\13JAR2.SGM
13JAR2
erowe on DSK5CLS3C1PROD with RULES_2
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
(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 § 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 https://
www.ncpdp.org.
(1) SCRIPT Standard, Implementation
Guide, Version 10.6, October, 2008,
(Approval date for ANSI: November 12,
2008), IBR approved for § 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 https://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
§ 170.205.
(2) [Reserved]
(g) Regenstrief Institute, Inc., LOINC®
c/o Medical Informatics The Regenstrief
Institute, Inc 410 West 10th Street, Suite
2000 Indianapolis, IN 46202–3012;
Telephone (317) 423–5558 or https://
loinc.org/.
(1) Logical Observation Identifiers
Names and Codes (LOINC®) version
2.27, June 15, 2009, IBR approved for
§ 170.205.
(2) [Reserved]
(h) U.S. National Library of Medicine,
8600 Rockville Pike, Bethesda, MD
20894; Telephone (301) 594–5983 or
https://www.nlm.nih.gov/.
(1) International Health Terminology
Standards Development Organization
Systematized Nomenclature of Medicine
Clinical Terms (SNOMED CT®),
International Release, July 2009, IBR
approved for § 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 § 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 § 170.205.
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
(2) 2009 Physician Quality Reporting
Initiative Measure Specifications
Manual for Claims and Registry, Version
3.0, December 8, 2008 IBR approved for
§ 170.205.
Subpart C—Certification Criteria for
Health Information Technology
§ 170.300
Applicability.
The certification criteria adopted in
this subpart apply to the testing and
certification of Complete EHRs and EHR
Modules.
§ 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, drugformulary 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 § 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
§ 170.205(a)(2)(i)(A); or
(2) At a minimum, the version of the
standard specified in
§ 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 § 170.205(a)(2)(iv).
(d) Maintain active medication allergy
list. Enable a user to electronically
record, modify, and retrieve a patient’s
PO 00000
Frm 00033
Fmt 4701
Sfmt 4700
2045
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® 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 § 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 § 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
E:\FR\FM\13JAR2.SGM
13JAR2
erowe on DSK5CLS3C1PROD with RULES_2
2046
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
specifications specified in
§ 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
§ 170.205(h)(1) and, at a minimum, the
version of the standard specified in
§ 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
§ 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 § 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 § 170.210(c).
(2) Detection. Detect the alteration
and deletion of electronic health
information and audit logs, in
accordance with the standard specified
in § 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
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
health information across a network is
the one claimed and is authorized to
access such information in accordance
with the standard specified in
§ 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 § 170.210(a)(1).
(2) Exchange. Encrypt and decrypt
electronic health information when
exchanged in accordance with the
standard specified in § 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 § 170.210(e).
§ 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 § 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,
PO 00000
Frm 00034
Fmt 4701
Sfmt 4700
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
§ 170.205(a)(1);
(ii) The standard specified in
§ 170.205(a)(2)(i)(A), or, at a minimum,
the version of the standard specified in
§ 170.205(a)(2)(i)(B);
(iii) One of the standards specified in
§ 170.205(a)(2)(ii);
(iv) At a minimum, the version of the
standard specified in § 170.205(a)(2)(iii);
and
(v) The standard specified in
§ 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
§ 170.205(a)(1);
(B) The standard specified in
§ 170.205(a)(2)(i)(A), or, at a minimum,
the version of the standard specified in
§ 170.205(a)(2)(i)(B);
(C) One of the standards specified in
§ 170.205(a)(2)(ii);
(D) At a minimum, the version of the
standard specified in § 170.205(a)(2)(iii);
and
(E) The standard specified in
§ 170.205(a)(2)(iv).
E:\FR\FM\13JAR2.SGM
13JAR2
Federal Register / Vol. 75, No. 8 / Wednesday, January 13, 2010 / Rules and Regulations
(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
§ 170.205(a) and upon receipt of a
patient summary record formatted in an
alternate standard specified in
§ 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
§ 170.205(a)(1);
(ii) The standard specified in
§ 170.205(a)(2)(i)(A), or, at a minimum,
the version of the standard specified in
§ 170.205(a)(2)(i)(B);
(iii) One of the standards specified in
§ 170.205(a)(2)(ii);
(iv) At a minimum, the version of the
standard specified in § 170.205(a)(2)(iii);
and
(v) The standard specified in
§ 170.205(a)(2)(iv).
§ 170.306 Specific certification criteria for
Complete EHRs or EHR Modules designed
for an inpatient setting.
erowe on DSK5CLS3C1PROD with RULES_2
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;
VerDate Nov<24>2008
14:41 Jan 12, 2010
Jkt 220001
(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
§ 170.205(a)(1);
(ii) The standard specified in
§ 170.205(a)(2)(i)(A), or, at a minimum,
the version of the standard specified in
§ 170.205(a)(2)(i)(B);
(iii) One of the standards specified in
§ 170.205(a)(2)(ii);
(iv) At a minimum, the version of the
standard specified in § 170.205(a)(2)(iii);
and
(v) The standard specified in
§ 170.205(a)(2)(iv).
(e) Electronic copy of discharge
information. Enable a user to create an
PO 00000
Frm 00035
Fmt 4701
Sfmt 9990
2047
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 § 170.205(a) and upon
receipt of a patient summary record
formatted in an alternate standard
specified in § 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
§ 170.205(a)(1);
(ii) The standard specified in
§ 170.205(a)(2)(i)(A), or, at a minimum,
the version of the standard specified in
§ 170.205(a)(2)(i)(B);
(iii) One of the standards specified in
§ 170.205(a)(2)(ii);
(iv) At a minimum, the version of the
standard specified in § 170.205(a)(2)(iii);
and
(v) The standard specified in
§ 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
§ 170.205(f)(1) and, at a minimum, the
version of the standard specified in
§ 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
E:\FR\FM\13JAR2.SGM
13JAR2
Agencies
[Federal Register Volume 75, Number 8 (Wednesday, January 13, 2010)]
[Rules and Regulations]
[Pages 2014-2047]
From the Federal Register Online via the Government Printing 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. https://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 https://www.regulations.gov.
Docket: For access to the docket to read background documents or
comments received, go to https://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 per