[Federal Register Volume 79, Number 176 (Thursday, September 11, 2014)]
[Rules and Regulations]
[Pages 54430-54480]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2014-21633]
[[Page 54429]]
Vol. 79
Thursday,
No. 176
September 11, 2014
Part IV
Department of Health and Human Services
-----------------------------------------------------------------------
Office of the Secretary
-----------------------------------------------------------------------
45 CFR Part 170
2014 Edition Release 2 Electronic Health Record (EHR) Certification
Criteria and the ONC HIT Certification Program; Regulatory
Flexibilities, Improvements, and Enhanced Health Information Exchange;
Final Rule
Federal Register / Vol. 79 , No. 176 / Thursday, September 11, 2014 /
Rules and Regulations
[[Page 54430]]
-----------------------------------------------------------------------
DEPARTMENT OF HEALTH AND HUMAN SERVICES
Office of the Secretary
45 CFR Part 170
RIN 0991-AB92
2014 Edition Release 2 Electronic Health Record (EHR)
Certification Criteria and the ONC HIT Certification Program;
Regulatory Flexibilities, Improvements, and Enhanced Health Information
Exchange
AGENCY: Office of the National Coordinator for Health Information
Technology (ONC), Department of Health and Human Services.
ACTION: Final rule.
-----------------------------------------------------------------------
SUMMARY: This final rule introduces regulatory flexibilities and
general improvements for certification to the 2014 Edition EHR
certification criteria (2014 Edition). It also codifies a few revisions
and updates to the ONC HIT Certification Program for certification to
the 2014 Edition and future editions of certification criteria as well
as makes administrative updates to the Code of Federal Regulations.
DATES: This rule is effective October 14, 2014, except for the
amendments to the amendatory instruction number 3 amendment to Sec.
170.102, the amendments to Sec. Sec. 170.205, 170.207, 170.210,
170.302, 170.304, 170.306, and the amendatory instruction number 18
amendment to Sec. 170.550, which are effective on March 1, 2015.
The incorporation by reference of certain publications listed in
the rule is approved by the Director of the Federal Register as of
October 14, 2014.
FOR FURTHER INFORMATION CONTACT: Michael Lipinski, Office of Policy,
Office of the National Coordinator for Health Information Technology,
202-690-7151.
SUPPLEMENTARY INFORMATION:
Commonly Used Acronyms
CAH Critical Access Hospital
CDA Clinical Document Architecture
CDC Centers for Disease Control and Prevention
CDS Clinical Decision Support
CEHRT Certified Electronic Health Record Technology
CFR Code of Federal Regulations
CHPL Certified Health Information Technology Product List
CLIA Clinical Laboratory Improvement Amendments
CMS Centers for Medicare & Medicaid Services
CQM Clinical Quality Measure
CY Calendar Year
EH Eligible Hospital
EHR Electronic Health Record
EP Eligible Professional
FDA Food and Drug Administration
FY Fiscal Year
HHS Department of Health and Human Services
HIT Health Information Technology
HITECH Health Information Technology for Economic and Clinical
Health
HITPC HIT Policy Committee
HITSC HIT Standards Committee
HL7 Health Level Seven
IG Implementation Guide
IHE Integrating the Healthcare Enterprise[supreg]
LOINC[supreg] Logical Observation Identifiers Names and Codes
MU Meaningful Use
OMB Office of Management and Budget
ONC Office of the National Coordinator for Health Information
Technology
NCPDP National Council for Prescription Drug Programs
NIST National Institute of Standards and Technology
PHSA Public Health Service Act
SNOMED CT[supreg] Systematized Nomenclature of Medicine Clinical
Terms
Table of Contents
I. Executive Summary
A. Purpose of Regulatory Action
1. New Approach
2. Edition Naming Convention
B. Summary of Major Provisions
1. Overview of the 2014 Edition Release 2 EHR Certification
Criteria
2. ONC HIT Certification Program
C. Costs and Benefits
II. Background
A. Statutory Basis
1. Standards, Implementation Specifications, and Certification
Criteria
2. HIT Certification Programs
B. Regulatory History
1. Standards, Implementation Specifications, and Certification
Criteria Rules
2. ONC HIT Certification Programs Rules
III. Adopted Proposals
A. 2014 Edition Release 2 EHR Certification Criteria
1. National Technology Transfer and Advancement Act (NTTAA) of
1995
2. Certification Criteria
3. Gap Certification Eligibility Table for 2014 Edition Release
2
4. Base EHR Definition
B. ONC HIT Certification Program
1. Discontinuation of the Complete EHR
2. Applicability
3. ONC Regulations FAQ 28
4. Patient List Creation Certification Criteria
5. ISO/IEC 17065
6. ONC Certification Mark
C. Removal of the 2011 Edition EHR Certification Criteria From
the CFR
D. Removal of the Temporary Certification Program From the CFR
IV. Not Adopted Proposals
A. Not Adopted EHR Certification Criteria and Certification
Criteria Proposals
B. 2014 Edition and Proposed Voluntary Edition Equivalency Table
C. HIT Definitions
1. CEHRT
2. Common MU Data Set
C. ONC HIT Certification Program
1. Non-MU EHR Technology Certification
2. ``Certification Packages'' for EHR Modules
V. Comments Beyond the Scope of This Final Rule
VI. Collection of Information Requirements
VII. Regulatory Impact Statement
A. Statement of Need
B. Overall Impact
1. Executive Orders 12866 and 13563--Regulatory Planning and
Review Analysis
2. Regulatory Flexibility Act
3. Executive Order 13132--Federalism
4. Unfunded Mandates Reform Act of 1995
I. Executive Summary
A. Purpose of Regulatory Action
1. New Approach
In the notice of proposed rulemaking titled ``Voluntary 2015
Edition Electronic Health Record (EHR) Certification Criteria;
Interoperability Updates and Regulatory Improvements; Proposed Rule''
(79 FR 10880) (the ``Proposed Rule''), we gave many reasons for the
adoption of the proposed ``2015 Edition EHR certification criteria'' or
``2015 Edition'' (henceforth the ``Proposed Voluntary Edition'' (79 FR
10880)).\1\ We still believe that many of these reasons remain valid.
However, upon consideration of public comment, further reflection of
ONC goals and timelines, and a desire to adhere to the administration's
principles embodied in Executive Order (EO) 13563, we have not adopted
the Proposed Voluntary Edition. Rather, we have adopted a small subset
of our original proposals in the Proposed Voluntary Edition as optional
2014 Edition EHR certification criteria and made revisions to 2014
Edition EHR certification criteria (also referred to as the ``2014
Edition Release 2'' or ``2014 Edition Release 2 EHR certification
criteria'') that provide flexibility, clarity, and enhance health
information exchange; and administrative proposals (i.e., removal of
regulatory text from the Code of Federal Regulations) and proposals for
the ONC HIT Certification Program that provide improvements. The
certification criteria we have adopted in this final rule are
consistent with the principles and instructions for retrospective
review of regulations embodied in EO 13563 to make our program more
effective and less burdensome in achieving regulatory objectives. This
final rule introduces multiple means to reduce regulatory burden,
increase regulatory flexibility for stakeholders, and promote further
innovation.
---------------------------------------------------------------------------
\1\ 79 FR 10881-82.
---------------------------------------------------------------------------
[[Page 54431]]
We note that EHR technology developers do not have to update and
recertify their products to the 2014 Edition Release 2 nor do eligible
professionals (EPs), eligible hospitals (EHs), and critical access
hospitals (CAHs) have to upgrade to EHR technology certified to the
2014 Edition Release 2. However, we encourage EHR technology developers
and the EPs, EHs, and CAHs that they support to consider whether the
2014 Edition Release 2 offers any opportunities that they might want to
pursue.
2. Naming Conventions
In the Proposed Rule, we proposed to call the Proposed Voluntary
Edition the ``2015 Edition.'' \2\
---------------------------------------------------------------------------
\2\ 79 FR 10885.
---------------------------------------------------------------------------
Comments. Commenters indicated that attributing years to the
certification criteria editions creates unrealistic expectations for
providers and other potential ``users'' of the certification program
that vendors will develop products ready to be used by the designated
edition year.
Response. In the July 28, 2010 final rule entitled ``Health
Information Technology: Initial Set of Standards, Implementation
Specifications, and Certification Criteria for Electronic Health Record
Technology (75 FR 44590) and referred to as the ``2011 Edition Final
Rule,'' the Secretary adopted certification criteria in title 45, part
170, Sec. Sec. 170.302, 170.304, and 170.306 of the Code of Federal
Regulations (CFR). In March 2012, to make a clear distinction between
the certification criteria adopted in Sec. Sec. 170.302, 170.304, and
170.306 and the certification criteria proposed for adoption in Sec.
170.314 (the notice of proposed rulemaking with request for comments
titled, ``Health Information Technology: Standards, Implementation
Specification and Certification Criteria for Electronic Health Record
Technology, 2014 Edition; Revisions to the Permanent Certification
Program for Health Information Technology'' (77 FR 13832)), we
discussed that we would be using an ``edition'' naming approach for the
sets of certification criteria subsequently adopted by the Secretary.
We stated that we would refer to the certification criteria adopted in
the 2011 Edition Final Rule and included in Sec. Sec. 170.302,
170.304, and 170.306 collectively as the ``2011 Edition EHR
certification criteria'' and that the certification criterion adopted
in Sec. 170.314 would be referred to as the ``2014 Edition EHR
certification criteria.'' We finalized this approach and adopted a
``2014 Edition'' in the September 4, 2012 final rule we issued entitled
``Health Information Technology: Standards, Implementation
Specifications, and Certification Criteria for Electronic Health Record
Technology, 2014 Edition; Revisions to the Permanent Certification
Program for Health Information Technology'' (77 FR 54163) (the ``2014
Edition Final Rule'').
These two years ``2011'' and ``2014'' were purposefully chosen
because they coincided with the first year in which compliance with
that edition of EHR certification criteria would be required for use
under the Medicare and Medicaid EHR Incentive Programs (``EHR Incentive
Programs''). This approach was meant to simplify the communication
related to the certification criteria editions and enabled generalized
statements like ``an EP needs to be using 2014 Edition CEHRT when they
demonstrate meaningful use (MU) in CY 2014.'' In retrospect, it appears
that this approach unintentionally linked certification criteria
editions solely to MU to many stakeholders, while the certification
criteria editions already support and are referenced by other HHS
programs (e.g., the CMS and HHS Office of Inspector General (OIG) final
rules to modify the Physician Self-Referral Law exception and Anti-
kickback Statute safe harbor for certain EHR donations (78 FR 78751)
and (78 FR 79202), respectively).\3\
---------------------------------------------------------------------------
\3\ CMS final rule ``Medicare Program; Physicians' Referrals to
Health Care Entities With Which They Have Financial Relationships:
Exception for Certain Electronic Health Records Arrangements'' (78
FR 78751). OIG final rule ``Medicare and State Health Care Programs:
Fraud and Abuse; Electronic Health Records Safe Harbor Under the
Anti-Kickback Statute'' (78 FR 79202).
---------------------------------------------------------------------------
We and CMS recently issued a final rule (79 FR 52910) that
demonstrated linking a certification criteria edition's year to any
other program's compliance date could confuse the original intent of
the edition's year selection (due to the final rule pushing back the
compliance requirement of using EHR technology certified only to the
2014 Edition to fiscal year (FY) and calendar year (CY) 2015 for EPs,
EHs, and CAHs). Accordingly, we believe that a simpler approach will be
for future certification criteria editions to be named by the year in
which the final rule is published, and other rulemakings like this
final rule (which include additional criteria or alternatives to
previously adopted certification criteria) would be added to the most
current edition of certification criteria. To further clarify, a
rulemaking like this one that does not adopt an edition of
certification criteria would be referred to as ``[current edition year]
Release #X.''
For example, we expect that the final rule for the next edition of
certification criteria we adopt will be an edition of certification
criteria and will be published in 2015. Thus, that edition of
certification criteria would be called the ``2015 Edition'' because it
will be an edition of certification criteria and its final rule would
be published in 2015. If we were to subsequently issue a final rule in
2016 with seven certification criteria to support another HHS program
or to make revisions to the adopted 2015 Edition certification
criteria, we would refer to that rulemaking as the ``2015 Edition
Release 2'' rulemaking and ultimately make modifications to the 2015
Edition certification criteria at its CFR location and regulation text.
Importantly, this provides stakeholders with a consistent and
predictable naming approach for future editions and also supports ONC's
broader interests to have the ONC HIT Certification Program be
generally accessible to other programs either within or outside
government. Stakeholders that seek to leverage the ONC HIT
Certification Program would then be able to choose which edition of
certification criteria (or subset of criteria within an edition) is
most relevant and appropriate for their program needs.
B. Summary of Major Provisions
1. Overview of the 2014 Edition Release 2 EHR Certification Criteria
The 2014 Edition Release 2 EHR certification criteria we have
adopted in this final rule include ten optional and two revised
certification criteria for inclusion in the 2014 Edition.\4\ Each of
these certification criteria originate with the current 2014 Edition.
The optional certification criteria include the splitting of the
``computerized provider order entry'' (CPOE) criterion into three
certification criteria based on capabilities (medications, laboratory,
and diagnostic imaging); a ``transitions of care'' (ToC) certification
criterion that is decoupled from the transport method; three separate
transport method certification criteria (corresponding to the three
transport standards found in Sec. 170.314(b)(1) and (2)); a ``clinical
information reconciliation and incorporation certification'' (CIRI)
certification criterion that moves
[[Page 54432]]
``incorporation'' from the ToC certification criterion; and a
``transmission to public health agencies--syndromic surveillance''
certification criterion that permits any electronic method for creating
syndromic surveillance information for exchange. Additionally, the
``automated numerator recording'' certification criterion (Sec.
170.314(g)(1)) has been changed to be designated ``optional'' for the
purposes of excluding it from the 2014 Edition Complete EHR definition
as discussed in more detail in the ONC HIT Certification Program
section below.
---------------------------------------------------------------------------
\4\ As we explained in the Proposed Rule (79 FR 10918), the
designation of ``optional'' for certification criteria (in this
case, the 2014 Edition) was developed to accommodate the Complete
EHR definition. If a certification criterion is not designated
``optional,'' an EHR technology designed for the ambulatory setting
or inpatient setting would need to be certified to the criterion in
order to satisfy the Complete EHR definition and be issued a
Complete EHR certification.
---------------------------------------------------------------------------
The two revised certification criterion include a revised ``view,
download, and transmit to 3rd party'' (VDT) certification criterion
(Sec. 170.314(e)(1)) that permits the same optionality provided in the
new optional ToC certification criterion as it relates to transport
methods, and a revised ``safety-enhanced design'' (SED) certification
criterion that includes the optional CPOE certification criteria and
the optional CIRI certification criterion. We discuss the revisions to
SED under the discussions of CPOE and CIRI in section III.A.2 of this
preamble.
Table 1 below specifies the 2014 Edition Release 2 EHR
certification criteria.
Table 1--2014 Edition Release 2 EHR Certification Criteria
----------------------------------------------------------------------------------------------------------------
Optional certification criteria Revised certification criteria
----------------------------------------------------------------------------------------------------------------
Title of regulation Title of regulation
Regulation section paragraph Regulation section paragraph
----------------------------------------------------------------------------------------------------------------
Sec. 170.314(a)(18)........... Optional--computerize Sec. 170.314(e)(1)............ View, download, and
d provider order transmit to 3rd
entry--medications. party.
Sec. 170.314(a)(19)........... Optional--computerize Sec. 170.314(g)(3)............ Safety-enhanced
d provider order design.
entry--laboratory.
Sec. 170.314(a)(20)........... Optional--computerize
d provider order
entry--diagnostic
imaging.
Sec. 170.314(b)(8)............ Optional--transitions
of care.
Sec. 170.314(b)(9)............ Optional--clinical
information
reconciliation and
incorporation.
Sec. 170.314(f)(7)............ Optional--ambulatory
setting only--
Transmission to
public health
agencies--syndromic
surveillance.
Sec. 170.314(g)(1)............ Optional--automated
numerator recording.
Sec. 170.314(h)(1)............ Optional--Applicabili
ty Statement for
Secure Health
Transport.
Sec. 170.314(h)(2)............ Optional--Applicabili
ty Statement for
Secure Health
Transport and XDR/
XDM for Direct
Messaging.
Sec. 170.314(h)(3)............ Optional--SOAP
Transport and
Security
Specification and
XDR/XDM for Direct
Messaging.
----------------------------------------------------------------------------------------------------------------
2. ONC HIT Certification Program
We proposed several modifications to the ONC HIT Certification
Program, some of which we have finalized in this final rule. We are
discontinuing the ``Complete EHR'' certification concept, including the
definition, starting with the next certification criteria edition that
we adopt in a subsequent final rule. This decision has no effect on
certification to the 2014 Edition. We have adopted an updated standard
(ISO/IEC 17065) for the accreditation of ONC-Authorized Certification
Bodies (ACBs) to maintain alignment with industry practices. We have
adopted the ``ONC Certified HIT'' certification and design mark for
required use by ONC-ACBs, which we believe will provide clarity for the
market as it relates to EHR technology certified under the program. We
have designated the 2014 Edition ``automated numerator recording''
certification criterion (Sec. 170.314(g)(1)) as optional for the
purposes of excluding it from Complete EHR certification (it still
applies for EHR Module certification) and revised Sec. 170.550(f) to
clearly require and permit EHR Module certification to either Sec.
170.314(g)(1) or (g)(2) (``automated measure calculation''). Last, we
have provided clarifying guidance for certification to the 2014 Edition
``patient list creation'' certification criterion.
C. Costs and Benefits
Our estimates indicate that this final rule is not an economically
significant rule as its overall costs are significantly below $100
million in any one year. We have, however, estimated the costs and
benefits of this final rule. The estimated costs expected to be
incurred by EHR technology developers to develop and prepare EHR
technology to be tested and certified in accordance with the adopted
optional and revised 2014 Edition certification criteria (and the
standards and implementation specifications they include) are
represented in monetary terms in Table 2 below. We believe a small
number of EHR technology developers and other health information
technology (HIT) developers will seek to be tested and certified to the
certification criteria adopted in this final rule. We estimate that
development and preparation efforts for the optional and revised 2014
Edition certification criteria adopted in the final rule will be split
evenly over CYs 2014 and 2015 and will be confined to these years
because we expect to issue a 2015 Edition final rule in 2015 and expect
that the majority of EHR development and preparation efforts at that
time will shift towards meeting the 2015 Edition. The dollar amounts
expressed in Table 2 are expressed in 2014 dollars.
[[Page 54433]]
Table 2--Distributed Total Development and Preparation Costs for EHR Technology Developers (2-Year Period)--
Totals Rounded
----------------------------------------------------------------------------------------------------------------
Total
Total low Total high average
Year Ratio cost cost cost
(percent) estimate estimate estimate
($M) ($M) ($M)
----------------------------------------------------------------------------------------------------------------
2014........................................................ 50 $1.46 $2.90 $2.19
2015........................................................ 50 1.46 2.90 2.19
2-Year Totals............................................... ........... 2.92 5.80 4.38
----------------------------------------------------------------------------------------------------------------
While we believe only a small number of EHR technology developers
and other HIT developers will seek testing and certification to the
optional and revised 2014 Edition certification criteria adopted in the
final rule, the regulatory flexibility these certification criteria
provide will offer several significant benefits to patients, health
care providers, and HIT developers. The 2014 Edition Release 2
incorporates stakeholder feedback on particular 2014 Edition issues
identified as impacting innovation and causing undue burden. The 2014
Edition Release 2 also seeks to continue to improve EHR technology's
interoperability and electronic health information exchange.
Specifically, the separating out of the ``content'' and ``transport''
capabilities in the optional 2014 Edition ToC certification criterion
we have adopted in this final rule (compared to the 2014 Edition ToC
certification criteria adopted at Sec. 170.314(b)(1) and (2)) and the
adoption of the Implementation Guide (IG) for Direct Edge Protocols
(Direct Edge Protocols IG) is aimed at improving the market
availability of electronic health information exchange services for
transitions of care. The new certification flexibilities offered by the
optional ``CPOE'' and optional ``syndromic surveillance'' certification
criteria are designed to enhance innovation and offer providers
enhanced functionality and options for meeting applicable MU measures.
The new flexibility in the VDT certification criterion is designed to
further facilitate the exchange of patient health information between
provider and patient. The optional CIRI criterion is designed to better
align with clinical workflows than the process in the ToC certification
criterion at Sec. 170.314(b)(1).
II. Background
A. Statutory Basis
The Health Information Technology for Economic and Clinical Health
(HITECH) Act, Title XIII of Division A and Title IV of Division B of
the American Recovery and Reinvestment Act of 2009 (the Recovery Act)
(Pub. L. 111-5), was enacted on February 17, 2009. The HITECH Act
amended the Public Health Service Act (PHSA) and created ``Title XXX--
Health Information Technology and Quality'' (Title XXX) to improve
health care quality, safety, and efficiency through the promotion of
HIT and electronic health information exchange.
1. Standards, Implementation Specifications, and Certification Criteria
The HITECH Act established two new federal advisory committees, the
HIT Policy Committee (HITPC) and the HIT Standards Committee (HITSC)
(sections 3002 and 3003 of the PHSA, respectively). Each is responsible
for advising the National Coordinator for Health Information Technology
(National Coordinator) on different aspects of standards,
implementation specifications, and certification criteria. The HITPC is
responsible for, among other duties, recommending priorities for the
development, harmonization, and recognition of standards,
implementation specifications, and certification criteria. Main
responsibilities of the HITSC include recommending standards,
implementation specifications, and certification criteria for adoption
by the Secretary under section 3004 of the PHSA consistent with the
ONC-coordinated Federal Health IT Strategic Plan.
Section 3004 of the PHSA identifies a process for the adoption of
health IT standards, implementation specifications, and certification
criteria and authorizes the Secretary to adopt such standards,
implementation specifications, and certification criteria. As specified
in section 3004(a)(1), the Secretary is required, in consultation with
representatives of other relevant federal agencies, to jointly review
standards, implementation specifications, and certification criteria
endorsed by the National Coordinator under section 3001(c) and
subsequently determine whether to propose the adoption of any grouping
of such standards, implementation specifications, or certification
criteria. The Secretary is required to publish all determinations in
the Federal Register.
Section 3004(b)(3) of the PHSA titled ``Subsequent Standards
Activity'' provides that the ``Secretary shall adopt additional
standards, implementation specifications, and certification criteria as
necessary and consistent'' with the schedule published by the HITSC. We
consider this provision in the broader context of the HITECH Act to
grant the Secretary the authority and discretion to adopt standards,
implementation specifications, and certification criteria that have
been recommended by the HITSC and endorsed by the National Coordinator,
as well as other appropriate and necessary HIT standards,
implementation specifications, and certification criteria. Throughout
this process, the Secretary intends to continue to seek the insights
and recommendations of the HITSC.
2. HIT Certification Programs
Section 3001(c)(5) of the PHSA provides the National Coordinator
with the authority to establish a certification program or programs for
the voluntary certification of HIT. Specifically, section 3001(c)(5)(A)
specifies that the ``National Coordinator, in consultation with the
Director of the National Institute of Standards and Technology, shall
keep or recognize a program or programs for the voluntary certification
of health information technology as being in compliance with applicable
certification criteria adopted under this subtitle'' (i.e.,
certification criteria adopted by the Secretary under section 3004 of
the PHSA).
The certification program(s) must also ``include, as appropriate,
testing of the technology in accordance with section 13201(b) of the
[HITECH] Act.'' Overall, section 13201(b) of the HITECH Act requires
that with respect to the development of standards and implementation
specifications, the Director of the National Institute of Standards and
Technology (NIST), in coordination with the HITSC, ``shall support the
establishment of a
[[Page 54434]]
conformance testing infrastructure, including the development of
technical test beds.'' The HITECH Act also indicates that ``[t]he
development of this conformance testing infrastructure may include a
program to accredit independent, non-Federal laboratories to perform
testing.''
B. Regulatory History
1. Standards, Implementation Specifications, and Certification Criteria
Rules
The Secretary issued an interim final rule with request for
comments titled, ``Health Information Technology: Initial Set of
Standards, Implementation Specifications, and Certification Criteria
for Electronic Health Record Technology'' (75 FR 2014, Jan. 13, 2010)
(the ``S&CC January 2010 interim final rule''), which adopted an
initial set of standards, implementation specifications, and
certification criteria. After consideration of the public comments
received on the S&CC January 2010 interim final rule, a final rule was
issued to complete the adoption of the initial set of standards,
implementation specifications, and certification criteria and realign
them with the final objectives and measures established for meaningful
use (MU) Stage 1 (formally titled: Health Information Technology:
Initial Set of Standards, Implementation Specifications, and
Certification Criteria for Electronic Health Record Technology; Final
Rule, (75 FR 44590, July 28, 2010) and referred to as the ``2011
Edition Final Rule''). The 2011 Edition Final Rule also established the
first version of the CEHRT definition. Subsequent to the 2011 Edition
Final Rule (October 13, 2010), we issued an interim final rule with a
request for comment to remove certain implementation specifications
related to public health surveillance that had been previously adopted
in the 2011 Edition Final Rule (75 FR 62686).
The standards, implementation specifications, and certification
criteria adopted by the Secretary in the 2011 Edition Final Rule
established the capabilities that CEHRT must include in order to, at a
minimum, support the achievement of MU Stage 1 by EPs, EHs, and CAHs
under the Medicare and Medicaid EHR Incentive Programs Stage 1 final
rule (the ``EHR Incentive Programs Stage 1 final rule'') (see 75 FR
44314 for more information about MU and the Stage 1 requirements).
The Secretary issued a notice of proposed rulemaking with request
for comments titled ``Health Information Technology: Standards,
Implementation Specifications, and Certification Criteria for
Electronic Health Record Technology, 2014 Edition; Revisions to the
Permanent Certification Program for Health Information Technology'' (77
FR 13832, March 7, 2012) (the ``2014 Edition NPRM''), which proposed
new and revised standards, implementation specifications, and
certification criteria. After consideration of the public comments
received on the 2014 Edition NPRM, a final rule was issued to adopt the
2014 Edition set of standards, implementation specifications, and
certification criteria and realign them with the final objectives and
measures established for MU Stage 2 as well as MU Stage 1 revisions
(Health Information Technology: Standards, Implementation
Specifications, and Certification Criteria for Electronic Health Record
Technology, 2014 Edition; Revisions to the Permanent Certification
Program for Health Information Technology (77 FR 54163, Sept. 4, 2012)
(the ``2014 Edition Final Rule''). The standards, implementation
specifications, and certification criteria adopted by the Secretary in
the 2014 Edition Final Rule established the capabilities that CEHRT
must include in order to, at a minimum, support the achievement of MU
Stage 2 by EPs, EHs, and CAHs under the Medicare and Medicaid EHR
Incentive Programs Stage 2 final rule (the ``EHR Incentive Programs
Stage 2 final rule'') (see 77 FR 53968 for more information about the
MU Stage 2 requirements).
On December 7, 2012, an interim final rule with a request for
comment was jointly issued by ONC and CMS to update certain standards
that had been previously adopted in the 2014 Edition Final Rule. The
interim final rule also revised the EHR Incentive Programs by adding an
alternative measure for the MU Stage 2 objective for hospitals to
provide structured electronic laboratory results to ambulatory
providers, corrected the regulation text for the measures associated
with the objective for hospitals to provide patients the ability to
view online, download, and transmit information about a hospital
admission, and made the case number threshold exemption policy for
clinical quality measure (CQM) reporting applicable for eligible
hospitals and CAHs beginning with FY 2013. The rule also provided
notice of CMS's intent to issue technical corrections to the electronic
specifications for CQMs released on October 25, 2012 (77 FR 72985).
On November 4, 2013, the Secretary published an interim final rule
with a request for comment, 2014 Edition Electronic Health Record
Certification Criteria: Revision to the Definition of ``Common
Meaningful Use (MU) Data Set'' (78 FR 65884), to make a minor revision
to the Common MU Data Set definition. This revision was intended to
allow more flexibility with respect to the representation of dental
procedures data for EHR technology testing and certification.
On February 26, 2014, the Secretary issued the Proposed Rule. The
Proposed Rule proposed voluntary certification criteria that would
enable a more efficient and effective response to stakeholder feedback,
incorporate ``bug fixes'' to improve on 2014 Edition in ways designed
to make ONC's rules clearer and easier to implement, and reference
newer standards and implementation specifications. A correction notice
was published for the Proposed Rule on March 19, 2014, entitled
``Voluntary 2015 Edition Electronic Health Record (EHR) Certification
Criteria; Interoperability Updates and Regulatory Improvements;
Correction'' (79 FR 15282). This correction notice corrected the
preamble text and gap certification table for four certification
criteria that were omitted from the list of certification criteria
eligible for gap certification for the 2015 Edition EHR certification
criteria.
On May 23, 2014, CMS and ONC jointly published the ``Medicare and
Medicaid Programs; Modifications to the Medicare and Medicaid
Electronic Health Record Incentive Programs for 2014; and Health
Information Technology: Revisions to the Certified EHR Technology
Definition'' proposed rule (79 FR 29732). The rule proposed to update
the MU Stage 2 and Stage 3 participation timeline. It proposed to
revise the CEHRT definition to permit the use of EHR technology
certified to the 2011 Edition to meet the CEHRT definition for FY/CY
2014. It also proposed to allow EPs, EHs, and CAHs that could not fully
implement EHR technology certified to the 2014 Edition for an EHR
reporting period in 2014 due to delays in the availability of such
technology to continue to use EHR technology certified to the 2011
Edition or a combination of EHR technology certified to the 2011
Edition and 2014 Edition for the EHR reporting periods in CY 2014 and
FY 2014. On September 4, 2014, a final rule (``MU Flexibility Final
Rule'') was published (79 FR 52910) adopting these proposals.
2. ONC HIT Certification Program Rules
On March 10, 2010, ONC published a proposed rule (75 FR 11328)
titled, ``Proposed Establishment of Certification Programs for Health
Information Technology'' (the
[[Page 54435]]
``Certification Programs proposed rule''). The rule proposed both a
temporary and permanent certification program for the purposes of
testing and certifying HIT. It also specified the processes the
National Coordinator would follow to authorize organizations to perform
the certification of HIT. A final rule establishing the temporary
certification program was published on June 24, 2010 (75 FR 36158) (the
``Temporary Certification Program final rule'') and a final rule
establishing the permanent certification program was published on
January 7, 2011 (76 FR 1262) (``the Permanent Certification Program
final rule'').
On May 31, 2011, ONC published a proposed rule (76 FR 31272) titled
``Permanent Certification Program for Health Information Technology;
Revisions to ONC-Approved Accreditor Processes.'' The rule proposed a
process for addressing instances where the ONC-Approved Accreditor
(ONC-AA) engaged in improper conduct or did not perform its
responsibilities under the permanent certification program, addressed
the status of ONC-Authorized Certification Bodies in instances where
there may be a change in the accreditation organization serving as the
ONC-AA, and clarified the responsibilities of the new ONC-AA. All these
proposals were finalized in a final rule published on November 25, 2011
(76 FR 72636).
The 2014 Edition Final Rule made changes to the permanent
certification program. The final rule adopted a proposal to change the
Permanent Certification Program's name to the ``ONC HIT Certification
Program,'' revised the process for permitting the use of newer versions
of ``minimum standard'' code sets, modified the certification processes
ONC-Authorized Certification Bodies (ONC-ACBs) need to follow for
certifying EHR Modules in a manner that provides clear implementation
direction and compliance with the new certification criteria, and
reduced regulatory burden by eliminating the certification requirement
that every EHR Module be certified to the ``privacy and security''
certification criteria.
The Proposed Rule included proposals that focused on improving
regulatory clarity, simplifying the certification of EHR Modules that
are designed for purposes other than achieving MU, and discontinuing
the use of the Complete EHR definition starting with the ``Proposed
Voluntary Edition.''
III. Adopted Proposals
A. 2014 Edition Release 2 EHR Certification Criteria
We proposed to adopt the Proposed Voluntary Edition, which included
a full set of certification criteria (57 certification criteria) for
the ambulatory and inpatient settings.
Comments. We received both positive and negative comments on the
Proposed Voluntary Edition. Commenters that supported the Proposed
Voluntary Edition stated that it was responsive to stakeholder
feedback, permitted certification to new functionality and standards in
a timely manner, and appropriately raised the bar on interoperability.
Commenters that did not support the Proposed Voluntary Edition stated
that the scope was too large, some standards were too immature for
adoption, additional certification would be too costly (after just
preparing EHR technology for certification to the 2014 Edition), and
that it set an unrealistic expectation among providers and patients
that EHR technology developers could have products certified to the
Proposed Voluntary Edition in a timely manner (shortly after the 2014
Edition and while preparing for the next edition that would directly
support MU Stage 3).
Response. We thank commenters for their support of the Proposed
Voluntary Edition. We also appreciate the constructive feedback offered
by other commenters. As stated in the Executive Summary, we have only
adopted a small subset of our original proposals in the Proposed
Voluntary Edition as optional 2014 Edition EHR certification criteria
and made revisions to 2014 Edition EHR certification criteria (also
referred to as the ``2014 Edition Release 2'' or ``2014 Edition Release
2 EHR certification criteria'') that provide flexibility, clarity and
enhance health information exchange. While we believe there are many
valid reasons for the adoption of the Proposed Voluntary Edition,
including those mentioned by commenters, we believe that our approach
in this final rule is the most appropriate at this time. This approach
addresses commenters' concerns and introduces multiple means to reduce
regulatory burden, increase regulatory flexibility for stakeholders,
and promote further innovation.
1. National Technology Transfer and Advancement Act (NTTAA) of 1995
The National Technology Transfer and Advancement Act (NTTAA) of
1995 (15 U.S.C. 3701 et seq.) and the Office of Management and Budget
(OMB) Circular A-119 \5\ require the use of, wherever practical,
technical standards that are developed or adopted by voluntary
consensus standards bodies to carry out policy objectives or
activities, with certain exceptions. The NTTAA and OMB Circular A-119
provide exceptions to selecting only standards developed or adopted by
voluntary consensus standards bodies, namely when doing so would be
inconsistent with applicable law or otherwise impractical. In this
final rule, we have adopted ISO/IEC 17065, which is a voluntary
consensus standard. We have also adopted the ONC Implementation Guide
for Direct Edge Protocols, Version 1.1. This standard was not developed
by a voluntary consensus standards body, but was developed by a group
of industry stakeholders committed to advancing the Direct Project,\6\
which started as an initiative under the Standards and Interoperability
(S&I) Framework.\7\ This group used a consensus process similar to
those used by other industry stakeholders and voluntary consensus
standards bodies. We are aware of no voluntary consensus standard that
would serve as an alternative to this standard for the purposes that we
have identified in this final rule.
---------------------------------------------------------------------------
\5\ http://www.whitehouse.gov/omb/circulars_a119.
\6\ http://www.healthit.gov/policy-researchers-implementers/direct-project.
\7\ http://www.healthit.gov/policy-researchers-implementers/standards-interoperability-si-framework.
---------------------------------------------------------------------------
2. Certification Criteria
Computerized Provider Order Entry
Section 3000 of the PHSA, as added by section 13101 of the HITECH
Act, requires that computerized provider order entry (CPOE)
capabilities be included in CEHRT. We included CPOE capabilities in the
Base EHR definition, which is part of the CEHRT definition, under 45
CFR 170.102. Within the 2011 and 2014 Editions, we adopted CPOE
certification criteria that require EHR technology to be capable of
performing CPOE for medication, laboratory, and radiology/imaging
orders. In the Proposed Rule, we stated that based on stakeholder
feedback since the 2014 Edition Final Rule, we understood that this
approach can prevent EHR technology developers from creating more
efficient, provider-specific ``adaptations'' of EHR technology that
support CPOE.\8\ For example, a mobile adaptation of CPOE currently
must include all of the capabilities listed in the 2014 Edition CPOE
certification
[[Page 54436]]
criterion (i.e., the adaptation must be capable of performing CPOE for
each of the three types of orders (medication, laboratory and
radiology/imaging)) even though the EHR technology developer's
customers may only wish to use the mobile adaptation to enter
medication orders away from the office.
---------------------------------------------------------------------------
\8\ Please see 77 FR 54267-68 for a discussion of adaptations.
---------------------------------------------------------------------------
Similarly, we noted that some providers could interpret our
approach to CPOE certification as inconsistent with the flexibility
provided in the FY/CY 2014 CEHRT definition under Sec. 170.102. As one
example, we noted that the MU Stage 2 CPOE objective for EPs includes
three associated measures (one measure for each of the three types of
orders) and exclusions for each of those three measures. An EP who
could potentially meet an exclusion for one or two of the measures
would still need to possess EHR technology certified to the 2014
Edition CPOE certification criterion (that is, CEHRT that includes CPOE
capabilities for each of the three types of orders). As another
example, we stated that the MU Stage 1 CPOE objective for EPs does not
include measures for laboratory and radiology orders, which means EPs
attempting this objective also do not necessarily require these
additional certified CPOE capabilities. As one final example, we
explained that if an EP expects to meet the MU exclusion for one or two
of the MU measures (i.e., writing fewer than 100 of each order type
during an EHR reporting period), they could choose to adopt EHR
technology certified only to the proposed CPOE certification criterion
for the order types reflected in the measure(s) they expect to
demonstrate for MU. This approach would permit an EP to meet the Base
EHR definition requirements and CEHRT definition without having to
adopt EHR technology that includes certified CPOE capabilities they
would not expect to use for MU.
For the reasons above, we proposed to split the CPOE certification
criterion for the Proposed Voluntary Edition into three separate
certification criteria with each criterion focused on one of the three
order types, reasoning that certification criteria focused on each
order type would permit EHR technology developers to develop order-
specific CPOE adaptations and provide EPs, EHs, and CAHs with
significantly more implementation flexibility.
In the Proposed Rule, we also stated that the proposed ``CPOE''
certification criteria would omit the ``at a minimum'' language
included in the 2014 Edition and 2011 Edition CPOE certification
criteria. We noted that the ``at a minimum'' language was included in
prior editions to indicate that EHR technology developers could include
capabilities that support other types of orders. We stated that this
language is extraneous because we have consistently maintained that
certification criteria (and certification in general) serve as minimum
requirements or a baseline.
Comments. We received universal support for adopting three separate
CPOE certification criteria based on medications, laboratory, and
radiology/imaging orders. We also received support for the elimination
of the ``at a minimum'' language found in the 2011 and 2014 Edition
criteria with commenters stating that elimination of the language would
remove redundancy from the criteria and reduce confusion.
Response. We have adopted these three certification criteria as
2014 Edition optional certification criteria based on stakeholder
feedback and for the reasons we cited in the Proposed Rule. We clarify
and emphasize that there are no standards included in the optional
certification criteria, unlike the proposed CPOE--laboratory
certification criterion. We have also omitted the ``at a minimum''
language in these certification criteria for the reasons proposed and
supported by commenters.
We have changed the title of the certification criterion that
supports CPOE for ``radiology/imaging'' (Sec. 170.314(a)(20)) to
``CPOE--diagnostic imaging'' and changed the relevant regulation text
of this certification criterion from ``radiology and imaging orders''
to ``diagnostic imaging orders.'' We have also made a similar revision
to Sec. 170.3014(a)(1)(iii) by replacing ``radiology/imaging'' with
``diagnostic imaging.'' We have made these revisions to eliminate any
potential confusion as to the type of orders we are referencing. We
note, however, that these revisions in no way alter the required
capability.
We have adopted the optional certification criteria at Sec.
170.314(a)(18) through (20) and included them in the Base EHR
definition. We have also revised the ``safety-enhanced design'' (SED)
certification criterion at Sec. 170.314(g)(3) to include the three
optional CPOE certification criteria. These optional CPOE certification
criteria included the same ``patient safety-related'' capabilities
included in the CPOE certification criterion at Sec. 170.314(a)(1) and
thus the same ``patient safety risk'' rationale for their inclusion in
the SED certification criterion at Sec. 170.314(g)(3) applies.\9\
---------------------------------------------------------------------------
\9\ Please see the 2014 Edition Final Rule (77 FR 54187) for a
discussion of the capabilities and certification criteria that we
believe present a risk to patient safety and thus are included in
the SED certification criterion.
---------------------------------------------------------------------------
As we noted in the Proposed Rule (79 FR 10886), we caution that
this additional flexibility comes with potential risk for EPs who
expect to qualify for one or more of the exclusions from the CPOE
measures, but do not ultimately satisfy the exclusion criteria based on
the number of orders written during an EHR reporting period. EPs who
choose to possess EHR technology that is not certified for each of the
three types of orders may risk not having EHR technology that meets the
CEHRT definition if they ultimately fail to meet one or more MU
exclusions. Therefore, we emphasize that EHR technology developers need
to be aware that this additional certification flexibility and
subsequent certification decisions could have corresponding impacts on
EPs who are ultimately responsible for ensuring that their EHR
technology meets the CEHRT definition.
We note that we discuss comments received on each of the three
proposed CPOE certification criteria that suggested changes to the
criteria under section IV.A ``Not Adopted EHR Certification Criteria
and Certification Criteria Proposals.'' This includes a discussion of
our reasons for not adopting the HL7 Laboratory Orders Interface (LOI)
standard and the Clinical Laboratory Improvement Amendments (CLIA)-
related requirements for the proposed ``CPOE--laboratory''
certification criterion.
Transitions of Care
We proposed to make several changes to the ``transitions of care''
(ToC) certification criterion, including decoupling content and
transport capabilities, the inclusion of the Direct Edge Protocols IG
Version 1.0, and shifting the ``incorporation'' requirements into an
updated ``clinical information reconciliation and incorporation''
(CIRI). We included several other proposals in the ToC certification
criterion that we have not finalized. These proposals are discussed in
section IV.A of this preamble.
``Decoupling'' Content and Transport
In the Proposed Rule, we recited specific stakeholder feedback
stating that the ``binding'' of transport and content capabilities
within the scope of a single certification criterion could impede
innovation and limit EPs', EHs', and CAHs' market choices for
electronic health information exchange. We also recited stakeholder
feedback indicating that we had incorrectly imposed the coupling of
technical capabilities that
[[Page 54437]]
can be adequately performed by two different systems. More
specifically, stakeholders stated that content capabilities and
transport capabilities should be separately tested and certified as the
standard that supports one may change over time while the other remains
the same. In this regard, we illustrated how the ``binding'' of the
transport and content capabilities within the scope of a single
criterion has led, in some cases, to the intertwining of EHR and health
information service provider (HISP) functionality (i.e., HISP
functionality being built into an EHR or EHR functionality being built
into a HISP) solely for the purposes of certification. As a result, we
proposed to decouple content and transport capabilities and adopt a
single ToC criterion that focused on content capabilities and EHR
technology's capability to connect to a service that is conformant with
the primary Direct Project specification through the use of the Direct
Edge Protocols IG Version 1.0.
Comments. We received significant public comment on this proposal
from associations representing providers, consumers, and HIT developers
as well as comments from numerous HIT developers. The vast majority of
the commenters supported decoupling content and transport capabilities,
with some voicing concerns about the proposed Edge Protocol IG Version
1.0. Specifically, commenters noted that the decoupling represented a
much-needed flexibility for HIT developers and a workflow update that
reflected implementations already widely used. One commenter, an ONC-
ACB, noted that ToC and HISP functionality was already separated for
most EHRs across different systems. Other commenters voiced concerns
that the decoupling would create a greater burden on providers and
hospitals as they assemble their certified systems. Finally, comments
from the EHR technology developer community stated that the change was
proposed too late to provide flexibility, noting that they had already
complied with the 2014 Edition requirements and combined the
functionality.
Response. We have decided to finalize our proposal to decouple
content and transport capabilities. We have also decided to adopt an
updated version of the Direct Edge Protocols IG, which we discuss in
more detail below. We appreciate the support for this proposal and
agree with commenters that the decoupling will achieve much needed
flexibility and allow for continued innovation in the market. While
this flexibility may be considered too late by some stakeholders, we
believe that the potential benefits of its availability for the 2015
EHR reporting period outweigh the negatives. Accordingly, we have
adopted an optional ToC certification criterion at Sec. 170.314(b)(8)
that focuses on content creation and edge protocol capabilities. We do
not believe the optional ToC certification criterion will cause
additional burden or complexity for EPs, EHs, and CAHs because it is
voluntary and if pursued by an EHR technology developer will be done so
to provide additional flexibility and options for an EP, EH, or CAH to
choose their HISP.
Edge Protocol for EHR to HISP Connectivity for Direct Transmissions
Comments. Commenters voiced support for decoupling the content and
transport requirements under the ToC criterion, however, many voiced
concern about the Direct Edge Protocols IG Version 1.0 (``Version
1.0''). Commenters stated the protocol optionality in Version 1.0
provided the potential for interoperability incompatibilities.
Commenters also noted that this level of optionality would require
technology developers to support all four protocols in Version 1.0 in
order to support the variety of valid protocol implementations in ToC.
Commenters recommended ONC choose a minimum set of edge protocols that
would be mandatory, instead of allowing all four. Other commenters
noted that Version 1.0 was never intended to be part of a regulatory
framework. Commenters also voiced concern that Version 1.0 did not have
widespread development and implementation experience and it that it was
premature to adopt it. Finally, commenters noted that the Direct Edge
Protocols IG Version 1.1 (``Version 1.1'') would be finalized shortly
and urged us to include that version instead of Version 1.0 if we
decided to adopt the Direct Edge Protocol IG.
Response. We appreciate the diverse and specific feedback on our
proposal to adopt the Version 1.0. In addition to the comments we
received on the Proposed Rule, stakeholders who helped develop Version
1.0 provided feedback (through the IG development process) that the
edge protocol specifications and message tracking guidance needed to be
clarified and refined based upon their experiences in the field. We
agree that some of the ambiguities in Version 1.0 could introduce
interoperability and implementation challenges for technology
developers. Version 1.0 represented a first attempt toward a consistent
and uniform approach for HISPs and EHR technology (and other so-called
``edge'' systems in the IG) to implement the most common protocols
(described as ``edge protocols'' in the IG) between these systems.
In response to feedback, the stakeholder community (comprised of
several HISPs and EHR technology developers) released an updated
version of the IG for Direct Edge Protocols, Version 1.1 through the
stakeholder lead Direct Project.\10\ Version 1.1, as discussed in more
detail below, builds on and improves Version 1.0 with consistent
implementation and interoperability in mind because it includes more
thoroughly documented technical constraints for the edge protocols it
references. Version 1.1 addresses many stakeholder concerns because it
minimizes variability between implementations.
---------------------------------------------------------------------------
\10\ http://www.healthit.gov/sites/default/files/implementationguidefordirectedgeprotocolsv1_1.pdf.
---------------------------------------------------------------------------
As outlined in the Proposed Rule, we believe it is important to
adopt a Direct Edge Protocols IG in order to support the separation of
content and transport related to ToC. If we were to not adopt a Direct
Edge Protocols IG, HIT developers would likely first implement
inconsistent approaches to edge protocols and then need to spend
additional resources later to reconcile those inconsistencies.
Providing for certification to Version 1.1 can enable greater certainty
and assurance to HIT developers that products certified to this IG have
implemented the IG's edge protocol(s) in a consistent manner. The
availability of certification should also enhance HIT developers'
ability to reliably connect their products without the need for
customized interfaces and, ultimately, enable health care providers a
greater ability to choose or switch HISP services.
Therefore, in consideration of public comments and our proposal to
permit content and transport capabilities to be separately tested and
certified, we have decided to adopt Version 1.1 as part of this
optional ToC certification criterion. EHR technology presented for
certification to the criterion adopted at Sec. 170.314(b)(8) would
need to demonstrate compliance with Version 1.1.
The following explains the context and reasons for our decision to
adopt Version 1.1 as a standard at Sec. 170.202(d) and reference it
within the optional ToC certification criterion at Sec. 170.314(b)(8).
For clarity, we note that the optional ToC certification criterion
adopted at Sec. 170.314(b)(8) would be only applicable to EHR
technology in the role of the ``edge system'' identified in Version
1.1. We also note that this
[[Page 54438]]
policy only applies for the purposes of EHR technology to be certified
and is not meant to impose a ``ceiling'' or limit the use of other edge
protocols if so implemented in order to enable electronic exchange for
the purposes of meeting the MU transitions of care objective and
measures.
Version 1.1 includes two key improvements upon Version 1.0:
Version 1.1 clarifies the permissible combinations of edge
protocols and their applicability within the scope of the IG. For
example, two of the edge protocols within the IG (Post Office Protocol
(POP) and Internet Message Access Protocol (IMAP)) are unidirectional,
meaning they must be paired with another protocol to enable two-way
communication between an ``edge system'' and its HISP. Version 1.0 did
not clearly specify what the other protocols should be paired with POP
and IMAP. Thus, implementers found this guidance incomplete and
unclear. Version 1.1 addresses that ambiguity and instructs Edge
systems to pair POP and IMAP with Simple Mail Transfer Protocol (SMTP).
Version 1.1 clarifies technical constraints for Cross-
Enterprise Document Reliable Interchange (XDR), SMTP, POP, and IMAP.
Implementers of Version 1.0 noted that the IG's level of specification
for edge protocols left room for too much variation in implementations,
impacting interoperability by creating interface incompatibilities in
some instances. In this case, Version 1.0's ambiguities and inherent
variability proved problematic and, from a consistent implementation
perspective, demonstrated that a more tightly constrained specification
would be beneficial. Version 1.1 improves the specificity around XDR,
SMTP, POP, and IMAP in areas such as security and authentication to
minimize variability and increase interoperability.
Version 1.1 references the same four edge protocols that were
referenced in Version 1.0:
1. Integrating the Healthcare Enterprise (IHE) XDR profile for
Limited Metadata Document Sources;
2. SMTP;
3. Internet Message Access Protocol version 4rev1 (IMAP4); and
4. Post Office Protocol version 3 (POP3).
However, with respect to the edge system specifications identified
in Version 1.1, such edge systems are expected to support either the
``IHE XDR profile for Limited Metadata Document Sources'' edge protocol
or an SMTP-focused edge protocol (SMTP alone or SMTP in combination
with either IMAP4 or POP3). Thus, for the purposes of testing and
certification, compliance with this specific capability within the
certification criterion can be demonstrated in one of two ways: Using
the specific IHE XDR approach or one of the SMTP approaches.
For this final rule, we evaluated whether to adopt a single edge
protocol (of the four available) and decided to conduct fact finding
with several HISPs and EHR technology developers to understand what
edge protocol(s) they had implemented in the absence of any specific
edge protocol requirements as part of the 2014 Edition. Our fact
finding identified that EHR technology developers (for the ambulatory
and inpatient settings) have already started implementing the two edge
protocol approaches identified in Version 1.1 and used either an IHE
XDR-based or SMTP-based edge protocol approach to connect to HISPs, and
that HISPs were supporting both IHE XDR and SMTP-based edge protocol
approaches in order to accommodate different customer needs. We also
learned that smaller EHR technology developers were more likely to have
implemented an SMTP-based edge protocol approach because the IHE XDR
edge protocol approach would have been too resource-intensive. Given
this additional information, we determined that requiring the adoption
of a single edge protocol would be unwise since such an approach could
disadvantage certain EHR technology developers in addition to not
providing any commensurate downstream benefit to their customers (EPs,
EHs and CAHs).
Overall, we believe that the adoption of Version 1.1 will further
support efforts already underway by the community by enabling EHR
technology developers to demonstrate through testing and certification
that they have implemented an edge protocol in a manner consistent with
Version 1.1. Without this consistency, interoperability could be
impacted and make it difficult for any specific EHR technology to
reliably connect to any HISP. It could also lead to greater costs to
providers for continued customized interfaces for the edge connectivity
to a HISP and, thus, make it more likely that the provider would be
``locked-in'' to that HISP instead of being able to pair with/subscribe
to a HISP of their choosing.
Shifting ``Incorporation'' From ToC to Clinical Information
Reconciliation
In response to stakeholder feedback indicating that the inclusion
of ``incorporation'' capabilities in the 2014 Edition ToC criterion
(Sec. 170.314(b)(1)(iii)) was not aligned with typical clinical
workflows, we proposed to include ``incorporation'' capabilities in a
proposed ``clinical information reconciliation and incorporation''
(CIRI) certification criterion. The ``incorporation'' capabilities
require EHR technology, upon receipt of a transition of care/referral
summary formatted according to the Consolidated CDA Release 1.1, to
demonstrate that the transition of care/referral summary received is or
can be properly matched to the correct patient and it can
electronically incorporate medications, problems, and medication
allergies according to specified vocabulary standards.
Comments. We received comments from several EHR developers on this
proposal. Commenters overwhelmingly supported including the
incorporation functionality in a CIRI criterion instead of a ToC
criterion. Commenters stated that this was a better fit for the
capabilities and more appropriate for clinical workflow. One commenter
stated that we should change the language in the CIRI criterion to
clarify ambiguities around the ``extract'' term and its associated
requirements.
Response. Given the comments in support, we have finalized our
proposal to ``move'' the incorporation requirements into an updated
CIRI criterion as proposed. We have adopted the updated CIRI criterion
as an optional 2014 Edition certification criterion at Sec.
170.314(b)(9). We agree with commenters that this approach will clarify
the interplay between the ToC and CIRI certification criteria and will
clear up any misconceptions about anticipated workflow. We decline to
change the term ``extract'' at this time because: 1) It is not part of
the CIRI criterion; and 2) the same term is used in the 2014 Edition
ToC certification criterion at Sec. 170.314(b)(1) as well as the new
optional 2014 Edition ToC criterion at Sec. 170.314(b)(8), and the
term's meaning and context is discussed in the 2014 Edition Final Rule
(77 FR 54219).
Clinical Information Reconciliation and Incorporation
We proposed a CIRI certification criterion for the Proposed
Voluntary Edition that was revised in comparison to the 2014 Edition
certification criterion. As discussed in more detail under the ToC
certification criterion above, we proposed a CIRI criterion that
included the same type of incorporation capabilities that we previously
adopted as part of the ToC certification criterion at Sec.
170.314(b)(1).
Comments. As noted in the ToC certification criterion above, we
received widespread support for ``moving'' the incorporation
capabilities
[[Page 54439]]
into a CIRI certification criterion. One commenter suggested that we
make this certification criterion eligible for gap certification.
Response. We have adopted a new optional 2014 Edition CIRI
certification criterion that includes the incorporation capability. We
appreciate the comments in support of this proposal and believe it will
more align with clinical workflow. This certification criterion is not
eligible for gap certification because the change in capabilities
required to meet this optional CIRI certification criterion make it a
``revised'' certification criterion as compared to the current 2014
Edition ``clinical information reconciliation'' (CIR) certification
criterion and thus ineligible for gap certification.
We have also revised the SED certification criterion at Sec.
170.314(g)(3) to include this optional CIRI certification criterion.
The optional CIRI certification criterion includes the same ``patient
safety-related'' capabilities included in the CIR certification
criterion at Sec. 170.314(b)(4) and thus the same ``patient safety
risk'' rationale for its inclusion in the SED certification criterion
at Sec. 170.314(g)(3) applies.\11\
---------------------------------------------------------------------------
\11\ Please see the 2014 Edition Final Rule (77 FR 54187) for a
discussion of the capabilities and certification criteria that we
believe presented a risk to patient safety and thus included in the
SED certification criterion.
---------------------------------------------------------------------------
View, Download, and Transmit to 3rd Party (VDT)
The Proposed Rule summary in this section only summarizes and
includes the ``comments'' and ``response'' for the proposal that we
have adopted as part of this final rule. We included several other
proposals in the proposed VDT certification criterion that we have not
finalized. These proposals are discussed in section IV.A of this
preamble.
Decoupling Transport and Content
For the reasons we provided in the Proposed Rule for the separation
of content capabilities and transport capabilities (79 FR 10896-97,
10906) and recited under the ToC certification criterion discussed
previously in this preamble section, we proposed to ``decouple'' the
transport and content capabilities of the VDT certification criterion.
We noted that similar to the proposed ToC revisions, the certification
criterion would focus on content requirements and EHR technology's
ability to demonstrate conformance with the Direct Edge Protocols IG
Version 1.0 and enable a successful transmission. We further specified
that this would require EHR technology to enable a patient to
accomplish a transmission that conforms to the Direct Edge Protocols IG
Version 1.0 and is used by a service that has implemented the primary
Direct Project specification.
We clarified that ``accomplish'' was intended to convey our
expectation and that our anticipated approach through testing would be
to assess whether the transmitted Consolidated Clinical Document
Architecture (CDA) arrived at its destination. We emphasized that under
this proposed revision EHR technology developers seeking testing and
certification would be permitted to demonstrate compliance with the
transport requirement without having to be a HISP (or be bound to a
single HISP through certification). However, we indicated that
demonstrating this outcome could be expedited if the EHR technology
developer uses a service that is certified to enable health information
to be electronically transmitted (sent and received) in accordance with
the primary Direct Project specification (under our new proposal for
this to be a separate certification criterion).
Comments. Given the parallels between this proposal and the
proposal we made for the ToC criterion, the vast majority of commenters
expressed the same general support for the ``decoupling.'' Commenters
also expressed similar concerns about the proposed Edge Protocol IG
Version 1.0 interoperability incompatibilities and the need for HIT
developers to support all four protocols in order to support the
variety of valid protocol implementations. In general, commenters
stated that the decoupling of content and transport represented a much-
needed flexibility for developers and a workflow update that reflected
implementations already widely used.
Response. For the same reasons we provide in response to the ToC
certification criterion related to the decoupling of content and
transport as well as the Direct Edge Protocols IG Version 1.1, we have
adopted Version 1.1 for the purposes of the VDT certification
criterion. In light of our overall approach for this final rule's
scope, we have determined that the best and simplest approach to
include this new flexibility is to modify the existing VDT
certification criterion at Sec. 170.314(e)(1). This modification would
add an alternative pathway for EHR technology developers to demonstrate
compliance with the certification criterion. The modification would do
so in a way that recognizes the content and transport separation we
discussed in the Proposed Rule. Specifically, we have modified Sec.
170.314(e)(1)(i)(C)(1) and (2) to include the alternative ``decoupled''
approach. This revised regulatory text expresses that compliance with
the specific transport capability requirement can be demonstrated in
one of two ways. One way is the original approach adopted as part of
the 2014 Edition Final Rule (certification to the ONC Applicability
Statement for Secure Health Transport (Direct)).\12\ The other way is
the new approach adopted in this final rule (certification to the Edge
Protocol IG Version 1.1). We note that this optionality is specified
with regulatory text that states ``at least one of the following'' to
more clearly convey that both transport approaches do not need to be
supported for the purposes of certification nor would an EHR technology
developer customers need the other approach certified if the
alternative was demonstrated for the purposes of certification.
---------------------------------------------------------------------------
\12\ 77 FR 54182.
---------------------------------------------------------------------------
Transmission to Public Health Agencies--Syndromic Surveillance
We proposed to revise the 2014 Edition ``syndromic surveillance''
certification criterion and adopt a parallel ``syndromic surveillance''
certification criterion for the Proposed Voluntary Edition.
For both MU Stages 1 and 2, EPs may choose the ``electronic
syndromic surveillance data'' objective under the menu set. In the MU
Stage 2 final rule, CMS stated that very few public health agencies
were accepting syndromic surveillance data from ambulatory, non-
hospital providers, and there was no corresponding HL7 2.5.1 IG
available at the time of the final rule's publication (77 FR 54025).
CMS also noted, however, that the CDC was working with the syndromic
surveillance community to develop a new IG for ambulatory reporting of
syndromic surveillance data, which was expected to be published in
spring 2013.
We stated in the Proposed Rule that only a few public health
agencies are currently accepting syndromic surveillance data from the
ambulatory setting using HL7 2.5.1. We stated that due to lack of
demand, the CDC no longer planned to develop an HL7 2.5.1 IG for
ambulatory reporting of syndromic surveillance data and that without
such an IG most public health agencies would not have enough specific
guidance to build systems to receive syndromic surveillance data from
the ambulatory setting formatted to HL7 2.5.1. Further, we noted that
the MU Stage 2 final rule permits an EP, EH, or CAH to claim an
exclusion if the public health agency does not have the
[[Page 54440]]
capacity to accept reporting (77 FR 54021) and, therefore, many EPs may
qualify for an exclusion for this objective and associated measure and,
as a result, would need to choose another objective from the menu set
on which to report.
Given the lack of an ambulatory IG for HL7 2.5.1, we proposed to
revise the current 2014 Edition certification criterion to allow EHR
technology designed for the ambulatory setting to be certified to
alternative standards that support other modes of electronic syndromic
surveillance data submission. In this regard, we indicated that
syndromic surveillance data was being sent to public health agencies
through new query-based models, including the QueryHealth
initiative.\13\ Query-based models take patient level data, de-identify
it, and aggregate it for population health use. In the Proposed Rule,
we also noted that we understood that the query-based models use HL7
CDA and QRDA Category III (``QRDA III'') standards, and did not
necessarily use the HL7 2.5.1 standard. Further, we stated that CDA and
QRDA III standards were adopted and referenced by 2014 Edition
certification criteria and, as a result, had become more widely
implemented.
---------------------------------------------------------------------------
\13\ http://wiki.siframework.org/Query+Health.
---------------------------------------------------------------------------
In light of the potential that many EPs may qualify for an
exclusion for the MU objective and associated measure with which this
certification criterion correlates, we noted that we sought to make
available additional electronic syndromic surveillance submission
capabilities in order to better support their opportunity to receive
credit for the syndromic surveillance MU objective. Therefore, we
proposed to specifically revise the 2014 Edition ``syndromic
surveillance'' certification criterion at Sec. 170.314(f)(3) to
include the HL7 CDA and QRDA III standards as alternative standards to
HL7 2.5.1 for EHR technology certification designed for the ambulatory
setting.
For EHR technology certification to the inpatient setting, we
proposed to revise the 2014 Edition certification criterion by
replacing the adopted version of the HL7 2.5.1 IG with a newer version
of the IG that incorporates an addendum clarifying conformance guidance
(PHIN Messaging Guide for Syndromic Surveillance: Emergency Department,
Urgent Care, and Inpatient Settings, Release 1.9 (April 2013)).
We proposed the same ambulatory and inpatient setting requirements
in a parallel ``syndromic surveillance'' certification criterion for
the Proposed Voluntary Edition.
We solicited comment on whether public health agencies are using
the QRDA Category I standard to receive query-based syndromic
surveillance data, and whether we should consider adopting the standard
for the ambulatory setting.
Comments. We received a range of comments on the use of the CDA and
QRDA III standards in addition to the HL7 2.5.1 standard for ambulatory
setting certification. Some commenters stated that the added
flexibility of allowing alternate standards would increase the exchange
of syndromic surveillance data. Commenters stated that the lack of a
HL7 2.5.1 IG for the ambulatory setting has led to variation across
EHRs. Other commenters opined that the absence of an HL7 2.5.1 IG for
the ambulatory setting has also resulted in reluctance from EHR
developers to build custom interfaces to enable public health agencies
to receive ambulatory syndromic surveillance. One public health agency
commented that they have built the infrastructure to receive CDA and
QRDA III through their HIE and related partners. This public health
agency stated that CDA and QRDA III standards could represent
significant advances for timely and efficient ambulatory syndromic
surveillance data collection and supported the proposal to allow
alternate standards for certification.
Commenters in opposition to the proposal to allow use of CDA and
QRDA III standards for certification stated that ONC should promote a
single standard for ambulatory syndromic surveillance rather than allow
multiple standards. Others commented that despite the proposed
regulation text permitting use of HL7 2.5.1, CDA, ``or'' QRDA III
standards, the ``or'' would really be implemented as an ``and'' if the
EHR technology developer's customers want to use CDA or QRDA III
because an EHR developer would have to offer any and all options
desired by their customers. Some commenters expressed concern that
public health agencies are not ready to develop the infrastructure to
receive CDA and QRDA III data if they had not previously done so.
Commenters noted that, without specific IGs for the use of CDA and QRDA
III for ambulatory syndromic surveillance, the standards are not
constrained enough to reach uniform submission of the data. Likewise,
commenters indicated that the CDA and QRDA III standards have not been
piloted or tested for syndromic surveillance purposes.
The majority of commenters supported adoption of the proposed
updated IG for inpatient certification. However, many commenters stated
that since the IG Release 1.9 publication numerous errors have been
identified with Release 1.9. For example, many commenters pointed to
the report issued by the International Society for Disease Surveillance
identifying issues and errors with Release 1.9.\14\ Commenters opined
that those issues and errors should be addressed before requiring
compliance with Release 1.9. A few commenters noted that stakeholders
are working toward Release 2.0 of the IG, which they noted would
include more substantive updates relative to Release 1.8 in comparison
to the updates included in Release 1.9. Therefore, the commenters
recommended waiting to adopt Release 2.0 to avoid redundant and
unnecessary work for EHRs and public health agencies as well as to get
the maximum benefit for updated systems.
---------------------------------------------------------------------------
\14\ The ISDS Issue Report is available at https://docs.google.com/spreadsheet/ccc?key=0AlhELG407-6OdFVPa0ZjZXFjYnNVd0tPSHRCRGF0WXc&usp=sharing.
---------------------------------------------------------------------------
A few commenters stated that QRDA Category I is not being used for
query-based syndromic surveillance in ambulatory settings and opined
that Category I is not appropriate as it includes patient-level results
rather than aggregate results which are more suitable for syndromic
surveillance.
Response. We proposed revisions to the 2014 Edition version of this
criterion and a ``syndromic surveillance'' certification criterion for
the Proposed Voluntary Edition to permit alternate standards for the
transmission of ambulatory syndromic surveillance data as a means of
providing additional flexibility for EHR technology certification and
for EPs attempting to meet the syndromic surveillance MU objective and
measure. Since publication of the Proposed Rule we have heard from the
CDC that some public health agencies have requested that the CDC
reconsider developing an IG for HL7 2.5.1 as the HL7 2.5.1 standard is
used by some public health agencies.
With consideration of the request to CDC, our overall approach to
this final rule as described in the Executive Summary, and to provide
the most clarity for certification as possible, we are not removing or
revising the current 2014 Edition ``syndromic surveillance''
certification criterion (Sec. 170.314(f)(3)) nor adopting a separate
``syndromic surveillance'' certification criterion for the Proposed
Voluntary Edition. Rather, we have adopted an optional 2014 Edition
``syndromic surveillance'' certification criterion (Sec.
170.314(f)(7)) for the ambulatory setting. The optional
[[Page 54441]]
certification criterion permits EHR technology, for the purposes of
certification, to use any method or standard to electronically create
syndrome-based public health surveillance information for electronic
transmission. Consistent with the intent of our proposal, this will
provide additional certification flexibility for EHR technology
developers and flexibility for EPs attempting to achieve MU. We note
that this approach does not affect the corresponding MU Stage 2
objective and measure.\15\
---------------------------------------------------------------------------
\15\ MU2 Measure: Successful ongoing submission of electronic
syndromic surveillance data from certified EHR technology to a
public health agency for the entire EHR reporting period.
---------------------------------------------------------------------------
We agree with commenters that without specific IGs for the use of
CDA and QRDA III for the transmission of ambulatory syndromic
surveillance data, the standards are not constrained enough on their
own to enable interoperable submissions. However, even before
publication of the Proposed Rule, query-based standards were piloted
and demonstrated in a few cases for ambulatory syndromic surveillance
data, including through the QueryHealth initiative. These efforts and
the use of query-based models continue and we expect the use of query-
based models to grow among public health agencies. Therefore, we
concluded that the best approach at this time was to adopt an optional
``syndromic surveillance'' certification criterion that permits EHR
technology designed for the ambulatory setting to simply demonstrate
that it can electronically create syndrome-based public health
surveillance information for electronic submission (using any method or
standard) to be certified to this criterion. This provides
certification flexibility and potential EP flexibility as mentioned
above, while also providing a path forward as described below.
Because there is no current IG that supports ambulatory syndromic
surveillance data submission using query-based standards, we have also
included an optional set of data elements within this optional
certification criterion to provide some additional specificity and to
which EHR technology developers may choose to have their EHR technology
certified. These data elements are: Patient demographics, provider
specialty, provider address, problem list, vital signs, laboratory
results, procedures, medications, and insurance. While the
aforementioned data elements are optional for the purposes of
demonstrating compliance to this certification criterion, if an EHR
technology developer wishes to certify its EHR technology to this
criterion as a whole, including the optional data set, the EHR
technology would need to demonstrate that it can electronically produce
syndromic surveillance information that contains all of the data
elements. In other words, an EHR technology that could only produce
half of the data elements would not be able to be certified to this
optional portion of the criterion. The public health agencies and
stakeholders that have piloted and continue to pilot query-based models
for transmitting ambulatory syndromic surveillance data send all of the
data elements identified above. Therefore, by identifying these data
elements for certification, EHR technology developers will have clarity
as to the data elements they should focus on for creating syndrome-
based public health information submissions and will need to include to
support query-based models now and in the future, including any
potential certification requirements introduced through future
rulemaking.
The use of the QRDA III standard represents the response portion of
a query-response model, but there currently are no mature standards for
the query portion of the model of which we are aware. We intend to
continue working with stakeholders on standards for both the query and
response portions to support the electronic transmission of ambulatory
syndromic surveillance data. We intend to gather more information
regarding the implementation guidance provided by stakeholders that are
currently piloting or using CDA or constrained QRDA III for ambulatory
syndromic surveillance data transmissions to inform our consideration
of what standards to propose in the future. This work will include
confirming which data elements are commonly transmitted through these
and other query-based models, such as the ones identified above and any
other data elements that may also be typically sent using query-based
approaches.
Given our approach to this final rule as stated in the Executive
Summary, we have not adopted the IG Release 1.9 for inpatient
certification to either the current ``syndromic surveillance''
certification criterion or the optional ``syndromic surveillance''
certification criterion we have adopted in this final rule. We agree
with comments that any issues or errors identified in Release 1.9
should be remedied before requiring the IG for adoption. We also
recognize that the industry is working on Release 2.0 of the IG.
Therefore, we will consider this feedback for future rulemaking
concerning a ``syndromic surveillance'' certification criterion.
We also thank commenters for the input on the usefulness of QRDA
Category I for query-based ambulatory syndromic surveillance and will
consider this feedback for future rulemaking.
Transport Methods (Formerly ``Transmission'') Certification Criteria
As a result of our proposal to decouple content and transport
capabilities from the ToC certification criteria and VDT certification
criterion, we proposed to adopt three separate transport certification
criteria. These three proposed transport certification criteria
mirrored the specific transport capabilities identified within the 2014
Edition ToC certification criteria at Sec. 170.314(b)(1) and (2). The
first criterion mirrored the capability expressed at Sec.
170.314(b)(1)(i)(A) and Sec. 170.314(b)(2)(ii)(A) (i.e., Direct); the
second mirrored the ``optional'' capability expressed at Sec.
170.314(b)(1)(i)(B) and Sec. 170.314(b)(2)(ii)(B) (i.e., Direct and
XDR/XDM for Direct Messaging); and the third mirrored the ``optional''
capability expressed at Sec. 170.314(b)(1)(i)(C) and Sec.
170.314(b)(2)(ii)(C) (i.e., SOAP RTM and XDR/XDM for Direct Messaging).
We stated for all three proposed certification criteria that we
expected them to be tested similarly to how they are tested today
except that only these capabilities would be tested.
Comments. Commenters generally supported the separation of content
and transport (as outlined in more detail under the ToC certification
criterion above) and the inclusion of independent transport
certification criteria in order to support our overall approach to
decoupling content and transport capabilities. Some commenters believed
the first three transport criteria (i.e., Direct, Direct and XDR/XDM
for Direct Messaging, and SOAP RTM and XDR/XDM for Direct Messaging)
should be eligible for gap certification because each capability could
be tested as part of the 2014 Edition ToC criteria. One commenter asked
for clarification regarding the grouping of the proposed certification
criteria. Specifically, the commenter asked if the transport criteria
were separate and could be individually tested and certified.
Response. We have revised the title of this category of
certification criteria for clarity. We now refer to this category of
certification criteria (Sec. 170314(h)) as ``transport methods''
instead of ``transmission.'' We believe this provides better
attribution to the type of criteria and functionality that are included
in this category.
[[Page 54442]]
We appreciate the widespread support and feedback regarding the
decoupling of content and transport requirements. We believe finalizing
three, independent transport criteria will allow technology developers
to build in the transport capabilities suited to their customers'
needs. Therefore, consistent with our earlier discussion related to the
optional ToC certification criterion (Sec. 170.314(b)(8)), we have
decided to adopt all three of the proposed transport capabilities
(previously contained within the ToC certification criteria) in three
separate certification criteria that can be individually tested and
certified. For all three adopted criteria, we have removed the term
``transmit'' from the title of criteria and replaced the regulation
text ``electronically transmitted'' in each criterion with
``electronically sent and electronically received.'' These changes
provide clarity in two ways. They eliminate any confusion with the use
of the term ``transmit'' (or ``transmitted''), which we used in the
2014 Edition Final Rule to mean only ``send from one point to another''
(77 FR 54168). Equally important, the changes clearly specify how these
standards will be tested and certified, which is consistent with how
these standards are currently tested and certified. The changes are
also consistent with our expectations expressed in the Proposed Rule
and recited above about testing and certification.
As noted in the following section (III.A.3 ``Gap Certification
Eligibility Table for 2014 Edition Release 2''), the certification
criteria for Direct, Direct and XDR/XDM for Direct Messaging, and SOAP
RTM and XDR/XDM for Direct Messaging are eligible for gap
certification. We discuss each certification criterion in more detail
in the following comments and responses.
Comments. Some commenters asked that we identify one transport
criterion as the minimum required for transport. The commenters noted
that if one method of transmission were not required, vendors would be
forced to support all transport methods.
Response. As we explained in the preamble of the Proposed Rule, we
seek to maintain the same policy we included in the 2014 Edition Final
Rule--that in order for EPs, EHs, and CAHs to have EHR technology that
met the CEHRT definition they would need to have EHR technology capable
of performing transmissions in accordance with the primary Direct
Project specification. We accentuated this policy by proposing to
modify the Base EHR definition to ensure that it reflected this policy,
which we have finalized in this final rule. Thus, in response to these
comments, we reiterate that the primary Direct Project specification is
still the minimum required transport capability EPs, EHs, and CAHs will
need to meet the CEHRT definition.
Applicability Statement for Secure Health Transport
Comments. Commenters widely supported the adoption of this
certification criterion. One commenter noted that in the case of
immunization information, Direct is a suboptimal transport method.
Response. We appreciate the comments received on this certification
criterion and have adopted this criterion as a new optional
certification criterion at Sec. 170.314(h)(1). We recognize that the
primary Direct Project specification may not be the best fit for every
type of transmission. However, we note that the standard is not
required for public health transmissions.
Applicability Statement for Secure Health Transport and XDR/XDM for
Direct Messaging
Comments. We did not receive any comments suggesting we not adopt
this specific criterion.
Response. We have adopted this criterion as a new optional
certification criterion at Sec. 170.314(h)(2). We note that the
proposed regulation text in the Proposed Rule was not consistent with
the Proposed Rule preamble in that it did not mirror the ``optional''
capability expressed at Sec. 170.314(b)(1)(i)(B) andSec.
170.314(b)(2)(ii)(B) (i.e., Direct and XDR/XDM for Direct Messaging).
Rather, it only referenced the XDR/XDM for Direct Messaging standard.
In what we are adopting in this final rule, we have now aligned the
regulation text with our proposal by including references to both the
XDR/XDM for Direct Messaging (Sec. 170.202(b)) and the Direct standard
(Sec. 170.202(a)).
SOAP Transport and Security Specification and XDR/XDM for Direct
Messaging
Comments. Commenters supported the adoption of this certification
criterion. One commenter noted that this criterion would best support
immunization information transmissions.
Response. We appreciate the comments we received on this criterion
and have adopted this criterion as a new optional certification
criterion at Sec. 170.314(h)(3). We note that the proposed regulation
text in the Proposed Rule was not consistent with the Proposed Rule
preamble in that it did not mirror the ``optional'' capability
expressed at Sec. 170.314(b)(1)(i)(C) and Sec. 170.314(b)(2)(ii)(C)
(i.e., SOAP RTM and XDR/XDM for Direct Messaging). Rather, it only
referenced the SOAP RTM standard. In what we are adopting in this final
rule, we have now aligned the regulation text with our proposal by
including references to both the SOAP RTM standard (Sec. 170.202(c))
and the XDR/XDM for Direct Messaging (Sec. 170.202(b)).
3. Gap Certification Eligibility Table for 2014 Edition Release 2
``Gap certification'' is defined at 45 CFR 170.502 as ``the
certification of a previously certified Complete EHR or EHR Module(s)
to: (1) [a]ll applicable new and/or revised certification criteria
adopted by the Secretary at subpart C of [part 170] based on the test
results of a NVLAP-accredited testing laboratory; and (2) [a]ll other
applicable certification criteria adopted by the Secretary at subpart C
of [part 170] based on the test results used to previously certify the
Complete EHR or EHR Module(s)'' (for further explanation, see 76 FR
1307-1308). Our gap certification policy focuses on the differences
between certification criteria that are adopted through rulemaking at
different points in time. Under our gap certification policy,
``unchanged'' criteria (see 77 FR 54248 for further explanation) are
eligible for gap certification, and each ONC-ACB has discretion over
whether it will provide the option of gap certification.
In the Proposed Rule, we included a table (79 FR 10916) that
provided a crosswalk of unchanged Proposed Voluntary Edition EHR
certification criteria to the corresponding 2014 Edition EHR
certification criteria. We provided corrections to this table in a
notice published in the Federal Register on March 19, 2014 (79 FR
15282). We have provided a new table (Table 3) in this final rule
because we have not adopted the full Proposed Voluntary Edition and
have also made revisions to a proposed certification criterion that we
are including in the 2014 Edition as part of Release 2 (i.e., ``CPOE--
laboratory'' Sec. 170.314(a)(19)). The table below provides a
crosswalk of 2014 Edition Release 2 certification criteria that are
eligible for gap certification using the test results of EHR technology
previously certified to the 2014 Edition and 2011 Edition.
[[Page 54443]]
Table 3--Gap Certification Eligibility for 2014 Edition, Release 2 EHR Certification Criteria
----------------------------------------------------------------------------------------------------------------
2014 edition release 2 2014 Edition 2011 Edition
----------------------------------------------------------------------------------------------------------------
Title of Title of Title of
Regulation section regulation Regulation regulation Regulation section regulation
paragraph section paragraph paragraph
----------------------------------------------------------------------------------------------------------------
Sec. Optional--computeri
170.314(a)(18). zed physician
order entry--
medications.
Sec. Optional--computeri Sec. Computerized Sec. 170.304(a); Computeriz
170.314(a)(19). zed physician 170.314(a)(1). physician order Sec. 170.306(a). ed
order entry-- entry. physician
laboratory. order
entry.
Sec. Optional--computeri
170.314(a)(20). zed physician
order entry--
diagnostic
imaging.
Sec. Optional--ambulator Sec. Transmission to Sec. 170.302(1). Public
170.314(f)(7)*. y setting only-- 170.314(f)(3). public health health
transmission to agencies--syndrom surveillan
public health ic surveillance ce
agencies--syndromi (ambulatory (ambulator
c surveillance. setting only). y setting
only).
Sec. Optional--Applicabi Sec. Transitions of Not applicable.... Not
170.314(h)(1). lity Statement for 170.314(b)(1)(i)( care--receive, applicable
Secure Health. A) and Sec. display, and .
170.314(b)(2)(ii) incorporate
(A). transition of
care/referral
summaries.Transit
ions of care--
create and
transmit
transition of
care/referral
summaries..
Sec. Optional--Applicabi Sec. Transitions of Not applicable.... Not
170.314(h)(2). lity Statement for 170.314(b)(1)(i)( care--receive, applicable
Secure Health B) and Sec. display, and .
Transport and XDR/ 170.314(b)(2)(ii) incorporate
XDM for Direct (B). transition of
Messaging. care/referral
summaries
Transitions of
care--create and
transmit
transition of
care/referral
summaries..
Sec. Optional--SOAP Sec. Transitions of Not applicable.... Not
170.314(h)(3). Transport and 170.314(b)(1)(i)( care--create and applicable
Security C) and Sec. transmit .
Specification and 170.314(b)(2)(ii) transition of
XDR/XDM for Direct (C). care/referral
Messaging. summaries.
----------------------------------------------------------------------------------------------------------------
* Gap certification does not apply for the optional data elements listed in Sec. 170.314(f)(7).
4. Base EHR Definition
We proposed to include in the Base EHR definition (a foundational
part of the CEHRT definition) the Proposed Voluntary Edition EHR
certification criteria that corresponded to the 2014 Edition EHR
certification criteria already specified in the Base EHR definition
(i.e., CPOE, demographics, problem list, medication list, medication
allergy list, clinical decision support (CDS), CQMs, transitions of
care, data portability, and privacy and security).
Comments. We received a comment that supported the inclusion of the
proposed CPOE certification criteria in the Base EHR definition because
it would provide the potential for more flexibility and less burden for
EPs, EHs, and CAHs in meeting the Base EHR definition.
Response. We have not revised the Base EHR definition as proposed.
However, we have revised the Base EHR definition to include the
optional CPOE, ToC, and the Direct transport (Sec. 170.314(h)(1))
certification criteria adopted in this final rule. The inclusion of
these certification criteria in the Base EHR definition will, as noted
by the commenter in relation to the CPOE certification criteria, offer
flexibility and reduced burden in meeting the Base EHR definition for
some EPs, EHs, and CAHs.
B. ONC HIT Certification Program
1. Discontinuation of the Complete EHR
We proposed to discontinue use of the Complete EHR definition as a
regulatory concept and the certification of Complete EHRs beginning
with the Proposed Voluntary Edition. As an alternative to the proposal,
if we were to keep the Complete EHR concept and definition for editions
of certification criteria beyond the 2014 Edition, we proposed to
either continue the same policy of adopting an edition-specific
Complete EHR (e.g., ``2015 Edition'' Complete EHR) or define a Complete
EHR as ``EHR technology that has been developed to meet, at a minimum,
all mandatory certification criteria of an edition of EHR certification
criteria adopted by the Secretary for either an ambulatory setting or
inpatient setting and meets the Base EHR definition.'' For the latter,
we noted that ONC-ACBs would be responsible for issuing Complete EHR
certifications that specify the edition the Complete EHR was certified
to and that the information would be evident through listing on the
Certified HIT Product List (CHPL).
Comments. We received many comments from associations representing
providers, consumers, and HIT developers as well as comments from
numerous HIT developers. The overwhelming majority supported our
proposal to discontinue the Complete EHR definition and Complete EHR
certification for the reasons we specified in the Proposed Rule
(recited below in the response). One association was neither for nor
against our proposal, but was more concerned that providers have a
clear understanding of what they are purchasing. In particular, the
association stated that information outlining the product's criteria
should be readily apparent when purchasing the product and also
available on ONC's Web site. A few commenters suggested that we retain
Complete EHR certification as an option for EHR technology developer
and consumer purchasing. One of these commenters recommended that we
tailor a Complete
[[Page 54444]]
EHR certification by the MU Stage it would be associated with, while
another suggested calling it a ``Comprehensive EHR.''
Response. We have finalized our proposal to discontinue the
Complete EHR definition and Complete EHR certification. While we have
not adopted the Proposed Voluntary Edition, this approach will apply
for all future adopted editions of certification criteria as specified
in Sec. 170.501(b) (discussed in more detail under section III.B.2
``Applicability'' of this preamble). To be clear, the discontinuation
of the Complete EHR definition and Complete EHR certification will have
no impact on current 2014 Edition Complete EHR certifications or in
using a 2014 Edition Complete EHR to meet the current CEHRT definition.
In regard to additional 2014 Edition Release 2 certification criteria,
we have adopted them all as optional criteria and thus they do not
impact the 2014 Edition Complete EHR definition.
In the Proposed Rule (79 FR 10917-10918), we explained our
rationale for discontinuing the Complete EHR definition. We are
reciting our rationale again here as we still believe these reasons
hold true. Following the recitation of these reasons, with minor
modifications due to the MU Flexibility Final Rule (79 FR 52910), we
offer further rationale and responses to comments.
(1) The Complete EHR definition initially was intended to support
the original CEHRT definition established in the 2011 Edition Final
Rule under Sec. 170.102. As a general summary, the original CEHRT
definition required an EP, EH, and CAH to have EHR technology that met
ALL of the certification criteria adopted for an applicable setting
(ambulatory or inpatient). The ``Complete EHR'' term and definition was
meant to convey that all applicable certification criteria had been met
and the statutory requirements of the Qualified EHR definition had been
fulfilled. The CEHRT definition based on EHR technology certification
to the 2014 Edition (2014 Edition CEHRT definition) and Complete EHR
definition no longer share the same symmetry. In fact, the 2014 Edition
Complete EHR definition now exceeds the 2014 Edition CEHRT definition's
requirements as to the number of certification criteria to which an EHR
technology would need to be certified to meet the CEHRT definition.
(2) Since publication of the 2014 Edition Final Rule, we have
received stakeholder feedback through email questions and during
educational presentations and other outreach that demonstrates
confusion about the interplay between the CEHRT definition, the Base
EHR definition (adopted as part of the 2014 Edition Final Rule), and
the Complete EHR definition. Stakeholders have correctly concluded that
a certified 2014 Edition Complete EHR could be used to meet the CEHRT
definition. However, some stakeholders believe incorrectly that their
only regulatory option to meet the CEHRT definition is to adopt a
certified Complete EHR when, under the CEHRT definition for FY/CY 2014
and subsequent years in Sec. 170.102, they can use EHR technology (EHR
Module(s)) certified to the 2014 Edition EHR certification criteria
that meets the Base EHR definition (a finite set of capabilities) and
includes all other capabilities that are necessary to meet the
objectives and measures and successfully report CQMs for the MU Stage
they are attempting to achieve.
(3) A Complete EHR is not necessarily ``complete'' or sufficient
when it comes to an EP's, EH's, or CAH's attempt to achieve MU. For
example, based on the ``Complete EHR, 2014 Edition'' definition, it may
not be certified to particular CQMs on which an EP intends to report
and it may not have been certified to capabilities included in optional
certification criteria that an EP needs for MU, such as the 2014
Edition cancer reporting certification criteria (Sec. 170.314(f)(5)
and (6)). Thus, if we were to continue this policy approach, we believe
this discrepancy would only grow and cause greater confusion over time.
(4) Stakeholder feedback to us since the 2014 Edition Final Rule
(via conference and webinar question and answer sessions, public
meetings, and emails) and the data currently available on the CHPL
indicates that some EHR technology developers have continued to seek
only a 2014 Edition Complete EHR certification and, thus, only plan to
offer a certified Complete EHR as a solution to customers. While we
recognize EHR technology developers may choose to pursue various
approaches for designing and marketing their products, we are in a
position to modify our policy so that it does not encourage EHR
technology developers to offer only a single certified solution. In
general, we believe the decision to seek certification only for a
Complete EHR serves to defeat the flexibility provided by the 2014
Edition CEHRT definition. Consequently, by discontinuing the
availability of the Complete EHR certification, the EHR technology
market could be driven by EHR technology developers competing on the
capabilities included in their EHR technology rather than on the type
of certification issued (Complete EHR or EHR Module).
(5) The discrepancy between what any single EP, EH, or CAH needs to
achieve MU and the Complete EHR definition will likely only grow more
disparate when we adopt certification criteria in a new edition to
support MU Stage 3. At that time, there may be EPs, EHs, and CAHs
attempting to achieve each of the three stages of MU, but a Complete
EHR following the structure of the 2014 Edition Complete EHR definition
would likely include capabilities that support core and menu objectives
and measures for all MU stages.
(6) Discontinuing the use of the Complete EHR concept would be
consistent with the instruction of Executive Order 13563 to identify
and consider approaches that make the agency's regulatory program more
effective or less burdensome in achieving the regulatory objectives. To
illustrate, we would not need to designate EHR certification criteria
as mandatory or optional in our regulation text as these categories
were specifically developed to accommodate the Complete EHR definition
(i.e., cases where EHR technology would otherwise have to be certified
to a criterion solely because it is required in order to satisfy the
Complete EHR certification).
As stated in the Proposed Rule, discontinuation of Complete EHR
definition and certification does not affect EHR Module certification.
In fact, as it stands now with 2014 Edition certification, an EHR
Module certificate can be issued to an EHR technology that includes
every certification criterion that is included in a Complete EHR
certificate issued to an EHR technology (and even with the EHR Module
certificate, the capabilities can be integrated in the same
manner),\16\ but would not be given the ``Complete EHR'' designation.
The discontinuation of the Complete EHR definition and certification
will also help to address commenters' concerns about clearly knowing
what certification criteria an EHR technology is certified to because,
unlike Complete EHR developers for their Complete EHRs, an EHR Module
developer is required by regulation to specifically list in
communications and marketing materials all the certification criteria
to which the EHR technology was certified and for which it was issued
an EHR Module certificate.
[[Page 54445]]
Therefore, with only EHR Module certificates on the market, we believe
it will be easier to know and compare the certification criteria to
which they have been certified. Last, while we do not believe the use
of the terms ``Complete'' or ``Comprehensive'' are appropriate for
``labeling'' EHR technology going forward, we will consider for our
next rulemaking whether any other ``labeling'' for certified
technologies could continue to make the scope of certification clearer.
---------------------------------------------------------------------------
\16\ To note, the ONC HIT Certification Program does not include
integration testing and certification of Complete EHRs or EHR
Modules as that is left to the EHR technology developer and its
customers.
---------------------------------------------------------------------------
2. Applicability
We proposed to revise the ``applicability'' section (Sec. 170.501)
for the ONC HIT Certification Program to clearly indicate that
references to the term Complete EHR and Complete EHR certification do
not apply to certification in accordance with the Proposed Voluntary
Edition and any subsequent edition of certification criteria adopted by
the Secretary under subpart C. This proposal was consistent with our
proposal to discontinue the use of the Complete EHR concept and
Complete EHR certification beginning with the Proposed Voluntary
Edition.
Comments. We received two comments expressing agreement with our
proposal.
Response. We have finalized our proposal consistent with our
decision to finalize the proposals to discontinue use of the Complete
EHR concept and Complete EHR certification for any subsequent adopted
edition of certification criteria. We have, however, finalized this
proposal in a manner that accounts for our decision not to adopt the
Proposed Voluntary Edition. Specifically, we have revised Sec.
170.501(b) to read: ``References to the term Complete EHR and Complete
EHR certification throughout this subpart do not apply to certification
in accordance with any edition of certification criteria that is
adopted by the Secretary under subpart C after the 2014 Edition EHR
certification criteria.''
3. ONC Regulations FAQ 28
In ONC regulations FAQ 28,\17\ we provide guidance on the
application of Sec. 170.314(g)(1) and (g)(2) to the certification of
Complete EHRs and EHR Modules. We state in FAQ 28 and in the 2014
Edition Final Rule (77 FR 54186) that ONC-ACBs can certify an EHR
Module to either the 2014 Edition ``automated numerator recording''
certification criterion or the 2014 Edition ``automated measure
calculation'' certification criterion.
---------------------------------------------------------------------------
\17\ http://www.healthit.gov/policy-researchers-implementers/28-question-11-12-028.
---------------------------------------------------------------------------
To provide regulatory clarity, we proposed to revise Sec.
170.550(f)(1) to specify this flexibility for the certification of EHR
Modules to the 2014 Edition and proposed the same flexibility in Sec.
170.550(g)(1) for MU EHR Modules certified to the Proposed Voluntary
Edition ``automated numerator recording'' certification criterion and
the ``automated measure calculation'' certification criterion. We also
clarified that an EHR Module (or proposed ``MU EHR Module'' with regard
to the Proposed Voluntary Edition) could be certified to only the
``automated measure calculation'' certification criterion (Sec. Sec.
170.314(g)(2) or proposed 170.315(g)(2)) in situations where the EHR
Module does not include a capability that supports a percentage-based
MU objective and measure, but can meet the requirements of the
``automated measure calculation'' certification criterion (Sec. Sec.
170.314(g)(2) or proposed 170.315(g)(2)). We noted that an example of
this would be an ``analytics'' EHR Module where data is fed from other
EHR technology and the EHR Module can record the requisite numerators,
denominators and create the necessary percentage report as specified in
the ``automated measure calculation'' certification criterion. In these
situations, we stated that Sec. 170.550(f)(1) or (g)(1) would not be
implicated or need to be applied.
We proposed to revise Sec. 170.314(g)(1) to be an optional
certification criterion as a means of providing regulatory clarity for
the certification of Complete EHRs to the 2014 Edition, which would
implement the guidance provided in FAQ 28. In FAQ 28, we stated that
EHR technology issued a 2014 Edition Complete EHR certification must be
certified to Sec. 170.314(g)(2) because it is a mandatory
certification criterion consistent with the 2014 Edition Complete EHR
definition requiring certification to all mandatory certification
criteria for a particular setting (ambulatory or inpatient), but not
Sec. 170.314(g)(1) (even though it too was designated as a mandatory
certification criterion) because a 2014 Edition Complete EHR would have
demonstrated capabilities beyond those included in Sec. 170.314(g)(1)
by being certified to (g)(2).
We proposed that if were to retain the Complete EHR concept for the
Proposed Voluntary Edition, we would take the same approach for
Complete EHRs as specified in FAQ 28 and in our proposed regulatory
changes to Sec. 170.314(g)(1).
Comments. We received a few comments supporting the continued
requirement for Complete EHRs to be certified to the ``automated
measure calculation'' certification criterion (Sec. 170.314(g)(2)). We
received one comment supporting our proposal to revise Sec.
170.314(g)(1) to be an optional certification criterion as a means of
providing regulatory clarity for the certification of Complete EHRs to
the 2014 Edition.
Response. We have not finalized the proposals related to the
Proposed Voluntary Edition because we have not adopted the Proposed
Voluntary Edition. We have, however, finalized the proposals related to
the 2014 Edition. We have designated the ``automated numerator
recording'' certification criterion at Sec. 170.314(g)(1) as an
optional certification criterion, which will provide greater regulatory
clarity for ONC-ACBs as they determine whether EHR technology meets the
2014 Edition Complete EHR definition and therefore must be certified to
Sec. 170.314(g)(2). Certification to Sec. 170.314(g)(2) is required
to meet the 2014 Complete EHR definition as it is a mandatory
certification criterion. This approach is also supported by commenters.
We have revised Sec. 170.550(f)(1) to require ONC-ACBs to certify EHR
Modules to either Sec. 170.314(g)(1) or (2), rather than just
requiring certification to Sec. 170.314(g)(1). This will implement FAQ
28 guidance and flexibility as well as provide regulatory clarity.
We also maintain our clarification and guidance included in the
Proposed Rule related to an EHR Module being able to be certified to
only the ``automated measure calculation'' certification criterion
(Sec. 170.314(g)(2)) in situations where the EHR Module does not
include a capability that supports a percentage-based MU objective and
measure, but can meet the requirements of the ``automated measure
calculation'' certification criterion.
4. Patient List Creation Certification Criteria
In the Proposed Rule, we discussed how the 2014 Edition (and
Proposed Voluntary Edition) ``patient list creation'' certification
criterion includes capabilities that support two MU objectives, one
with a percentage-based measure and one without (i.e., ``use clinically
relevant information to identify patients who should receive reminders
for preventive/follow-up care and send these patients the reminders,
per patient preference'' (``patient
[[Page 54446]]
reminders'') \18\ and ``generate lists of patients by specific
conditions to use for quality improvement, reduction of disparities,
research, or outreach,'' respectively). We clarified that in situations
where EHR technology is presented for certification to the 2014 Edition
(and Proposed Voluntary Edition) ``patient list creation''
certification criterion and does not include a capability to support
``patient reminders,'' it would not need to be certified to the
``automated numerator recording'' certification criterion (Sec.
170.314(g)(1)) nor the ``automated measure calculation'' certification
criterion (Sec. 170.314(g)(2)) for ``patient reminders'' percentage-
based measure capabilities.
---------------------------------------------------------------------------
\18\ The MU measure for this objective is: More than 10 percent
of all unique patients who have had 2 or more office visits with the
EP within the 24 months before the beginning of the EHR reporting
period were sent a reminder, per patient preference when available.
---------------------------------------------------------------------------
Comments. We received a few comments supporting our clarification
and guidance. An ONC-ACB further noted that, in its experience, there
are only a ``handful'' of EHR technologies presented for certification
for which this type of scenario would be applicable.
Response. We appreciate commenters' support and agreement with our
clarification and guidance. While we have not adopted the proposed
``patient list creation'' certification criterion, our clarification
and guidance remains applicable for the certification of EHR technology
to the 2014 Edition ``patient list creation'' certification criterion
(Sec. 170.314(a)(14)). As noted by the ONC-ACB, the clarification and
guidance will be helpful in facilitating the proper certification of at
least some EHR technology to the 2014 Edition ``patient list creation''
certification criterion.
5. ISO/IEC 17065
Section 170.503(b)(1) requires applicants for ONC-Approved
Accreditor (ONC-AA) status to provide a detailed description of their
experience evaluating the conformance of certification bodies to
International Organization for Standardization/International
Electrotechnical Commission (ISO/IEC) Guide 65:1996 (``Guide 65'').
Section 170.503(e)(2) requires the ONC-AA to verify that the
certification bodies it accredits and ONC-ACBs conform to, at a
minimum, Guide 65. The ISO issued ISO/IEC 17065: 2012 \19\ (ISO 17065),
which cancels and replaces Guide 65.
---------------------------------------------------------------------------
\19\ http://www.iso.org/iso/catalogue_detail.htm?csnumber=46568. ISO slide presentation
on 17065: http://www.iso.org/iso/ppt_presentation_17065.ppt.
---------------------------------------------------------------------------
Because ISO has replaced Guide 65 with ISO/IEC 17065, we proposed
to revise Sec. 170.503(b)(1) and (e)(2) to replace the references to
Guide 65 with ISO 17065. For Sec. 170.503(b)(1), we proposed that the
change would be effective as of the effective date of this final rule.
We noted that we anticipated that the effective date of this final rule
would occur after we select an accreditation body as the ONC-AA for the
next three-year term as ANSI's \20\ initial term expired in June 2014.
Because of this, we noted that we would next need to assess applicants
for ONC-AA status in early 2017 and by then we expected that any
applicant would have experience evaluating the conformance of
certification bodies to ISO 17065. For Sec. 170.503(e)(2), we proposed
to require compliance with ISO 17065 beginning in FY 2016 (in other
words, as of October 1, 2015). We stated that this compliance date
should provide sufficient time for certification bodies that are
interested in serving as ONC-ACBs, as well as existing ONC-ACBs, to be
accredited to ISO 17065 by the ONC-AA.
---------------------------------------------------------------------------
\20\ American National Standards Institute, the ONC-AA.
---------------------------------------------------------------------------
We also proposed to revise our references to ISO/IEC standards
17011, 17065 and Guide 65 in Sec. 170.503 by removing or not including
the date reference for each standard. The published date information
for each standard will continue to be listed in Sec. 170.599. This
approach aligns with guidance we received from the Office of the
Federal Register.
Comments. We received comments from the ONC-AA and ONC-ACBs. The
comments from these organizations specifically supported our proposals
transition from Guide 65 to ISO 17065 and to remove the date reference
for each standard.
Response. We appreciate the comments of support for our proposals
and also note that, as anticipated, an accreditation organization
(ANSI) was selected to serve as the ONC-AA for a 3-year term that began
in June 2014.\21\ Based on comments received and the rationale cited in
the Proposed Rule, we have finalized revisions to Sec. 170.503(b)(1)
and (e)(2) as proposed. We have also removed the date references for
the standards in Sec. 170.503 as proposed. In regard to removing the
dates, we have also revised Sec. 170.599(b) to provide clear
attribution to the version of the ISO/IEC standards we are referring to
in Sec. 170.503. More specifically, we identify in Sec. 170.599 that
the ISO/IEC standards will be referred to as ``ISO/IEC 17011,'' ISO/IEC
Guide 65,'' and ISO/IEC 17065'' when used in subpart E of Part 170.
This approach is consistent with guidance from the Office of the
Federal Register.
---------------------------------------------------------------------------
\21\ http://www.hhs.gov/news/press/2014pres/05/20140513c.html.
---------------------------------------------------------------------------
6. ONC Certification Mark
ONC has developed and administers the ``ONC Certified HIT''
certification and design mark (the ``Mark'').\22\ The Mark, as used by
an authorized user, certifies that a particular HIT product (Complete
EHR, EHR Module, or other types of HIT for which the Secretary of HHS
adopts applicable certification criteria, see 45 CFR 170.510) has been
tested in accordance with test procedures approved by the National
Coordinator; has been certified in accordance with the certification
criteria adopted by the Secretary at 45 CFR part 170, Subpart C; and
has met all other required conditions of the ONC HIT Certification
Program at 45 CFR part 170, Subpart E.
---------------------------------------------------------------------------
\22\ http://www.healthit.gov/policy-researchers-implementers/onc-hit-certification-program.
---------------------------------------------------------------------------
We proposed to require ONC-ACBs to use the Mark in connection with
HIT they certify under the ONC HIT Certification Program. More
specifically, we proposed to revise Sec. 170.523 (``Principles of
Proper Conduct'') to require ONC-ACBs to display the Mark on all
certifications issued under the ONC HIT Certification Program in a
manner that complies with the Criteria and Terms of Use for the ONC
Certified HIT Certification and Design Mark (``Terms of Use'').\23\ In
addition, we proposed to revise Sec. 170.523 to require ONC-ACBs to
ensure that use of the Mark by HIT developers whose products are
certified under the ONC HIT Certification Program is compliant with the
Terms of Use. We noted that, in the event that the Terms of Use are
revised or updated, compliance with the most recent version would be
required.
---------------------------------------------------------------------------
\23\ http://www.healthit.gov/sites/default/files/hit_certificationterms_of_use_final.pdf.
---------------------------------------------------------------------------
Comments. Commenters expressed agreement with our proposals citing
to the consistency and clarity that a standard mark would provide in
terms of identifying HIT certified under the ONC HIT Certification
Program. One commenter requested clarification as to whether ONC-ACBs
may also use their own mark in conjunction with the Mark, while another
commenter requested clarity as to whether a HIT developer would be
required to use the Mark.
Response. We thank commenters for their support. We have finalized
the revisions to Sec. 170.523 as proposed. As noted by commenters and
in the
[[Page 54447]]
Proposed Rule, the required use of a singular identifying mark will
provide consistency in the recognition of HIT certified under the ONC
HIT Certification Program and mitigate any potential market confusion
for purchasers between HIT products certified under the ONC HIT
Certification Program and those certified under any other program.
While every ONC-ACB will be required to display the Mark on all
certifications issued under the ONC HIT Certification Program in a
manner that complies with the Terms of Use, they will also be able to
use their own marks in conjunction with the Mark as specified in the
Terms of Use under the ``Accompanying Marks, Logos, and Symbols''
section. This would also hold true for a HIT developer that chose to
use the Mark. To this point and to address the requested commenter
clarification, an HIT developer is not required to use the Mark.
However, if they choose to use the Mark, then the ONC-ACB that issued
the certification to the HIT developer would be required to ensure that
the use of the Mark by the HIT developer is compliant with the Terms of
Use. Our expectation is that HIT developers will want to use the Mark
as a way of clearly and easily identifying that their product was
certified under the ONC HIT Certification Program.
C. Removal of the 2011 Edition EHR Certification Criteria From the CFR
We proposed to remove the 2011 Edition EHR Certification Criteria
and related standards, terms, and requirements from the CFR.
Specifically, we proposed to remove 45 CFR 170.302, 170.304, and
170.306. We also proposed to remove the standards and implementation
specifications found in 45 CFR 170.205, 170.207, 170.210, and 170.299
that are only referenced in the 2011 Edition EHR certification
criteria. In regard to terms, we proposed to retire the definitions
found in 45 CFR 170.102 related to the 2011 Edition, including ``2011
Edition EHR certification criteria'' and ``Complete EHR, 2011
Edition.'' In regard to requirements, we proposed to remove Sec.
170.550(e) and any other requirement in subpart E, Sec. Sec. 170.500
through 170.599 that is specific to the 2011 Edition and does not have
general applicability to other editions of certification criteria.
Comments. We received one comment supporting this ``administrative
update.''
Response. In the Proposed Rule, we stated that EHR technology
certified to 2011 Edition no longer meets the CEHRT definition. We also
referenced recent rulemakings by the HHS Office of Inspector General
and CMS around donations of EHR items and services that cited our
expectations to retire old/no longer applicable certification criteria
editions.\24\ As noted in the Proposed Rule, we believe this approach
will streamline our requirements and ensure there is no regulatory
confusion involving administration of ONC's rules and the rules of
other agencies' such as CMS's Physician Self-Referral Law exception and
OIG's Anti-kickback Statute safe harbor for certain EHR donations.
Therefore, consistent with EO 13563 instruction to ``determine whether
any [agency] regulations should be modified, streamlined, expanded, or
repealed so as to make the agency's regulatory program more effective
or less burdensome in achieving the regulatory objectives,'' we are
removing the 2011 Edition EHR certification criteria and related
standards, terms, and requirements from the CFR.
---------------------------------------------------------------------------
\24\ CMS final rule ``Medicare Program; Physicians' Referrals to
Health Care Entities With Which They Have Financial Relationships:
Exception for Certain Electronic Health Records Arrangements'' (78
FR 78751).OIG final rule ``Medicare and State Health Care Programs:
Fraud and Abuse; Electronic Health Records Safe Harbor Under the
Anti-Kickback Statute'' (78 FR 79202).
---------------------------------------------------------------------------
Since publication of our Proposed Rule, we and CMS jointly issued a
final rule entitled ``Medicare and Medicaid Programs; Modifications to
the Medicare and Medicaid Electronic Health Record Incentive Programs
for 2014; and Health Information Technology: Revisions to the Certified
EHR Technology Definition'' (79 FR 52910). The final rule permits EPs,
EHs, and CAHs to use EHR technology certified to the 2011 Edition or a
combination of EHR technology certified to the 2011 Edition and 2014
Edition to meet the CEHRT definition in CY 2014 and FY 2014. To account
for the permitted use of EHR technology certified to the 2011 Edition
to meet the CEHRT definition in 2014 and the potential certification of
EHR technology to the 2011 Edition through the end of CY 2014, the
effective date for the removal of the 2011 Edition EHR certification
criteria and related standards, terms, and requirements from the CFR
will be March 1, 2015.
D. Removal of the Temporary Certification Program From the CFR
The temporary certification program sunset on October 4, 2012, and
is no longer in existence (77 FR 54268). Accordingly, we proposed to
remove from the CFR the associated regulations, consisting of subpart D
(Sec. Sec. 170.400 through 170.499).
Comments. We received no comments on this proposal.
Response. We are removing the temporary certification program
regulations from the CFR on the effective date of this final rule.
IV. Not Adopted Proposals
This section of the preamble discusses proposals from the Proposed
Rule that we have not adopted, including comments received on those
proposals and our response to those comments. As noted in the Executive
Summary, we have not adopted the Proposed Voluntary Edition. Rather, we
have only adopted a small subset of the proposed certification criteria
as optional 2014 Edition EHR certification criteria and made revisions
to 2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange; and administrative
proposals (i.e., removal of regulatory text from the CFR) and proposals
for the ONC HIT Certification Program that provide improvements.
A. Not Adopted EHR Certification Criteria and Certification Criteria
Proposals Applicability--Sec. 170.300
Section 170.300 establishes the applicability of subpart C--
Certification Criteria for Health Information Technology. We proposed
to revise paragraph (d) of Sec. 170.300 to add in a reference to Sec.
170.315, which would clarify which specific capabilities within a
certification criterion included in Sec. 170.315 have general
applicability (i.e., apply to both ambulatory and inpatient settings)
or apply only to an inpatient setting or an ambulatory setting.
Comments. We did not receive any comments on this specific
proposal.
Response. As noted in the Executive Summary, we have not adopted
the Proposed Voluntary Edition. Rather, we have only adopted a small
subset of the proposed certification criteria as optional 2014 Edition
EHR certification criteria and made revisions to 2014 Edition EHR
certification criteria that provide flexibility, clarity, and enhance
health information exchange. Therefore, we have not revised paragraph
(d) of Sec. 170.300 to add in a reference to Sec. 170.315. The
optional certification criteria that we have adopted in this final rule
will be part of the 2014 Edition and are included in Sec. 170.314,
which is already referenced in paragraph (d) of Sec. 170.300.
Computerized Provider Order Entry--Medications
We proposed to adopt for the Proposed Voluntary Edition a CPOE
[[Page 54448]]
certification criterion specific to medication ordering. The proposed
criterion was structured substantially similar to the 2014 Edition CPOE
certification criterion, except it did not reference laboratory and
radiology/imaging orders. We did not request any specific public
comments on this certification criterion.
Comments. One commenter recommended that we add functionality that
would allow health care providers to electronically report adverse
events related to medications directly to manufacturers and the Food
and Drug Administration (FDA). Another commenter suggested that when
providers order medication, labs and radiology that providers
electronically send a CDA formatted document to the patient, where the
capability exists.
Response. We appreciate these comments, but they are outside the
scope of the proposed criterion. We have not adopted this certification
criterion as part of the Proposed Voluntary Edition because we have not
adopted the Proposed Voluntary Edition. Rather, we have only adopted a
small subset of the proposed certification criteria as optional 2014
Edition EHR certification criteria and made revisions to 2014 Edition
EHR certification criteria that provide flexibility, clarity, and
enhance health information exchange. As discussed under section III.A.2
of this preamble, we have adopted this certification criterion without
modification as a 2014 Edition optional certification criterion.
Computerized Provider Order Entry--Laboratory
We proposed to adopt for the Proposed Voluntary Edition a CPOE
certification criterion specific to laboratory ordering. We proposed to
adopt, for the ambulatory setting, the HL7 Version 2.5.1 Implementation
Guide: S&I Framework Laboratory Orders from EHR, Release 1-US Realm,
Draft Standard for Trial Use, November 2013 (LOI).\25\ We also proposed
to require the use of, at a minimum, the version of Logical Observation
Identifiers Names and Codes (LOINC[supreg]) adopted at Sec.
170.207(c)(2) (version 2.40) as the vocabulary standard for laboratory
orders. Last, we proposed that laboratory orders must include all the
information for a test requisition as specified at 42 CFR
493.1241(c)(1) through (c)(8). We stated that the use of these
standards and compliance with these requirements should greatly improve
the interoperability of laboratory orders sent from ambulatory EHR
technology to a laboratory and laboratory compliance with the Clinical
Laboratory Improvements Amendments (CLIA).
---------------------------------------------------------------------------
\25\ http://www.hl7.org/special/committees/projman/searchableprojectindex.cfm?action=edit&ProjectNumber=922.
---------------------------------------------------------------------------
Comments. Commenters were generally supportive of adoption of
interoperable laboratory standards, particularly the LOI IG, and
aligning requirements with CLIA. Commenters did, however, express
concern with the LOI IG, the use of LOINC[supreg] for all orders, and
the lack of a proposal to adopt the Electronic Directory of Services
(eDOS) IG. Commenters stated that the LOI IG was new, likely
incomplete, and will require substantial updates over the next 12-18
months. Commenters suggested waiting for a more complete version of the
LOI IG, including pilot testing of the IG. Commenters expressed
considerable concern that without the eDOS IG it would be difficult to
achieve optimal interoperability. Commenters stated that LOINC[supreg]
does not cover all orderable tests and that testing and certification
would need to accommodate this fact. Commenters suggested additional
guidance was necessary for compliance with the proposed CLIA
requirements.
Response. We have not adopted this certification criterion as part
of the Proposed Voluntary Edition because we have not adopted the
Proposed Voluntary Edition. Rather, we have only adopted a small subset
of the proposed certification criteria as optional 2014 Edition EHR
certification criteria and made revisions to 2014 Edition EHR
certification criteria that provide flexibility, clarity, and enhance
health information exchange. As discussed under section III.A.2 of this
preamble, we have adopted this certification criterion without
modification as a 2014 Edition optional certification criterion. We
first note that we did not propose to adopt the eDOS IG because it was
our understanding that the eDOS IG was still undergoing revisions at
the time the Proposed Rule was being drafted. We also understood that
the LOI IG was fairly new and we appreciate the stakeholder feedback on
potential concerns with the LOI IG. We also thank commenters for their
insight related to the use of LOINC[supreg] for all laboratory orders.
While we have not adopted the LOI IG at this time, we plan to
reconsider it for adoption in our next rulemaking along with the eDOS
IG. We believe the time between now and our next final rule will permit
many of the concerns with these IGs to be sufficiently addressed.
Overall, the work towards laboratory interoperability and electronic
exchange shows great promise, including the work on the Lab Results
Interface (LRI) IG, Electronic Laboratory Reporting to Public Health
(ELR) IG and harmonization of all laboratory IGs. The adoption of these
standards for the ONC HIT Certification Program could help facilitate
laboratory interoperability and electronic exchange among providers,
assist laboratories with CLIA compliance. and reduce provider burden
with respect to the availability and use of the eDOS IG. As such, we
plan to revisit these standards in future rulemaking.
Computerized Provider Order Entry--Radiology/Imaging
We proposed to adopt for the Proposed Voluntary Edition a CPOE
certification criterion specific to radiology/imaging. The proposed
criterion was structured substantially similar to the 2014 Edition CPOE
certification criterion, except it did not reference medications and
laboratory orders. We did not request any specific public comments on
this certification criterion.
Comments. A few commenters questioned the value of this
certification criterion as is, while other commenters suggested that an
appropriate IG be developed and adopted for this certification
criterion.
Response. We have not adopted this certification criterion as part
of the Proposed Voluntary Edition because we have not adopted the
Proposed Voluntary Edition. Rather, we have only adopted a small subset
of the proposed certification criteria as optional 2014 Edition EHR
certification criteria and made revisions to 2014 Edition EHR
certification criteria that provide flexibility, clarity, and enhance
health information exchange. As discussed under section III.A.2 of this
preamble, we have adopted this certification criterion without
modification as a 2014 Edition optional certification criterion. We
will consider comments on the value of the certification criterion
without any associated standards or IGs and whether there are any
appropriate standards or IGs to adopt as part of future rulemaking.
Drug-Drug, Drug-Allergy Interaction Checks
We proposed a ``drug-drug, drug-allergy interaction checks''
certification criterion for the Proposed Voluntary Edition that was
unchanged as compared to the 2014 Edition certification criterion.
However, we solicited comment on whether drug-drug interaction (DDI) or
drug-allergy interaction (DAI) checks-capable EHR technology should be
able to track
[[Page 54449]]
health professionals' responses to the DDI/DAI checks that are
performed, and whether such a capability should track if and when the
health professional viewed, accepted, declined, ignored, overrode, or
otherwise commented on the product of a DDI/DAI check. We also sought
comment on who should be permitted to review the data collected by the
DDI/DAI check tracking capability, who should be able to adjust its
configuration settings, whether the data tracked should be limited in
scope or specificity, and whether EHR technology should be able to
track when an adverse event occurs for which a DDI/DAI check was missed
or ignored. In addition, we sought comment on whether a DDI/DAI
tracking capability should only track inaction or responses related to
certain drug-drug and drug-allergy reactions, such as only tracking
DDI/DAI alerts that if missed or ignored would cause severe reactions
in patients. Last, we sought comment on what factors, definitions,
standards, and existing consensus should be considered in determining
whether a likely DDI/DAI reaction should be considered severe.
Comments. Responses from commenters varied. Some commenters
expressed strong support for response tracking for DDI and DAI, and
suggested that a certification criterion also include response tracking
for other interactions, such as drug/lab, drug/diagnosis, food allergy,
drug-gene, therapeutic duplication, and environmental allergy
interactions. One commenter suggested that response tracking
certification exist for CDS interventions in general.
Of those commenters that opposed the inclusion of response tracking
as a certification criterion, several themes surfaced. Some commenters
noted that response tracking would be burdensome, require significant
time and investment, and could conflict with existing system
configuration settings already designed for tracking DDI/DAI provider
responses. Other commenters noted that response tracking functionality
should not be included in a certification criterion and should be
developed in the private sector according to the needs of individual
providers and their health IT developers. A few commenters noted that
response tracking could add an additional layer of alerting and impact
provider workflow. A few others noted that response tracking should
apply specifically to active alerts and should not apply to passive
alerts.
A few commenters noted that response tracking is not appropriate
for an EHR system and that such information is stored and tracked
within Risk Management Information Systems (RMIS) for liability
purposes and for analysis related to efforts to minimize the risk of
future adverse events.
We received a number of specific comments on the scope of response
tracking. Commenters who supported response tracking noted the value
such tracking provides to quality measurement, the improved usefulness
of a DDI/DAI alert criterion that would result from response tracking,
and the importance of such tracking being automated. One commenter
noted that response tracking should track whether the DAI/DAI alert is
``displayed'' and not whether it is ``viewed,'' which the commenter
suggested would impact the provider workflow by requiring provider
action. Others noted that in addition to tracking the response of a
provider, the factors that may have impacted a provider response would
be important to track--such as relevant patient factors or system
construction factors that can influence a provider's reaction to a
specific alert. A similar concern was raised by another commenter who
stated that provider response only provides part of the information
needed, and noted that whether the provider is a seasoned health care
professional or less experienced is an example of corollary information
that could impact whether an ignored DDI/DAI alert is a concern.
We received a variety of comments on who should be able to review
the responses of providers and who should be able to adjust tracking
configuration. Some commenters noted that in order for this proposal to
be operational and, if not already part of existing security protocols,
EHR vendors may need to implement new security classes to control
viewing privileges related to alerts. Some commenters noted that
adjustment of the tracking configuration should be done by the care
team and members of the ordering team, while other commenters noted
that the ability to adjust configuration or review the response
tracking results should be limited to a select few. Many commenters
stated that the decision on who should be able to adjust the tracking
configuration should be determined by the provider or the organization.
One commenter stated that EHR systems also should allow an
administrator to modify the workflow that a provider must take when
certain DDI/DAI alerts appear.
As part of the request for comment, we asked whether EHR systems
should be able to track when an adverse event occurs for a DDI/DAI
alert that is ignored. Many commenters expressed concern regarding
adverse event tracking. Some commenters stated that significant
development would be required to enable this capability in EHR systems.
Other commenters stated that the number of factors that can contribute
to an adverse event would inhibit the usefulness of such a criterion.
Conversely, we heard from several commenters that adverse event
reporting related to DDI/DAI alerts plays an important role. Some
commenters noted that providers should be able to make reports directly
to manufacturers and the FDA about adverse events associated with
medications. One commenter stated that in order for this criterion to
be useful, an approach to adverse events similar to the Vaccine Adverse
Event Reporting System would be needed.
Regarding what factors, definitions, standards, and existing
consensus should be considered in determining whether a likely DDI/DAI
reaction should be considered severe, some commenters noted that
standard vocabularies should be used for exchanging drug-allergy
information and that the DDI/DAI terminology should be standardized.
Other commenters opposed limiting tracking to only DDI/DAI that are
considered severe and suggested that the proposed tracking should apply
to all DDI/DAI because there is little consensus on what characterizes
a severe reaction. Another commenter stated that in lieu of defining
the term ``severe,'' the EHR technology developer or DDI/DAI content
provider should define the term. Another commenter stated that any life
threatening interaction should be considered severe.
A few commenters stated that in the case of medication allergies,
an assessment of severity would not be appropriate. Rather, a
``criticality assessment'' should be used.
We also received several comments on how to improve any future
response tracking certification criterion. One commenter stated that we
should consider how to leverage patient-generated health data to inform
drug interaction and intolerance-related notifications (including over-
the-counter medications). Another commenter suggested that compendia
information should be updated monthly to ensure the efficacy of DDI/DAI
alerts, which the commenter suggested would help ensure that providers
are accessing up-to-date information about allergies and warnings, and
would ensure that the list of FDA-approved treatments is current.
A few commenters stated that pharmacists can play an important role
in DDI/DAI functionality. These
[[Page 54450]]
commenters stated that pharmacists should be able to review data
collected by DDI/DAI response tracking, noting that pharmacists can
help improve the DDI/DAI alert workflow by minimizing provider alert
fatigue as well as mitigate against future adverse events through
review of adverse outcomes. One commenter stated that pharmacy
standards development organizations should be involved in the
development of standards for any future response tracking certification
criterion.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``drug-drug interaction, drug-allergy
interaction'' certification criterion. We will, however, consider all
comments regarding response tracking of DDI/DAI alerts for future
rulemaking concerning a ``drug-drug interaction, drug-allergy
interaction'' certification criterion.
Demographics
We proposed a ``demographics'' certification criterion for the
Proposed Voluntary Edition that was revised in comparison to the 2014
Edition certification criterion. The criterion included a requirement
that EHR technology designed for the inpatient setting be capable of
enabling a user to electronically record, change, and access the ``date
of death.'' We previously included the capability to access the date of
death as part of the 2011 Edition ``demographics'' certification
criterion and inadvertently omitted it from the 2014 Edition. We also
proposed to adopt a new preferred language standard because our
constrained approach to the use of ISO 639-2 unintentionally excluded
multiple languages that are currently in use, such as sign language and
Hmong. Additionally, we noted that ISO 639-2 is meant to support
written languages, which may not be the language with which patients
instinctively respond when asked for their preferred language. To
improve this situation, we proposed three options for which we
solicited public comments: The full ISO 639-2, ISO 639-3, or Request
for Comments (RFC) 5646 to be the preferred language standard for the
proposed ``demographics'' certification criterion. To implement this
proposal, we proposed to modify the regulatory text hierarchy in Sec.
170.207(g) to designate the standard referenced by the 2014 Edition
``demographics'' certification criterion at Sec. 170.207(g) to be at
Sec. 170.207(g)(1).
Comments. We received a few comments on our proposal related to
``date of death'' stating that there was value in such information, but
that commenters were unaware of any EHR technology developers certified
to the 2011 Edition who removed this capability. We received comments
on the preferred language for the ``demographics'' certification
criterion advocating for: No change in the standard, the full ISO 639-
2, ISO 639-3, and RFC 5646. Commenters representing consumer groups and
patients advocated for the inclusion of a standard that covered all
languages and dialects. A commenter noted that, in California, both
Hmong and Cantonese are Medicaid ``threshold languages,'' requiring
additional language assistance services from Medicaid providers. Many
commenters questioned the relative benefit of changing the standard (a
few more languages) in relation to the cost and burden of switching
standards. Commenters also emphasized the need for standards to have
backwards compatibility with already adopted standards and not conflict
with industry standards already adopted for the same purpose, such as
those included in the Consolidated CDA and National Council for
Prescription Drug Programs (NCPDP) standards.
Response. We have not adopted a ``demographics'' certification
criterion. The insightful comments we received on the preferred
language standard necessitate further evaluation of whether the
preferred language standard should be changed, including assessment of
the compatibility and alignment of alternative standards with already
adopted standards and additional cost-benefit analysis of any potential
change in the adopted preferred language standard. Further, based on
comments, there appears to be no need to adopt a revised
``demographics'' certification criterion that simply includes the
``date of death'' functionality. In future rulemaking that may address
the ``demographics'' certification criterion, we will reconsider the
need for specifically including functionality related to ``date of
death.'' We will also consider comments we received on preferred
language standards and our subsequent research on the matter.
Vital Signs, Body Mass Index (BMI), and Growth Charts
We proposed a ``vital signs, body mass index, and growth charts''
certification criterion for the Proposed Voluntary Edition that was
unchanged as compared to the 2014 Edition certification criterion.
However, we solicited comment on whether to require EHR technology to
record vital signs in standardized vocabularies (e.g., LOINC[supreg],
Systemized Nomenclature of Medicine Clinical Terms (SNOMED CT[supreg]),
and The Unified Code of Units of Measure (UCUM)). We also solicited
comments on two approaches if EHR technology were to be required to
record vital signs in standardized vocabularies:
Option 1: Require EHR technology to record vital signs in
standardized vocabularies natively within the EHR;
Option 2: Require EHR technology to record vital signs in
standardized vocabularies only when data was exchanged.
Comments. The majority of commenters supported leaving this
certification criterion unchanged and suggested waiting until the next
edition to propose any changes. A commenter recommended linking weight
information to drug formularies in order to assist licensed clinicians
in selecting the appropriate dosage. Commenters also suggested that the
calculation for creatinine clearance should appear in the header along
with the BMI for the purposes of patient safety and proper dosing of
medications. Another commenter recommended standardizing the use of
international BMI as risk of health conditions may vary by race or
ethnicity.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``vital signs, body mass index, and growth
charts'' certification criterion. We will, however, consider comments
regarding support for medication dosing and use of international BMI
references for future rulemaking concerning a ``vital signs, body mass
index, and growth charts'' certification criterion. We clarify that the
comment solicitation regarding standardized vocabularies and
[[Page 54451]]
options for recording vital signs within the EHR was intended to inform
a future edition of certification criteria, not the Proposed Voluntary
Edition. Therefore, we will also consider the comments received on this
topic as we develop proposals for future rulemaking.
Problem List
We proposed a ``problem list'' certification criterion for the
Proposed Voluntary Edition that was unchanged as compared to the 2014
Edition certification criterion. We did not request any specific public
comments on this certification criterion.
Comments. The majority of commenters supported an unchanged
criterion. One commenter suggested removing this criterion in future
editions because lists in of themselves have no value, but the
commenter noted that lists are useful within the context of CQMs, ToC,
and VDT certification criteria. A few commenters stated that they
support the use of SNOMED CT[supreg] coding for this criterion and not
the use of International Classification of Diseases-10 (ICD-10) as an
additional coding system because its use would require more mappings
and added complexity when using the Consolidated CDA templates. One
commenter recommended adopting the most recent releases of SNOMED
CT[supreg] (International July 2013 and US Extension September 2013).
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``problem list'' certification criterion. We will,
however, consider feedback suggesting that this criterion is
unnecessary in of itself for future rulemaking.
In regard to comments on ICD-10, as we stated in the 2014 Edition
Final Rule, we believe SNOMED CT[supreg] is more appropriate than ICD-
10 for clinical purposes and provides greater clinical accuracy (77 FR
54210). Therefore, it was adopted for the 2014 Edition ``problem list''
certification criterion.
We confirm that the 2014 Edition ``problem list'' certification
criterion requires the use of the SNOMED CT[supreg] July 2012
International Release and March 2012 US Extension as a minimum
standard. Regarding the comment recommending that we adopt the updated
SNOMED CT[supreg] versions, we will reassess whether a newer version of
the minimum standard should be adopted in future rulemaking. As we
stated in the 2014 Edition Final Rule, based on our experience, newer
versions of the ``minimum standards'' code sets that we have adopted
are issued more frequently than our current process can reasonably
accommodate. We do not believe that permitting EHR technology to be
upgraded and certified to newer versions of these code sets would
normally pose an interoperability risk, and therefore we allow use of a
newer version voluntarily for certification without adversely affecting
the EHR technology's certified status unless the Secretary specifically
prohibits the use of a newer version (77 FR 54268). Thus, EHR
technology may be certified to newer versions of SNOMED CT[supreg].
Medication List
We proposed a ``medication list'' certification criterion for the
Proposed Voluntary Edition that was unchanged as compared to the 2014
Edition certification criterion. We did not request any specific public
comments on this certification criterion.
Comments. The majority of commenters supported an unchanged
criterion. One commenter suggested removing this criterion in future
editions because lists in of themselves have no value, but the
commenter noted that lists are useful within the context of CQMs, ToC,
and VDT certification criteria. A few commenters stated that
medications can come from a number of sources, including over-the-
counter, samples, and alternative medicines. These commenters
recommended that a medication list include the most complete list
possible to help minimize patient safety risks.
One commenter stated that the FDA is working to implement
requirements in the Drug Supply Chain Security Act regarding standards
for the interoperable exchange of information for tracing human,
finished, and/or prescription drugs. The commenter recommended that we
be aware of these efforts and align current and future EHR requirements
with any future FDA requirements for standards-based identification of
prescription drugs. Another commenter recommended that EHR technology
be able to track DDI/DAI checks based on a patient's medication list.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``medication list'' certification criterion. We
will consider feedback suggesting that this criterion is unnecessary in
of itself for future rulemaking. We will also consider comments
regarding the FDA's work to implement requirements in the Drug Supply
Chain Security Act, EHR support of DDI/DAI checks, and the definition
and inclusion of types of medications for future rulemaking.
Medication Allergy List
We proposed a ``medication allergy list'' certification criterion
for the Proposed Voluntary Edition that was unchanged as compared to
the 2014 Edition certification criterion.
Comments. The majority of commenters supported an unchanged
criterion. One commenter suggested removing this criterion in future
editions because lists in of themselves have no value, but the
commenter noted that lists are useful within the context of CQMs, ToC,
and VDT certification criteria. Many commenters recommended that the
medication allergy list should include other types of allergies and
intolerances, including food and environmental allergies.
One commenter stated that the FDA is working to implement
requirements in the Drug Supply Chain Security Act regarding standards
for the interoperable exchange of information for tracing human,
finished, and/or prescription drugs. The commenter recommended that we
be aware of these efforts and align current and future EHR requirements
with any future FDA requirements for standards-based identification of
prescription drugs. Another commenter recommended that EHR technology
be able to track DDI/DAI checks based on a patient's medication allergy
list.
One commenter recommended the development of an ``idealized''
interoperable allergy value set that would encompass the same
terminology code base and support documenting patient allergies and
drug sensitivities. This commenter was concerned that currently active
patient medication allergy and drug sensitivities are dominated by the
use of multiple proprietary code sets. The commenter
[[Page 54452]]
stated that codified allergy and drug sensitivity information is
commonly exchanged as free-text or when converted to interoperable code
sets, the original meaning of the documented allergy is lost. The
commenter stated that the National Library of Medicine (NLM)'s RxNorm
source vocabulary concepts and cross-referenced vocabulary terms best
meet the characteristics of the ``idealized'' allergy value set.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``medication allergy list'' certification
criterion. We will consider feedback suggesting that this criterion is
unnecessary in of itself and comments regarding the FDA's work to
implement requirements in the Drug Supply Chain Security Act for future
rulemaking. We note that we solicited specific feedback on vocabularies
to code medication allergies and intolerances for a future edition of
certification criteria and thank the commenters for their detailed
feedback and recommendations on these topics. We will take these
comments into consideration for future rulemaking.
Clinical Decision Support (CDS)
We proposed a ``clinical decision support'' certification criterion
for the Proposed Voluntary Edition that was revised in comparison to
the 2014 Edition certification criterion in several ways. First, we
proposed to incorporate the guidance we provided in FAQ 39 \26\ that
EHR technology certified to the CDS criterion must demonstrate the
capability to use at least one of the more specific data categories
included in the ``demographics'' certification criterion (Sec.
170.315(a)(5)) (e.g., the sex or date of birth). We also proposed to
incorporate guidance we provided in FAQ 34 \27\ to clarify that the CDS
criterion would not require compliance with the Infobutton-enabled
capability for vital signs or medication allergies data. Additionally,
we proposed to discontinue referencing ``laboratory values/results''
data as stakeholder feedback indicated that the Infobutton standard
cannot support this specific data.
---------------------------------------------------------------------------
\26\ http://www.healthit.gov/policy-researchers-implementers/39-question-04-13-039.
\27\ http://www.healthit.gov/policy-researchers-implementers/34-question-12-12-034.
---------------------------------------------------------------------------
We proposed to include and adopt the HL7 Implementation Guide:
Service-Oriented Architecture Implementations of the Context-aware
Knowledge Retrieval (Infobutton) Domain, Release 1, August 2013 (at
Sec. 170.204(b)(3)) in place of the older version referenced by the
2014 Edition certification criterion.
We proposed to adopt two new IGs from the Health eDecisions (HeD)
S&I Framework initiative that support shareable CDS. The first IG
defines requirements for the contents of ``CDS Knowledge Artifacts''
\28\ for event condition action rules, order sets, and documentation
templates (HL7 Implementation Guide: Clinical Decision Support
Knowledge Artifact Implementation Guide, Release 1 (January 2013)
(``HeD standard'')). In addition to proposing to adopt this IG, we
proposed to require EHR technology be able to electronically process a
CDS artifact in the HeD standard. The second IG defines SOAP and REST
web interface requirements needed to send patient data and receive CDS
guidance when a request for clinical guidance is made to a CDS guidance
supplier (HL7 Decision Support Service Implementation Guide, Release 1,
Version 1 (December 2013)). We also proposed to require that EHR
technology demonstrate the ability to make an information request, send
patient data, and receive CDS guidance according to the interface
requirements defined in the Decision Support Service IG.
---------------------------------------------------------------------------
\28\ A CDS Knowledge Artifact is the encoding of structured CDS
content as a rule to support clinical decision making in many areas
of the health care system, including quality and utilization
measures, disease outbreaks, comparative effectiveness analysis,
efficacy of drug treatments, and monitoring health trends.
---------------------------------------------------------------------------
To supplement the HeD proposals, we solicited comment on what we
should focus on for testing and certification of CDS Knowledge
Artifacts, decision support services, and user experience to-date with
implementing the HeD standards.
Comments. Commenters overwhelmingly supported our proposed approach
in FAQ 39 to require that EHR technology certified to a CDS criterion
must demonstrate the capability to use at least one of the more
specific data categories included in the ``demographics'' certification
criterion (Sec. 170.315(a)(5)) (e.g., the sex or date of birth). Some
commenters noted that our FAQs have been previously issued and that
most EHR technology developers have already implemented the policy
clarifications offered by the FAQs. Therefore, the commenters stated
that there is no added value in codifying the FAQs.
Commenters also overwhelmingly supported the proposed approach in
FAQ 34 to not require adherence to the Infobutton standard for
medication allergies or vital signs. They also supported our proposal
to not require adherence to the Infobutton standard for laboratory test
values/results. A few commenters indicated that a more recent version
of the Infobutton standard (Release 4 of the HL7 Infobutton URL-based
Implementation Guide) does support laboratory test values/results.
We received support to adopt the updated HL7 Implementation Guide:
Service-Oriented Architecture Implementations of the Context-aware
Knowledge Retrieval (Infobutton) Domain, Release 1, August 2013.
Commenters also recommended that we do not discontinue referencing the
Infobutton URL-Based IG (HL7 Version 3 Implementation Guide: URL-Based
Implementations of the Context-Aware Information Retrieval (Infobutton)
Domain).
We received mixed feedback on the proposals to adopt the HeD
standards for the two use cases. Some commenters supported adoption of
the HeD standards in the Proposed Voluntary Edition, while others
cautioned that the standards are immature and not well-tested. Those in
support of adoption contended that providers and patients would benefit
from standardized CDS that could help providers make informed decisions
about their patients' care. Commenters also stated that adopting a
standard would lessen the implementation burden on providers as CDS has
normally been customized for each EHR system. A few organizations
commented that they have already successfully piloted the HeD standards
and are in production with a number of groups. Thus, they stated that
the standards were mature and tested enough to require as part of
voluntary certification.
A few commenters suggested further development of diagnostic
imaging CDS and alignment with clinical recommendations for
immunization-based CDS. One commenter recommended that providers be
able to view the HIT developer, bibliographic citation, source of
funding, and release/revision date of a CDS rule for full transparency.
Other commenters noted that the regulation text language of the
proposed CDS certification criterion was
[[Page 54453]]
unclear and that the regulation text could be improved with more
specificity.
The majority of commenters who opposed the HeD proposals expressed
concern about the HeD standards immaturity and lack of testing. Some
also argued that the standards would still be too immature to propose
for the next edition of certification criteria. To support their claim,
many pointed to the work of the S&I Clinical Quality Framework (CQF)
initiative to harmonize and update HeD with standards for CQMs (e.g.,
the Health Quality Measures Format standard (HQMF)). Commenters were
concerned that EHR technology developers would have to significantly
upgrade their systems once the harmonized HeD and HQMF standards become
available and that the amount of rework was not worth the short-term
benefit. Some commenters stated that market demand should drive the
standards and technology for shareable CDS rather than regulation. One
commenter suggested that the two HeD use cases should be evaluated
separately and not lumped together as the user experience to date may
be different between the two.
For testing and certification, many commenters recommended a focus
on a few simple and/or high impact or high clinical value Knowledge
Artifacts and decision support services to simplify the development,
testing, and certification processes. For example, one commenter
recommended focusing testing for the first use case on event action
condition rules as the commenter thought these are the most common type
of Knowledge Artifact and most tested. A few commenters recommended
that we and CMS consider allowing successful pilot testing of the HeD
standards to count toward meeting MU requirements. Last, some
commenters noted at least one case where an EHR accesses a CDS service
based on the HeD standards outside of the EHR and recommended allowing
the CDS service to be external to the EHR.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange.
We agree with commenters that our issued FAQs have addressed
earlier concerns and that most EHR developers have already implemented
the policy clarifications offered by the FAQs. Therefore, there is no
added value in codifying the FAQs at this point in time. There is also
no substantial value in adopting a criterion solely with an updated
Service-Oriented Architecture IG when, as commenters noted, there is a
new URL-based IG that we should also consider for adoption. We will
consider the comments regarding the updated Infobutton Service-Oriented
Architecture IG and updated Infobutton URL-Based IG for future
rulemaking activities and appreciate the detailed responses commenters
provided. To clarify, we did not propose to remove the Infobutton URL-
Based IG (at Sec. 170.204(b)(1)) from the 2014 Edition CDS
certification criterion. Rather, we proposed to include the updated
Service-Oriented Architecture IG as part of the voluntary proposed CDS
certification criterion that we have not adopted. We also agree with
commenters that more deliberation and clarity is needed regarding the
HeD proposals. We will consider the comments on HeD standards maturity,
appropriate use cases, and testing, as well as comments suggesting
improved clarity is needed in the CDS certification criterion
regulatory text in developing future proposals for rulemaking.
Electronic Notes
We proposed an ``electronic notes'' certification criterion for the
Proposed Voluntary Edition that was revised in comparison to the 2014
Edition certification criterion. We included in the proposed
certification criterion a capability to search for information across
separate notes within EHR technology rather than just within one
particular note. We stated that this expanded requirement was intended
to reduce the time providers spend looking for specific patient
information and noted that the requirement to search across notes was
not limited to a specific method. In addition to this proposal, we
requested comments regarding: Whether the proposed functionality should
extend to all patient electronic notes stored in the EHR or just to a
specific patient's electronic notes or specific types of patient notes;
whether we should wait to include the proposed functionality in a
future edition of certification criteria; and whether additional
metadata should be required as part of electronic notes (such as the
HL7 R2 header). We also asked for health care provider opinions on
whether the availability of the proposed functionality (either
searching across a specific patient's electronic notes stored in the
EHR or all patients' electronic notes stored in an EHR) is so
widespread that it would be unnecessary to require it as a condition of
certification.
Comments. We received comments, including those from provider
organizations, expressing support for expanding the search
functionality both across a patient's notes and across all patients'
notes in the EHR as a means of improving provider usability. We also
received comments recommending that we not expand the search
capability. These commenters argued that the functionality is not
required for participation in a particular government program (e.g.,
the EHR Incentive Programs), it could stifle innovation, and market-
driven approaches are sufficient to determine if additional search
capabilities are essential or not. Some commenters supported including
enhanced search functionality in the proposed certification criterion,
while others thought we should wait for a future edition. A few
comments supported metadata inclusion with the electronic note, while
most comments saw no value in mandating the inclusion of metadata.
Response. We have not adopted the proposed certification criterion.
Based on comments, we believe further evaluation is necessary as to
whether an enhanced search capability should be included in an
``electronic notes'' certification criterion and for what purpose the
certification of any enhanced search capability would serve. We will
consider the comments received in developing proposals future
rulemaking.
Drug Formulary Checks
We proposed a ``drug formulary checks'' certification criterion for
the Proposed Voluntary Edition that was unchanged as compared to the
2014 Edition certification criterion. However, we solicited public
comment on whether we should leave the criterion as-is (flexible and
without reference to a standard) or if it would be appropriate for us
to adopt a standard in the Proposed Voluntary Edition certification
criterion for which compliance would be required. In the 2014 Edition
Final Rule, we stated it was necessary to require the use of a
particular standard for certification as our certification criterion
was flexible and permitted EHR technology to access and store external
drug formularies in support of MU. As described in more detail in the
Proposed Rule (79 FR 10892), CMS recently finalized a proposal to
recognize NDPDP Formulary and Benefit Standard v3.0 as a backwards
compatible version of NCPDP Formulary and Benefit Standard 1.0 for
[[Page 54454]]
the period of July 1, 2014 through February 28, 2015, and to retire
version 1.0 and adopt version 3.0 as the official Part D e-Prescribing
standard on March 1, 2015 (78 FR 74787-74789).\29\ As such, we stated
in the proposed rule that it was an opportune time to solicit comment
on whether to adopt a particular standard for the drug-formulary checks
criterion.
---------------------------------------------------------------------------
\29\ CMS originally proposed retiring version 1.0 on July 1,
2014, but, in response to comment, subsequently decided to postpone
the retirement date to March 1, 2015, to allow the industry adequate
time to implement the necessary changes and testing to implement
version 3.0 (78 FR 74789).
---------------------------------------------------------------------------
We also noted the NCPDP Formulary and Benefit Standard v.4.0's \30\
potential limitations as discussed by the HITSC, including that the
version does not support expanded use cases such as real-time benefit
checks.\31\ Thus, we also solicited comment on whether there are other
standards or solutions (e.g., NCPDP Telecommunication Standard) that
could be used in conjunction with or in place of the NCPDP Formulary
and Benefit Standard to address the potential limitations or expanded
use cases identified by the HITSC.
---------------------------------------------------------------------------
\30\ V.4.0 has minor changes compared to v.3.0, including
removal of values from an unused diagnosis code, typographical
changes, and a change to the standard length of the name field. CMS
has adopted v.3.0 (77 FR 74787-74789), which includes substantive
changes from previous versions.
\31\ The HITSC has discussed these potential limitations. Please
refer to Clinical Operations Workgroup Update to the HITSC on June
19, 2013. http://www.healthit.gov/FACAS/sites/faca/files/clinical_operations_wg_update_062013_0.pdf
---------------------------------------------------------------------------
Comments. We received mixed comments regarding the proposal to
adopt a standard (namely the NCPDP Formulary and Benefit Standard v3.0)
for the proposed certification criterion. Some commenters supported
adopting the NCPDP Formulary and Benefit Standard v3.0 (``v3.0'') in
this rule, but most of these commenters recommended its adoption for
the next edition of certification criteria. Those in support of
adopting v3.0 noted the potential to reduce file sizes, which is
beneficial when checking thousands of drug formularies on a daily
basis. Many recommended that we should also accept test results from
the current Surescripts e-prescribing certification without additional
testing requirements.
Some commenters were concerned about known problems with v3.0, and
pointed to the NCPDP Formulary and Benefit Standard v4.0 (``v4.0''),
which may fix some of these known problems. Other commenters were
concerned about rework if we required v3.0 in the proposed
certification criterion followed by requiring v4.0 in the next edition.
One commenter stated that v4.0 is too unstable to require for
certification at this point. Some commenters also stated that the
industry should determine the EHR's drug formulary features and that we
should not be prescriptive in naming a particular standard for
adherence.
One ONC-ACB noted that, in their experience, the current drug-
formulary check criterion is considered an ``easy'' pass during the
certification process. The test procedure requires EHRs to simply show
formulary query results, and therefore the commenter recommended that
we consider expanding the test procedure to capture more of the real-
world setup of the formulary at the patient or practice level. However,
the ONC-ACB noted that this capability may be working fine and may not
need further changes as they have never received any surveillance
complaints regarding formulary features of certified EHR technologies.
Most commenters were in support of the expanded use case for real-
time, patient-level formulary benefit checking. However, we received
mixed opinions on the appropriateness of leveraging the NCPDP
Telecommunication Standard in conjunction with the NCPDP Formulary and
Benefit Standard v3.0 for this expanded use case. One commenter stated
that some of the issues found with the NCPDP Formulary and Benefit
Standard are due to payer implementations rather than issues with the
standard itself. The commenter recommended that we review an NCPDP-
authored white paper describing how payers and vendors should implement
the Formulary and Benefit Standard for maximum benefit.\32\
---------------------------------------------------------------------------
\32\ http://www.ncpdp.org/Education/Whitepaper ``Challenges and
Opportunities for Stakeholders Regarding ePrescribing Technologies
and Formulary Compliance''.
---------------------------------------------------------------------------
Some commenters stated that it was inappropriate to use the NCPDP
Telecommunication Standard for real-time, patient-level benefit
checking as it was not developed with that use case in mind. Rather, it
was developed to respond with coverage information for a pre-selected
medication, not a complete range of treatment options. Additionally,
commenters opined that use of the NCPDP Telecommunication Standard
could result in delays, workflow issues during provider ordering, and
additional EHR performance issues because the standard can take several
minutes to return a response. In addition to the NCPDP
Telecommunication Standard, commenters suggested that we consider the
pros and cons of additional standards that could be leveraged for real-
time benefit checking. These standards include the ASC X12/005010X279
Health Care Eligibility Benefit Inquiry and Response (270/271) standard
and the Proposed Real Time Benefit Check (RTBC) transaction based on a
previous version of NCPDP SCRIPT standard (also referred to by some
commenters as the Surescripts Real-Time Benefit Check standard).
Commenters also referred to different versions of the NCPDP
Telecommunications Standard (e.g., B1 (Billing), D1 (Pre-termination of
Benefits), D.0).
One commenter recommended that as we evaluate alternative standards
for real-time benefit checking, we should also consider protections to
ensure that direct communication between pharmacy benefit managers and
providers does not lead to unwanted advertising or pop-up messaging
intended to influence the prescription decision of a health care
professional at the point of care. A few commenters also recommended
that we consider proposals for automated electronic prior authorization
of medications to allow a prescriber to initiate prior authorization
electronically as part of future rulemaking.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. We will consider
comments regarding the pros and cons and maturity of the NCPDP
Formulary and Benefit Standard v3.0 and v4.0 for future rulemaking. We
will also examine whether we can learn from and/or leverage the
processes of existing certification programs as well as improve the
test procedure for this certification criterion as part of future
rulemaking.
We thank commenters for their detailed responses about specific
standards for the expanded use case of real-time, patient-level
formulary and benefit checking, and will continue to examine the pros
and cons of each to inform our future rulemaking. We will consider
these comments and comments encouraging adoption of standards for
electronic prior authorization for future rulemaking. Additionally, as
part of our continued work, we will seek to understand the differences
among the versions of the NCPDP Telecommunication Standard and
[[Page 54455]]
between the RTBC transaction with the Surescripts Real-Time Benefit
Check standard. As to the comment suggesting that we prohibit unwanted
advertising or pop-up messaging in communications between providers and
pharmacy benefit managers, we believe this request falls outside the
scope of the ONC HIT Certification Program.
Smoking Status
We proposed a ``smoking status'' certification criterion for the
Proposed Voluntary Edition that was unchanged as compared to the 2014
Edition certification criterion. We did not request any specific public
comments on this certification criterion.
Comments. We received comments expressing support for this
certification criterion as unchanged. A few commenters noted that there
is misalignment with the code sets adopted for the 2014 Edition and
proposed ``smoking status'' certification criteria and the Consolidated
CDA Release 2.0 and e-clinical quality measures (eCQMs). A few
commenters also suggested that we consider requiring the capture of
additional forms of tobacco use, such as smokeless tobacco and betel
nut use.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``smoking status'' certification criterion. We
note that we have also not adopted the proposed Consolidated CDA
Release 2.0 as discussed under the ToC certification criterion in this
section (IV.A). We will, however, take the comments about expansion of
the smoking code set and alignment with the Consolidated CDA Release
2.0 and eCQMs under consideration for future rulemaking concerning a
``smoking status'' certification criterion and the Consolidated CDA
standard.
Image Results
We proposed an ``image results'' certification criterion for the
Proposed Voluntary Edition that was unchanged as compared to the 2014
Edition certification criterion. We did not request any specific public
comments on this certification criterion.
Comments. We received a small number of comments on this proposed
unchanged criterion. A majority of the comments received on this
proposal simply indicated their support for keeping this certification
criterion as-is. However, some commenters offered additional
suggestions, including one that suggested we remove this certification
criterion in the next edition. This commenter did not believe the
functionality expressed in the certification criterion would be
relevant until a quality or incentive program existed that defined
clear objectives for its use as well as the requirement of consistent
vocabulary and interoperability support through common standards.
Another commenter recommended that images be of diagnostic quality.
Other commenters suggested that we incorporate the adoption of the
Digital Imaging and Communication in Medicine (DICOM) standards in
future editions. One commenter suggested that future editions should go
beyond the ``accessibility'' of images to focus on the transmission of
images. Commenters also stated that the interoperability of imaging
among different EHR systems must be supported through standards.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``image results'' certification criterion. The
2014 Edition certification criterion was expressly adopted to support
the correlated MU objective and associated measure, which focuses on
the accessibility of electronic imaging results through CEHRT. We point
readers to the 2014 Edition Final Rule (77 FR 54173) in which we
concluded ``that the adoption of the DICOM standard (or any other
standards) was unnecessary to enable users with electronic access to
images and their narrative interpretations.'' We will take the DICOM
suggestion as well as those comments that encouraged a broader
certification criterion into consideration for future rulemaking, if
the intended purpose for which this certification criterion was adopted
changes or new functionality for testing and certification appears
necessary.
Family Health History
We proposed a ``family health history'' (FHH) certification
criterion for the Proposed Voluntary Edition that was revised in
comparison to the 2014 Edition certification criterion. We proposed to
adopt the HL7 Pedigree IG, HL7 Version 3 Implementation Guide: Family
History/Pedigree Interoperability, Release 1 and to include only the
HL7 Pedigree standard and the new IG in this certification criterion,
and no longer permit demonstrating the use of only SNOMED CT[supreg] to
code family health history as a means of meeting this certification
criterion.
Comments. Some commenters expressed general agreement with the
proposal, noting that the proposed approach should improve
interoperability by moving to one standard and patient care through use
of a more comprehensive standard. Many commenters were against moving
solely to the HL7 Pedigree standard. Commenters argued that there was a
high burden in shifting to HL7 Pedigree, particularly after just
adopting SNOMED CT[supreg] for FHH. Commenters also expressed concern
about Consolidated CDA compatibility and, as they described it, HL7
Pedigree's nominal benefit in terms of genomics. Commenters also
recommended identifying an appropriate use case for moving solely to
HL7 Pedigree, noting that HL7 Pedigree relies on SNOMED CT[supreg] for
coding problems and problems is the predominate use case for coding FHH
among most providers.
Response. We have not adopted the proposed FHH certification
criterion. The comments received suggest further evaluation is needed
as to whether moving to solely the HL7 Pedigree standard for FHH serves
an appropriate use case for certification and whether the benefits
exceed any potential costs and burden for developers and providers.
Patient List Creation
We proposed a ``patient list creation'' certification criterion for
the Proposed Voluntary Edition that was revised in comparison to the
2014 Edition certification criterion. We proposed to include text in
the proposed ``patient list creation'' certification criterion
clarifying that EHR technology must demonstrate its capability to use
at least one of the more specific data categories included in the
proposed ``demographics'' certification criterion (e.g., sex or date of
birth), which
[[Page 54456]]
incorporated the guidance provided in FAQ 39.\33\
---------------------------------------------------------------------------
\33\ http://www.healthit.gov/policy-researchers-implementers/39-question-04-13-039.
---------------------------------------------------------------------------
Comments. We received only a few comments on this proposal.
Commenters expressed support for this proposal. Commenters also stated
that the certification criterion was essentially the ``same'' as the
2014 Edition by incorporating FAQ 39 because the FAQ applies for
certification to the 2014 Edition certification criterion. One
commenter suggested that instead of requiring the use of ``at least
one'' demographic data element in the creation of patient lists that we
require ``at least two'' demographic data elements.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would simply incorporate
guidance that EHR technology developers are already following for
certification to the 2014 Edition ``patient list creation''
certification criterion.
The required use of a minimum of two demographic elements was not
proposed. Therefore, we have insufficient stakeholder feedback on the
potential requirement's benefit versus its burden. We will, however,
consider this suggestion in relation to future rulemaking activity
concerning a ``patient list creation'' certification criterion.
Patient-Specific Education Resources
We proposed a ``patient-specific education resources''
certification criterion for the Proposed Voluntary Edition that was
revised in comparison to the 2014 Edition certification criterion. We
proposed to adopt this certification without the requirement that EHR
technology be capable of electronically identifying patient-specific
education resources based on ``laboratory values/results'' due to
stakeholder feedback indicating that the Infobutton standard does not
support this level of data specificity. We proposed to adopt the HL7
Implementation Guide: Service-Oriented Architecture (SOA)
Implementations of the Context-aware Knowledge Retrieval (Infobutton)
Domain, Release 1, August 2013, which is an updated version of the IG
we adopted for the 2014 Edition. To clearly distinguish this IG in the
regulation text from the prior version, we proposed a technical
amendment to Sec. 170.204(b)(2).
We proposed to revise the regulation text to be more consistent
with the intent and interpretation of the 2014 Edition certification
criterion regulation text that we expressed in the 2014 Edition Final
Rule.\34\ We noted that the text of the proposed certification
criterion made clear that the EHR technology must demonstrate the
capability to electronically identify patient-specific education
resources using Infobutton and an alternative method that does not rely
on Infobutton. We also noted that the guidance we provided in FAQ 40
\35\ would still be applicable to the proposed ``patient-specific
education resources'' certification criterion.
---------------------------------------------------------------------------
\34\ 77 FR 54216.
\35\ http://www.healthit.gov/policy-researchers-implementers/40-question-04-13-040.
---------------------------------------------------------------------------
We requested comment on whether we should adopt a different
approach related to the methods EHR technology uses to electronically
identify patient-specific education resources for the proposed
certification criterion, a potential future ``patient-specific
education resources'' certification criterion, or both. The 2014
Edition and proposed certification criterion require EHR technology to
demonstrate the capability to electronically identify for a user
patient-specific education resources using Infobutton and an
alternative method. We sought comment on whether we should: (1)
Maintain this approach; (2) require EHR technology to demonstrate only
the use of Infobutton, but permit EHR technology to be certified to
other methods upon an EHR technology developer's request for the
purpose of an EP, EH, or CAH being able to use the alternative
certified method for MU (to count such use toward meeting the measure);
or (3) certify only the use of Infobutton and consult with CMS
regarding a meaningful use policy change that would permit the use of
any method (certified or not) to electronically identify patient-
specific education resources, provided that the EP, EH, or CAH has EHR
technology certified to perform the Infobutton capability.
We also sought comment on whether we should require that EHR
technology be capable of providing patient-specific education resources
in a patient's preferred language in the proposed certification
criterion, in a potential future certification criterion, or in both.
Comments. We received comments supporting removal of the laboratory
values/results data element, adoption of the updated SOA IG, and the
proposed clarifying regulation text. We received comments supporting
both options (1) and (3) related to the methods EHR technology must
demonstrate for providing patient-specific education resources. Most
commenters preferred option (3). No commenters expressed support for
option (2). Consumer and patient advocacy groups supported providing
patient-specific education resources in a patient's preferred language,
while EHR technology developers did not support this proposal due to
the burden they stated it would create because of the great number of
potential languages and the lack of content resources for all potential
languages. These commenters also noted that burden would far exceed the
benefits (e.g., the number of patients requesting patient-specific
education resources in a preferred language).
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. We will consider the
comments on the specific proposed changes to the certification
criterion as well as the comments on the methods EHR technology must
demonstrate for providing patient-specific education resources and the
use of preferred language in providing those resources for future
rulemaking concerning a ``patient-specific education resources''
certification criterion.
Electronic Medication Administration Record
We proposed an ``electronic medication administration record''
(eMAR) certification criterion for the Proposed Voluntary Edition that
was unchanged as compared to the 2014 Edition certification criterion.
We did not request any specific public comments on this certification
criterion.
Comments. The majority of commenters supported an unchanged
criterion. One commenter suggested removing this criterion in future
editions because the market drove availability and adoption of this
functionality before it was introduced in the 2014 Edition. This
commenter also opined that the functionality could be
[[Page 54457]]
better improved as part of or in the context of the CDS criterion.
Another commenter stated that CDS at the point of medication
administration would serve as an additional quality check. A commenter
stated that a bar code administration process is needed to fulfill this
requirement. A commenter also suggested that a distinction be made for
data models that include pro re nata (PRN) medications that are
prescribed ``as needed'' and may not actually be given on a regular
basis. The commenter stated that these medications may be included in
the denominator even though they may never be included in the
numerator, and thus the commenter opined that PRN medications should be
treated differently than other medications.
One commenter stated that the FDA is working to implement
requirements in the Drug Supply Chain Security Act regarding standards
for the interoperable exchange of information for tracing human,
finished, and/or prescription drugs. The commenter recommended that we
be aware of these efforts and align current and future EHR requirements
with any future FDA requirements for standards-based identification of
prescription drugs.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. We will consider, in
regards to future rulemaking, feedback that this criterion is
unnecessary in of itself, comments regarding the FDA's work to
implement requirements in the Drug Supply Chain Security Act, comments
providing guidance for fulfilling this requirement, and comments noting
the distinction between PRN medications and other medications given on
a regular basis.
Advance Directives
We proposed an ``advance directives'' certification criterion for
the Proposed Voluntary Edition that was unchanged as compared to the
2014 Edition certification criterion. We did not request any specific
public comments on this certification criterion.
Comments. Commenters expressed support for the proposed unchanged
certification criterion. Some commenters suggested, however, that this
certification criterion be further enhanced by requiring HIT certified
to this certification criterion to be able to record the electronic
location of an advance directive, provide a link or instructions to the
location of an advance directive, provide the content of an advance
directive, and include other care planning documents such as a
Physicians Order for Life-Sustaining Treatment (POLST).
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``advance directives'' certification criterion. We
will, however, consider whether this certification criterion should be
enhanced in any of the ways mentioned by commenters as part of future
rulemaking activity concerning an ``advance directive'' certification
criterion.
Implantable Device List
We proposed to adopt a new certification criterion for EHR
technology to demonstrate that it is able to record and display a
unique device identifier (UDI) \36\ and other information about a
patient's implantable devices. We noted that this proposal represented
a first step towards enabling EHR technology to facilitate the
widespread capture and use of UDI data to prevent device-related
medical errors, improve the ability of hospitals and clinicians to
respond to device recalls and device-related patient safety
information, and achieve other important patient safety and public
health benefits consistent with the fundamental aims of the HITECH Act
and the July 2, 2013 HHS Health Information Technology Patient Safety
Action and Surveillance Plan.\37\ We also provided a short summary of
the FDA's regulatory activity associated with the UDI.
---------------------------------------------------------------------------
\36\ A UDI is a unique numeric or alphanumeric code that
consists of two parts: (1) A device identifier (DI), a mandatory,
fixed portion of a UDI that identifies the labeler and the specific
version or model of a device, and (2) a production identifier (PI),
a conditional, variable portion of a UDI that identifies one or more
of the following when included on the label of a device: The lot or
batch number within which a device was manufactured; the serial
number of a specific device; the expiration date of a specific
device; the date a specific device was manufactured; the distinct
identification code required by 21 CFR 1271.290(c) for a human cell,
tissue, or cellular and tissue-based product (HCT/P) regulated as a
device. http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/UniqueDeviceIdentification/.
\37\ http://www.healthit.gov/sites/default/files/safety_plan_master.pdf
---------------------------------------------------------------------------
In our proposal, we explained our belief that EHR technology will
play a key role in the widespread adoption and utilization of UDIs and
that EHRs' use of UDIs can help reduce device-related medical errors
and provide other significant patient safety, health care quality, and
public health benefits. For example, EHR technology could be leveraged
in conjunction with automated identification and data capture (AIDC)
technology or other technologies to streamline the capture and exchange
of UDIs and associated device data in clinical and administrative
workflows. We also noted that patients' UDI data in EHR technology
could pave the way for new CDS and help health care providers more
rapidly and accurately identify a patient's devices and key information
about the safe and effective use of such devices.
As part of our proposal, we recognized that additional standards
and technical specifications would be required to support the full
range of contemplated capabilities and uses, and that efforts to
identify or develop these standards are already underway. Nevertheless,
we stated our belief that specifying some baseline functionality as
part of a certification criterion would be important in order for EHR
technology developers to consider the functionality necessary to
capture, store, and retrieve UDIs and other contextually relevant
information associated with a patient's medical devices, specifically
implantable devices.
Our proposal focused on a certification criterion that would assess
an EHR technology's ability to record UDI information about implantable
devices. More specifically, we proposed that EHR technology would have
to show that it could enable a user to electronically record the UDI of
an implantable device and other relevant information (such as a
procedure note or additional information about the device) as part of a
patient's ``implantable device list.'' We also proposed that EHR
technology would need to allow a user to electronically access and view
a patient's list of UDIs and other relevant information associated with
a patient's implantable devices. Our last proposal focused on an EHR
technology's ability to parse the UDI in order to extract and allow a
user to view the ``device
[[Page 54458]]
identifier'' and ``production identifier'' portions of the UDI.
Combined with this specific certification criterion's proposal, we
also proposed that the UDI would need to be included as part of a
Consolidated CDA in each of the following proposed criteria:
Sec. 170.315(b)(1)--Transitions of care;
Sec. 170.315(b)(6)--Data portability;
Sec. 170.315(e)(1)--View, download, and transmit to 3rd
party; and
Sec. 170.315(e)(2)--Clinical summary.
Finally, we proposed to modify Sec. 170.102 to include new
definitions for ``implantable device,'' ``unique device identifier,''
``device identifier,'' and ``production identifier'' in order to
prevent any misinterpretation and ensure that each term's specific
meaning reflected the same meaning given to them in the Unique Device
Identification System Final Rule and in 21 CFR 801.3. We also sought
public comment on issues outside the scope of the Proposed Rule in
order to inform future rulemaking considerations, which we noted in the
Proposed Rule would not be responded to in this final rule.
Comments. Many commenters supported the overall intent behind the
proposed certification criterion. These commenters recognized its
potential benefits to patient safety and supported the adoption of a
certification criterion focused on implantable device list
functionality. Some commenters (including those that conceptually
supported the proposed criterion) contended that the proposed
certification criterion was complex, included new workflow
considerations and, from a timing perspective, that it would be
premature to adopt a certification criterion including the proposed
functionality in this final rule. Instead, they suggested that we wait
for the next rulemaking (the rulemaking we expressed our intention to
issue with CMS to accompany policy updates to the EHR Incentive
Programs) as that would provide EHR technology developers more time to
design their systems as well as time for the FDA to continue to make
progress on the broader technical infrastructure necessary to
comprehensively support the UDI.
Other commenters, mostly EHR technology developers, suggested that
the proposed criterion would not be applicable or relevant to the
ambulatory setting (due to where implantable device UDI data would be
most routinely captured in the inpatient setting) and requested that we
scope this criterion to be specific to the inpatient setting. A few
commenters suggested that this certification criterion might be ill-
suited for both the ambulatory and inpatient settings because the
capture of implantable device identifiers would take place in surgical
HIT systems. Additionally, some commenters suggested limiting the scope
of the certification criterion to focus just on storing only the UDI
number as structured data and include the criterion in a future edition
of certification criteria without any of the added functional
requirements proposed in the Proposed Rule. Another commenter suggested
expanding the scope of the certification criterion to include all
devices as opposed to the implantable device scope we had included in
our proposal, as greater alignment should exist between EHR technology
and other technologies used to support supply chain management.
Commenters stated that we had not clearly identified specific use
cases that the proposed certification criterion was meant to support.
They requested greater clarity in order to better understand how the
UDI data was to be used. In that regard, some commenters expressed
concern that including the UDI data as part of information exchange
transactions (specifically in the Consolidated CDA only) would be
premature and suggested that we work with other standards development
organizations (such as HL7, NCPDP, and X12) to clarify when and to whom
the UDI would need to be communicated. Along different lines, one
commenter suggested that we modify the proposal to ``electronically
record the UDI'' to focus on the EHR technology recording the UDI in
its complete and parsed state and similarly presented to users in an
understandable manner. Another commenter suggested that EHR technology
have the capability to generate patient lists by a particular device.
Several commenters requested that we require as part of the
certification criterion the use of AIDC technology, while another
commenter acknowledged that the system behavior for EHR technology
could be similar to that described in the 2014 Edition eMAR
certification criterion. These commenters reasoned that an EHR user
should not have to manually enter the UDI as it would be inefficient
and that the UDI's length could increase the risk of harm due to
inaccurate data entry. At least one commenter indicated that financial
constraints surrounding AIDC technology could hamper investments in
such technology and cause its use to be delayed.
Response. We have not adopted this certification criterion. We
believe additional work is necessary to further refine our proposal
based on public comments. We very much appreciate the detailed comments
submitted, including those that pointed to areas where we need to
provide additional detail and clarity. We believe that our next
rulemaking can provide such detail and clarity, and intend to propose a
UDI-focused certification criterion that reflects the input provided.
Transitions of Care
We proposed to make several changes to the ToC certification
criterion, including adopting an updated version of the Consolidated
CDA, certain data quality constraints on the creation of Consolidated
CDAs to improve patient matching, a proposed ``performance standard''
that would have required EHR technology to successfully electronically
process validly formatted Consolidated CDAs no less than 95% of the
time, and the inclusion of UDI information.
Updated Consolidated CDA Standard
We proposed to incorporate an updated version of the Consolidated
CDA Standard, HL7 Implementation Guide for CDA Release 2: Consolidated
CDA Templates for Clinical Notes (U.S. Realm), Draft Standard for Trial
Use, Release 2.0 (``Release 2.0''), which was balloted in the summer of
2013. We proposed to include Release 2.0 in four certification
criteria: ToC, VDT, clinical summary, and data portability.
Comments. We received many comments on this proposal. The majority
of commenters, especially those from EHR technology developers,
developer associations, and certification bodies, did not support this
proposal. Commenters voiced concerns that Release 2.0 was so new that
many stakeholders had not had the chance to review it and it had not
been sufficiently piloted. In addition, commenters pointed out a
technical problem with the update, known as ``bilateral asynchronous
cutover'' wherein Release 2.0 is not backwards compatible with previous
versions of the Consolidated CDA and therefore a provider with a 2014
Edition certified product could not receive a document conformant to
the Release 2.0 standard. These commenters supported considering
Release 2.0 for future editions of our certification rules. Consumer
advocacy groups supported the proposal, noting that the additional
functionality included in Release 2.0 such as new structural elements
for care plans, patient goals, and health
[[Page 54459]]
outcomes were important to longitudinal health and care planning and
therefore should be included.
Response. We have not adopted Release 2.0 for any certification
criteria in this final rule. We appreciate the detailed feedback we
received from the developer community and agree that more work remains
to address some of the challenges expressed by stakeholders. We remain
interested in moving to Release 2.0 and acknowledge that pilot testing
is occurring. We will continue to monitor the pilot testing and any
other developments concerning Release 2.0 and will consider them in
determining whether to include Release 2.0 in a future rulemaking.
ToC Interoperability and MU Stage 2 ``Cross-Vendor'' Exchange
We proposed to create a new ``cross-vendor'' exchange requirement.
We proposed to require EHR technology certified to the ToC
certification criterion to demonstrate that it can successfully
electronically process validly formatted Consolidated CDAs no less than
95% of the time.
Comments. We received many comments on this proposal. Overall,
commenters did not support our proposal. Commenters voiced concerns
about the testability of this requirement. Commenters also questioned
the likelihood that the proper set of testing documents could be
collected, which would prevent efficient testing and development.
Commenters questioned how we determined the 95% threshold and requested
we provide evidence supporting that limit. Commenters stated that the
95% threshold would be impractical, time consuming, and expensive to
implement, given the wide variation in Consolidated CDA implementation.
Commenters also noted that the proposal was vague and confusing, and
sought additional information about various portions of the proposal,
including what it means to ``electronically process.'' Commenters
supported constraining the Consolidated CDA as a better way to achieve
our stated goals.
Response. Given our approach in this final rule to only adopt a
small subset of the proposed certification criteria as optional 2014
Edition EHR certification criteria and include revisions to 2014
Edition EHR certification criteria that provide flexibility, clarity,
and enhance health information exchange, we have not finalized this
proposal. We agree that a more constrained Consolidated CDA is an
equally implementable approach to reducing the implementation ambiguity
and flexibility afforded in the current Consolidated CDA. We encourage
industry stakeholders to take such steps. We will re-consider this
proposal and the comments received for future rulemaking.
``Create'' and Patient Matching Data Quality
We proposed to include a limited set of standardized data (79 FR
10900) as a part of the ``create'' portion of the Proposed Voluntary
Edition ToC criterion to improve the quality of the data included in
outbound summary care records. We also sought comment on additional
data to include and other constraints that could be applied to this
data to improve its quality.
Comments. Overall, the vast majority of commenters supported the
policy that standardized patient identifying attributes should be
required and captured by certified EHR technology for use in relevant
exchange transactions. Commenters overwhelmingly supported the
inclusion of the proposed constrained specifications for last name/
family name, suffix, first/given name, middle/second name, date of
birth, current address and historical address, phone number, and sex in
support of patient matching.
We received an especially large amount of feedback regarding the
address proposal. Commenters suggested that we delay support for
international standards for address until future editions of
certification criteria. Commenters also provided feedback that the
United States Postal Service format specifications are not in sync with
other MU requirements, such as the LRI and LOI IGs, and recommended
further review of the appropriate address standardization. Commenters
also recommended the inclusion of a field for ``former name'' as many
patients change their names for purposes beyond marriage.
Commenters noted that some of the proposed data elements would come
from practice management systems that EHRs do not control, including
maiden name, historical address and phone number (including multiple
phone numbers), and recommended these fields be made optional. Some
commenters stated that the proposed standardization was premature,
raising usability and privacy concerns and urging us to do further
analysis.
Response. Given our approach in this final rule to only adopt a
small subset of the proposed certification criteria as optional 2014
Edition EHR certification criteria and include revisions to 2014
Edition EHR certification criteria that provide flexibility, clarity,
and enhance health information exchange, we have not adopted this
proposal. We will consider comments regarding patient matching
functionality for future rulemaking.
Unique Device Identifier Information
We proposed to include UDIs for a patient's implantable device
within a created Consolidated CDA formatted document.
Comments. As noted in the UDI section, commenters stated that it
was premature to include implantable device information in Consolidated
CDA formatted documents and raised questions about the Consolidated
CDA's ability to support such information.
Response. We have not finalized our proposal to include the UDI
information in a Consolidated CDA formatted document given our decision
not to adopt a UDI certification criterion at this time. We appreciate
the comments from stakeholders and will consider them for future
rulemakings.
Electronic Prescribing (e-prescribing)
We proposed an ``e-prescribing'' certification criterion for the
Proposed Voluntary Edition that was unchanged as compared to the 2014
Edition certification criterion. We did not request any specific public
comments on this certification criterion.
Comments. The majority of commenters supported an unchanged
criterion. One commenter suggested merging this criterion with the
CPOE--medications certification criterion. Multiple commenters
recommended that we adopt the NCPDP ``SCRIPT Implementation
Recommendations'' guidance document that provides clarity on how to
populate e-prescribing transactions.\38\ One commenter endorsed the
inclusion of RxNorm drug identifiers to provide quality controls for
drug identification and promote interoperable exchange of medication
information. This commenter recommended use of RxNorm in place of a
representative National Drug Code (NDC). One commenter suggested that
we consider requiring transmission of in-language prescription labels
to prevent inappropriate misuse of prescriptions.
---------------------------------------------------------------------------
\38\ The most recent version of this document is Version 1.26
May 2014.
---------------------------------------------------------------------------
A commenter noted that the FDA is working to implement requirements
in the Drug Supply Chain Security Act regarding standards for the
interoperable exchange of information for tracing human, finished, and/
or prescription drugs. The commenter recommended that we be aware of
these
[[Page 54460]]
efforts and align current and future EHR requirements with any future
FDA requirements for standards-based identification of prescription
drugs.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. We will consider
comments including those on vocabularies, the NCDPD SCRIPT
implementation guidance, prescription labeling, and the FDA's work to
implement the requirements in the Drug Supply Chain Security Act for
future rulemaking activity concerning an ``e-prescribing''
certification criterion.
Incorporate Laboratory Tests and Values/Results
We proposed an ``incorporate laboratory tests and values/results''
certification criterion for the Proposed Voluntary Edition that was
revised in comparison to the 2014 Edition certification criterion.
Specifically, we proposed to include in the criterion the HL7 Version
2.5.1 Implementation Guide: Standards and Interoperability Framework
Laboratory Results Interface, Release 1 (U.S. Realm) (S&I Framework
LRI) with Errata.\39\ We also proposed more specific requirements for
how EHR technology must be capable of electronically displaying the
information included in a test report. As stated in the Proposed Rule,
this specificity would improve the consistency with how laboratory
tests and values/results are displayed, which would also assist
laboratories with CLIA compliance. We proposed to require EHR
technology to be capable of displaying the following information
included in laboratory test reports it receives: The information for a
test report as specified in 42 CFR 493.1291(a)(1) through (a)(3) and
(c)(1) through (c)(7); the information related to reference values as
specified in 42 CFR 493.1291(d); the information for alerts and delays
as specified in 42 CFR 493.1291(g) and (h); and the information for
corrected reports as specified in 42 CFR 493.1291(k)(2).
---------------------------------------------------------------------------
\39\ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=279.
---------------------------------------------------------------------------
Comments. Commenters were generally supportive of adoption of
interoperable laboratory standards, particularly the LRI IG with
errata, and with aligning requirements with CLIA. Commenters did,
however, express concerns. Commenters recommended that major errata in
the proposed LRI IG be tested further before normative balloting,
stating that this would give laboratories and HIT developers more
awareness of significant changes and time to implement and test the
changes before the IG becomes normative. EHR technology developers
expressed concerns with specific requirements for EHRs to display
information that they stated would routinely be captured in a
laboratory information system or other system and not available to
EHRs. Commenters also strongly recommended that there should be
harmonization across all IGs (e.g., LRI, LOI, ELR, eDOS, CDA and other
IGs) for consistent process, behavior, terminology, and usage.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. We believe, however,
that there is great promise and value in the LRI IG in terms of
improving the interoperability of laboratory test results/values, the
electronic exchange of laboratory test results/values, and compliance
with CLIA for laboratories. We believe work is currently being done to
address the concerns of commenters, such as addressing interoperability
concerns and ambiguities with the LRI IG with errata, testing use of
the LRI IG, developing implementation guidance for EHR functionality,
and harmonizing all laboratory standards and IGs. Accordingly, while we
have not adopted the proposed certification criterion at this time or
the LRI IG with errata, we intend to revisit this certification
criterion and the use of an updated LRI IG along with CLIA requirements
in a future rulemaking.
Transmission of Electronic Laboratory Tests and Values/Results to
Ambulatory Providers
We proposed a ``transmission of electronic laboratory tests and
values/results to ambulatory providers'' certification criterion for
the Proposed Voluntary Edition that was revised in comparison to the
2014 Edition certification criterion. Specifically, we proposed to
include in the criterion the HL7 Version 2.5.1 Implementation Guide:
Standards and Interoperability Framework Laboratory Results Interface,
Release 1 (U.S. Realm) (S&I Framework LRI) with Errata.\40\ We also
proposed to include new functionality that would improve the
consistency with how laboratory tests and values/results are sent,
received, and displayed. As stated in the Proposed Rule, this would
assist laboratories with CLIA compliance. We proposed to require EHR
technology to be capable of including in the laboratory test reports it
creates for electronic transmission: The information for a test report
as specified in 42 CFR 493.1291(a)(1) through (a)(3) and (c)(1) through
(c)(7); the information related to reference values as specified in 42
CFR 493.1291(d); the information for alerts and delays as specified in
42 CFR 493.1291(g) and (h); and the information for corrected reports
as specified in 42 CFR 493.1291(k)(2).
---------------------------------------------------------------------------
\40\ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=279.
---------------------------------------------------------------------------
To make the CFR easier to follow for readers, we proposed to adopt
the updated S&I Framework LRI at Sec. 170.205(j)(2), which would
require the modification of the regulatory text hierarchy in Sec.
170.205(j) to designate the standard referenced by the 2014 Edition
version of this certification criterion at Sec. 170.205(j) to be at
Sec. 170.205(j)(1).
Comments. The comments we received on this proposed certification
criterion were substantially similar to the comments we received on the
``incorporate laboratory tests and values/results'' certification
criterion discussed above. We refer readers to those comments.
Response. We have not adopted this certification criterion. Our
rationale for not adopting this certification criterion is the same as
that provided for the ``incorporate laboratory tests and values/
results'' certification criterion discussed above. We refer readers to
that response.
Data Portability
We proposed a ``data portability'' certification criterion for the
Proposed Voluntary Edition that was revised in comparison to the 2014
Edition certification criterion. We proposed to include in the
certification criterion the Consolidated CDA Release 2.0 and UDIs for a
patient's implantable device within a created Consolidated CDA
formatted document.
Comments. The comments we received regarding the Consolidated CDA
Release 2.0 in response to this criterion were similar to those
received on the other four criteria that we proposed to incorporate it
within. The majority of commenters thought it was premature to adopt
Release 2.0 and that
[[Page 54461]]
Release 2.0 would create backwards compatibility issues with previous
versions of the Consolidated CDA, thus preventing the receipt of the
new version. Commenters recommended we do not include it in the data
portability certification criterion at this time. Commenters also
stated that it was premature to include patient implantable device
information (i.e., UDIs) in Consolidated CDA formatted documents.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As discussed under
the ToC certification criterion in this section (IV.A) of the preamble,
we have not adopted the Consolidated CDA Release 2.0. As discussed
under the ``implantable device list'' certification criterion in this
section (IV.A) of the preamble, we have not adopted that proposed
certification criterion. We will, however, in relation to future
rulemaking activity, consider the comments received concerning a ``data
portability'' certification criterion, the Consolidated CDA Release
2.0, and a patient's implantable device list and associated UDIs.
Clinical Quality Measures--Capture and Export
We proposed a ``clinical quality measures--capture and export''
certification criterion as part of the Proposed Voluntary Edition that
was unchanged as compared to the 2014 Edition certification criterion.
We did, however, solicit public comment on the potential usefulness of
broadening the export requirement to include a QRDA Category II
formatted data file.
Comments. We received a few comments that the immunization CQMs do
not match well with the Advisory Committee on Immunization Practice's
recommendations. A commenter suggested that we should not update the
standards we adopted for CQMs in the 2014 Edition until the industry
has had sufficient time to adjust to the current standards. One
commenter suggested that we and CMS revise the current eCQM process and
provide a database configuration that all EHR technology developers,
EPs, EHs, and CAHs would install. The commenter stated that the
configuration would be able to take raw data and produce the desired
output for each eCQM and QRDA submission, thereby reducing the burden
on EHR technology developers to adapt to changes in the database schema
and data collection.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``clinical quality measures--capture and export''
certification criterion. Our request for comment on the potential
usefulness of broadening the export requirement to also include a QRDA
Category II formatted data file was to inform our decision-making for
future rulemaking. We will take comments received on this topic into
consideration with the comments received regarding clinical
recommendations, standards maturity, and the current eCQM process for
future rulemaking concerning CQMs.
Clinical Quality Measures--Import and Calculate
We proposed a ``clinical quality measures--import and calculate''
certification criterion as part of the Proposed Voluntary Edition that
was unchanged as compared to the 2014 Edition certification criterion.
We did not request any specific public comments on this certification
criterion.
Comments. One commenter stated that this criterion requires a level
of patient matching that does not currently exist. This commenter
encouraged the creation of a national patient identification number.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``clinical quality measures--import and
calculate'' certification criterion. We thank commenters and understand
the importance of matching clinical quality data with the right
patient. We note that we solicited comments on patient matching in the
Proposed Rule and discuss this topic in more detail under the ``ToC''
certification criterion in this section (IV.A) of the preamble.
However, we note that we have not adopted patient matching requirements
in this final rule given our rulemaking approach and will consider
comments on the topic for future rulemaking.
Clinical Quality Measures--Electronic Submission
We proposed a ``clinical quality measures--electronic submission''
certification criterion for the Proposed Voluntary Edition that was
unchanged as compared to the 2014 Edition certification criterion. We
did not request any specific public comments on this certification
criterion.
Comments. A few commenters noted the discrepancies between the QRDA
Category I and III standards referenced in the 2014 Edition and the
subsequently issued CMS QRDA Category I and III IGs dictating the
``form and manner'' of eCQM submission to CMS, as required for
participation in the Physician Quality Reporting System and Inpatient
Prospective Payment System programs. Commenters noted that the CMS QRDA
IGs issued in 2013 had some conflicts with the base QRDA Category I and
III standards named in the 2014 Edition. Commenters also stated that
the CMS QRDA IG publication dates (April 1, 2013 for EHs, June 1, 2013
for EPs) did not provide sufficient time for EHR updates, testing, and
rollout to providers. Therefore, these commenters suggested we remove
the language in paragraph (ii) of this criterion requiring the
electronic data file can be electronically accepted by CMS.
Two commenters recommended that we not adopt standards that are in
draft standard for trial use (DSTU) form and wait until they become
normalized standards. These commenters noted that the QRDA Category I
and III standards adopted in the 2014 Edition are still DSTUs. One
commenter added that no regulatory action has been taken to incorporate
the errata to the QRDA Category I and III standards since their release
in 2013. Another commenter stated that the QRDA Category I and III
standards are not widely used to transmit data.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR
[[Page 54462]]
certification criteria that provide flexibility, clarity, and enhance
health information exchange. As proposed, this certification criterion
would offer no value as an optional 2014 Edition certification
criterion because it would be the same as the current 2014 Edition
``clinical quality measures--electronic submission'' certification
criterion. We will consider comments received on this criterion
regarding QRDA standards maturity and program-specific QRDA IGs for
future rulemaking concerning CQMs.
Clinical Quality Measures--Patient Population Filtering
We proposed a new ``clinical quality measures--patient population
filtering'' certification criterion for the Proposed Voluntary Edition
that would require filtering of CQMs by patient population
characteristics. Certain CMS reporting programs such as the
Comprehensive Primary Care initiative and Pioneer Accountable Care
Organization model may determine financial incentives or bonus payments
based on the performance of an entity other than the individual
provider. To support CQM reporting for these groups, we proposed to
require EHR technology be able to record structured data for the
purposes of being able to filter CQM results to create different
patient population groupings by one or more of a combination of the
following patient characteristics:
Practice site and address;
Tax Identification Number (TIN), National Provider
Identifier (NPI), and TIN/NPI combination;
Diagnosis (e.g., by SNOMED CT code);
Primary and secondary health insurance, including
identification of Medicare and Medicaid dual eligibles; and
Demographics including age, sex, preferred language,
education level, and socioeconomic status (SES).
To inform our proposal, we solicited comment on whether current CQM
standards (e.g., QRDA Category I and Category III) can collect metadata
for the characteristics listed above, and filter and create a CQM
report for a particular characteristic or combination of
characteristics. We also solicited comment on vocabulary standards that
could be used to record the characteristics proposed above.
Comments. We received mixed comments on the proposal to adopt a new
certification criterion to support filtering of CQMs by patient
characteristics. Those commenters in support of the proposal stated
that the added functionality included in the certification criterion
would help address health disparities and social determinants of
health. Some commenters believed that collecting the data in a
structured way would allow data to be filtered. One commenter pointed
to the National Quality Forum's draft report on ``Risk Adjustment for
Socioeconomic Status or Other Socioedemographic Factors,'' which
recommends stratification of measures on the basis of relevant socio-
demographic factors when the intended purpose is to identify and reduce
disparities.\41\ Additionally, commenters stated that the proposal
would help providers participating in programs where the reporting is
at an aggregate, rather than individual, provider level. Some
commenters noted that the use case for this functionality was not made
clear in the preamble.
---------------------------------------------------------------------------
\41\ http://www.qualityforum.org/WorkArea/linkit.aspx?LinkIdentifier=id&ItemID=75398.
---------------------------------------------------------------------------
A few commenters pointed out that race and ethnicity were not
included in the proposed list of characteristics and strongly urged us
to consider including race and ethnicity. Commenters also suggested the
inclusion of practice type, practice specialty, sexual orientation and
gender identity, and disability status in the list of characteristics
required for filtering. Some commenters suggested that we perform a
full inventory of the possible data elements that CQMs could be
filtered by before proposing a list.
We also received comments expressing concern about the level of
work required to build the proposed functionality into EHRs. Commenters
pointed out that some of the proposed data elements are typically found
within administrative systems (e.g., practice address and insurance
data) while other data is found within clinical systems such as the
EHR. Commenters opined that while some systems can easily merge
administrative and clinical data, not all systems currently have this
capability and thus the ability to support this proposed criterion
varies. Many commenters noted that proposed characteristics, such as
age, sex, diagnosis, NPI, and TIN, are being collected in standardized
ways within EHRs, but that there are not standard vocabularies or
definitions for other data elements such as education and SES. One
commenter recommended using a standard for collecting education based
on the standard used by the National Center for Health Statistics. Some
commenters were concerned about the complexity of establishing a
definition and standard for SES as it could factor in information on
occupation, education, income, wealth, and place of residence.
Commenters stated that this kind of data is not typically collected in
a clinical setting. Additionally, SES could change over time and thus
the inputs may change, adding further complexity.
Regarding standards for quality measurement, some commenters
remarked that the QRDA standards can currently capture the data
elements needed to filter CQMs by certain patient population
characteristics, although not all data elements in standardized form as
noted above. Commenters stated that the HQMF standard can currently
support filtering by patient characteristics but not by other provider
or location variables such as address, TIN, and NPI. Additionally, a
commenter stated that HQMF does not have the ability to indicate the
level at which a measure needs to be evaluated and summarized. The
commenter contended that this could affect whether patients are
identified in the initial patient population for group reporting or
not, and would impact whether the patient is filtered or not.
Response. Given the feedback we received, we believe additional
work is needed to further refine our proposal. Therefore, we have not
adopted this certification criterion. We clarify that we envision two
types of uses for this functionality: 1) Filtering of CQM results to
support the identification of health disparities, to help providers
identify gaps in quality, and to support a provider in delivering more
effective care to sub-groups of their patient populations, and 2) to
support administrative and group/ACO reporting of CQMs where the unit
of measurement is not the individual provider. We are considering
whether this functionality could be a standalone certification
criterion or an additional functionality included in a new version of
the ``clinical quality measures--import and calculate'' certification
criterion at Sec. 170.314(c)(2). As we have considered stakeholder
feedback on the workflow to filter CQMs, EHRs may need to first
calculate the CQM and then be able to stratify/filter results by
certain characteristics.
We agree with commenters that there are standardized vocabularies
to collect some of the data elements we proposed, but not all. We
recognize that more work is needed to identify standards for other data
elements we proposed. We also recognize that the list we proposed is
not a complete set, and that there are additional data elements the
stakeholders may wish to filter by. We appreciate the comments
regarding standards for quality reporting (e.g.,
[[Page 54463]]
QRDA and HQMF), and will use this feedback to inform our future
rulemaking. We will also take into consideration comments on the level
of filtering and summarization of CQMs for group and ACO reporting.
Authentication, Access Control, and Authorization
We proposed an ``authentication, access control, and
authorization'' certification criterion for the Proposed Voluntary
Edition that was unchanged as compared to the 2014 Edition
certification criterion. We did, however, solicit comments on the issue
of two-factor authentication to support two use cases: E-prescribing of
controlled substances; and remote provider access. In 2010, the Drug
Enforcement Agency (DEA) removed the federal ban on e-prescribing
controlled substances. The DEA requires the use of two-factor
authentication protocol when e-prescribing. In 2012, the HITPC
recommended that we adopt multi-factor authentication by providers
remotely accessing protected health information. We asked the public to
respond to two questions:
(1) Should we adopt a general two-factor authentication requirement
for certification?
(2) Were the HITPC's recommendations appropriate and actionable?
Comments. All commenters supported the certification criterion as
unchanged. Commenters did not support a broad two-factor authentication
requirement for certification. The majority of the commenters did,
however, support the inclusion of two-factor authentication
functionality for the specific purpose of e-prescribing controlled
substances. Some commenters noted that the DEA's requirements were more
complex than basic two-factor authentication and urged us to consult
with the DEA before creating a criterion to support this use case.
Commenters were divided in their support for requiring two-factor
authentication for remote access for providers. Commenters agreed that
the HITPC's recommendations regarding remote access for providers were
actionable. However, comments varied with regard to whether the
recommendation was appropriate for remote access. Specifically,
commenters were concerned that differences in EHR systems (i.e., cloud-
based versus practice-installed) created ambiguity as to when the
requirement would apply and sought clarity in the term ``remote
access.'' In addition, commenters voiced concern about the potential
criterion becoming too prescriptive, with many commenters urging us to
propose a criterion that required EHRs to support these use cases
without describing how they did so. Commenters further noted concern
about the ability to test two-factor authentication.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``authentication, access control, and
authorization'' certification criterion. We will consider comments
regarding the use of two-factor authentication to support e-prescribing
of controlled substances and remote access for providers in future
rulemaking concerning an ``authentication, access control, and
authorization'' certification criterion.
Auditable Events and Tamper-Resistance
We proposed an ``auditable events and tamper-resistance''
certification criterion for the Proposed Voluntary Edition that was
revised in comparison to the 2014 Edition certification criterion. We
proposed this certification criterion in response to a report by the
OIG entitled, ``Not All Recommended Safeguards Have Been Implemented in
Hospital EHR Technology'' (OEI-01-11-00570).\42\ We proposed to require
EHR technology to prevent all users from being able to disable an audit
log. We asked for public comment on the impact and potential unintended
consequences of such a change and for specific examples where disabling
an EHR technology's audit log is warranted.
---------------------------------------------------------------------------
\42\ https://oig.hhs.gov/oei/reports/oei01-11-00570.pdf.
---------------------------------------------------------------------------
Comments. The majority of commenters, including EHR technology
developers, EHR developer associations, and the HITSC, did not support
preventing all users from being able to disable the audit log.
Commenters stressed that there were valid and important reasons for
users to disable the audit log, including allowing a system
administrator to disable the audit log for performance fixes,
stability, disaster recovery, and system updates or allowing a system
administrator to disable it when there is rapid server space loss which
is hindering a provider from accessing needed clinical information in a
timely manner. Commenters stated that the majority of EHR developers do
not currently allow audit logs to be disabled. Commenters also stated
that preventing the disabling of the audit log was a best practice, but
should not be included in the certification criterion because of cases
of emergency or disaster that would necessitate disabling of the audit
log. Other commenters, including providers, provider associations,
consumer advocates, and EHR technology developers, supported the OIG
recommendation. Consumer advocates and others commented that preventing
the audit log from being disabled would improve consumers' trust. A
minority of commenters supported identifying a baseline set of
auditable actions that should be prevented from being disabled. The
baseline set included additions, deletions, and other changes.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. Additionally, in
response to the significant and detailed feedback we received
recommending that we do not finalize our proposal, we will further
evaluate whether it is appropriate to implement the OIG report's
recommendation. As many commenters noted, there are valid reasons that
require a limited number of EHR users to be capable of disabling the
audit log. We will continue to engage with stakeholders regarding audit
log functionality, and will consider stakeholder feedback in regard to
future rulemaking concerning an ``auditable events and tamper-
resistance'' certification criterion.
Audit Report(s)
We proposed an ``audit report(s)'' certification criterion for the
Proposed Voluntary Edition that was unchanged as compared to the 2014
Edition certification criterion. We did not request any specific public
comments on this certification criterion as part of the Proposed
Voluntary Edition.
Comments. Commenters supported the proposed certification criterion
as unchanged.
Response. We thank commenters for their support of this proposed
unchanged certification criterion. We have not, however, adopted this
[[Page 54464]]
certification criterion because we have not adopted the Proposed
Voluntary Edition. Rather, we have only adopted a small subset of the
proposed certification criteria as optional 2014 Edition EHR
certification criteria and made revisions to 2014 Edition EHR
certification criteria that provide flexibility, clarity, and enhance
health information exchange. As proposed, this certification criterion
would offer no value as an optional 2014 Edition certification
criterion because it would be the same as the current 2014 Edition
``audit report(s)'' certification criterion.
Amendments
We proposed an ``amendments'' certification criterion for the
Proposed Voluntary Edition that was unchanged as compared to the 2014
Edition certification criterion. We did not request any specific public
comments on this certification criterion.
Comments. Commenters supported the proposed certification criterion
as unchanged. Some commenters noted the importance of this
certification criterion and recommended records tag patient-generated
amendments to denote the appropriate provenance.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``amendments'' certification criterion. We will,
however, consider the comments about data provenance of amendments for
future rulemaking activity concerning an ``amendments'' certification
criterion.
Automatic Log-Off
We proposed an ``automatic log-off'' certification criterion for
the Proposed Voluntary Edition that was unchanged as compared to the
2014 Edition certification criterion. We did not request any specific
public comments on this certification criterion.
Comments. Commenters supported the proposed certification criterion
as unchanged.
Response. We thank commenters for their support. However, we have
not adopted this certification criterion because we have not adopted
the Proposed Voluntary Edition. Rather, we have only adopted a small
subset of the proposed certification criteria as optional 2014 Edition
EHR certification criteria and made revisions to 2014 Edition EHR
certification criteria that provide flexibility, clarity, and enhance
health information exchange. As proposed, this certification criterion
would offer no value as an optional 2014 Edition certification
criterion because it would be the same as the current 2014 Edition
``automatic log-off'' certification criterion.
Emergency Access
We proposed an ``emergency access'' certification criterion for the
Proposed Voluntary Edition that was unchanged as compared to the 2014
Edition certification criterion. We did not request any specific public
comments on this certification criterion.
Comments. Commenters supported the proposed certification criterion
as unchanged. One commenter expressed concerns that untrained users
could make a mistake in a complex EHR system related to access.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``emergency access'' certification criterion. In
response to the comment on ``untrained'' users, we note that the 2014
Edition certification criterion (and the proposed ``emergency access''
criterion) requires EHR technology to be able to designate a ``set of
users.'' A provider would determine appropriate users and access to
their system in conjunction with the EHR technology developer, which is
not part of the certification process under the ONC HIT Certification
Program.
End-User Device Encryption
We proposed an ``end-user device encryption'' certification
criterion for the Proposed Voluntary Edition that was unchanged as
compared to the 2014 Edition certification criterion. We did not
request any specific public comments on this certification criterion.
Comments. Commenters supported the proposed certification criterion
as unchanged.
Response. We thank commenters for their support. However, we have
not adopted this certification criterion because we have not adopted
the Proposed Voluntary Edition. Rather, we have only adopted a small
subset of the proposed certification criteria as optional 2014 Edition
EHR certification criteria and made revisions to 2014 Edition EHR
certification criteria that provide flexibility, clarity, and enhance
health information exchange. As proposed, this certification criterion
would offer no value as an optional 2014 Edition certification
criterion because it would be the same as the current 2014 Edition
``end-user device encryption'' certification criterion.
Integrity
We proposed an ``integrity'' certification criterion for the
Proposed Voluntary Edition that was unchanged as compared to the 2014
Edition certification criterion. We did not request any specific public
comments on this certification criterion.
Comments. Commenters supported the proposed certification criterion
as unchanged.
Response. We thank commenters for their support. However, we have
not adopted this certification criterion because we have not adopted
the Proposed Voluntary Edition. Rather, we have only adopted a small
subset of the proposed certification criteria as optional 2014 Edition
EHR certification criteria and made revisions to 2014 Edition EHR
certification criteria that provide flexibility, clarity, and enhance
health information exchange. As proposed, this certification criterion
would offer no value as an optional 2014 Edition certification
criterion because it would be the same as the current 2014 Edition
``integrity'' certification criterion.
Accounting of Disclosures
We proposed an ``accounting of disclosures'' certification
criterion for the Proposed Voluntary Edition that was unchanged
substantively as compared to the 2014 Edition certification criterion.
We did, however, propose to remove the ``optional'' designation from
this certification criterion for the Proposed Voluntary Edition because
such a designation would no longer be necessary with the proposed
discontinuation of the Complete EHR concept.
Comments. All of the comments received supported leaving the
certification criterion unchanged. Commenters overwhelmingly
recommended that we do not remove the optional designation regardless
of
[[Page 54465]]
other proposed changes. Commenters suggested removing the optional
designation would create confusion in the marketplace and require
significant additional development work.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. We note that
commenters apparently misunderstand the purpose of designating
certification criteria as optional. As we explained in the Proposed
Rule (79 FR 10918), the designation of ``optional'' for certification
criteria was developed to accommodate the Complete EHR definition
(i.e., cases where EHR technology would otherwise have to be certified
to a criterion solely because it is required in order to satisfy the
Complete EHR definition and certification). Complete EHR certification
is still permitted to the 2014 Edition. Therefore, as proposed, it
would make no sense to adopt this certification criterion as part of
the 2014 Edition as it is substantively the same as the current 2014
Edition ``accounting of disclosures'' certification criterion and,
without the optional designation, it would directly contradict the
current 2014 Edition ``accounting of disclosures'' certification
criterion and EHR technology would be required to certify to it for a
Complete EHR certification.
View, Download, and Transmit to 3rd Party
The summary of the proposals in the Proposed Rule recited in this
section only summarize and include the ``comments'' and ``response''
for the proposals that we have not adopted in this final rule. For the
VDT proposal made in the Proposed Rule and adopted in this final rule,
including a summary of what was proposed for that proposal, please see
section III.A.2 of this preamble.
We proposed to revise the VDT criterion in a number of ways,
including: Clarifying introductory text in order to clearly specify
that this criterion expressed patient facing capabilities for patient
use; decoupling the content and transport requirements and in tandem
proposing a revision that would more clearly express EHR technology's
ability to support a patient's ability to choose the destination or to
whom they wanted to send their health information; updating the
Consolidated CDA version with the corresponding inclusion of UDI
information; increasing the Web Content Accessibility Guidelines (WCAG)
level to level AA; and revising the activity history log requirement to
record two additional data elements (the addressee to whom an
ambulatory summary or inpatient summary was transmitted and whether
that transmission was successful).
Comments. Commenters generally supported clarifying the
introductory text of VDT. Commenters stressed the importance of
allowing authorized representatives the ability to perform the VDT
functionality. Some EHR technology developers opposed revisions related
to the clarification around a patient's ability to ``download'' a human
readable file, a Consolidated CDA file, or both. A commenter
representative of the majority of EHR technology developers indicated
that the revised criterion is overly prescriptive and not in sync with
actual software development. The commenter stated that EHR technology
developers enable users to download the XML version and the style sheet
together, since the style sheet is applied to the XML to provide the
human-readable information. The commenter concluded that most patients
would find making a choice confusing and did not believe that patients
would benefit from this proposal.
With respect to our proposal for EHR technology to enable a patient
to choose the destination or whom they wanted to send their health
information via Direct, many commenters opposed or raised concerns
about this proposal. Most of these commenters were EHR technology
developers who identified a number of technical concerns with the
proposal. They stated that:
EHR technology cannot guarantee that any message sent to a
Direct address specified for transmission will reach the endpoint. Each
HISP has rules beyond the EHR's control specifying their exchange with
other HISPs.
The ability of a patient to enter a third party
destination of their choice (i.e., initiate a direct exchange using a
valid direct exchange address) would imply that the EHR technology has
the ability to determine if the address entered is valid. When a
patient enters an address, the EHR technology would not know if it is
valid and with the separation of content from transport, the EHR
technology would no longer control the Domain Name System/Lightweight
Directory Access Protocol (DNS/LDAP) look up to ensure that the
certificate is valid and included within the sender's HISP trust
circle.
Patients have not, and will not any time soon, be given
Direct addresses because it is too great an expense.
We received many comments on our proposal to update the
Consolidated CDA version to Release 2.0. The majority of commenters,
especially those from EHR technology developers, HIT developer
associations, and certification bodies, did not support this proposal.
Commenters voiced concerns that Release 2.0 was so new that many
stakeholders had not had the chance to review it and it had not been
sufficiently piloted. In addition, commenters pointed out a technical
problem with the update, known as ``bilateral asynchronous cutover''
wherein Release 2.0 is not backwards compatible with previous versions
of the Consolidated CDA and therefore a provider with a 2014 Edition
certified product could not receive a document conformant to the
updated Consolidated CDA standard. These commenters supported
considering Release 2.0 for future editions of our certification
criteria. Consumer advocacy groups supported the proposal, noting that
the additional functionality included in Release 2.0, such as new
structural elements for care plans, patient goals, and health outcomes,
were important to consumers and care planning.
We received mixed comments on our proposal to move to WCAG Level
AA, including many from EHR technology developers. Some opposed the
increased level citing the cost and burden to reach Level AA.
Conversely, other EHR technology developers supported the move and
offered no concerns. In both cases, EHR technology developers noted
that WCAG conformance tools are somewhat sparse and that they have had
difficulty finding viable tools. Of the few comments on whether a
hybrid of Level A and Level AA would be preferred, the comments opposed
this type of approach because it would lead to variability and
inconsistency.
Most commenters supported the inclusion of the intended recipient
in the activity history log. Commenters voiced concern about requiring
a history log to record whether the transmission was successful, noting
that EHRs do not have information on what happens to a message once it
leaves the EHR and is processed by the HISP. Commenters stated that
prior to being able to make this information patient accessible,
standards development would be necessary to support this use case. Some
commenters agreed that activity history logs should record and include
both new data points and stated that this
[[Page 54466]]
transaction history provides important information about care
coordination that patients should be able to access.
Response. We appreciate the detailed feedback we received on many
of the VDT proposals. While we are not revising the 2014 Edition VDT to
include the proposed clarifying regulation text, we note for commenters
that the requirement to provide patients with the ability to download a
human readable version, a Consolidated CDA version, or both, already
exists within the 2014 Edition VDT certification criterion. As
discussed in the Proposed Rule, the clarification was not a
modification of existing policy. Rather, it was an attempt at more
clearly articulating existing policy to avoid any confusion. As EHR
technology developers indicated, we have long-standing policy that
permits them to satisfy this approach through the use of a style sheet,
which would be an acceptable approach because it would give a patient
both human readable and Consolidated CDA versions.
We have also decided to leave the 2014 Edition certification
criterion unmodified with respect to our proposal to enable a patient
to choose the destination or whom they wanted to send their health
information via Direct. We will consider the technical challenges
raised by EHR technology developers. In the case of the Consolidated
CDA update, we have already discussed our decision not to adopt this
proposal in the discussion on the ToC criterion (Section IV.A) and do
not adopt it for the VDT certification criterion for the same reasons.
In response to comments, we will continue to evaluate the WCAG level
and suitable testing approaches. Last, we will continue to evaluate
comments on our proposal to expand the activity history log and its
connection to some of the technical challenges identified by comments.
Overall, given our approach in this final rule to only adopt a
small subset of the proposed certification criteria as optional 2014
Edition EHR certification criteria and include revisions to 2014
Edition EHR certification criteria that provide flexibility, clarity,
and enhance health information exchange, we have not adopted any of the
proposals discussed in this section.
Clinical Summary
We proposed a ``clinical summary'' certification criterion for the
Proposed Voluntary Edition that was revised in comparison to the 2014
Edition certification criterion. We proposed to reflect the
clarifications we provided in FAQ 33 \43\ (i.e., require the use of
LOINC[reg] for diagnostic tests pending and future scheduled tests to
the degree such test could be coded in LOINC[reg]), to require the use
of CVX codes for immunizations, and reference the Consolidated CDA
Release 2.0 (including UDI(s) for a patient's implantable device(s) as
data within a created Consolidated CDA formatted document) in the
proposed certification criterion. We requested comment on whether
LOINC[reg] can be used to represent all possible diagnostic tests
pending and future scheduled tests.
---------------------------------------------------------------------------
\43\ http://www.healthit.gov/policy-researchers-implementers/33-question-12-12-033.
---------------------------------------------------------------------------
We also reiterated the situational dependency (office visit-
dependent) of certain data that the EHR technology must be able to
provide, and limit, in the clinical summary to meet the proposed
certification criterion as well as the 2014 Edition ``clinical
summary'' certification criterion. We stated that although the
regulation text for medications, diagnostic tests pending, and future
scheduled tests may seem redundant with the Common MU Data Set, this
data along with immunizations is specified separately because EHR
technology must have the capability to limit this data in a clinical
summary it creates to only those medications and immunizations
administered during the visit and/or the diagnostic tests pending and
future scheduled tests after the visit. We clarified that in terms of
customization of the clinical summary, this permits the user to limit
this data in the clinical summary if so desired. We further clarified
that while providing historical data for medications, immunizations,
and diagnostic tests in the clinical summary may be of benefit in
certain instances, EHR technology is not required to have these
capabilities to meet the certification criterion. Last, we noted that
this certification criterion, like the 2014 Edition ``clinical
summary'' certification criterion, was designed to support the
associated MU objective and measure that seeks to provide a patient
with a record of the office visit and specific lab tests or specific
follow-up actions and treatment related to the office visit.
Comments. We received many comments supporting the required use of
CVX and LOINC[reg]. A few commenters opposed the use of LOINC[reg]
codes, while others suggested the use be required ``where applicable''
because LOINC[reg] cannot currently cover all possible tests. We
received comments for and against the use of the Consolidated CDA
Release 2.0 and the inclusion of UDI(s). Commenters also expressed
varying opinions on the data that should be included in a clinical
summary. Some commenters suggested that EHR technology allow for
complete customization of the data. Others commenters recommended not
including historical information or code sets in the clinical summary
(which they claimed were confusing to patients).
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. We also note that we
have not adopted the proposed Consolidated CDA Release 2.0 as discussed
under the ToC certification criterion and the ``implantable device
list'' certification criterion in this section of the preamble (IV.A).
We expect EHR technology developers to follow FAQ 33 for certification
to the 2014 Edition ``clinical summary'' certification criterion and we
continue to encourage, but not require, the use of CVX codes for
immunizations. The data element requirements for certification to the
2014 Edition ``clinical summary'' certification criterion remain the
same as does the ``situational dependency'' guidance we provided in the
Proposed Rule and have recited above. We will, however, take into
consideration the comments we received about the data that should be in
a clinical summary and how it should be expressed for future rulemaking
activity concerning a ``clinical summary'' certification criterion.
Secure Messaging
We proposed a ``secure messaging'' certification criterion for the
Proposed Voluntary Edition that was unchanged as compared to the 2014
Edition certification criterion. We did not request any specific public
comments on this certification criterion.
Comments. The majority of commenters supported adopting this
certification criterion as unchanged. However, a few commenters
recommended that we take steps to allow a patient's authorized
representative to send and receive secure messages on the patient's
behalf as part of the Proposed Voluntary Edition. In addition, one
commenter suggested that this criterion should utilize the same
``decoupling'' of content and transport requirements as
[[Page 54467]]
was proposed for the ToC certification criterion.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``secure messaging'' certification criterion. We
also note that the comment about decoupling is unclear. This
certification criterion does not establish message content requirements
so we are not certain about what the commenter thinks should be
decoupled. Further, any method of transport that meets the security
requirements of the proposed criterion would have been permitted, as it
is currently permitted with the 2014 Edition ``secure messaging''
certification criterion.
Public Health Certification Criteria
We received comments related to the public health certification
criteria, but not specific to the proposed criteria or our proposals.
We summarize and respond to these comments below.
Comments. We received a comment in favor of bidirectional exchange
between EHRs and clinical registries. The commenter encouraged us to
consider certification requirements to promote bidirectional data
exchange and data standardization between EHRs and clinical data
registries, such as certification of clinical data registries. The
commenter stated that this would assist physicians and health care
systems as well as align with payment programs that utilize clinical
data registries (e.g., PQRS). The commenter also suggested that we
consider utilizing existing national standards being used for EHRs.
Response. We appreciate the feedback and will consider the
suggestions on standards and to require certification of clinical data
registries for future rulemaking.
Immunization Information
We proposed an ``immunization information'' certification criterion
for the Proposed Voluntary Edition that was unchanged as compared to
the 2014 Edition certification criterion. We did not request any
specific public comments on this certification criterion.
Comments. The majority of commenters supported an unchanged
criterion. One commenter suggested that we not adopt this criterion, or
similar criteria in future editions, because the ``transmission to
immunization registries'' criteria sufficiently addressed the
interoperability aspects of the immunization information.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``immunization information'' certification
criterion. We appreciate the feedback suggesting that this criterion is
unnecessary as the ``transmission to immunization registries''
certification criterion addresses the functionality required by this
criterion. We will consider this feedback for future rulemaking
concerning an ``immunization information'' certification criterion.
Transmission to Immunization Registries
We proposed a ``transmission to immunization registries''
certification criterion for the Proposed Voluntary Edition that was
revised in comparison to the 2014 Edition certification criterion. We
proposed to include in this criterion the updated IG for immunization
messaging: HL7 Version 2.5.1: Implementation Guide for Immunization
Messaging, Release 1.5. The updated IG focuses on known issues from the
previous release and revises certain HL7 message elements to reduce
differences between states and jurisdictions for recording specific
data elements.
Comments. The majority of commenters supported adoption of the
updated IG for immunization messaging. These commenters stated that the
updated IG provides additional clarification and guidance for better
interoperability between EHRs and immunization registries. Commenters
in opposition to adopting the updated IG were concerned about needing
to support two versions of an IG at the same time. Some commenters were
also concerned about backwards compatibility with the version currently
required in the 2014 Edition. Commenters who were generally opposed to
the proposed voluntary and more incremental rulemaking approach also
contended that the updated IG did not offer much value for the work
that would be required to update systems.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. We appreciate the
feedback commenters provided regarding the updated IG and will consider
the comments received for future rulemaking concerning a ``transmission
to immunization registries'' certification criterion.
Transmission of Reportable Laboratory Tests and Values/Results
We proposed a ``transmission of reportable laboratory tests and
values/results'' certification criterion for the Proposed Voluntary
Edition that was revised in comparison to the 2014 Edition
certification criterion. We proposed to include in this criterion the
updated IG for reporting laboratory tests and values/results to public
health agencies (HL7 Version 2.5.1: HL7 Version 2.5.1 Implementation
Guide: Electronic Laboratory Reporting to Public Health, DSTU, Release
2 (US Realm), 2013). The updated IG addresses technical corrections and
clarifications for interoperability with laboratory orders and other
laboratory domain IGs. To properly codify this proposal in regulation,
we proposed to modify the regulatory text hierarchy in Sec. 170.205(g)
to designate the standard and implementation specifications referenced
by the 2014 Edition ``transmission of reportable laboratory tests and
values/results'' certification criterion at Sec. 170.205(g)(1) instead
of its current designation at Sec. 170.205(g).
Comments. We received mixed feedback on the proposal to adopt the
updated IG for reporting laboratory tests and values/results to public
health agencies. Some commenters were in favor of adopting the updated
IG. Other commenters stated that many state public health agencies and
EHR technology developers are still working to implement the version we
adopted in the 2014 Edition, and thus contended it is too early to
require compliance with an updated IG.
A few commenters supported SNOMED-encoded observations values,
where applicable, because of the
[[Page 54468]]
potential value add to reportable laboratory results for public health.
Two commenters stated that we incorrectly referenced the author of the
updated IG in the preamble of the Proposed Rule. These commenters
recommended that we correct the author reference from CDC to the HL7
Public Health and Emergency Response Workgroup. These commenters also
recommended we update the title of the IG to ``HL7 Version 2.5.1
Implementation Guide: Electronic Laboratory Reporting to Public Health,
R2, US Realm--Draft Standard for Trial Use'' in order to encompass all
current and subsequent releases. One commenter recommended we update
the minimum code versions for LOINC[supreg] and SNOMED CT[supreg].
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange.
We agree with the correction of the author of the updated IG and
believe that the CDC worked in conjunction with the HL7 Public Health
Emergency Response Workgroup to develop the updated IG. For future
rulemaking, we will consider the comments received regarding the
maturity and version/naming of the updated IG. Regarding the comments
recommending that we adopt the updated LOINC[supreg] and SNOMED
CT[supreg] standards, we will reassess whether newer versions of the
minimum standards should be adopted in future rulemaking. As we stated
in the 2014 Edition Final Rule, based on our experience, newer versions
of the ``minimum standards'' code sets that we have adopted are issued
more frequently than our current process can reasonably accommodate. We
do not believe that permitting EHR technology to be upgraded and
certified to newer versions of these code sets would normally pose an
interoperability risk, and therefore we allow use of a newer version
voluntarily for certification without adversely affecting the EHR
technology's certified status unless the Secretary specifically
prohibits the use of a newer version (77 FR 54268). Thus, EHRs may be
certified to newer versions of LOINC[supreg] and SNOMED CT[supreg].
Cancer Case Information
We proposed a ``cancer case information'' certification criterion
for the Proposed Voluntary Edition that was unchanged as compared to
the 2014 Edition certification criterion. We did not request any
specific public comments on this certification criterion.
Comments. The majority of commenters supported an unchanged
criterion. One commenter suggested removing this criterion in future
editions because they recommend a focus on privacy and security,
interoperability, and quality reporting, and thus contended that this
criterion is not necessary. Another commenter recommended that we
consider privacy issues so that patients are not inappropriately
penalized by insurance companies or employers for having cancer or a
preexisting condition.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``cancer case information'' certification
criterion. We will consider the feedback regarding the necessity of
this criterion and privacy concerns for future rulemaking concerning a
``cancer case information'' certification criterion.
Transmission to Cancer Registries
We proposed a ``transmission to cancer registries'' certification
criterion for the Proposed Voluntary Edition that was revised in
comparison to the 2014 Edition certification criterion. We proposed to
include in this criterion an updated IG (Implementation Guide for
Ambulatory Healthcare Provider Reporting to Central Cancer Registries,
HL7 Clinical Document Architecture (CDA), Release 1.1, March 2014) to
address technical corrections and clarifications for interoperability
with EHRs and cancer registries. We also proposed to make a technical
amendment to the regulation text for the 2014 Edition certification
criterion so that it continues to point to the appropriate standard
\44\ in the regulatory text hierarchy at Sec. 170.205(i), while
accommodating our Proposed Voluntary Edition proposal. Specifically, we
proposed to modify the 2014 Edition certification criterion to
reference Sec. 170.205(i)(1) to establish the regulatory text
hierarchy necessary to accommodate the standard and IG referenced by
the Proposed Voluntary Edition certification criterion.
---------------------------------------------------------------------------
\44\ Standard. HL7 Clinical Document Architecture (CDA), Release
2.0, Normative Edition (incorporated by reference in Sec. 170.299).
Implementation specifications. Implementation Guide for Ambulatory
Healthcare Provider Reporting to Central Cancer Registries, HL7
Clinical Document Architecture (CDA), Release 1.0 (incorporated by
reference in Sec. 170.299).
---------------------------------------------------------------------------
Comments. We received mixed feedback on the proposal to adopt the
updated cancer transmission IG. Some commenters supported adopting the
updated IG and also commented that they look forward to more
generalizable CDA-based case reporting in the future. Other commenters
were concerned about the differences in state requirements that lead to
custom interface development before achieving bidirectional exchange.
Some suggested we wait until the next edition to propose adopting the
updated IG because there has not been sufficient time for
implementation experience.
Some commenters stated that, in their experience, the adoption of
the cancer transmission IG required in the 2014 Edition is low, and
therefore they did not foresee that many would adopt an updated
version. One commenter noted that there is a proposed HL7 project to
more closely align the CDA-based cancer reporting IG with the
Consolidated CDA standard. We also received comments stating that we
should consult with existing registries for guidance on the appropriate
standards to adopt. One commenter recommended that the updated IG
should include data elements for transmission of grade and pathological
TNM Stage,\45\ as it is difficult to report to state cancer agencies if
cancer synoptics are not in a structured data format and can be prone
to manual data entry errors.
---------------------------------------------------------------------------
\45\ The TNM Classification of Malignant Tumours (TNM) is a
cancer staging system that describes the extent of a person's
cancer.
---------------------------------------------------------------------------
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. We agree that we
should evaluate the maturity of the updated IG, its required data
elements, efforts to move to the Consolidated CDA standard, and
standards used by current registries to inform our future rulemaking
concerning a ``transmission to cancer registries'' certification
criterion.
[[Page 54469]]
Automated Numerator Recording
We proposed to adopt an unchanged ``automated numerator recording''
certification criterion as compared to the 2014 Edition certification
criterion. We did not request any specific public comments on this
certification criterion.
Comments. Commenters expressed support for the proposed unchanged
certification criterion. Commenters also expressed concern over the
burden involved in meeting MU measurement requirements (e.g., time
consuming and affects efforts to improving clinical functionality and
usability). One commenter suggested that this criterion either be
removed or be made more granular and defined sufficiently. In terms of
more granularity, the commenter suggested that each numerator recording
requirement for a capability (e.g., CPOE or VDT) should be specified in
the ``automated numerator recording'' certification criterion.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``automated numerator recording'' certification
criterion. We will, however, consider whether additional specificity is
appropriate for the ``automated numerator recording'' certification
criterion and further evaluate the costs and benefits of this
certification requirement for future rulemaking activity concerning an
``automated numerator recording'' certification criterion.
Automated Measure Calculation
We proposed to adopt an unchanged ``automated numerator recording''
certification criterion as compared to the 2014 Edition certification
criterion. We proposed to apply guidance for certification to the 2014
Edition ``automated measure calculation'' certification criterion
included in the 2014 Edition Final Rule to the proposed certification
criterion (79 FR 10911). We also proposed that the interpretation of
the 2014 Edition ``automated measure calculation'' certification
criterion in FAQ 32 \46\ would apply to the proposed certification
criterion. We did not request any specific public comments on this
certification criterion.
---------------------------------------------------------------------------
\46\ http://healthit.gov/policy-researchers-implementers/32-question-11-12-032.
---------------------------------------------------------------------------
Comments. Commenters expressed support for the proposed
certification criterion as unchanged. A couple of commenters stated
this certification criterion helped providers and lessened their MU
reporting burden. EHR technology developers stated that this criterion
represents one of the largest areas of development investment of all of
the MU certification requirements. The commenters noted that it is
common to invest more effort in measuring a particular MU requirement
than developing the associated capability. One commenter suggested that
this criterion be made more granular. The commenter suggested that each
measure requirement for a capability (e.g., CPOE or VDT) should be
specified in the ``automated measure calculation'' certification
criterion. Another commenter recommended making available different
testing methods for this certification criterion, including scenario-
based testing options.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``automated measure calculation'' certification
criterion. We will, however, consider whether additional specificity is
appropriate for ``automated measure calculation'' certification
criteria, further evaluate the development effort associated with this
certification criterion, and consider any potential alternative testing
methods now and in relation to future rulemaking activity concerning an
``automated measure calculation'' certification criterion.
Safety-Enhanced Design
We proposed a ``safety-enhanced design'' (SED) certification
criterion for the Proposed Voluntary Edition that was unchanged as
compared to the 2014 Edition certification criterion. We did, however,
solicit public comment regarding whether we should modify the
certification criterion. Specifically, we requested comment regarding
whether:
The scope of SED should be expanded to include additional
certification criteria;
Formative usability tests should be explicitly required,
or used as substitutes for summative testing;
There are explicit usability tests that should be required
in addition to summative testing; and
There should be a minimum number of test subjects
explicitly required for usability testing.
Comments. We received many comments in response to our request for
comments. Commenters suggested expanding the certification criteria
covered in this criterion to criteria covering laboratory exchange,
problems, and other areas. Conversely, other commenters recommended not
expanding the certification criteria covered by the SED criterion.
Commenters were both for and against using actual formative usability
tests with some suggesting testing to certain usability standards. Some
commenters also suggested that there be a minimum number of test
subjects, with a few commenters emphasizing that the test subjects and
process should be objective.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``safety-enhanced design'' certification
criterion. We will, however, consider all the thoughtful comments we
received regarding expanding the scope and testing of the SED
certification criterion in relation to future rulemaking activity
concerning a SED certification criterion.
We note that we have revised the 2014 Edition SED certification
criterion (Sec. 170.314(g)(3)) to include the three optional CPOE
certification criteria and the optional CIRI certification criterion.
We discuss these revisions in further detail under the discussions of
CPOE and CIRI in section III.A.2 of this preamble.
Quality Management System
We proposed a ``quality management system'' certification criterion
for the Proposed Voluntary Edition that was unchanged as compared to
the 2014 Edition certification criterion. We did
[[Page 54470]]
not request any specific public comments on this certification
criterion.
Comments. Commenters expressed support for the proposed
certification criterion as unchanged. One commenter suggested that we
remove this certification criterion for the proposed edition and any
future editions until the Food and Drug Administration Safety and
Innovation Act (FDASIA) health care IT regulatory framework has been
established and implemented.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``quality management system'' certification
criterion. As with all stakeholder feedback, we appreciate the comments
submitted, including the recommendation to remove this certification
criterion from future editions. We will consider the FDASIA Health IT
Report,\47\ including a published final report, in future rulemaking
activity concerning a ``quality management system'' certification
criterion.
---------------------------------------------------------------------------
\47\ http://www.healthit.gov/sites/default/files/fdasia_healthitreport_final.pdf.
---------------------------------------------------------------------------
Non-Percentage-Based Measures Report
We proposed a new ``non-percentage-based measures report''
certification criterion for the Proposed Voluntary Edition.
Specifically, we proposed to adopt a new certification criterion that
would apply to EHR technology presented for certification that includes
certain ``non-percentage-based capabilities'' (i.e., capabilities that
support MU objectives for which the corresponding MU measure is not
percentage-based). In the 2014 Edition NPRM (77 FR 13842), we proposed
a certification criterion for ``non-percentage-based measure use
report,'' but subsequently did not adopt the criterion in the 2014
Edition Final Rule based on commenters' concerns that additional
specificity would be needed to make the proposed criterion more
effective. In the Proposed Rule, we stated that we continue to believe
that EPs, EHs and CAHs could benefit from EHR technology that could
electronically report non-percentage-based MU objectives and measures,
and we have also received feedback from OIG and comments in response to
a MU Stage 3 Request For Comment \48\ echoing this need.
---------------------------------------------------------------------------
\48\ The Request for Comments is available at: http://www.healthit.gov/sites/default/files/hitpc_stage3_rfc_final.pdf.
---------------------------------------------------------------------------
Therefore, we proposed a new criterion that is more specific than
the one proposed in the 2014 Edition NPRM and recognizes that certain
aspects of ``use'' associated with non-percentage-based measures will
occur in different ways based on the particular EHR capability
involved. The proposed certification criterion would require that an
EHR technology presented for certification be capable of electronically
generating a report that shows a user had used (or interacted with) the
EHR technology capability associated with a non-percentage-based MU
measure during an EHR reporting period. This means that, at a minimum,
the EHR technology would need to be capable of determining an EHR
reporting period (date range) and be able to record some evidence of
use (e.g., transaction, user action, intervention/reminder) during the
reporting period. We requested public comment on whether we should make
the regulatory text for this certification criterion more specific or
if we should maintain the word ``evidence'' and use this final rule's
preamble to provide more examples of what evidence would be acceptable.
If we were to make the regulatory text more specific, we proposed two
options, but also solicited comment on other potential language that
would make satisfying this criterion clearer.
Option 1: Require the EHR technology to record evidence of
use each time a particular capability was used during the reporting
period.
Option 2: Require the EHR technology to record evidence of
use at the beginning, during, and end of the reporting period.
We believe the proposed criterion provides EHR technology
developers with substantial flexibility to create innovative approaches
to document evidence of use. The proposed criterion would apply to only
those non-percentage-based measures for which this pertinent
information would be available to the EHR technology based on the
nature of the capabilities and the ways in which a user could be
expected to interact with them. To illustrate which certification
criteria support one or more non-percentage-based measures, we provided
a table (79 FR 10912) in the Proposed Rule. As described in the
Proposed Rule, we also proposed not to include the proposed ``drug-
formulary checks'' and ToC certification criteria within the scope of
this criterion because the corresponding MU measures already provide
evidence of use. We also proposed that all the proposed privacy and
security certification criteria of the Proposed Voluntary Edition
should not be included within the scope of this certification criterion
because EHR technology would not be able to capture that a security
risk analysis was performed by an EP, EH, or CAH except through a
manual entry by the EP, EH, or CAH affirming the completion of the risk
analysis.
Consistent with the way in which we have previously implemented
certification policy that more generally applies to EHR technology, an
ONC-ACB would need to have new certification responsibilities if we
were to adopt this proposed criterion. As a result, we also proposed to
revise Sec. 170.550. This proposed revision would ensure that EHR
Modules presented for certification to certification criteria that
support MU objectives with a non-percentage-based measure are certified
to this proposed certification criterion.
Comments. We received mixed comments regarding the proposal to
adopt a new certification criterion to generate reports for non-
percentage-based EHR capabilities. Some commenters supported the new
criterion for all of the seven certification criteria we presented in
the table (79 FR 10912).\49\ However, some commenters stated that this
requirement would only be feasible or preferable for a subset of the
proposed certification criteria. One commenter opined that this
functionality was feasible for drug-drug, drug-allergy interaction
checks and CDS, but for the rest of the certification criteria, it
would be difficult to build this functionality on a user-level. Another
commenter recommended adopting this functionality only to support CDS.
One commenter recommended the requirement be that EHRs be able to
perform this function for three out of the six proposed certification
criteria to lessen the administrative burden.
---------------------------------------------------------------------------
\49\ Drug-drug, drug-allergy interaction checks; clinical
decision support; patient list creation; transmission to
immunization registries; transmission of syndromic surveillance data
to public health agencies; transmission of reportable lab tests and
values/results to public health agencies; and transmission to cancer
registries.
---------------------------------------------------------------------------
Commenters that opposed adopting the proposed criterion expressed
that the reason for not adopting this criterion in the 2014 Edition
still holds (i.e.,
[[Page 54471]]
additional specificity is needed to make the proposed criterion more
effective). Many commenters stated that providers can, and currently
do, attest to the non-percentage-based MU objectives without the EHR
having to monitor or ``police'' the provider's interactions with the
EHR. Commenters were also concerned that building this functionality
will be a major development undertaking and will have to be custom-
built for each certification criterion. Commenters provided specific
examples of the challenges in building this functionality for certain
certification criteria. For example:
For CDS interventions, EHR systems vary in their
configurations that determine how often interventions are seen. EHR
developers who currently track this information note that the data
volumes can be very large, and that retention of large volumes of data
over extended periods of time can have performance and hardware
implications.
For the public health certification criteria, it is
possible that an EHR user is connected and submitting appropriate
information but may not have submissions within a particular reporting
period. Multiple transport methods and methodologies can introduce
challenges to implementing this functionality in a standard way. What
is defined as ``ongoing submission'' can vary and human judgment is
required to make the determination (e.g., data is sent using different
procedures like real-time or periodic uploads).
Thus, some commenters were concerned that an auditor could review the
``non-percentage-based measures report'' and incorrectly conclude that
the EP, EH, or CAH failed the CDS objective if none of the implemented
CDS rules/interventions were triggered during the reporting period.
Another commenter recommended changing the regulatory text that as
proposed would require an EHR to ``electronically record evidence that
a user used or interacted with the capability . . .'' The commenter
stated that the use of the word ``evidence'' implies too strong of a
legal ramification and that the EHR can only indicate when different
features or options were triggered or activated within the EHR, but not
that a user did or did not properly act upon the MU-related feature.
A few commenters were opposed to Option 1, which would require EHR
technology to record evidence of use each time a particular capability
was used during the reporting period. One commenter stated that there
are no standards to support reporting of this type of information.
Another commenter suggested that Option 1 would result in large amounts
of data that would require additional storage space. One commenter
supported Option 2 and agreed with the need to show that certain
functionalities were enabled in the system during the reporting period.
Response. There was mixed feedback on which certification criteria
this functionality would be required to support. We agree with comments
stating that this functionality would vary in support of different
certification criteria, and believe that more work is needed to further
refine our proposal. Since the overall scope of this final rule focuses
on the adoption of a small subset of the proposed certification
criteria as optional 2014 Edition EHR certification criteria and
includes revisions to 2014 Edition EHR certification criteria that
provide flexibility, clarity, and enhance health information exchange,
we do not believe it is appropriate to adopt this new certification
criterion at this time. Our experience with the certification of EHR
technology to the 2014 Edition suggests that EHR technology developers
have already implemented or are in the process of implementing their
certified software with providers and hospitals, and it is unlikely
that EHRs would be updated with this new functionality in time to
positively affect reporting for non-percentage-based functions. Thus,
we will consider the comments received on feasibility, implementation,
the regulatory text, and frequency of recording data on use of
particular capabilities for future rulemaking concerning a ``non-
percentage-based measures report'' certification criterion.
Applicability Statement for Secure Health Transport and Delivery
Notification in Direct
We proposed to adopt a new certification criterion for electronic
sending and receiving that would enable EHR technology to be tested and
certified solely to perform ``transmissions'' in accordance with the
Applicability Statement for Secure Health Transport (the primary Direct
Project specification) adopted at Sec. 170.202(a) and its companion
implementation specification (Implementation Guide for Delivery
Notification in Direct, Version 1.0, June 29, 2012 (Delivery
Notification IG)).\50\
---------------------------------------------------------------------------
\50\ http://wiki.directproject.org/file/view/Implementation+Guide+for+Delivery+Notification+in+Direct+v1.0.pdf.
---------------------------------------------------------------------------
Comments. Some commenters supported the goal of acknowledging
receipt of the documents by the intended recipient. Commenters also
voiced concern that this was a new area of certification that lacked
HIT developer feedback and recommended that we further consider this
certification criterion before finalizing it. Other commenters stated
that the depth of information required to be reported to the sender of
information would cause significant burden on HIT developers to create
the functionality and providers and health care organizations to use
the functionality. One commenter noted that, as the market matured,
demand for this kind of functionality would increase and HIT developers
would design these functions without the need of a certification
criterion.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. We will, however,
consider comments regarding the Delivery Notification IG capabilities,
the concerns expressed by commenters, and evaluate whether the market
demand for this capability would moot the benefit that certification
could provide for proof of a consistent implementation according to the
IG as part of future rulemaking.
B. 2014 Edition and Proposed Voluntary Edition Equivalency Table
In the Proposed Rule, we provided an ``equivalency table'' (79 FR
10915-16) that identified the Proposed Voluntary Edition EHR
certification criteria that were equivalent to the 2014 Edition
certification criteria for the purposes of meeting the CEHRT
definition. There is no longer a need for an ``equivalency table''
because we have not adopted the Proposed Voluntary Edition in this
final rule. Therefore, we have not included an ``equivalency table'' in
this final rule.
C. HIT Definitions
1. CEHRT
We proposed to revise the CEHRT definition for FY/CY 2014 and
subsequent years to include reference to the Proposed Voluntary Edition
as a means of giving EPs, EHs, and CAHs the flexibility to use EHR
technology that has been certified to either the 2014 Edition or the
Proposed Voluntary
[[Page 54472]]
Edition, or a combination of both editions, to meet the CEHRT
definition for FY/CY 2014 and subsequent years.
Comments. We received many comments recommending that we do not
adopt the Proposed Voluntary Edition.
Response. We have not revised the CEHRT definition. In response to
comments recommending that we not adopt the Proposed Voluntary Edition
and for the other reasons discussed earlier in this preamble, we have
not adopted the full Proposed Voluntary Edition. Rather, we have only
adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As such, no revisions
are necessary to the CEHRT definition to account for the additional
optional 2014 Edition EHR certification criteria.
2. Common MU Data Set
We proposed to revise the Common MU Data Set definition in Sec.
170.102 by including the preferred language standard in the proposed
``demographics'' certification criterion solely for the purposes of
certifying EHR technology to the Proposed Voluntary Edition EHR
certification criteria that referenced the Common MU Data Set.
Comments. We received comments recommending that we not adopt a new
preferred language standard as well as comments on each of the
standards we proposed as the potential new preferred language standard.
Response. We have not adopted a revised or new demographics
certification criterion or a new preferred language standard consistent
with our reasons for not adopting the Proposed Voluntary Edition and
for the reasons discussed in more detail under the ``demographics''
certification criterion in section IV.A. Accordingly, we have not
finalized our proposal to revise the Common MU Data Set definition.
C. ONC HIT Certification Program
1. Non-MU EHR Technology Certification
We proposed to establish an ``MU EHR Module'' definition and a
``non-MU EHR Module'' definition under the main ``EHR Module''
definition at Sec. 170.102. We proposed to define an ``MU EHR Module''
as any service, component, or combination thereof that is designed for
purposes of the Medicare and Medicaid EHR Incentive Programs and can
meet the requirements of at least one certification criterion adopted
by the Secretary. We proposed to define a ``non-MU EHR Module'' as any
service, component, or combination thereof that is designed for any
purpose other than the Medicare and Medicaid EHR Incentive Programs and
can meet the requirements of at least one certification criterion
adopted by the Secretary. Correspondingly, we proposed to revise Sec.
170.550 to require the certification of only MU EHR Modules, as
applicable, to the Proposed Voluntary Edition ``automated numerator
recording'' certification criterion, the ``automated measure
calculation'' certification criterion, and the ``non-percentage-based
measure use report'' certification criterion.
We stated that these proposals would ensure that EHR technology
designed for MU purposes and certified to certification criteria that
include capabilities that support percentage-based and/or non-
percentage-based MU measures are capable of electronically performing
the associated recording and calculation of measure activities for MU
purposes, while permitting EHR technology that is designed for non-MU
purposes (e.g., broad electronic health information exchange or
behavioral health settings staffed mainly by MU ineligibles) to be
certified without having to include capabilities that support
percentage-based and/or non-percentage-based MU measures. These
proposals were based on our belief that EHR technology developers who
design EHR technology for non-MU purposes and settings find that the MU
measurement certification criteria requirements are unnecessary burdens
and resource investments (i.e., to have to program MU-specific rules
into their software just to get certified). Similarly, we noted that
because of the specific ways in which MU measures are structured non-MU
health care providers would find little benefit in receiving EHR
utilization reports showing MU performance. In the Proposed Rule, we
specifically requested comment on these assumptions and on how best to
implement our proposed approach if we were to adopt it in this final
rule (e.g., requested comments on what processes we should use for
testing and certification and distinguishing MU and non-MU EHR Modules
on the CHPL) (79 FR 10919-20).
Overall, as stated in the Proposed Rule, we saw these proposals as
a first step towards the expansion of the ONC HIT Certification Program
to accommodate other types of HIT (79 FR 10930). To note, as stated in
the Proposed Rule, we did not propose to apply the certification
concept of MU EHR Module and non-MU EHR Module to the 2014 Edition
because of the inconsistency and potential confusion it would create
regarding EHR Modules that have already been certified and, more
importantly, because it would be infeasible to implement for the
purposes of establishing a distinction on the CHPL in a timely manner
to avoid such potential confusion.
Comments. We received comments supporting our proposal not to
require ``non-MU'' technologies to be certified to certification
criteria designed to support MU measurement. We also received a
significant number of comments expressing concern that our proposals
would cause confusion. Commenters suggested that designations and
concepts such as ``MU,'' ``non-MU,'' and ``beyond MU purposes'' would
add complexity and confusion to an already strained marketplace. A few
commenters stated that we need to also account for non-EHR
technologies. Another commenter suggested that we not rely on
assumptions about the differences in technology needs between providers
that are eligible for MU incentive payments and those that are
ineligible. As an example, the commenter suggested that the numerator
and denominator calculations may, in fact, be useful to providers that
are not eligible for MU incentive payments for patient safety tracking
and other purposes.
Response. In consideration of comments and our overall goal to
expand the ONC HIT Certification Program to accommodate other types of
HIT, we have decided not to adopt any of these proposals. Upon further
reflection, we believe these proposals may not clearly and
appropriately move us away from a certification program currently
focused on MU. By using terminology such as ``MU'' and ``non-MU,'' we
only reinforce the MU-aspect of the ONC HIT Certification Program.
Further, as noted by commenters, our proposals could confuse providers
and may not be based on sound assumptions such as MU-ineligible
providers not finding value in some of the capabilities that support MU
measurement as noted by a commenter. Accordingly, with consideration of
comments that supported our stated goal and recommended that we address
non-EHR technologies, we will further consider how best to restructure
the ONC HIT Certification Program to move it beyond MU in preparation
for our next rulemaking. To reaffirm, as our request for comment
indicated in the Proposed Rule (79 FR 10929-30), we intend to propose
changes to the ONC HIT
[[Page 54473]]
Certification Program that will permit the certification of other types
of HIT and the certification of HIT for other specific types of health
care settings (i.e., beyond the general ambulatory and general
inpatient settings). For now, we direct stakeholders to our guidance
for EHR technology developers serving providers ineligible for the EHR
Incentive Programs titled ``Certification Guidance for EHR Technology
Developers Serving Health Care Providers Ineligible for Medicare and
Medicaid EHR Incentive Payments.''\51\
---------------------------------------------------------------------------
\51\ http://www.healthit.gov/sites/default/files/generalcertexchangeguidance_final_9-9-13.pdf.
---------------------------------------------------------------------------
2. ``Certification Packages'' for EHR Modules
We proposed to establish the concept of predefined ``certification
packages'' that would reflect groupings of certification criteria. We
stated that our proposal was intended to improve the ease with which
our regulatory concepts could be communicated to the general public and
to EHR Module purchasers. More specifically, we stated that this
concept would make it easier for stakeholders to communicate and
understand the functionality an EHR Module includes and the
certification criteria to which it is certified.
We proposed to define ``certification package'' in Sec. 170.502 as
an identified set of certification criteria adopted by the Secretary in
subpart C of part 170 that represent a specific grouping of
capabilities. For EHR Modules certified to the Proposed Voluntary
Edition, we proposed definitions in Sec. 170.502 for ``2015 Edition
Care Coordination Package'' and ``2015 Edition Patient Engagement
Package'' that each identified the set of specific certification
criteria to which an EHR Module would need to be certified, at a
minimum, in order for its EHR Module developer to represent that the
EHR Module meets the requirements of a particular package. We further
sought comment on what certification criteria should be included in the
care coordination and patient engagement packages.
We also clarified that if an EHR Module were certified to the
certification criteria included in a proposed certification package
definition, then the EHR Module developer would be able to indicate
this fact without the need for any additional determination to be made
by the ONC-ACB. However, to ensure that certification packages would be
represented accurately to potential purchasers and users of EHR
Modules, we proposed to modify Sec. 170.523(k)(1) to require ONC-ACBs
to ensure that an EHR Module developer accurately represents the
certification packages its EHR Module meets if and when the EHR Module
developer uses the certification package designation(s) on its Web site
and in marketing materials, communications statements, or other
assertions related to the EHR Module's certification. We further
clarified that the certification criteria included in a certification
package would be a minimum threshold, meaning that an EHR Module could
be certified to other certification criteria adopted by the Secretary
in subpart C of part 170 in addition to the certification criteria
included in the certification package at issue. Thus, in the event that
an EHR Module presented for certification satisfied the certification
criteria included in each of the proposed certification packages and
was also certified to other certification criteria, it could be so
indicated by the EHR Module developer to its customers.
Comments. We received only three comments that supported our
proposals. However, the commenters submitting these comments
misconstrued our proposals as either a new required type of
certification for EHR Modules to the Proposed Voluntary Edition or as
an additional requirement beyond initial certification, such as
specifically requiring additional functionality for ``care
coordination.'' All other commenters did not support our proposals.
These commenters disagreed with our rationale that our approach would
provide clarity for stakeholders. Rather, commenters stated that our
approach would cause more confusion than it would solve. Commenters
noted that one individual's definition of ``care coordination'' may not
be the same as another, which could lead to misunderstandings about
what is or is not included in the EHR technology. Commenters also noted
that there are a large number of possible combinations of certification
criteria and associated capabilities that could plausibly be called
``care coordination'' (e.g., inclusion of lab exchange certification
criteria and capabilities) and patient engagement (e.g., inclusion of
the ``clinical summary'' certification criterion). The commenters
opined that the certification criteria included in the proposed
packages seemed arbitrary and not applicable to all providers.
Commenters suggested that we focus on educating providers, particularly
those ineligible for the EHR Incentive Programs, as to what types of
certified capabilities providers should look for in a certified
technology. In this regard, one commenter suggested that we rely on and
educate more providers on our guidance titled ``Certification Guidance
for EHR Technology Developers Serving Health Care Providers Ineligible
for Medicare and Medicaid EHR Incentive Payments.'' \52\ A few
commenters also mentioned that certified technologies should be
properly labeled as to the certification criteria and associated
capabilities they include.
---------------------------------------------------------------------------
\52\ http://www.healthit.gov/sites/default/files/generalcertexchangeguidance_final_9-9-13.pdf.
---------------------------------------------------------------------------
Response. We have not finalized our proposals for the ``care
coordination'' and ``patient engagement'' packages.
We clarify that our ``certification packages'' proposals did not
require a new type of certification or additional functionality for EHR
Modules. Under the proposals, an EHR Module would not have been
required to be certified to the certification criteria specified in a
certification package, and an EHR Module could have been certified to
more certification criteria than were included in a certification
package. Our proposal was designed such that an EHR Module developer
could assert (e.g., for communications and marketing purposes) that its
EHR Module met a certification package if the EHR Module had been
certified to all of the certification criteria included in a
certification package without any additional determination made by an
ONC-ACB. However, given the comments received from commenters that
clearly understood our proposals, we have not adopted ``certification
package'' as a concept and definition in Sec. 170.502 nor have we
finalized a requirement under Sec. 170.523(k)(1) that an ONC-ACB
ensure that an EHR Module developer accurately represents the
certification packages its EHR Module meets. We agree with commenters
that our proposed ``certification packages'' could have ended up
creating more confusion than they solved, and that there are no
definitive certification criteria that meet the concept of ``care
coordination'' and ``patient engagement'' for all providers. As
recommended by commenters, we will try to further educate providers on
the capabilities included in certification criteria, the means for
determining what capabilities a certified EHR Module includes (e.g.,
utilizing the CHPL and reviewing an EHR technology developer's
communications and marketing materials, which should include a list of
the certification criteria and CQMs that the EHR Module was certified
to), and on the ``Certification Guidance for EHR Technology Developers
Serving Health Care Providers Ineligible for Medicare and
[[Page 54474]]
Medicaid EHR Incentive Payments'' guidance we issued in 2013.
V. Comments Beyond the Scope of This Final Rule
In response to the Proposed Rule, some commenters chose to raise
issues that are beyond the scope of our proposals such as encouraging
us to amend our certification criteria to include EHR accessibility for
users with disabilities. We do not summarize or respond to those
comments in this final rule. However, we will review the comments and
consider whether other actions may be necessary, such as addressing the
comments in future rulemakings.
VI. Collection of Information Requirements
This final rule contains no new collections of information under
the Paperwork Reduction Act nor does it revise any current collection
of information approved by OMB.
VII. Regulatory Impact Statement
A. Statement of Need
Consistent with EO 13563, we have completed a retrospective review
of our 2014 Edition Final Rule and the certification criteria we
adopted in that final rule. Further, consistent with EO 13563, we have
only adopted the proposed certification criteria as part of the 2014
Edition that provide regulatory flexibility and reduce regulatory
burden for stakeholders.
B. Overall Impact
We have examined the impact of this final rule as required by EO
12866 on Regulatory Planning and Review (September 30, 1993), EO 13563
on Improving Regulation and Regulatory Review (February 2, 2011), the
Regulatory Flexibility Act (5 U.S.C. 601 et seq.), section 202 of the
Unfunded Mandates Reform Act of 1995 (2 U.S.C. 1532), and EO 13132 on
Federalism (August 4, 1999).
1. Executive Orders 12866 and 13563--Regulatory Planning and Review
Analysis
EOs 12866 and 13563 direct agencies to assess all costs and
benefits of available regulatory alternatives and, if regulation is
necessary, to select regulatory approaches that maximize net benefits
(including potential economic, environmental, public health and safety
effects, distributive impacts, and equity). A regulatory impact
analysis (RIA) must be prepared for major rules with economically
significant effects ($100 million or more in any 1 year). We have
determined that this final rule is not an economically significant
rule. Related costs to prepare EHR technology and other HIT to be
tested and certified are estimated to be far less than $100 million per
year. Nevertheless, because of the public interest in this final rule,
we have prepared an RIA that to the best of our ability presents the
costs and benefits of this final rule.
a. Costs
This final rule adopts new optional certification criteria and
revised certification criteria as part of the 2014 Edition. Our
analysis focuses on the direct effects of the provisions of this final
rule--the costs incurred by EHR technology developers to develop and
prepare EHR technology to be tested and certified in accordance with
the certification criteria (and the standards and implementation
specifications they include) adopted by the Secretary. That is, we
focus on the technological development and preparation costs necessary
for EHR technology already certified to the 2014 Edition to certify to
the new optional certification criteria and revised certification
criteria and for developing new EHR technology to meet the new optional
certification criteria and revised certification criteria. The costs
for testing and certification of EHR technologies to the certification
criteria adopted in this final rule were captured in the RIA of the
Permanent Certification Program final rule as we discuss in more detail
below (VI.B.1.a.ii ``Testing and Certification Costs for the 2014
Edition Release 2''). The costs that EPs, EHs, and CAHs will incur in
adopting and implementing EHR technology certified to the certification
criteria adopted in this final rule are not within the scope of this
final rule.
i. Development and Preparation Costs for the 2014 Edition Release 2
In the Proposed Rule (79 FR 10932-36), we estimated the development
and preparation costs for the Proposed Voluntary Edition. We
categorized proposed certification criteria based on their gap
certification status (i.e., new, revised, and unchanged). We used the
total number of unique \53\ 2011 Edition Complete EHRs and EHR Modules
that were used for MU Stage 1 attestation as reported at the end of FY
2013.\54\ Using the unique number of 2011 Edition EHR technologies used
for MU Stage 1 attestation we established a range of between 20% and
40% of unique EHR technologies used for MU Stage 1 that we believed
would be developed and prepared to meet each of the certification
criteria of the Proposed Voluntary Edition. This range accounted for
potential new entrants to the market as well as those EHR technologies
used for MU Stage 1 attestation that may no longer be brought forth for
certification because of such factors as corporate re-organizations
(e.g., mergers and acquisitions) as well as the loss of market share
for some EHR technologies. The range also took into account any
potential non-MU-focused EHR technologies that will be developed and
prepared to meet the Proposed Voluntary Edition, but not designed for
MU purposes. We identified three levels of effort to associate with the
development and preparation of EHR technology to meet the requirements
of the Proposed Voluntary Edition.\55\ We based the effort levels on
the hours necessary for a software developer to develop and prepare the
EHR technology for testing and certification and calculated the average
software developer's wage with benefits at $61 per hour.\56\ We
calculated a low cost estimate, high cost estimate, and average cost
estimate for each proposed certification criterion and then estimated
the totals equally split between 2014 and 2015.\57\
---------------------------------------------------------------------------
\53\ We attempted to discern how many Complete EHRs and EHR
Modules were used that would not constitute a newer version of the
same EHR technology.
\54\ For the Proposed Voluntary Edition certification criteria
that did not have equivalent 2011 Edition EHR certification
criteria, we used the unique number for the equivalent 2014 Edition
EHR certification criteria as identified and used for the 2014
Edition Final Rule regulatory impact analysis.
\55\ 79 FR 10932-33.
\56\ 79 FR 10933.
\57\ 79 FR 10933-36.
---------------------------------------------------------------------------
Comments. We received very limited comments on our proposed impact
analysis, all of which came from EHR technology developers and
reiterated the detailed comment that came from the Electronic Health
Record Association (EHRA). In its comments, the EHRA presented average
hourly burden estimates that would be incurred by an EHR technology
developer per proposed certification criterion. The EHRA indicated that
its estimates presumed a product was already certified to 2014 Edition
certification criteria and included ``research, planning and design,
development, testing, usability testing, documentation, release, and
certification effort.'' Additionally, a follow-up request for
clarification and fact finding indicated that these hourly estimates
included an average of 2.5 products per EHR technology developer that
would be certified to the certification criteria of the Proposed
Voluntary Edition. Overall, the EHRA
[[Page 54475]]
generally concluded that we had, in most cases, significantly
underestimated the hourly burden associated with the proposed
certification criteria and provided a detailed chart identifying the
potential discrepancies.
Response. We appreciate the detailed response provided by the EHR
technology developer community. In reviewing the provided comments, it
became clear that the way in which we were presenting the calculation
of our impacts in the preamble and the way in which EHR technology
developers think about the impacts were different. In other words, our
approach in the Proposed Rule was to assign burden hours to each
certified product listed on the CHPL by certification criterion and we
never provided a ``per EHR technology developer'' estimate. However, in
contrast, the EHRA estimates were burden hours by EHR technology
developer for each certification criterion.
On face value, for example, if one were to compare the ``Level 2
range'' we included in the Proposed Rule of 100-300 hours without
multiplying by the number of products on the CHPL attributable to a
particular EHR technology developer it would appear that we did
significantly underestimate the burden. However, if one were to
multiply that 100-300 hour range by the number of products attributable
to a particular EHR technology developer and that were certified to the
certification criterion in question a potentially narrower gap in the
estimates could result.
After considering these comments, we believe that a more direct way
for this final rule and for future rulemakings to identify burden will
be to identify hourly burden estimates for each certification criterion
by EHR technology developer. Given the reduced scope of this final
rule, we do not include hourly cost estimates for certification
criteria that we are not finalizing. Table 4 indicates only the
regulatory changes we have finalized for the adopted certification
criteria and our hourly burden estimate range for each of the changes
by EHR technology developer.
We also include an estimated number of EHR technology developers
that we believe will seek certification to these certification criteria
(and built into this assumption is that they would be presenting on
average 3 products for certification, similar to EHRA's number). To
arrive at this estimate, we analyzed available CHPL data from mid-May
of this year for 2014 Edition certifications. From this data, we
determined how many EHR technology developers had at least one product
certified to the adopted 2014 Edition. From the group of EHR technology
developers with a product certified to the 2014 Edition, we estimate
that no more than 20% of those developers will seek certification
because of the reduced and specific scope of this final rule. We also
believe that for some certification criteria the 20% estimate could be
a substantial overestimation. We provide a more detailed criterion-by-
criterion explanation of our estimates below in Table 4.
Additionally, despite the specificity included in the EHRA
estimates, we have found from past experience that at times EHR
technology developers have misinterpreted what we have proposed. The
EHRA's comments noted this kind of discrepancy by stating for certain
certification criteria that some of its members interpreted the burden
to be reasonably low while others very high. Given that we have no
other comments by which to compare the EHRA estimates, we have
generally used the EHRA estimate as our ``high average'' rounded up or
down to the nearest hundred hours.
Table 4--Development and Preparation Costs for EHR Technology Developers for Adopted Certification Criteria
----------------------------------------------------------------------------------------------------------------
Number of EHR Hourly development effort by
developers who EHR developer
Certification develop -------------------------------
Item # CFR Text criterion name product(s) for
certification Low avg High avg
to criterion
----------------------------------------------------------------------------------------------------------------
1.................... Sec. CPOE--medications.. 33 0 100
170.314(a)(18).
2.................... Sec. CPOE--laboratory... 33 0 100
170.314(a)(19).
3.................... Sec. CPOE--diagnostic 33 0 100
170.314(a)(20). imaging.
4.................... Sec. 170.314(b)(8) Transitions of care 29 400 600
5.................... Sec. 170.314(b)(9) Clinical 27 0 100
information
reconciliation and
incorporation.
6.................... Sec. 170.314(e)(1) View, download, and 33 400 600
transmit to 3rd
party.
7.................... Sec. 170.314(f)(7) Transmission to 25 0 100
public health
agencies--syndromi
c surveillance.
8.................... Sec. 170.314(g)(1) Automated numerator N/A N/A N/A
recording.
9.................... Sec. 170.314(g)(3) Safety-enhanced 77 0 100
design.
10................... Sec. 170.314(h)(1) Applicability 33 300 500
Statement for
Secure Health
Transport.
11................... Sec. 170.314(h)(2) Applicability 33 200 300
Statement for
Secure Health
Transport & XDR/
XDM for Direct
Messaging.
12................... Sec. 170.314(h)(3) SOAP Transport and 33 200 300
Security
Specification &
XDR/XDM for Direct
Messaging.
----------------------------------------------------------------------------------------------------------------
Items #1 through #3: With the exception of splitting out
the three CPOE order type functionalities, there are no new
requirements as part of any of these three certification criteria in
this final rule. As a result, we provided a low range estimate.
Item #4: For this certification criterion, the only
substantial new development change between it and the 2014 Edition
certification criteria at Sec. 170.314(b)(1) and (2) is the addition
of the Direct Edge Protocols IG. The EHRA estimates did not clearly
identify whether the hourly range of 1,380 hours was to implement all
four edge protocols or some number of them. Regardless, given that we
only require one for certification, we have more than halved the EHRA
estimate to fall into a range that we believe would be more reflective
of the burden imposed by the final certification criterion.
Item #5: The EHRA did not provide any hourly estimate for
new development, nor does this criterion substantively differ from
already
[[Page 54476]]
required capabilities in the 2014 Edition. As a result, we provided a
low estimate.
Item #6: For this certification criterion, the only
substantial new development change between it and the original 2014
Edition version is the addition of the IG for Direct Edge Protocols. As
a result, our estimates are the same as for Item #4.
Item #7: Given the adoption of this more general
certification criterion, we have provided a low estimate.
Item # 8: This certification criterion was simply changed
to an ``optional'' designation to provide regulatory clarity for
Complete EHR certification to the 2014 Edition. There should be no new
cost estimates related to certification as this regulatory change
simply implements ONC Regulation FAQ 28 as discussed in section III.B.3
of the preamble.
Item # 9: This certification criterion now includes the
adopted optional CPOE and CIRI certification criteria. We have
estimated a low cost range because we anticipate that EHR technology
developers will use the same SED practices they used for certification
to the CPOE (Sec. 170.314(a)(1)) and CIR (Sec. 170.314(b)(4))
certification criteria. Additionally, we note that we do not believe
that there will be 99 different EHR technology developers that will get
certified to the three CPOE criteria (i.e., 33 + 33 + 33). We expect
that there will be overlap (i.e., multiple EHR technology developers
getting certified to more than one CPOE certification criterion) and
that some EHR technology developers will only get certified to one CPOE
certification criterion such as CPOE--medications or CPOE--laboratory.
Therefore, we estimate that there will be no more than 50 EHR
technology developers that are certified to the SED certification
criterion based on certification to the new optional CPOE certification
criteria. We have combined this estimated number with the number of EHR
technology developers we have estimated for the CIRI certification
criterion to get an estimated total for this certification criterion.
Items #10-12: We provide estimates reasonably close to the
EHRA estimates.
Table 5 includes an overall 2-year cost estimate for each
criterion. We retain the 2-year cost estimate period (CY 2014 and CY
2015) for the reason provided in the Proposed Rule as they would
similarly apply to the adopted optional and revised 2014 Edition
certification criteria. Additionally, we retain and use the estimate of
$61 per hour (with benefits) as the average software developer's wage.
Table 5--Distributed Total Development and Preparation Costs for EHR Technology Developers (Two-Year Period)--
Totals Rounded
----------------------------------------------------------------------------------------------------------------
Total high Total average
Item # CFR Text Certification Total low cost cost estimate cost estimate
criterion name estimate ($M) ($M) ($M)
----------------------------------------------------------------------------------------------------------------
1............................ Sec. CPOE--medicatio $0 $.2 $.1
170.314(a)(18). ns.
2............................ Sec. CPOE--laborator 0 .2 .1
170.314(a)(19). y.
3............................ Sec. CPOE--diagnosti 0 .2 .1
170.314(a)(20). c imaging.
4............................ Sec. Transitions of .71 1.0 .89
170.314(b)(8). care.
5............................ Sec. Clinical 0 .16 .081
170.314(b)(9). information
reconciliation
and
incorporation.
6............................ Sec. View, download, .81 1.22 1.0
170.314(e)(1). and transmit
to 3rd party.
7............................ Sec. Transmission to 0 .15 .077
170.314(f)(7). public health
agencies--synd
romic
surveillance.
8............................ Sec. Automated N/A N/A N/A
170.314(g)(1). numerator
recording.
9............................ Sec. Safety-enhanced 0 .47 .235
170.314(g)(3). design.
10........................... Sec. Applicability .6 1.0 .8
170.314(h)(1). Statement for
Secure Health
Transport.
11........................... Sec. Applicability .4 .6 .5
170.314(h)(2). Statement for
Secure Health
Transport &
XDR/XDM for
Direct
Messaging.
12........................... Sec. SOAP Transport .4 .6 .5
170.314(h)(3). and Security
Specification
& XDR/XDM for
Direct
Messaging.
2-Year Total............. ................ ............... 2.92 5.80 4.38
2014 total (50%)......... ................ ............... 1.46 2.90 2.19
2015 total (50%)......... ................ ............... 1.46 2.90 2.19
----------------------------------------------------------------------------------------------------------------
iii. Testing and Certification Costs for the 2014 Edition Release 2
In the RIA of the Permanent Certification Program final rule, we
estimated the costs for testing and certification of EHR technologies
that would be used for providers to attempt to achieve MU Stages 1-
3.\58\ These costs were based on a two-year rulemaking cycle for the
CEHRT definition and each MU stage. We believe the costs we attributed
to testing and certification of EHR technologies in support of MU Stage
2 in the Permanent Certification Program final rule would encompass the
actual testing and certification of EHR technologies to both the 2014
Edition and the certification criteria we have adopted as part of the
2014 Edition Release 2. This assessment is based on the number of EHR
technologies currently certified to the 2014 Edition and our
projections for the number of EHR technology developers that would
likely have their EHR technologies tested and certified to the optional
and revised 2014 Edition certification criteria adopted in this final
rule. Further, we note that the estimated costs in the Permanent
Certification Program final rule included costs for surveillance of EHR
technologies and also estimated the costs for testing and certification
above what we understand are the cost ranges charged by ONC-ACBs today.
---------------------------------------------------------------------------
\58\ 76 FR 1318.
---------------------------------------------------------------------------
b. Benefits
The regulatory flexibility the 2014 Edition Release 2 certification
criteria provide will offer several significant benefits to patients,
health care providers, and HIT developers. The 2014 Edition Release 2
incorporates stakeholder feedback on particular 2014 Edition issues
identified as unnecessarily impeding innovation and causing undue
burden. The 2014 Edition Release 2 also seeks to continue to improve
EHR technology's interoperability and electronic health
[[Page 54477]]
information exchange. Specifically, the separating out of the
``content'' and ``transport'' capabilities in the optional 2014 Edition
ToC certification criterion (compared to the 2014 Edition ToC
certification criteria adopted at Sec. 170.314(b)(1) and (2)) and
adoption of the Edge Protocol IG is aimed at improving the market
availability of electronic health information exchange services. The
new certification flexibilities offered by the optional ``CPOE'' and
optional ``syndromic surveillance'' certification criteria are designed
to enhance innovation and offer providers enhanced functionality and
options for meeting applicable MU measures. The new flexibility in the
VDT certification criterion is designed to further facilitate the
exchange of patient health information between provider and patient.
The optional CIRI criterion is designed to align better with clinical
workflows and reduce regulatory burden found in certification to the
current ToC certification criterion at Sec. 170.314(b)(1).
2. Regulatory Flexibility Act (RFA)
The RFA requires agencies to analyze options for regulatory relief
of small businesses if a rule has a significant impact on a substantial
number of small entities.
The Small Business Administration (SBA) establishes the size of
small businesses for federal government programs based on average
annual receipts or the average employment of a firm. While EHR
technology developers that pursue certification under the ONC HIT
Certification Program represent a small segment of the overall
information technology industry, we believe that the entities impacted
by this final rule most likely fall under the North American Industry
Classification System (NAICS) code 541511 ``Custom Computer Programming
Services'' specified at 13 CFR 121.201 where the SBA publishes ``Small
Business Size Standards by NAICS Industry.'' The SBA size standard
associated with this NAICS code is set at $25 million in annual
receipts \59\ which ``indicates the maximum allowed for a concern and
its affiliates to be considered small entities.''
---------------------------------------------------------------------------
\59\ The SBA references that annual receipts means ``total
income'' (or in the case of a sole proprietorship, ``gross income'')
plus ``cost of goods sold'' as these terms are defined and reported
on Internal Revenue Service tax return forms. http://www.sba.gov/sites/default/files/files/Size_Standards_Table.pdf.
---------------------------------------------------------------------------
Based on our analysis, we believe that there is enough data
generally available to establish that between 75% and 90% of entities
that are categorized under the NAICS code 541511 are under the SBA size
standard, but note that the available data does not show how many of
these entities will develop a EHR product that will be certified to the
optional 2014 Edition Release 2 certification criteria under the ONC
HIT Certification Program. We also note that with the exception of
aggregate business information available through the U.S. Census Bureau
and the SBA related to NAICS code 541511, it appears that many EHR
technology developers that pursue certification under the ONC HIT
Certification Program are privately held or owned and do not regularly,
if at all, make their specific annual receipts publicly available. As a
result, it is difficult to locate empirical data related to many of
these EHR technology developers to correlate to the SBA size standard.
However, although not correlated to the size standard for NAICS code
541511, we do have information indicating that over 60% of EHR
technology developers that have had Complete EHRs and/or EHR Modules
certified to the 2011 Edition EHR certification criteria have less than
51 employees.
We estimate that this final rule would have effects on EHR
technology developers that are likely to pursue certification under the
ONC HIT Certification Program, some of which may be small entities.
However, we believe that we have proposed the minimum amount of
requirements necessary to accomplish our policy goals, including a
reduction in regulatory burden and additional flexibility for the
regulated community, and that no additional appropriate regulatory
alternatives could be developed to lessen the compliance burden
associated with this final rule. We note that this final rule does not
impose the costs cited in the RIA as compliance costs, but rather as
investments which these EHR technology developers voluntarily take on
and expect to recover with an appropriate rate of return. Accordingly,
we do not find that this final rule will create a significant impact on
a substantial number of small entities. Additionally, the Secretary
certifies that this final rule will not have a significant impact on a
substantial number of small entities.
3. Executive Order 13132--Federalism
Executive Order 13132 establishes certain requirements that an
agency must meet when it promulgates a proposed rule (and subsequent
final rule) that imposes substantial direct requirement costs on state
and local governments, preempts state law, or otherwise has federalism
implications. Nothing in this final rule imposes substantial direct
compliance costs on state and local governments, preempts state law or
otherwise has federalism implications. We are not aware of any state
laws or regulations that are contradicted or impeded by any of the
certification criteria or other proposals we have adopted in this final
rule.
4. Unfunded Mandates Reform Act of 1995
Section 202 of the Unfunded Mandates Reform Act of 1995 requires
that agencies assess anticipated costs and benefits before issuing any
rule whose mandates require spending in any one year of $100 million in
1995 dollars, updated annually for inflation. The current inflation-
adjusted statutory threshold is approximately $141 million. This final
rule will not impose an unfunded mandate on state, local, and tribal
governments or on the private sector that will reach the threshold
level.
Regulation Text
List of Subjects in 45 CFR Part 170
Computer technology, Electronic health record, Electronic
information system, Electronic transactions, Health, Health care,
Health information technology, Health insurance, Health records,
Hospitals, Incorporation by reference, Laboratories, Medicaid,
Medicare, Privacy, Reporting and recordkeeping requirements, Public
health, Security.
For the reasons set forth in the preamble, 45 CFR subtitle A,
subchapter D, part 170, is amended as follows:
PART 170--HEALTH INFORMATION TECHNOLOGY STANDARDS, IMPLEMENTATION
SPECIFICATIONS, AND CERTIFICATION CRITERIA AND CERTIFICATION
PROGRAMS FOR HEALTH INFORMATION TECHNOLOGY
0
1. The authority citation for part 170 continues to read as follows:
Authority: 42 U.S.C. 300jj-11; 42 U.S.C. 300jj-14; 5 U.S.C.
552.
0
2. Section 170.102 is amended by revising the definition for ``Base
EHR'' to read as follows:
Sec. 170.102 Definitions.
* * * * *
Base EHR means an electronic record of health-related information
on an individual that:
(1) Includes patient demographic and clinical health information,
such as medical history and problem lists;
[[Page 54478]]
(2) Has the capacity:
(i) To provide clinical decision support;
(ii) To support physician order entry;
(iii) To capture and query information relevant to health care
quality;
(iv) To exchange electronic health information with, and integrate
such information from other sources;
(v) To protect the confidentiality, integrity, and availability of
health information stored and exchanged; and
(3) Has been certified to the certification criteria adopted by the
Secretary:
(i) For at least one of the four criteria adopted at Sec.
170.314(a)(1), (a)(18), (a)(19), or (a)(20);
(ii) At Sec. 170.314(a)(3);
(iii) At Sec. 170.314(a)(5) through Sec. 170.314(a)(8);
(iv) Both Sec. 170.314(b)(1) and (2); or, both Sec. 170.314(b)(8)
and Sec. 170.314(h)(1); or Sec. 170.314(b)(1) and (2) combined with
either Sec. 170.314(b)(8) or Sec. 170.314(h)(1), or both Sec.
170.314(b)(8) and Sec. 170.314(h)(1);
(v) At Sec. 170.314(b)(7);
(vi) At Sec. 170.314(c)(1) through Sec. 170.314(c)(3);
(vii) At Sec. 170.314(d)(1) through Sec. 170.314(d)(8);
(4) Has been certified to the certification criteria at Sec.
170.314(c)(1) and (2):
(i) For no fewer than 9 clinical quality measures covering at least
3 domains from the set selected by CMS for eligible professionals,
including at least 6 clinical quality measures from the recommended
core set identified by CMS; or
(ii) For no fewer than 16 clinical quality measures covering at
least 3 domains from the set selected by CMS for eligible hospitals and
critical access hospitals.
* * * * *
Sec. 170.102 [Amended]
0
3. Section 170.102 is further amended, effective March 1, 2015, by
removing the definitions of ``2011 Edition EHR certification criteria''
and ``Complete EHR, 2011 Edition.''
0
4. Section 170.202 is amended by adding paragraph (d) to read as
follows:
Sec. 170.202 Transport standards.
* * * * *
(d) Standard. ONC Implementation Guide for Direct Edge Protocols
(incorporated by reference in Sec. 170.299).
Sec. 170.205 [Amended]
0
5. Section 170.205 is amended, effective March 1, 2015, by removing and
reserving paragraphs (b)(1), (c), (d)(1), (e)(1) and (2), and (f).
Sec. 170.207 [Amended]
0
6. Section 170.207 is amended, effective March 1, 2015, by removing and
reserving paragraphs (a)(1) and (2), (b)(1), (c)(1), (d)(1), and
(e)(1).
Sec. 170.210 [Amended]
0
7. Section 170.210 is amended, effective March 1, 2015, by removing and
reserving paragraphs (a)(2) and (b).
0
8. Section 170.299 is amended by adding paragraph (k)(4) to read as
follows:
Sec. 170.299 Incorporation by reference.
* * * * *
(k) * * *
(4) ONC Implementation Guide for Direct Edge Protocols, Version
1.1, June 25, 2014, IBR approved for Sec. 170.202; available at http://www.healthit.gov/sites/default/files/implementationguidefordirectedgeprotocolsv1_1.pdf.
* * * * *
Sec. 170.302 [Removed and Reserved]
0
9. Section 170.302 is removed and reserved, effective March 1, 2015.
Sec. 170.304 [Removed and Reserved]
0
10. Section 170.304 is removed and reserved, effective March 1, 2015.
Sec. 170.306 [Removed and Reserved]
0
11. Section 170.306 is removed and reserved, effective March 1, 2015.
0
12. Section 170.314 is amended by:
0
a. Revising paragraph (a)(1)(iii);
0
b. Adding paragraphs (a)(18) through (20) and (b)(8) and (9);
0
c. Revising paragraphs (e)(1)(i)(C)(1) and (2);
0
d. Adding paragraph (f)(7);
0
e. Revising paragraphs (g)(1) and (3); and
0
f. Adding paragraph (h).
The revisions and additions read as follows:
Sec. 170.314 2014 Edition electronic health record certification
criteria.
* * * * *
(a) * * *
(1) * * *
(iii) Diagnostic imaging.
* * * * *
(18) Optional--computerized provider order entry--medications.
Enable a user to electronically record, change, and access medication
orders.
(19) Optional--computerized provider order entry--laboratory.
Enable a user to electronically record, change, and access laboratory
orders.
(20) Optional--computerized provider order entry--diagnostic
imaging. Enable a user to electronically record, change, and access
diagnostic imaging orders.
(b) * * *
(8) Optional--Transitions of care. (i) Send and receive via edge
protocol. EHR technology must be able to electronically:
(A) Send transitions of care/referral summaries through a method
that conforms to the standard specified at Sec. 170.202(d) and that
leads to such summaries being processed by a service that has
implemented the standard specified in Sec. 170.202(a); and
(B) Receive transitions of care/referral summaries through a method
that conforms to the standard specified at Sec. 170.202(d) from a
service that has implemented the standard specified in Sec.
170.202(a).
(ii)(A) Display. EHR technology must be able to electronically
display in human readable format the data included in transition of
care/referral summaries received and formatted according to any of the
following standards (and applicable implementation specifications)
specified in: Sec. 170.205(a)(1) through (3).
(B) Section views. Extract and allow for individual display each
additional section or sections (and the accompanying document header
information) that were included in a transition of care/referral
summary received and formatted in accordance with the standard adopted
at Sec. 170.205(a)(3).
(iii) Create. Enable a user to electronically create a transition
of care/referral summary formatted according to the standard adopted at
Sec. 170.205(a)(3) that includes, at a minimum, the Common MU Data Set
and the following data expressed, where applicable, according to the
specified standard(s):
(A) Encounter diagnoses. The standard specified in Sec. 170.207(i)
or, at a minimum, the version of the standard specified Sec.
170.207(a)(3);
(B) Immunizations. The standard specified in Sec. 170.207(e)(2);
(C) Cognitive status;
(D) Functional status;
(E) Ambulatory setting only. The reason for referral; and referring
or transitioning provider's name and office contact information; and
(F) Inpatient setting only. Discharge instructions.
(9) Optional--clinical information reconciliation and
incorporation--(i) Correct patient. Upon receipt of a transition of
care/referral summary formatted according to the standard adopted at
Sec. 170.205(a)(3), EHR technology must be able to demonstrate that
the transition of care/referral summary received is or can be properly
matched to the correct patient.
[[Page 54479]]
(ii) Reconciliation. Enable a user to electronically reconcile the
data that represent a patient's active medication, problem, and
medication allergy list as follows. For each list type:
(A) Electronically and simultaneously display (i.e., in a single
view) the data from at least two list sources in a manner that allows a
user to view the data and their attributes, which must include, at a
minimum, the source and last modification date;
(B) Enable a user to create a single reconciled list of
medications, medication allergies, or problems;
(C) Enable a user to review and validate the accuracy of a final
set of data; and
(D) Upon a user's confirmation, automatically update the list, and
electronically incorporate the following data expressed according to
the specified standard(s):
(1) Medications. At a minimum, the version of the standard
specified in Sec. 170.207(d)(2);
(2) Problems. At a minimum, the version of the standard specified
in Sec. 170.207(a)(3);
(3) Medication allergies. At a minimum, the version of the standard
specified in Sec. 170.207(d)(2).
* * * * *
(e) * * *
(1) * * *
(i) * * *
(C) * * *
(1) Electronically transmit the ambulatory summary or inpatient
summary (as applicable to the EHR technology setting for which
certification is requested) created in paragraph (e)(1)(i)(B)(1) of
this section in accordance with at least one of the following:
(i) The standard specified in Sec. 170.202(a).
(ii) Through a method that conforms to the standard specified at
Sec. 170.202(d) and that leads to such summary being processed by a
service that has implemented the standard specified in Sec.
170.202(a).
(2) Inpatient setting only. Electronically transmit transition of
care/referral summaries (as a result of a transition of care/referral)
selected by the patient (or their authorized representative) in
accordance with at least one of the following:
(i) The standard specified in Sec. 170.202(a).
(ii) Through a method that conforms to the standard specified at
Sec. 170.202(d) and that leads to such summary being processed by a
service that has implemented the standard specified in Sec.
170.202(a).
* * * * *
(f) * * *
(7) Optional--Ambulatory setting only--Transmission to public
health agencies--syndromic surveillance. EHR technology must be able to
electronically create syndrome-based public health surveillance
information for electronic transmission.
(i) Optional. That contains the following data:
(A) Patient demographics;
(B) Provider specialty;
(C) Provider address;
(D) Problem list;
(E) Vital signs;
(F) Laboratory test values/results;
(G) Procedures;
(H) Medication list; and
(I) Insurance.
(ii) [Reserved]
(g) * * *
(1) Optional--Automated numerator recording. For each meaningful
use objective with a percentage-based measure, EHR technology must be
able to create a report or file that enables a user to review the
patients or actions that would make the patient or action eligible to
be included in the measure's numerator. The information in the report
or file created must be of sufficient detail such that it enables a
user to match those patients or actions to meet the measure's
denominator limitations when necessary to generate an accurate
percentage.
* * * * *
(3) Safety-enhanced design. User-centered design processes must be
applied to each capability an EHR technology includes that is specified
in the following certification criteria: Sec. 170.314(a)(1), (2), (6)
through (8), (16) and (18) through (20) and (b)(3), (4), and (9).
* * * * *
(h) Transport methods--(1) Optional--Applicability Statement for
Secure Health Transport. Enable health information to be electronically
sent and electronically received in accordance with the standard
specified in Sec. 170.202(a).
(2) Optional--Applicability Statement for Secure Health Transport
and XDR/XDM for Direct Messaging. Enable health information to be
electronically sent and electronically received in accordance with the
standards specified in Sec. 170.202(a) and (b).
(3) Optional--SOAP Transport and Security Specification and XDR/XDM
for Direct Messaging. Enable health information to be electronically
sent and electronically received in accordance with the standards
specified in Sec. 170.202(b) and (c).
Subpart D--[Removed and Reserved]
0
13. Remove and reserve subpart D, consisting of Sec. Sec. 170.400
through 170.499.
0
14. Section 170.501 is amended by designating the existing text as
paragraph (a) and by adding paragraph (b) to read as follows:
Sec. 170.501 Applicability.
* * * * *
(b) References to the term Complete EHR and Complete EHR
certification throughout this subpart do not apply to certification in
accordance with any edition of certification criteria that is adopted
by the Secretary under subpart C after the 2014 Edition EHR
certification criteria.
0
15. Section 170.503 is amended by revising paragraphs (b)(1) and (e)(1)
and (2) to read as follows:
Sec. 170.503 Requests for ONC-AA status and ONC-AA ongoing
responsibilities.
* * * * *
(b) * * *
(1) A detailed description of the accreditation organization's
conformance to ISO/IEC17011 (incorporated by reference in Sec.
170.599) and experience evaluating the conformance of certification
bodies to ISO/IEC 17065 (incorporated by reference in Sec. 170.599).
* * * * *
(e) * * *
(1) Maintain conformance with ISO/IEC 17011 (incorporated by
reference in Sec. 170.599);
(2) Verify that the certification bodies it accredits and ONC-ACBs
conform to, at a minimum:
(i) For fiscal years 2014 and 2015, ISO/IEC Guide 65 (incorporated
by reference in Sec. 170.599); and
(ii) For fiscal year 2016 and subsequent years, ISO/IEC 17065
(incorporated by reference in Sec. 170.599).
* * * * *
0
16. Section 170.523 is amended by adding paragraph (l) to read as
follows:
Sec. 170.523 Principles of proper conduct for ONC-ACBs.
* * * * *
(l) Display the ONC Certified HIT Certification and Design Mark on
all certifications issued under the ONC HIT Certification Program in a
manner that complies with the Criteria and Terms of Use for the ONC
Certified HIT Certification and Design Mark, and ensure that use of the
mark by HIT developers whose products are certified under the ONC HIT
Certification Program is compliant with the Criteria
[[Page 54480]]
and Terms of Use for the ONC Certified HIT Certification and Design
Mark.
0
17. Section 170.550 is amended by revising paragraph (f)(1) to read as
follows:
Sec. 170.550 EHR Module certification.
* * * * *
(f) * * *
(1) Section 170.314(g)(1) or (2) if the EHR Module has capabilities
presented for certification that would support a meaningful use
objective with a percentage-based measure;
* * * * *
Sec. 170.550 [Amended]
0
18. Section 170.550 is further amended, effective March 1, 2015, by
removing and reserving paragraph (e).
0
19. Section 170.599 is amended by revising paragraphs (b)(1) and (2)
and adding paragraph (b)(3) to read as follows:
Sec. 170.599 Incorporation by reference.
* * * * *
(b) * * *
(1) ISO/IEC 17011:2004 Conformity Assessment--General Requirements
for Accreditation Bodies Accrediting Conformity Assessment Bodies
(Corrected Version), February 15, 2005, ``ISO/IEC 17011,'' IBR approved
for Sec. 170.503.
(2) ISO/IEC GUIDE 65:1996--General Requirements for Bodies
Operating Product Certification Systems (First Edition), 1996, ``ISO/
IEC Guide 65,'' IBR approved for Sec. 170.503.
(3) ISO/IEC 17065:2012(E)--Conformity assessment--Requirements for
bodies certifying products, processes and services (First Edition),
2012, ``ISO/IEC 17065,'' IBR approved for Sec. 170.503.
Dated: August 20, 2014.
Sylvia M. Burwell,
Secretary.
[FR Doc. 2014-21633 Filed 9-10-14; 8:45 am]
BILLING CODE 4150-45-P