[Federal Register Volume 77, Number 171 (Tuesday, September 4, 2012)]
[Rules and Regulations]
[Pages 54163-54292]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2012-20982]
[[Page 54163]]
-----------------------------------------------------------------------
DEPARTMENT OF HEALTH AND HUMAN SERVICES
Office of the Secretary
45 CFR Part 170
RIN 0991-AB82
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
AGENCY: Office of the National Coordinator for Health Information
Technology (ONC), Department of Health and Human Services.
ACTION: Final rule.
-----------------------------------------------------------------------
SUMMARY: With this final rule, the Secretary of Health and Human
Services adopts certification criteria that establish the technical
capabilities and specify the related standards and implementation
specifications that Certified Electronic Health Record (EHR) Technology
will need to include to, at a minimum, support the achievement of
meaningful use by eligible professionals, eligible hospitals, and
critical access hospitals under the Medicare and Medicaid EHR Incentive
Programs beginning with the EHR reporting periods in fiscal year and
calendar year 2014. This final rule also makes changes to the permanent
certification program for health information technology, including
changing the program's name to the ONC HIT Certification Program.
DATES: These regulations are effective October 4, 2012. The
incorporation by reference of certain publications listed in the rule
is approved by the Director of the Federal Register as of October 4,
2012.
FOR FURTHER INFORMATION CONTACT: Steven Posnack, Director, Federal
Policy Division, Office of Policy and Planning, Office of the National
Coordinator for Health Information Technology, 202-690-7151.
SUPPLEMENTARY INFORMATION: This final rule is issued under section 3004
of the Public Health Service Act.
Commonly Used Acronyms
CAH Critical Access Hospital
CDA Clinical Document Architecture
CDC Centers for Disease Control and Prevention
CDS Clinical Decision Support
CEHRT Certified EHR Technology
CFR Code of Federal Regulations
CHPL Certified HIT Products List
CMS Centers for Medicare & Medicaid Services
CQM Clinical Quality Measure
CY Calendar Year
EH Eligible Hospital
EHR Electronic Health Record
EP Eligible Professional
FY Fiscal Year
HHS Department of Health and Human Services
HIPAA Health Insurance Portability and Accountability Act of 1996
HIT Health Information Technology
HITECH Health Information Technology for Economic and Clinical
Health
HITPC HIT Policy Committee
HITSC HIT Standards Committee
HL7 Health Level Seven
ICD-9-CM International Classification of Diseases, 9th Revision,
Clinical Modification
ICD-10 International Classification of Diseases, 10th Revision
ICD-10-CM International Classification of Diseases, 10th Revision,
Clinical Modification
ICD-10-PCS International Classification of Diseases, 10th Revision,
Procedure Coding System
IHE Integrating the Healthcare Enterprise[supreg]
LOINC[supreg] Logical Observation Identifiers Names and Codes
MU Meaningful Use
ONC Office of the National Coordinator of 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
I. Executive Summary
A. Purpose of Regulatory Action
B. Summary of Major Provisions
1. Overview of the 2014 Edition EHR Certification Criteria
2. Certified EHR Technology
3. 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. Medicare and Medicaid EHR Incentive Programs Rules
3. HIT Certification Programs Rules
III. Provisions of the Final Rule Affecting Standards,
Implementation Specifications and Certification Criteria
A. 2014 Edition EHR Certification Criteria
1. Certification Criteria Relationship to MU
2. Applicability
3. Scope of a Certification Criterion for Certification
4. Explanation and Revision of Terms Used in Certification
Criteria
5. Consensus-Based Standards
6. Adopting Versions of Standards
7. Display of Vocabulary Standards
8. Common Data Elements in Certification Criteria
9. New Certification Criteria
a. Ambulatory and Inpatient Setting
b. Ambulatory Setting
c. Inpatient Setting
10. Revised Certification Criteria
a. Ambulatory and Inpatient Setting
b. Ambulatory Setting
c. Inpatient Setting
11. Unchanged Certification Criteria
a. Refinements to Unchanged Certification Criteria
b. Unchanged Certification Criteria Without Refinements
12. Gap Certification
13. ``Disability'' Status
B. Redefining Certified EHR Technology and Related Terms
1. Certified EHR Technology (CEHRT) Definition
2. Base EHR Definition
3. Complete EHR Definition
4. Certifications Issued for Complete EHRs and EHR Modules
5. Adaptations of Certified Complete EHRs or Certified EHR
Modules
IV. Provisions of the Final Rule Affecting the Permanent
Certification Program for HIT (``ONC HIT Certification Program'')
A. Program Name Change
B. ``Minimum Standards'' Code Sets
C. Revisions to EHR Module Certification Requirements
1. Privacy and Security Certification
2. Certification to Certain New Certification Criteria
D. ONC-ACB Reporting Requirements
E. Continuation and Representation of Certified Status
1. 2011 or 2014 Edition EHR Certification Criteria Compliant
2. Updating a Certification
3. Representation of Meeting the Base EHR Definition
F. EHR Technology Price Transparency
G. Certification and Certification Criteria for Other Health
Care Settings
V. Collection of Information Requirements
VI. Regulatory Impact Statement
A. Statement of Need
B. Overall Impact
1. Comment and Response
2. Executive Orders 12866 and 13563--Regulatory Planning and
Review Analysis
a. Costs
i. Development and Preparation Costs for 2014 Edition EHR
Certification Criteria
ii. Overall Development and Preparation Estimated Costs Over a
3-Year Period
iii. Costs for Reporting Test Results Hyperlinks
b. Benefits
3. Regulatory Flexibility Act Analysis
4. Executive Order 13132--Federalism
5. Unfunded Mandates Reform Act of 1995
Regulation Text
I. Executive Summary
A. Purpose of Regulatory Action
The HIT Standards Committee (HITSC) issued recommendations for
standards, implementation specifications, and certification criteria to
the National Coordinator for Health Information Technology (the
National Coordinator) on September 28, 2011 and
[[Page 54164]]
October 21, 2011. In fulfilling his duties under sections 3001(c)(1)(A)
and (B) of the Public Health Service Act (PHSA), the National
Coordinator reviewed the recommendations made by the HITSC, endorsed
certain standards, implementation specifications, and certification
criteria, and reported his determinations to the Secretary for
consideration. On March 7, 2012, the Secretary published a proposed
rule (77 FR 13832) with her determinations regarding the standards,
implementation specifications, and certification criteria endorsed by
the National Coordinator, as required by section 3004(a)(3) of the
PHSA. The proposed rule solicited public comment on the standards,
implementation specifications, and certification criteria the Secretary
proposed for adoption.
This final rule addresses comments received on the proposed rule
and specifies the adoption by the Secretary, under sections 3004(a)(3)
and 3004(b)(3) of the PHSA, of the standards, implementation
specifications, and certification criteria that will establish the
technical capabilities that electronic health record (EHR) technology
must include to be certified. EHR technology certified to these
standards, implementation specifications, and certification criteria
makes it possible for eligible professionals (EPs), eligible hospitals
(EHs), and critical access hospitals (CAHs) to adopt Certified EHR
Technology (CEHRT) and subsequently attempt to demonstrate its
meaningful use (MU) under the Medicare and Medicaid EHR Incentive
Programs (the ``EHR Incentive Programs'').
Consistent with Executive Order 13563, we have undertaken a
retrospective review of our regulations. The final rule establishes
multiple means for reducing regulatory burden and increasing regulatory
flexibility for stakeholders, including changes to current regulatory
requirements and approaches.
B. Summary of Major Provisions
1. Overview of the 2014 Edition EHR Certification Criteria
We have adopted certification criteria that will support the
changes to the EHR Incentive Programs, including the new and revised
objectives and measures for Stages 1 and 2 of MU finalized by CMS. The
adopted certification criteria also enhance care coordination, patient
engagement, and the security, safety, and efficacy of EHR technology.
We refer to the adopted certification criteria as the 2014 Edition EHR
certification criteria and the certification criteria previously
adopted through rulemaking (75 FR 2014, 75 FR 44590) as the 2011
Edition EHR certification criteria. To permit efficient certification
methods and reduce regulatory burden, we have identified those
certification criteria that we have adopted as part of the 2014 Edition
EHR certification criteria that include unchanged capabilities that
were also included in the 2011 Edition EHR certification criteria. For
EHR technology previously certified to the 2011 Edition EHR
certification criteria, this will permit, where applicable, the use of
prior test results for certification to the 2014 Edition EHR
certification criteria (see the discussion of ``gap certification'' in
section III.A.12 of this preamble).
2. Certified EHR Technology
Since the publication of the Standards and Certification Criteria
final rule in July 2010, 75 FR 44590 (July 28, 2010) (the ``S&CC July
2010 final rule''), HHS received significant feedback from stakeholders
which suggested that we change our CEHRT policy (and definition) to one
that would provide EPs, EHs, and CAHs the flexibility to have only the
EHR technology they need to demonstrate MU. Consistent with stakeholder
feedback and recommendations received from the HITSC, we proposed to
revise the CEHRT definition to offer the requested flexibility. Based
on comments received, we have finalized a CEHRT definition that
provides even more flexibility for EPs, EHs, and CAHs than we
originally proposed. In order to have EHR technology that meets the
CEHRT definition for FY and CY 2014 and subsequent years, EPs, EHs, and
CAHs must have EHR technology certified to the 2014 Edition EHR
certification criteria that meets the Base EHR definition (EHR
technology that includes fundamental capabilities all providers would
need to have) as well as the additional EHR technology certified to the
2014 Edition EHR certification criteria necessary to meet the MU
objectives and measures for the stage of MU that they seek to meet and
to capture, calculate, and electronically submit clinical quality
measures. In addition, this final rule permits EPs, EHs, and CAHs to
adopt EHR technology that meets the FY/CY 2014 CEHRT definition and use
it in their attempts to achieve MU prior to FY/CY 2014. We further
discuss the new dynamic CEHRT definition, including the Base EHR
definition in section III.B (``Redefining Certified EHR Technology and
Related Terms'').
We note that we continue to permit only two types of EHR
technology, Complete EHRs and EHR Modules, to be certified to meet
these definitions under the ``ONC HIT Certification Program.'' A
Complete EHR requires EHR technology to meet, at a minimum, all the
mandatory certification criteria for either the ambulatory or inpatient
setting, while an EHR Module can be any EHR technology certified to one
less than all the mandatory certification criteria for either the
ambulatory or inpatient setting (as noted, it would be a Complete EHR
if it was certified to all the mandatory certification criteria for a
setting). A Complete EHR, by definition, would meet the Base EHR
definition and could be used to meet the CEHRT definition, but we note
that an EP may need EHR technology certified to the optional ``cancer
registries'' certification criteria to support their attempt to achieve
MU. A single EHR Module could also be developed to meet the Base EHR
definition and CEHRT definition for an EP, EH, or CAH. Additionally, an
EP, EH, or CAH could use multiple certified EHR Modules or a certified
EHR Module(s) in conjunction with a certified Complete EHR to meet the
Base EHR definition and CEHRT definition.
3. ONC HIT Certification Program
This final rule revises the permanent certification program in ways
that increase regulatory clarity and transparency, reduce regulatory
burden, and add flexibility for the health information technology (HIT)
community. One of these revisions includes changing the permanent
certification program title to the ``ONC HIT Certification Program,''
which provides clearer attribution to the agency responsible for the
program and an appropriate description of the program's scope, covering
both current and potential future activities. The final rule also
revises the process for permitting the use of newer versions of
``minimum standard'' code sets. The new approach is expected to reduce
regulatory complexity and burden by providing the industry with the
flexibility to utilize newer versions of adopted ``minimum standard''
code sets in a timelier manner.
The final rule modifies the certification processes ONC-Authorized
Certification Bodies (ONC-ACBs) will need to follow for certifying EHR
Modules in a manner that provides clear implementation direction and
compliance with the new certification criteria. It also reduces
regulatory burden by eliminating the certification requirement that
every EHR Module be certified to the ``privacy and security''
certification criteria. Instead, the privacy and security capabilities
are
[[Page 54165]]
included in the Base EHR definition that every EP, EH, and CAH must
meet as part of meeting the CEHRT definition.
To increase clarity for purchasers in the HIT market, we have
established methods for representing certified Complete EHRs and
certified EHR Modules, including when Complete EHRs and EHR Modules
meet the Base EHR definition. We also require that test results used
for EHR technology certification be made publicly available in an
effort to increase transparency and provide EPs, EHs, and CAHs a
potential starting point from which to assess any implementation issues
associated with certified Complete EHRs and certified EHR Modules.
Finally, as another means of increasing transparency and mitigating any
potential confusion in the market, we require that ONC-ACBs ensure that
EHR technology developers include in their marketing materials and
communications notification to potential purchasers any additional
types of costs that an EP, EH, or CAH would pay to implement their
certified Complete EHR or certified EHR Module in order to attempt to
meet MU objectives and measures.
C. Costs and Benefits
We determined that this final rule is not an economically
significant rule as its overall costs will be less than $100 million in
any one year. We have, however, estimated the costs and benefits of the
final rule. The final rule does not account for the estimated costs
that EPs, EHs, and CAHs will incur in adopting and implementing
certified Complete EHRs and certified EHR Modules. Those costs are
estimated in the CMS Medicare and Medicaid EHR Incentive Programs Stage
2 final rule (Stage 2 final rule) published elsewhere in this issue of
the Federal Register. The estimated costs expected to be incurred by
EHR technology developers to develop and prepare EHR technology (i.e.,
Complete EHRs and EHR Modules) to be tested and certified in accordance
with the 2014 Edition EHR certification criteria are represented in
monetary terms in Table 1 below. We believe that there will be market
pressures to have certified Complete EHRs and certified EHR Modules
ready and available prior to when EPs, EHs, and CAHs must meet the
revised CEHRT definition for FY/CY 2014, particularly with the option
provided by this final rule for EPs, EHs, and CAHs to adopt EHR
technology that meets the FY/CY 2014 CEHRT definition and use it in
their attempts to achieve MU in FY/CY 2013. Due to these market
pressures, we believe that most of the estimated costs for developing
EHR technology to meet the 2014 Edition EHR certification criteria will
be incurred during the remainder of 2012 and throughout 2013, rather
than in 2014. As a result, as represented in Table 1, the estimated
costs attributable to this final rule are distributed as follows: 45%
for 2012, 45% for 2013, and 10% for 2014. The dollar amounts expressed
in Table 1 are expressed in 2012 dollars.
There are multiple potential benefits that stem from the 2014
Edition EHR certification criteria. Foremost, the 2014 Edition EHR
certification criteria promote enhanced interoperability,
functionality, utility, and security of EHR technology through the
capabilities they include and the standards they require EHR technology
to meet for certification. EHR technology certified to the 2014 Edition
EHR certification criteria also will be capable of supporting EPs, EHs,
and CAHs' attempts to demonstrate MU under the EHR Incentive Programs.
The revised CEHRT definition, the availability of gap certification,
and the revisions to the ONC HIT Certification Program, will, as noted,
increase regulatory clarity, improve transparency, and add flexibility,
while also reducing the regulatory burden on the HIT industry. Last,
the provisions of this final rule are supportive of other initiatives,
such as the Partnership for Patients, Medicare Shared Savings Program,
and other quality measure programs administered by CMS.
Table 1--Estimated Costs of the Final Rule: Distributed Total Development and Preparation Costs for Complete EHR
and EHR Module Developers (3-year period)--Totals Rounded
----------------------------------------------------------------------------------------------------------------
Primary mid-
Ratio Total low cost Total high point total
Year (percent) estimate ($M) cost estimate cost estimate
($M) ($M)
----------------------------------------------------------------------------------------------------------------
2012............................................... 45 45.85 130.02 87.93
2013............................................... 45 45.85 130.02 87.93
2014............................................... 10 10.20 28.90 19.56
------------------------------------------------------------
3-Year Totals.................................. ........... 101.90 288.94 195.42
----------------------------------------------------------------------------------------------------------------
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 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
With the passage of the HITECH Act, two new Federal advisory
committees were established, 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 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. The HITPC also considers
and provides recommendations to ONC and CMS on meaningful use (MU)
policy under the EHR Incentive Programs. The HITSC is responsible for
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
[[Page 54166]]
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.''
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
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 MU Stage 1.
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). On October 13,
2010, an interim final rule with a request for comment was issued to
remove certain implementation specifications related to public health
surveillance that had been previously adopted in the S&CC July 2010
final rule (75 FR 62686).
The standards, implementation specifications, and certification
criteria adopted by the Secretary in the S&CC July 2010 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 ``Stage 1 final rule'') (see 75 FR 44314 for more information
about MU and the Stage 1 requirements).
On March 7, 2012, ONC published a proposed rule (``the Proposed
Rule'') (77 FR 13832) in the Federal Register that proposed new and
revised certification criteria that would support the achievement of MU
beginning with the EHR reporting periods in FY/CY 2014. These
certification criteria are referred to as the 2014 Edition EHR
certification criteria. The rule also proposed revisions to the CEHRT
definition.
2. Medicare and Medicaid EHR Incentive Programs Rules
On January 13, 2010, CMS published the EHR Incentive Programs Stage
1 proposed rule (75 FR 1844). The rule proposed a definition for Stage
1 MU of CEHRT and regulations associated with the incentive payments
made available under Division B, Title IV of the HITECH Act.
Subsequently, CMS published a final rule (75 FR 44314) for the EHR
Incentive Programs on July 28, 2010, simultaneously with the
publication of the S&CC July 2010 final rule. The Stage 1 final rule
established the objectives, associated measures, and other requirements
that EPs, EHs, and CAHs must satisfy to demonstrate MU during Stage 1.
On March 7, 2012, CMS published a proposed rule (77 FR 13698) in
the Federal Register for MU Stage 2 that included proposed revisions to
MU Stage 1 beginning with the EHR reporting periods in FY/CY 2013
(Stage 2 proposed rule).
3. HIT Certification Programs Rules
On March 10, 2010, ONC published a proposed rule (75 FR 11328)
titled ``Proposed Establishment of Certification Programs for Health
Information Technology'' (the ``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'').
In the Proposed Rule mentioned above, ONC also proposed revisions
to the permanent certification program, including changing the
program's name to the ONC HIT Certification Program.
III. Provisions of the Final Rule Affecting Standards, Implementation
Specifications, and Certification Criteria
To make a clear distinction between previously adopted
certification criteria and the ones proposed for adoption in the
Proposed Rule, we stated we would refer to and define the certification
criteria adopted in the S&CC July 2010 final rule and included in
Sec. Sec. 170.302, 170.304, and 170.306 collectively as the
[[Page 54167]]
``2011 Edition EHR certification criteria.'' We proposed to revise
Sec. 170.102 to add this definition.
Comments. Commenters expressed support for ``editions'' of
certification criteria, particularly the use of ``2011 Edition EHR
certification criteria'' for collectively referencing Sec. Sec.
170.302, 170.304, and 170.306.
Response. We appreciate the expression of support and have revised
Sec. 170.102 to include the definition of 2011 Edition EHR
certification criteria as proposed.
A. 2014 Edition EHR Certification Criteria
In the Proposed Rule, we proposed new, revised, and unchanged
certification criteria that would establish the technical capabilities
and specify the related standards and implementation specifications
that CEHRT would need to include to, at a minimum, support the
achievement of MU by EPs, EHs, and CAHs under the EHR Incentive
Programs beginning with the EHR reporting periods in FY/CY 2014. We
referred to these new, revised, and unchanged certification criteria as
the ``2014 Edition EHR certification criteria'' and proposed to add
this term and its definition to Sec. 170.102. Additionally, we
proposed to include all of the 2014 Edition EHR certification criteria
in Sec. 170.314 to set them apart and make it easier for stakeholders
to quickly determine which certification criteria would be required
beginning with the EHR reporting periods that start in FY/CY 2014.
Comments. Commenters expressed support for ``editions'' of
certification criteria, particularly the use of ``2014 Edition EHR
certification criteria'' to reference the certification criteria
adopted in Sec. 170.314. One commenter, however, did not agree with
our approach to include all of the 2014 Edition EHR certification
criteria in Sec. 170.314. The commenter suggested that we should
maintain the approach used for the 2011 Edition EHR certification
criteria (i.e., to separate general, ambulatory, and inpatient
certification criteria into three sections of the Code of Federal
Regulations (CFR)).
Response. We appreciate the expression of support for our
``editions'' approach and have revised Sec. 170.102 to include the
definition of 2014 Edition EHR certification criteria as proposed. Use
of ``2014 Edition EHR certification criteria'' coupled with our use of
``2011 Edition EHR certification criteria'' should eliminate any
ambiguity and provide a clear distinction between the certification
criteria that are part of the 2011 Edition EHR certification criteria
and those in the 2014 Edition EHR certification criteria.
We believe by including all the 2014 Edition EHR certification
criteria in one section of the CFR is a better approach than our
previous approach of separating general, ambulatory, and inpatient
certification criteria into three sections of the CFR. As noted in the
Proposed Rule, the inclusion of all 2014 Edition EHR certification
criteria in one regulatory section will simplify the regulatory
framework for stakeholders.
1. Certification Criteria Relationship to MU
Many of the certification criteria that we proposed supported the
MU objectives and measures proposed by CMS in the Stage 2 proposed rule
as well as the reporting of MU objectives and measures and clinical
quality measures (CQMs). To the extent CMS has changed (e.g., added,
revised, or removed) the MU objectives, measures, or reporting
requirements in its final rule, we have made appropriate changes to the
associated certification criteria so that they continue to support the
MU objectives, measures, and reporting requirements.
We received many comments on the 2014 Edition EHR certification
criteria that were not within this rulemaking's scope. These comments
focused on the MU objectives, measures, CQM measures, and reporting
requirements. For responses to such comments, we direct readers to the
Stage 2 final rule published elsewhere in this issue of the Federal
Register.
We reiterate and emphasize for commenters to remember that
certification is a floor not a ceiling. It does not specify an
exhaustive set of capabilities that EHR technology must include.
Rather, certification assesses a subset of capabilities (generally
capabilities that support MU requirements) that may be part of the
overall EHR technology that an EP, EH, or CAH adopts. In this regard,
certification focuses on providing assurance to EPs, EHs, and CAHs that
EHR technology certified to a certification criterion includes the
specified capabilities, that those capabilities perform correctly and,
where applicable, that those capabilities properly utilize/support
adopted standards.
We discuss the new, revised, and unchanged certification criteria
that we are adopting as the 2014 Edition EHR certification criteria in
sections A.8 through A.10 below. We include a table at the beginning of
the discussion of each certification criterion or criteria that
specifies the MU objective that the 2014 Edition EHR certification
criterion or criteria support. The objective cited is either a Stage 1
or Stage 2 objective that will be effective for the EHR reporting
periods in FY/CY 2014. We provide this frame of reference because
beginning in FY/CY 2014 EHR technology will need to be certified to the
2014 Edition EHR certification criteria to meet the CEHRT definition
and the tables clearly associate the certification criterion or
criteria with the MU objective it supports. The tables also specify the
CFR location for each certification criterion adopted in Sec. 170.314.
2. Applicability
Section 170.300 establishes the applicability of subpart C--
Certification Criteria for Health Information Technology. Section
170.300(a) establishes the applicability of the adopted certification
criteria to the testing and certification of Complete EHRs and EHR
Modules. Section 170.300(b) specifies that when a certification
criterion refers to two or more standards as alternatives, the use of
at least one of the alternative standards will be considered compliant.
Section 170.300(c) specifies that Complete EHRs and EHR Modules are not
required to be compliant with certification criteria that are
designated as optional.
We proposed to revise Sec. 170.300 to reflect our proposed
regulatory structure for the 2014 Edition EHR certification criteria.
We proposed to revise paragraph (c) to add that Complete EHRs and EHR
Modules are also not required to be certified to specific capabilities
within a certification criterion that are designated as optional. We
also proposed to add a paragraph (d) that would clarify which
certification criteria or specific capabilities within a certification
criterion included in Sec. 170.314 have general applicability (i.e.,
apply to both ambulatory and inpatient settings) or apply only to an
inpatient setting or an ambulatory setting.
Comments. Comments asked for clarification on how the optionality
provided for capabilities within certification criteria would be
clearly identified to purchasers of certified EHR technology.
Response. We expect that the certifications issued to EHR
technology will clearly indicate whether the EHR technology was
certified to any optional capability within a certification criterion
or, for that matter, any optional certification criterion. The
Certified HIT Product List (CHPL) will also indicate
[[Page 54168]]
whether a certified Complete EHR or certified EHR Module was certified
to an optional certification criterion or an optional specific
capability within a certification criterion.
3. Scope of a Certification Criterion for Certification
In the Proposed Rule, based on our proposal to codify all the 2014
Edition EHR certification criteria in Sec. 170.314, we clarified that
certification to the certification criteria at Sec. 170.314 would
occur at the second paragraph level of the regulatory section. We noted
that the first paragraph level in Sec. 170.314 organizes the
certification criteria into categories. These categories include:
clinical (Sec. 170.314(a)); care coordination (Sec. 170.314(b));
clinical quality measures (Sec. 170.314(c)); privacy and security
(Sec. 170.314(d)); patient engagement (Sec. 170.314(e)); public
health (Sec. 170.314(f)); and utilization (Sec. 170.314(g)). Thus, we
stated that a certification criterion in Sec. 170.314 is at the second
paragraph level and would encompass all of the specific capabilities in
the paragraph levels below with, as noted in our discussion of
``applicability,'' an indication if the certification criterion or the
specific capabilities within the criterion only apply to one setting
(ambulatory or inpatient).
Comments. We received no comments on this clarification.
Response. Having adopted the 2014 Edition EHR certification
criteria in Sec. 170.314 as we proposed, our clarification remains
accurate. Additionally, we offer further clarity with an illustration
of this principle using the ``demographics'' certification criterion
adopted at Sec. 170.314(a)(3) (second paragraph level). The
certification criterion includes two specific capabilities at (3)(i)
and (ii) (third paragraph level): ``(i)'' enable a user to
electronically record, change, and access patient demographic data
including preferred language, gender, race, ethnicity, and date of
birth (in accordance with the specified standards for race, ethnicity,
and preferred language (Sec. 170.314(3)(i)(A) and (B)); and, ``(ii)''
for the inpatient setting only, enable a user to electronically record,
change, and access preliminary cause of death in the event of
mortality. Consequently, to meet the demographics certification
criterion, for example, EHR technology designed for the inpatient
setting would need to meet Sec. 170.314(a)(3)(i)(A) and (B) and (ii),
while EHR technology designed for the ambulatory setting would only
need to meet (3)(i)(A) and (B) because the capability at (3)(ii) only
applies to the inpatient setting.
4. Explanation and Revision of Terms Used in Certification Criteria
In the Proposed Rule, we noted that certain terms are repeatedly
used in the proposed 2014 Edition EHR certification criteria. We stated
that, based on our experience and stakeholder feedback related to how
terms in the 2011 Edition EHR certification criteria have been
interpreted, it was necessary in certain cases to select different
terms. Therefore, we provided the following list of terms that are
repeatedly used in the 2014 Edition EHR certification criteria and the
intended meaning for each term.
``User'' is used to mean a health care professional or his or her
office staff or a software program or service that would interact
directly with the CEHRT. This is essentially the same description that
we gave to ``user'' in the S&CC July 2010 final rule (75 FR 44598). We
clarified that, unless expressly stated otherwise, ``user'' does not
mean a patient.
``Record'' is used to mean the ability to capture and store
information in EHR technology. We consider this meaning complementary
to and consistent with related terms, namely ``change and ``access,''
and their associated capabilities.
``Change'' is used to mean the ability to alter or edit information
previously recorded in EHR technology. We proposed to replace the term
``modify'' used in the 2011 Edition EHR certification criteria with
``change.'' Although we interpret both terms to have essentially the
same meaning, we believe ``change'' connotes a more plain language
meaning as recommended by plainlanguage.gov.\1\ In certification
criteria in which this term is used, we stated that we do not intend
for it to be interpreted to mean that information previously recorded
would be able to be changed without the retention of prior value(s).
Rather, a change must be retained as an audited event and in a viewable
format that identifies the changed information in a patient's record
(similar to how one might see changes represented in a word-processing
application). How such changes are displayed is a design decision left
to EHR technology developers.
---------------------------------------------------------------------------
\1\ http://www.plainlanguage.gov/howto/wordsuggestions/simplewords.cfm#lm
---------------------------------------------------------------------------
``Access'' is used to mean the ability to examine or review
information in or through EHR technology. We proposed to replace the
term ``retrieve'' used in the 2011 Edition EHR certification criteria
with ``access'' because we believe it is clearer and more accurately
expresses the capability we intend for EHR technology to include. We
noted that some stakeholders had interpreted ``retrieve'' to suggest
that the EHR technology also needed to be able to obtain data from
external sources. Nevertheless, we stated that we interpret both
``access'' and ``retrieve'' to have essentially the same meaning, but
note that ``access'' should not be interpreted to include necessarily
the capability of obtaining or transferring the data from an external
source.
``Incorporate'' is used to mean to electronically import,
attribute, associate, or link information in EHR technology. With the
exception of import, we previously used these terms to describe the
``incorporate'' capability included in certification criteria as
illustrated by the capability specified at Sec. 170.302(h)(3). We
proposed to revise its unique meaning for the 2014 Edition EHR
certification criteria and the purposes of certification to account for
the ability to electronically import information.
``Create'' is used to mean to electronically produce or generate
information. We proposed to replace the term ``generate'' used in the
2011 Edition EHR certification criteria with ``create.'' We stated that
``create'' is clearer and is a better word choice than generate from a
plain language perspective.
``Transmit'' is used to mean to send from one point to another.
Comments. Commenters expressed general support for our proposed
replacement of terms in certification criteria with the proposed terms
described above. A few commenters, however, expressed confusion about
our description of ``incorporate'' as we described it and used it in
different certification criteria such as the proposed ``transitions of
care-incorporate summary care record'' certification criterion (Sec.
170.314(b)(1)) and the ``incorporate laboratory tests and values/
results'' certification criterion (Sec. 170.314(b)(5)).
Response. We appreciate the support for the proposed term
replacements and are replacing the terms as proposed, except for the
term ``incorporate.'' We agree with commenters that our description of
incorporate could create confusion based on the context in which we
proposed to use it in different certification criteria. In
consideration of comments received, we have revised our description of
incorporation to reflect the common interpretation commenters stated
they assigned to the term. Thus,
[[Page 54169]]
when the term incorporate is used within a certification criterion it
is intended to mean to electronically process structured information
from another source such that it is combined (in structured form) with
information maintained by EHR technology and is subsequently available
for use within the EHR technology by a user. As part of the 2014
Edition EHR certification criteria, the ``transitions of care'' and
``incorporate laboratory tests and values/results'' certification
criteria at Sec. 170.314(b)(2) and (b)(5), respectively, reference
this term in the context of a specific capability that would require
EHR technology to be able to incorporate information.
Comments. Commenters expressed confusion about how to interpret our
use of the phrase ``included in one or any combination of the
following'' in certification criteria.
Response. To eliminate any potential confusion, we have revised the
certification criteria containing this phrase to read ``each one and at
least one combination of the following data.'' We use this phrase to
mean that the capability for which certification is required must be
able to individually address each of the data specified in the
certification criterion and at least one combination of those data.
``One combination'' means a combination of two or more of the data
listed in the certification criterion. For example, in the clinical
decision support (CDS) certification criterion six categories of data
are listed in paragraphs Sec. 170.314 (a)(8)(i)(A) through (F). The
certification criterion states ``enable a limited set of identified
users to select (i.e., activate) one or more electronic clinical
decision support interventions [hellip] based on each one and at least
one combination of the following data.'' Thus, to meet this
certification criterion EHR technology must be able to enable the
selection of CDS interventions that would be separately applicable to
the data listed in (A) through (F) and at least one combination of the
data listed in (A) through (F), such as (A) and (D) (problems and
demographics).
To provide further clarity for the 2014 Edition EHR certification
criteria, we have revised a number of certification criteria to now
begin with ``EHR technology must be able to * * *'' rather than
``Enable a user to * * *.'' We believe this approach more clearly
communicates that the EHR technology must demonstrate the capability to
be certified to the certification criterion. As one last point of
clarification, we replaced ``data element'' references in certification
criteria, where appropriate, with simply ``data.'' We believe this
clarifies when we intend to mean data that includes types and elements.
We also believe this will prevent confusion when the reference point is
solely a ``data element.''
Comments. Commenters asked how terms used in MU objectives and
measures are defined for the purposes of the 2014 Edition EHR
certification criteria, such as ``electronic notes,'' ``images,''
``care plan,'' and ``care team.''
Response. We incorporate in our certification criteria the terms
used in MU objectives and measures as they are defined or described in
the Stage 2 final rule.
5. Consensus-Based Standards
Comments. Commenters stated that for interoperability to be
successful, it was essential that standards be created through
collaborative, consensus-based processes that take into consideration
the needs and concerns of all interested stakeholders. Response.
Federal agencies are required under the National Technology Transfer
and Advancement Act of 1995 (NTTAA) (15 U.S.C. Sec. 3701 et seq.) and
OMB Circular A-119 \2\ to use, wherever practical, technical standards
that are developed or adopted by voluntary consensus standards bodies
to carry out policy objectives or activities, with certain exceptions.
Both the NTTAA and OMB Circular A-119 provide for certain exceptions to
selecting only standards developed or adopted by voluntary consensus
standards bodies, namely when doing so would be inconsistent with
applicable law or otherwise impractical. In this final rule, we have
adopted or refer to voluntary consensus standards, except for the
following government-unique standards: the Office of Management and
Budget Standards for Maintaining, Collecting, and Presenting Federal
Data on Race and Ethnicity; the three transport standards adopted in
Sec. 170.202; the standard that identifies the data elements
referenced by clinical quality measures (adopted at Sec. 170.204(c));
and certain standards related to the protection of electronic health
information adopted in Sec. 170.210. We are aware of no voluntary
consensus standards that would serve as alternatives to these standards
for the purposes that we have identified.
---------------------------------------------------------------------------
\2\ http://www.whitehouse.gov/omb/circulars_a119.
---------------------------------------------------------------------------
Comments. A commenter suggested that we incorporate the HL7 EHR
System Functional Model (ISO/HL7 10781 standard) into certification.
The commenter noted that is a long-standing international consensus
standard for EHR System functionality and that Release 2 of this
standard is currently in ballot by the International Standards
Organization Technical Committee 215 on Health Informatics (ISO TC215),
the Committee for European Normalization Technical Committee 251 (CEN
TC251), the International Health Terminology Standards Development
Organisation (IHTSDO), the Clinical Data Interchange Standards
Consortium (CDISC) and Health Level Seven (HL7). The commenter
suggested that ``linking'' the function and conformance criteria of the
internationally-recognized ISO/HL7 10781 standard to the 2014 Edition
EHR certification criteria for the purposes of certification would make
EHR technology certified under the ONC HIT Certification Program more
competitive in international markets.
Response. It is our understanding that the HL7 EHR System
Functional Model provides a comprehensive set of EHR system functional
requirements that in many cases goes beyond the scope of the
capabilities required by the 2014 Edition EHR certification criteria.
As such, this comment is outside the scope of this current rulemaking.
However, we strongly support methods that could be used to increase
international interoperability and acceptance of EHR technology
certified under the ONC HIT Certification Program. Accordingly, we
intend to explore and request that the HITPC and HITSC consider the
applicability and usefulness of the HL7 EHR System Functional Model as
a basis for future recommendations on certification criteria.
6. Adopting Versions of Standards
Comments. We received comments recommending that we adopt standards
at a higher level of abstraction and that we should not be overly
prescriptive about the exact version and release of vocabulary and
messaging protocols. That is, that we should not adopt a particular
version of a content exchange standard for which certification would be
required, (e.g., HL7 2.x, where ``x'' could be any version within the
version 2 family) and accompany the adopted standards with detailed
implementation specifications or guidance outside of rulemaking.
Response. While the commenters' recommendation may provide added
flexibility, we are unable to accept the recommendation for multiple
reasons. First, it has the potential to create interoperability
challenges. Second, there are processes under the Administrative
Procedure Act that must be followed for the adoption of substantive
requirements. Third, in accordance with Office of the Federal Register
regulations related to ``incorporation by reference,'' 1 CFR
[[Page 54170]]
part 51, which we follow for this final rule, the publications we
reference are ``limited to the edition of the publication that is
approved'' and do not include ``[f]uture amendments or revisions of the
publication.'' Consequently, we do not include regulatory language that
refers, for instance, to ``Version 1.X'' when ``X'' remains a variable.
We note, however, that we have taken two steps for certain
vocabulary standards designated as minimum standards code sets. First,
in this final rule we have adopted updated versions of four vocabulary
standards that we proposed for certification in the Proposed Rule. We
proposed the use of the January 2012 International Release of SNOMED
CT[supreg], but have adopted the July 2012 International Release of
SNOMED CT[supreg] as well as the March 2012 U.S. Extension to SNOMED
CT[supreg]. We proposed the use of version 2.38 of LOINC[supreg], but
have adopted version 2.40. We proposed the use of the February 2012
monthly version of RxNorm, but have adopted the August 2012 monthly
version of RxNorm. We proposed the use of the August 15, 2011 version
of CVX code sets, but have adopted the updated through July 11, 2012
version. In all these instances, we have found that the newer versions
improve interoperability and EHR technology implementation, support MU,
and do not create additional substantive requirements in comparison to
the proposed versions of these vocabulary standards. Further, the
adoption of these versions establishes the baseline in the CFR with the
most recent versions of these vocabulary standards that is possible.
Second, we have also established an approach that permits the use of
newer versions of these standards than the one adopted in the CFR. We
refer readers to section IV.B for a discussion of ``minimum standards''
code sets and our new more flexible approach for their use in
certification and upgrading certified Complete EHRs and certified EHR
Modules. Readers should also review Sec. 170.555, which specifies the
certification processes for ``minimum standards'' code sets.
7. Display of Vocabulary Standards
Comments. Several commenters asked a similarly themed question with
respect to the vocabulary standards we proposed to adopt. The question
centered on whether EHR technology was required to display a particular
vocabulary to a user (for the certification criteria that require
recording certain patient information in a vocabulary standard) in
order to be certified. Commenters explained that for the problem list
certification criterion that SNOMED CT[supreg] codes should not be
required for display in EHR technology and that an organization should
be able to use whichever code set they prefer to display. Others
provided similar rationale and said that health care providers are
typically unfamiliar with SNOMED CT[supreg]. Commenters raised similar
questions regarding the display of race and ethnicity as well as
smoking status.
Response. We agree with commenters and want to make clear that EHR
technology does not have to display an adopted vocabulary to a user to
be certified to the certification criterion that includes the
vocabulary standard. For a more detailed discussion and example of our
intent please review our responses to the problem list certification
criterion.
8. Common Data in Certification Criteria
Comments. Several commenters pointed out that we repeat much of the
same data in the ``view, download, and transmit to a 3rd party,''
``clinical summaries,'' and both ``transitions of care'' certification
criteria. These commenters suggested that we specify a single
definition that included this common data and then reference that
definition in the applicable certification criteria. They added that
this would cut down on the repetitiveness of the certification
criteria, make the certification criteria smaller and, thus, easier to
read, and that this approach would be more efficient overall.
Commenters recommended that we define a ``Summary Care Record.''
Response. We agree with commenters' suggestions. Further, we note
that the data we reference in these certification criteria mirror those
specified by CMS for the objectives and measures to which these
certification criteria correlate. Because there is a common set of MU
data types/elements for which certification would be required across
several certification criteria, we have created the term ``Common MU
Data Set.'' We define this term by only the data that is common to
(i.e., included in all five certification criteria) the ``view,
download, and transmit to a 3rd party,'' ``clinical summary,''
``transitions of care--receive, display, and incorporate transition of
care/referral summaries,'' ``transitions of care--create and transmit
transition of care/referral summaries,'' and ``data portability''
certification criteria (see Table 2 below). We decline to create a
specific definition for ``summary care record'' because the Common MU
Data Set definition serves multiple certification criteria that
reference different ``summary'' oriented documents. For instance, data
referenced in the ``clinical summary'' shares the data in the Common MU
Data Set with the ``transitions of care'' certification criteria, but
also includes unique data that is specific to a clinical summary. The
following data are included in the Common MU Data Set definition and
where applicable reference the standard that would have otherwise been
assigned if the data were individually included within the
certification criteria.
Table 2--Common MU Data Set
------------------------------------------------------------------------
------------------------------------------------------------------------
1. Patient name 2. Sex.
3. Date of birth 4. Race.
5. Ethnicity 6. Preferred language.
7. Smoking status 8. Problems.
9. Medications 10. Medication allergies.
11. Laboratory test(s) 12. Laboratory value(s)/result(s).
13. Vital signs (height, weight, BP, 14. Care plan field(s), including
BMI) goals and instructions.
15. Procedures 16. Care team members.
------------------------------------------------------------------------
We also believe that further clarity for stakeholders can be
provided through the use of more specific descriptions for the
different types of ``data summaries'' referenced in certification
criteria. These specific descriptions are listed below and are used in
the applicable certification criteria and referenced in the preamble
discussions of the certification criteria. This revision is intended to
make the data referenced in the final rule and the ``data summary'' to
which it is assigned more readily apparent to readers. We note that the
use of these specific descriptions in the certification criteria are
for regulatory clarity purposes only and do not imply any additional
meaning.
----------------------------------------------------------------------------------------------------------------
Certification criterion Type of summary
----------------------------------------------------------------------------------------------------------------
Data portability Sec. 170.314(b)(7)........ Export Summary.
Transitions of care--receive, display, and Transition of care/referral summary.
incorporate transition of care/referral
summaries Sec. 170.314(b)(1).
Transitions of care--create and transmit
transition of care/referral summaries Sec.
170.314(b)(2).
[[Page 54171]]
View, download, and transmit to a 3rd party Ambulatory Summary.
Sec. 170.314(e)(1). Inpatient Summary.
Clinical Summary Sec. 170.314(e)(2)........ Clinical Summary.
----------------------------------------------------------------------------------------------------------------
9. New Certification Criteria
In the Proposed Rule, we described certification criteria that we
considered ``new.'' We noted the following factors that we would
consider when determining whether a certification criterion is ``new'':
The certification criterion only specifies capabilities
that have never been included in previously adopted certification
criteria; or
The certification criterion was previously adopted as
``mandatory'' for a particular setting and subsequently adopted as
``mandatory'' or ``optional'' for a different setting.
Comments. We did not receive comments questioning our description
of new certification criteria.
Response. We therefore continue to use this description of new
certification criteria to categorize the following certification
criteria we have adopted as part of the 2014 Edition EHR certification
criteria. The adopted new certification criteria include those
certification criteria that we explicitly proposed in the Proposed Rule
and two additional certification criteria stemming from proposals
related to quality management principles for EHR technology development
and data portability for which we solicited comments. We have not
adopted the proposed ``non-percentage-based measure use report''
certification criterion.
a. Ambulatory and Inpatient Setting
We have adopted 9 new certification criteria that will be
applicable to both the ambulatory and inpatient settings. We also
discuss the proposed ``non-percentage-based measure use report''
certification criterion but, as noted above, we have not adopted it as
part of the 2014 Edition EHR certification criteria.
Electronic Notes
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
Record electronic notes in patient records.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(a)(9) (Electronic notes).
------------------------------------------------------------------------
We proposed a certification criterion that was similar to the one
recommended by the HITSC to support the MU objective and measure
recommended by the HITPC. CMS did not specifically propose the HITPC
recommended MU objective and measure for Stage 2, but requested public
comment on whether the objective and measure should be incorporated
into MU Stage 2.
We proposed to replace the terms ``modify'' and ``retrieve'' in the
recommended criterion with ``change'' and ``access,'' respectively. We
proposed that ``search'' in the certification criterion was intended to
mean the ability to search free text and data fields of electronic
notes. We further proposed that the ability to search would mean the
ability to search the notes that any licensed health care professional
has included within the EHR technology and the ability to search for
information across separate notes rather than just within notes.
Comments. Many commenters stated that we should not adopt an
electronic notes certification criterion without CMS establishing a
corresponding MU objective and measure. Commenters requested that we
define a note for qualifying in the numerator and clarify who could
create, edit, and sign a note. Commenters suggested permitting a range
of options for capturing notes, such as templates and free text. A few
commenters suggested that electronic notes should be recorded in
structured data. These commenters thought this would help avoid
illegible scanned notes or make searching more efficient and useful
(e.g., searching be defined attributes such as physician name). One
commenter suggested structured data fields that include: symptomatic
(subjective); objective; assessment; and plan. The same commenter
suggested specific note structure for patient problem lists.
Commenters expressed general support for the search functionality.
They stated that the ability to search notes for relevant keywords will
reduce time spent reviewing documentation that is irrelevant to the
patient's current medical condition(s). Commenters, however, asked for
further clarification on the extent of the search capability EHR
technology needed to have in order to meet this certification
criterion. Commenters expressed concern that this certification
criterion would require a capability to search across notes, especially
across providers and patients' charts. Multiple commenters suggested
that a reasonable requirement for certification would be to require the
capability to search for a free-text string within a particular open
note, while other search capabilities should be left as competitive
differentiators within the marketplace. These commenters noted that
more specific certification requirements could interrupt innovative
ways to do effective chart search and information display. Conversely,
other commenters suggested requiring additional search functionality,
such as searching across notes based on date ranges or indexing of
notes in much the same way today's common search engines create
background indexes allowing for almost instant retrieval of documents
(e.g., Google, Spotlight on the Mac or ``locate'' on Unix-based
machines).
Commenters stated that some providers will find it particularly
challenging and burdensome to directly document their notes into EHRs.
For example, some EPs would need to have their notes dictated or
transcribed. Commenters stated that many hospitals scan physician paper
notes into EHR technology, particularly in the small hospital setting
where the EPs are not normally employed by the hospital.
A commenter suggested that the capabilities included in this
certification criterion be expanded to require EHR technology to be
able to export electronic notes as CDA Level 2 documents. The commenter
stated that this would require the electronic notes to be wrapped with
a CDA document header and to identify the document type and section
headings with LOINC[supreg] codes. The commenter stated that this would
not be an onerous requirement because most commercial transcription
services can already meet these requirements. The commenter further
stated that this requirement would provide hundreds of millions of
interoperable clinical documents per year and enrich the clinical
content shared during care transitions.
Response. We have adopted an ``electronic notes'' certification
criterion for the 2014 Edition EHR certification criteria at Sec.
170.314(a)(9) as proposed. After consideration of public comments, CMS
has included an ``electronic notes'' objective and measure in the MU
Stage 2 menu set and the adoption of this certification criterion will
support that objective and measure. We direct commenters to the Stage 2
final rule for further discussion of the ``electronic
[[Page 54172]]
notes'' objective and measure, including description of notes that
qualify for the numerator and explanation of who can create, edit, and
sign a note.
We did not propose, nor do we believe, that there is a standard and
industry-wide accepted format for capturing electronic notes.
Therefore, we agree with the commenters that suggested that a range of
options be permitted for capturing notes, including templates and free
text. We also note that in the Stage 2 final rule scanned notes that
are text searchable are acceptable for inclusion in the numerator. This
requirement should address the commenters' concern about illegible
scanned notes.
We appreciate the support expressed for the search capability
included in this certification criterion. After consideration of
comments, we have concluded that the search capability that EHR
technology must demonstrate to meet this certification criterion should
be limited to the ability to search within a note. We believe this will
provide EPs, EHs, and CAHs with a search capability that will be
useful, but still permit EHR technology developers to design and
develop search capabilities that meet specific customer needs.
Additionally, as commenters noted, this will permit the market to
innovate and offer various search capabilities for EPs, EHs, and CAHs.
While we appreciate the commenter's suggestion that the
capabilities included in this certification criterion be expanded to
require EHR technology to be able to export electronic notes as CDA
Level 2 documents, we decline to require EHR technology to demonstrate
this capability as a condition of certification since such a capability
would go beyond what we believe it is necessary to require for
certification in support of MU.
Image Results
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
Imaging results and information are accessible through Certified EHR
Technology.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(a)(12) (Image results).
------------------------------------------------------------------------
We proposed to adopt a new ``imaging'' certification criterion as
part of the 2014 Edition EHR certification criteria to support an EP's,
EH's, and CAH's performance of the proposed new MU objective and
measure. In the Proposed Rule, we clarified that the phrase ``immediate
electronic access'' was intended to mean that a user should be able to
electronically access images and their narrative interpretations
directly and without, for example, having to log in to a separate
electronic system or repository. We stated that this access could be
provided by multiple means, including, but not limited to, ``single
sign-on'' and ``secure identity parameter passing.'' We also considered
the Digital Imaging and Communications in Medicine (DICOM) standard for
this certification criterion, but concluded that the adoption of this
or other standards was not necessary to enable users to electronically
access images and their narrative interpretations, as required by this
certification criterion.
We have categorized and responded to comments under subheadings for
the purposes of clarity and readability.
Types of Images
Comments. Commenters requested a clear definition of ``image'' as
well as ``narrative interpretation.'' Commenters asked whether both
cardiology and pathology images are included or whether images were
limited to radiology. A few commenters specifically suggested that
images be limited to radiology and MRIs and not include photography or
electrocardiograms (ECGs). One commenter suggested the inclusion of
ECGs.
Response. It is outside the scope of this rulemaking to define the
scope of images and narrative interpretations. We direct commenters to
the Stage 2 final rule found elsewhere in this issue of the Federal
Register for a discussion of the MU objective and measure and responses
to these comments.
Internal and External and Storage of Images
Comments. Commenters stated that the requirement to display
diagnostic images is ideal; however, the infrastructure to display
images from all possible modalities, along with all possible technology
solutions within the ambulatory setting, would require huge numbers of
costly interfaces to integrate the images into the EHR technology.
Commenters further stated that clinical images are often large and
stored on external PACS systems. As such, these commenters contended
that requiring EHR technology to duplicate image storage and perform at
the level of a PACS system would be difficult and unnecessary
functionality for EHR technology. Some commenters stated that EHR
systems should not be required to store images, since the use of
reference pointers is enabled by DICOM Web Access to DICOM Persistent
Objects (WADO) standards. Commenters stated that the incorporation of
scanned images into EHRs is generally ineffective at improving patient
care. These commenters stated that when images are scanned into EHRs,
physicians cannot manipulate the data, which may prevent them from
truly seeing the images or understanding what the images represent. A
few other commenters stated that the storing of images by any means to
facilitate access will be costly.
Commenters recommended that the certification capability be limited
to directly linking to images stored in the EHR technology or providing
a context-sensitive link to an external application, which provides
access to images and their associated narrative. Other commenters
asserted that current EHR technology does not track whether a PACS link
is ``available'' or ``clicked on'' because the user interaction happens
largely with the Web-based PACS application. These commenters believed
that there might be barriers to EHR technology collecting information
about the availability of third party data accessible via a Web link
within the EHR to sufficiently meet this requirement. A few commenters
suggested that we limit the capability to provide narrative
interpretations and recommended that the ability to view images within
or through EHR technology be optional.
Response. We have adopted a new ``image results'' certification
criterion to support the new MU objective and measure. We clarify that
we did not propose nor are we requiring that EHR technology has to be
able to store images to meet this certification criterion. EHR
technology can meet this certification criterion by demonstrating a
capability to directly link to images stored in the EHR system or
providing a context-sensitive link to an external application which
provides access to images and their associated narrative. By ``context
sensitive link'' we mean that the link to the image will ideally
include parameters that enable access to the images themselves rather
than access to a system--which would require login, patient search,
image selection, and (finally) image viewing. However, we agree with
commenters that there is insufficient penetration of single sign-on or
services-oriented integration capabilities between EHR technology and
PACS systems, and that the fluidity with which this access is enabled
may not be under the CEHRT's control. We therefore do not explicitly
require that this link provide ``immediate access'' as described below.
Finally, we emphasize that access to both narrative and imaging data
must available to the user.
[[Page 54173]]
In cases where there is no narrative data (for example when a
radiographic image has not yet been interpreted by a radiologist) there
will obviously be no narrative available. Nonetheless, the EHR
technology must be capable of retrieving and displaying the narrative
information in order to meet this certification criterion.
Comments. A commenter requested clarification on whether the
proposed certification criterion pertains only to EPs who send x-rays
outside of their facility or whether providers that take x-rays in
their own offices required to meet this certification criterion.
Response. This certification criterion applies to EHR technology
designed for both the ambulatory and inpatient setting and expresses
the capabilities that EHR technology would need to include in order to
be certified to this certification criterion.
Clarification of Certification Criterion Text
Comments. A few commenters asked for clarification of ``and/or''
and whether it implies optionality regarding either images or the
corresponding narratives. Alternatively, the commenters asked if it
means that the EHR technology must be certified for both availability
of images and narrative interpretations. Other commenters asked whether
the intent of ``electronically indicated to a user the availability of
a patient's images'' was to identify imaging results as available in
order to circumvent redundant imaging tests. If that is the intent, the
commenter recommend that we require, at minimum that information on
when the imaging test was completed, results pending, results location
and date of completion be provided. Similarly, a commenter requested
clarification of whether a ``list'' of past imaging tests completed
would helpful.
Response. For clarity, we have removed the ``or'' from the ``and/
or'' in the regulation text. EHR technology must be capable of
electronically indicating the availability of both images and narrative
interpretations. Redundant imaging tests can lead to unnecessary costs.
We believe that the capabilities included in this certification
criterion can assist in preventing redundant testing. This
certification criterion, however, includes those capabilities that are
necessary to support an EP, EH, or CAH's attempt to achieve the
associated MU objective and measure. Therefore, we decline to include
the additional capabilities recommended by the commenters.
Immediate Electronic Access
Comments. Some commenters expressly supported our proposal that
users should have ``immediate electronic access'' to images and their
narrative interpretations directly and without having to login to a
separate electronic system. Many commenters stated that the
requirements for ``immediacy'' go beyond the capabilities of the EHR
system. Some commenters suggested the term ``immediate'' be removed
from the certification criterion. Other commenters requested
clarification of what immediate electronic access entailed. A commenter
stated that there appeared to be two different functions coupled with
the word ``immediate''--taking the image and getting access to the
image. Commenters also specifically stated that the requirements for
``immediacy'' via additional sign-on capabilities and other system
requirements are beyond the control of the EHR system and, thus, should
not be required for certification. One commenter suggested that, in
order to ensure immediate access, EHR technology should provide stream-
capable hyperlinks to images that can be viewed in a typical web
browser without the delay related to use of DICOM file transfer and
without the requirement to install additional software beyond the
standard web browser itself.
Response. We agree with commenters that ``immediate'' access is
vague and would be difficult to implement in EHR technology at this
time, particularly with methods such as single sign-on. Therefore, we
are removing the term ``immediate'' from the certification criterion.
Applicable Standard
Comments. Some commenters suggested that no standard be adopted for
this certification criterion. Conversely, some commenters recommended
the inclusion of the DICOM standard as a requirement for EHR
certification, as well as certification of DICOM compliance for the
storage and transmission of images. Commenters reasoned that the DICOM
standards and complementary implementation guides developed by
Integrating the Healthcare Enterprise[supreg] (IHE) provide
satisfactory methods for the formatting of medical imaging and for
their access through EHR systems. Some commenters specifically
recommended that DICOM Supplement 127: CT Radiation Dose Reporting
(Dose SR) should be required for the transmission of patient radiation
dose information.
Some commenters suggest that we adopt the Consolidated CDA
Diagnostic Imaging Report standard and the DICOM image standard for
exchanging images and their interpretations. A few commenters
recommended that we at least communicate that we intend to move towards
requiring this standard to complement the DICOM image standard for use
in exchanging images and their interpretations.
Response. We appreciate commenters' recommendations regarding the
DICOM standard, but the recommendations and information provided has
not altered our position expressed in the Proposed Rule nor has CMS
made revisions to the associated MU objective and measure that would
alter our position. As stated in the Proposed Rule, 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, the capability required by this
certification criterion and for MU.
Family Health History
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
Record patient family health history as structured data.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(a)(13) (Family health history).
------------------------------------------------------------------------
We proposed to adopt at Sec. 170.314(a)(13) a 2014 Edition EHR
certification criterion for family health history. The proposed
certification criterion required that EHR technology be able to, at
minimum, electronically record, change, and access the health history
of a patient's first-degree relatives. The Proposed Rule also solicited
comment on whether we should adopt specific standards for this
certification criterion, including the HL7 Pedigree standard \3\ and
the use of Systematized Nomenclature of Medicine--Clinical Terms
(SNOMED CT[supreg]) terms for familial conditions. We also noted that
the Surgeon General had produced a tool that can capture, save, and
manage family health histories using standard vocabularies and can
export the data in eXtensible Markup Language (XML) format and sought
comments on the maturity and breadth of adoption of this tool and its
export format.
---------------------------------------------------------------------------
\3\ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=8.
---------------------------------------------------------------------------
Comments. Commenters generally supported the concept of including a
certification criterion related to family health history. A commenter
noted that our description of the capabilities in this certification
criterion was
[[Page 54174]]
somewhat ambiguous and thus requested confirmation that we did not mean
to imply that this criterion requires the capability to access the
patient's first degree relatives' records. Many commenters expressed
that the HL7 Pedigree standard was not widely used or sufficiently
mature to adopt at the present time. Similarly, many commenters also
expressed that if a specific terminology is required for coding
familial conditions, then SNOMED CT[supreg] would be an appropriate
terminology. Commenters requested that the certification criterion
permit unstructured/free text entry.
Response. We appreciate commenters' general support for this
certification criterion. Equally, CMS received a great deal of support
and has included a family health history objective in the MU Stage 2
menu set. Accordingly, we have finalized a certification criterion for
family health history.
We clarify that this certification criterion requires EHR
technology to demonstrate that it is capable of enabling a user to
electronically record, change, and access a patient's family health
history. This means that EHR technology must, at minimum, be capable of
recording information about a patient's first degree relative in the
patient's record and permitting a user to change and access that
information as needed. EHR technology would not need to be able to
access the records of a patient's first degree relatives.
In support of MU, this certification criterion requires that EHR
technology be capable of capturing family health history in structured
data. Therefore, the certification criterion we have adopted does not
permit unstructured/free text for certification because such entries
would not constitute MU of CEHRT. Similar to commenters, we believe
that SNOMED CT[supreg] is an appropriate terminology, and perhaps the
best intermediate step, for coding family health history in structured
data if one was not to use the HL7 Pedigree standard. We also
understand that some organizations have built family health history CDS
interventions using SNOMED CT[supreg].
The HL7 Pedigree standard was originally released in 2007. Release
1 was recently reaffirmed by the American National Standards Institute
(ANSI), which is a process that occurs every five years. We have
adopted this reaffirmed version as it is the same version (Release 1)
of the standard as the version we proposed. An implementation guide for
this standard is scheduled to be published shortly after this final
rule. Although EHR technology will not be required to conform to the
implementation guide for certification, the implementation guide will
provide important guidance for use of the HL7 Pedigree standard with
EHR technology.
We have finalized that EHR technology may meet this certification
criterion by either being able to capture a patient's family health
history in SNOMED CT[supreg] or in the HL7 Pedigree standard. Since the
use of SNOMED CT[supreg] is required for meeting several other
certification criteria, we do not believe that it will be a challenge
to meet this certification criterion. We emphasize, as specified in the
Sec. 170.300(b), when ``a certification criterion refers to two or
more standards as alternatives, use of at least one of the alternative
standards will be considered compliant.'' Thus, an EHR technology can
demonstrate use of SNOMED CT[supreg] or the HL7 Pedigree standard to
meet this certification criterion.
Amendments
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
Protect electronic health information created or maintained by the
Certified EHR Technology through the implementation of appropriate
technical capabilities.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(d)(4) (Amendments).
------------------------------------------------------------------------
We proposed to adopt a new ``amendments'' certification criterion
(Sec. 170.314(d)(4)) as part of the 2014 Edition EHR certification
criteria. We made this proposal based on HITPC and HITSC
recommendations which included that a certification criterion should be
adopted that provides some of the basic technical tools to support
compliance with the HIPAA Privacy Rule. We noted in the Proposed Rule
that the proposed certification criterion does not address all of the
requirements specified at 45 CFR 164.526 and that EHR technology
certification is not a substitute for, or guarantee of, HIPAA Privacy
Rule compliance. Finally, we requested comment on whether EHR
technology should be required to be capable of appending patient
supplied information in both free text and scanned format or only one
or these methods to be certified to this proposed certification
criteria.
Comments. Many commenters recommended that the proposed
certification criterion's reference to ``free text or scanned'' patient
supplied information be revised. Many supported both and suggested that
both be permitted. Others contended that the certification criterion
was over specified and suggested that ONC not specify one or the other
because patient-supplied information could take many forms. In general,
commenters suggested that EHR technologies have different ways of
appending information and that either of these methods would be
sufficient for certification. Another commenter noted that scanning
patient amendments could be problematic from a storage perspective. One
commenter agreed with the certification criterion but recommended that
ONC should have robust standards for how patient information is
appended to EHR technology before allowing EHR technology developers to
create multiple versions of this workflow. Yet another stated that the
ability to append patient supplied information should be no different
from the ability to append any other ancillary information (outside
reports from other providers). One commenter stated that EHR technology
developers should only need to be certified to one method of amendment
and not all (i.e., free text, scanned information, or embedded links)
in order to meet the certification criterion. Additionally, a commenter
noted that amending the patient record should be allowed via the two
methods proposed, but that scanned documents should have to adhere to a
standard such as PDF or JPG.
Last, a group of commenters took issue with the phrase ``electronic
link'' in the certification criterion. They raised concerns that the
phrase ``embedding an electronic link'' in the certification criterion
could be interpreted in many ways, including some that would create
security risks. Commenters suggested removing ``or by embedding an
electronic link'' to allow different forms and ways to append patient-
supplied information. They also noted that the HIPAA Privacy Rule does
not mention electronic links.
Response. In consideration of the comments received, we have
modified this proposed certification criterion to make clear the
capabilities that EHR technology must include in order to be certified.
As we indicated in the Proposed Rule, we proposed this certification
criterion at the HITPC's recommendation. Along those lines, we
reiterated our agreement with the HITPC's expectation for this
certification criterion, that it be ``kept as simple as possible and
evolve over time to greater complexity, including potentially greater
standardization and automation.'' Our revisions seek to make clear this
certification criterion's focus on supporting the instance where a
HIPAA covered entity agrees or declines to accept a patient's request
for an amendment. Additionally, this certification criterion is meant
to be a
[[Page 54175]]
starting point from which more comprehensive capabilities and standards
can be included, so we disagree with the commenter that suggested we
wait until more comprehensive standards are available.
In response to commenter feedback, we have revised the
certification criterion to more closely mirror the language in the
HIPAA Privacy Rule at 45 CFR Sec. 164.526. In doing so, we no longer
specify a particular format (i.e., free text or scanned) and we have
revised the language associated with ``electronic link.'' The ``link,''
which is an alternative to appending the patient's record must convey
to a user or enable a user to obtain the information associated with an
amendment's acceptance or denial. We believe this adjustment to the
certification criterion provides EHR technology developers with more
flexibility with which to design a capability that can accommodate the
outcome this certification criterion expresses.
Comment. A commenter supported this proposed certification
criterion and stated that there should be a mechanism to identify and
make visible the source of the information to allow evaluation by any
recipient that the information came from a reliable and accurate
source.
Response. We appreciate this commenter's suggestion. However, it
appears to be more specific than we believe necessary at this point for
this new certification criterion. We believe that the requirements we
have included in the final certification criterion are a sufficient
start. We also believe that the certification criterion may, in part,
address this commenter's suggestion in that the information appended or
linked in the case of an accepted or denied amendment should at least
have an indication as to the source of the information (i.e., patient
or provider/organization).
Comments. Several commenters sought clarification as to whether
patient-supplied information had to be appended to specific data in the
patient's health record or attached to a specific instance of a
clinical note or document. Another commenter expressed concern
regarding the feasibility of being able to append patient supplied
information to specific data. The commenter stated that this practice
would be inconsistent with common provider policies that require all
amendments to documents be classified as separate documents. In this
way such information is clearly identified and maintained in a section
or folder of the electronic record, and then subject to clinician
review for what may be actually incorporated into the record upon
acceptance. They indicated that by following this approach the patient
requested amendment has its own ``wholeness'' or integrity as a medical
record entry. In general, other commenters echoed this statement and
suggested that it should be acceptable to have a separate section of
the record for patient-supplied information.
Response. The final certification criterion does not require that
accepted or denied amendments be appended to specific data in order for
compliance to be demonstrated. As indicated above, this criterion is
intended to support compliance with the HIPAA Privacy Rule's amendment
requirements at 45 CFR 164.526. The Privacy Rule provides some
flexibility with how accepted or denied amendments are appended to an
individual's protected health information, recognizing that the type
and scope of an amendment will vary based on the circumstances. For
example, the affected record could include a link to documentation of
an accepted or denied amendment, while still allowing, in the case of
an accepted amendment, any necessary corrections to be incorporated
directly into the record itself.
Comments. A couple of commenters requested clarification regarding
the interplay between the terms ``amend'' and ``append'' in the
certification criterion. One commenter stated that amendments are
documentation meant to clarify health information within a health
record whereas addendums are new documentation used to add information
to an existing entry, and corrections are changes to information meant
to clarify inaccuracies after the original document has been signed or
rendered complete. The other commenter stated that we described
``amending'' a patient's record as allowing clinicians to correct
errors or update the information within their record and that later we
referred to the act of ``appending'' patient supplied information by
using free text and/or scanned material. This commenter stated that
``amend'' and ``append'' are distinct concepts and should not be
combined into one certification criterion because if we intend to allow
these functions of correcting and/or attaching information to the
patient's record they should remain separate. The commenter reasoned
that amending should not permit any overwriting of the existing
documentation and should include a date, time and authentication record
of who took the action--while appending data should accurately capture
the date, time, and authentication of the appended information.
Response. The terminology used in this certification criterion is
meant to mirror the terms used in the HIPAA Privacy Rule at 45 CFR
164.526. Put simply, those rules describe that a patient is permitted
to request an amendment to their health information and the
corresponding obligations a HIPAA covered entity must follow to either
accept or deny the requested amendment. As stated in 45 CFR Sec.
164.526(c)(1), for example, if the amendment is accepted, ``[t]he
covered entity must make the appropriate amendment to the protected
health information or record that is the subject of the request for
amendment by * * * appending or otherwise providing a link to the
location of the amendment.'' Thus, this certification criterion
reflects some of the capabilities needed in the event of an accepted or
denied amendment.
Comment. A commenter stated that Sec. 170.314(d)(4)(i)(A)
conflicts with the description of the term of ``Change'' included in
the Proposed Rule and that this criterion needs to be consistent with
that definition.
Response. This comment is incorrect. The term ``change'' as
described in the Proposed Rule was not included in this certification
criterion. Thus, there is no conflict with respect to the clarity of
the capabilities specified by this certification criterion and others
that include the term ``change.''
Comment. A commenter asked for clarification on the degree of
information retained. They stated that too much information makes the
data storage requirements burdensome on providers and superfluous data
makes it difficult for auditors to detect unauthorized access.
Response. This certification criterion seeks to specify the EHR
technology capabilities necessary to support, in part, the requirements
specified at 45 CFR Sec. 164.526 and it is not within its scope to
address the degree or amount of information retained.
Comment. A commenter recommended that the electronic amendment
contain a date/time stamp and reflect the user who took such action
when content is amended.
Response. We appreciate this commenter's suggestion, however, we
expect that this kind of event would be subject to the audit log
requirements we have already specified (and which includes time and
date stamp).
Comments. One commenter asked for clarification as to whether this
criterion makes a distinction between ``work in progress'' records and
``signed off'' records. They stated, for example, a user may make
several changes to the same
[[Page 54176]]
data while working within a particular screen of the EHR technology.
They suggested that the changes should only be captured when the user
saves their changes and signs off on the record.
Response. No, this certification criterion does not make such a
distinction because those distinctions are inapplicable to this
certification criterion. We believe the commenter misinterpreted the
purpose of this certification criterion and its focus on incrementally
building in the capacity of EHR technology to make compliance with the
HIPAA Privacy Rule more efficient.
Comment. One commenter noted a concern that if this certification
criterion is applied to EHR Modules that are not part of the Base EHR
definition that it could result in conflicting and overlapping
practices and result in incorrect or inconsistent information in a
patient record. For example, the commenter noted that it was a
downstream business associate (or business associate subcontractor) and
an intermediary, and thus does not amend patient information. Further
they stated that they provide notice of any requests for amendments to
their upstream business associates and covered entities with whom they
directly contract. They concluded by stating that requiring an
intermediary or developers of certain EHR Modules to have the
capability to amend information could present confusion and should be
applicable to core functionality of the EHR technology utilized at the
provider level.
Response. For some of the reasons expressed by this commenter, we
proposed to remove the requirement that EHR Modules also be certified
to the privacy and security criteria. We clarify that this
certification criterion is not separately applied to any EHR Modules in
order for them to be certified. An EHR technology developer needs to
include such capability, however, if they seek certification for EHR
technology that would meet the Base EHR definition.
Comments. Two commenters recommended that we remove this
certification criterion. One agreed that HIT should support workflow
for complying with HIPAA privacy regulations, including allowing a user
to amend a patient record, but contended that this functionality is
typically found in a Medical Record Management system. Thus, they
encouraged ONC to remove the certification criterion. However, they
stated that if it remained, we should only require scanned documents.
The other commenter recommended that we delay this certification
criterion's adoption to a later edition of EHR certification criteria
because the technical and legal implications of supporting patient
amendments to the EHR are complex and evolving.
Response. We have not removed this proposed certification
criterion. We agree with the HITPC that starting with a simple
certification criterion can set us on a path to include more
comprehensive capabilities over time. We acknowledge that the processes
involved in supporting patient amendments can sometimes be difficult,
which is why we explained in the Proposed Rule and reiterated in the
above responses that this certification criterion can only help support
(and potentially make more efficient) a HIPAA covered entity's
compliance with the HIPAA Privacy Rule.
Comments. Several commenters supported the proposed certification
criterion, but requested joint confirmation from ONC and CMS that EPs,
EHs, and CAHs do not have to demonstrate use of this capability in
order to meet meaningful use. Other commenters urged us to acknowledge
that this functionality has importance beyond a privacy and security
context.
Response. This certification criterion expresses capabilities that
EHR technology would need to include in order to meet this
certification criterion. Given that this certification criterion is
included as part of the Base EHR definition, EPs, EHs, and CAHs, will
need to have EHR technology certified to this certification criterion
in order to have EHR technology that meets both the Base EHR and CEHRT
definitions. We have consulted with CMS and clarify that since there is
not a meaningful use objective expressly requiring the use of this
capability to satisfy an associated measure that EPs, EHs, and CAHs do
not need to demonstrate use of this capability in order to meet any
meaningful use stage. However, we encourage EPs, EHs, and CAHs to
consider if this capability could make compliance with the requirements
of the HIPAA Privacy Rule, particularly, 45 CFR Sec. 164.526, more
efficient.
View, Download, and Transmit to 3rd Party
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
EPs:
Provide patients the ability to view online, download, and transmit
their health information within 4 business days of the information
being available to the EP.
EHs and CAHs:
Provide patients the ability to view online, download, and transmit
information about a hospital admission.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(e)(1) (View, download, and transmit to 3rd party).
------------------------------------------------------------------------
We proposed a new criterion at Sec. 170.314(e)(1) to subsume the
certification criteria previously adopted at Sec. Sec. 170.304(f),
170.304(g), 170.306(d), and 170.306(e). This proposal was based on the
HITPC issued MU recommendation that patients (or their authorized
representative(s)) be able to view and download their health
information online (i.e., Internet/web-based). The HITPC recommended
that this MU objective should replace or subsume the objectives for
providing patients with timely electronic access to their health
information and providing patients with an electronic copy of their
health information and hospital discharge instructions upon request.
Consistent with these recommendations, the HITSC recommended a
certification criterion that framed the capabilities EHR technology
would need to include to support this new objective and that, for the
2014 Edition EHR certification criterion, the criterion should replace
the certification criteria previously adopted at Sec. Sec. 170.304(f),
170.304(g), 170.306(d), and 170.306(e).
In addition to the view and download capabilities recommended by
the HITSC, we proposed to include a third specific capability in this
certification criterion--the ability to transmit an ambulatory and
inpatient summary to a third party. Coupled with this addition, we
proposed that EHR technology would need to be capable of transmitting
an ambulatory and inpatient summary according to the two
specifications--developed under the Direct Project--which we proposed
for adoption: (1) Applicability Statement for Secure Health Transport
\4\ and (2) Cross-Enterprise Document Reliable Interchange (XDR) and
Cross-Enterprise Document Media Interchange (XDM) for Direct
Messaging.\5\ We indicated that these transport standards were ideal
for this purpose and would make it possible for patients to transmit a
copy of their ambulatory or inpatient summary to the destination of
their choice. Additionally, because we proposed requiring the
capability to perform transmissions in accordance with these transport
standards (which provide for encryption and integrity protection) in
[[Page 54177]]
this criterion and in the ``transitions of care--create and transmit
transition of care/referral summaries'' certification criterion, we
determined that it would not be necessary to include in the 2014
Edition EHR certification criteria the ``encrypting when exchanging''
certification criterion adopted in the 2011 Edition EHR certification
criteria (Sec. 170.302(v)). We stated our belief that to include the
2011 Edition EHR certification criterion would be redundant and that
our proposed approach more explicitly tied security to a particular
transmission.
---------------------------------------------------------------------------
\4\ http://wiki.directproject.org/Applicability+Statement+for+Secure+Health+Transport.
\5\ http://wiki.directproject.org/XDR+and+XDM+for+Direct+Messaging.
---------------------------------------------------------------------------
At the recommendation of the HITSC, the proposed certification
criterion required that EHR technology certified to this criterion
include a ``patient accessible log'' to track the use of the view,
download, and transmit capabilities included in this certification
criterion and make that information available to the patient. We
required this specific capability within this certification criterion
because we believed that it was highly likely numerous EHR Modules
could be certified to this criterion without also being certified to
the auditable events and tamper resistance certification criterion we
proposed to adopt at Sec. 170.314(d)(2) (due to the proposed policy
change we specified in section IV.C.1 of the proposed rule related to
EHR Modules and privacy and security). Thus, this explicit proposal was
meant to guarantee that an EHR Module certified to this criterion would
include the capability to track who has viewed, downloaded, or
transmitted to a third party electronic health information and that
patients would have access to this information. That being said, we
noted that we did not intend for this portion of the certification
criterion to impose a redundant requirement on EHR technology
developers who present a Complete EHR or EHR Module for certification
to both this certification criterion and the auditable events and
tamper resistance certification criterion. Accordingly, we provided in
paragraph (e)(1)(ii)(B) of Sec. 170.314 that EHR technology presented
for certification may demonstrate compliance with paragraph
(e)(1)(ii)(A) of Sec. 170.314 if it is also certified to the
certification criterion proposed for adoption at Sec. 170.314(d)(2)
and the information required to be recorded in paragraph (e)(1)(ii)(A)
of Sec. 170.314 is accessible to the patient. In other words, we
clarified that an EHR technology certified to Sec. 170.314(d)(2) would
not need to also include the ``patient accessible log'' capability
specified in paragraph (e)(1)(ii)(A) of Sec. 170.314 because it would
be capable of logging such events and providing the information to the
patient.
We also proposed that the ``patient accessible log'' capability
would need to record the date and time each action occurs using a
system clock that has been synchronized following either Request for
Comments (RFC) 1305 Network Time Protocol (NTP) v3 or RFC 5905 Network
Time Protocol Version 4: Protocol and Algorithms Specification (NTPv4).
We proposed to require EHR technology to be capable of enabling
images formatted according to the Digital Imaging and Communications in
Medicine (DICOM) standard \6\ to be downloaded and transmitted to a
third party. We stated our belief that this specific capability has the
potential to empower patients to play a greater role in their own care
coordination and could help assist in reducing the amount of redundant
and duplicative imaging-oriented tests performed.
---------------------------------------------------------------------------
\6\ ftp://medical.nema.org/medical/dicom/2011/.
---------------------------------------------------------------------------
Consistent with our belief that all patients should have an equal
opportunity to access their electronic health information without
barriers or diminished functionality or quality, we proposed that the
viewing capability must meet Level AA conformance with the most recent
set of the Web Content Accessibility Guidelines (WCAG). We explained
that the most recent set of guidelines (WCAG 2.0) were published in
2008 and are organized under 4 central principles with testable
``success criteria'': Perceivable, Operable, Understandable, and
Robust.\7\ We further explained that each guideline offers 3 levels of
conformance: A, AA, and AAA. We proposed compliance with Level AA
because it provides a stronger level of accessibility and addresses
areas of importance to the disabled community that are not included in
Level A. In addition to WCAG 2.0 Level AA conformance, we requested
public comment on whether commenters believed additional standards were
needed for certification to ensure accessibility for the viewing
capability, such as the User Agent Accessibility Guidelines (UAAG).\8\
---------------------------------------------------------------------------
\7\ http://www.w3.org/TR/WCAG20/.
\8\ http://www.w3.org/WAI/intro/uaag.php.
---------------------------------------------------------------------------
We proposed to require that EHR technology be capable of providing
the information that CMS proposed be required in an ambulatory or
inpatient summary that is provided to patients or their authorized
representatives. This proposal was based on the HITSC's recommendation
that we move to one standard for capturing this information and our
belief that moving to one standard would lead to increased
interoperability and spur innovation. We explained that we believed the
Consolidated CDA was the most appropriate standard to achieve this goal
because it was designed to be simpler and more straightforward to
implement and, in relation to this rulemaking, its template structure
can accommodate the formatting of an ambulatory or inpatient summary
that includes all of the data elements that CMS proposed be available
to be populated in an ambulatory or inpatient summary.
In certain instances in Sec. 170.314(e)(1), we proposed to require
that the capability be demonstrated in accordance with the specified
vocabulary standard--which were previously adopted or proposed for
adoption in the Proposed Rule consistent with the recommendations of
the HITSC. With the exception of four standards (LOINC[supreg], ICD-10-
CM, ICD-10-PCS, and CPT/HCPCS), the vocabulary standards included in
the certification criterion were discussed elsewhere in the Proposed
Rule in connection with the certification criteria where the vocabulary
standard is central to the required data or serves a primary purpose
(e.g., RxNorm for e-prescribing).
For encounter diagnoses and procedures, we proposed the use of ICD-
10 (ICD-10-CM and ICD-10-PCS, respectively). We requested comment,
however, on whether we should be more flexible with this proposed
requirement based on any potential extension of the ICD-10 compliance
deadline or possible delayed enforcement approach. More specifically,
we noted our interest in whether commenters believed it would be more
appropriate to require EHR technology to be certified to a subset of
ICD-10; either ICD-9 or ICD-10; or to both ICD-9 and ICD-10 for
encounter diagnoses and procedures. We also asked that commenters
consider these options when reviewing and commenting on the other
proposed certification criteria that include these standards (i.e.,
Sec. 170.314(a)(3), (b)(2), and (e)(2)). For procedures, we proposed
to continue to permit a choice for EHR technology certification, either
ICD-10-PCS or the combination of Health Care Financing Administration
Common Procedure Coding System (HCPCS) and Current Procedural
Terminology, Fourth Edition (CPT-4). For outbound messages including
laboratory tests, we stated that EHR technology must be capable of
transmitting the tests performed in LOINC[supreg] 2.38 to meet this
[[Page 54178]]
certification criterion and for all other proposed certification
criteria that include the capability to transmit laboratory tests in
the LOINC[supreg] 2.38 standard. We proposed to adopt the ``view,
download, and transmit to 3rd party'' certification criterion at Sec.
170.314(e)(1) and the ICD-10-PCS and ICD-10-CM standards for procedures
and encounter diagnoses at Sec. 170.207(b)(3) and (m), respectively.
We received a significant amount of comments on the proposed view,
download, and transmit to a 3rd party certification criterion. To make
clear the policy expressed in our responses to comments, we have used
subheadings under which specific comment themes will be discussed. In
response to comments, we have made several revisions to the proposed
certification criterion. Those revisions are explicitly noted in the
applicable response.
View
Comments. Many commenters raised questions and concerns about the
data we specified EHR technology would need to be capable of making
viewable to a patient or their authorized representative. Some
contended that the data exceeded those required for this use case and
questioned the value of such data. Others pointed out that we did not
have a consistent list of data between the ``view'' and ``download''
paragraphs. Commenters specifically called out ``encounter diagnoses''
as being inconsistently applied and raised concerns about our proposal
to refer to ICD-10-CM.
With respect to the vocabularies we proposed for procedures several
commenters disagreed with our proposal to permit EHR technology to be
certified to represent procedures in ICD-10-PCS. Overall, commenters
suggested in one form or another that SNOMED CT[supreg] should be the
sole clinical vocabulary for documentation because it would help better
meet the information objectives for MU. They further stated that SNOMED
CT[supreg] is most appropriate when data is to be represented for
clinical purposes and clinical accuracy. Commenters also contended that
ICD-10-PCS was an inappropriate standard to reference for the purposes
of clinical data exchange and was best suited for billing diagnosis and
billing purposes. Among those comments at least one commenter stated
that SNOMED CT[supreg] should be an alternative vocabulary standard
included in the final rule. Another commenter stated that permitting
the use of ICD-10-PCS to represent procedures in a Consolidated CDA
formatted document would unnecessarily limit the usefulness of the
Consolidated CDA document. This commenter stated that SNOMED CT[supreg]
was the appropriate reference terminology to use to encode procedures.
Similarly, other commenters recommended we replace ICD-10-PCS with
SNOMED CT[supreg] because they believed that ICD-10-PCS would be
inappropriate to use to represent procedures. They contended that
procedures need to address counseling, education, and specific
interventions that are not managed with a billing vocabulary. Last, one
commenter stated that we should adopt the American Dental Association's
Current Dental Terminology (CDT) as a vocabulary to represent
procedures. They reasoned that CDT is a named HIPAA standard for use in
electronic administrative transactions for dental claims and that this
is the standard vocabulary dentists use to represent procedures.
Response. The data that is specified in this certification
criterion was proposed to directly mirror the data that CMS proposed
should be available for patients to view, download, and transmit to a
3rd party. Thus, we disagree that the data exceeds what is required for
this use case. We have worked with CMS to align the data specified in
this certification criterion. In that respect if there were any
discrepancies we have corrected them. Additionally, as discussed
earlier in this preamble we have revised this certification criterion
to refer to the Common MU Data Set, which has significantly reduced the
certification criterion's overall size and complexity. Further, we have
removed ``encounter diagnoses'' from this certification criterion
because it is no longer data that is minimally necessary to support
what CMS has finalized for the objective and measure this certification
criterion is designed to support. ``Encounter diagnoses'' is referenced
by the transitions of care certification criterion (Sec.
170.314(b)(2)) and the data portability certification criterion (Sec.
170.314(b)(7)). Since the data portability certification criterion
mirrors a portion of the transitions of care certification criterion,
we have chosen to provide our response to comments on encounter
diagnoses when we discuss the transitions of care certification
criterion.
In consideration of the comments we received in response to our
questions about ICD-10-PCS, we agree with those commenters that argued
SNOMED CT[supreg] is a more appropriate vocabulary to reference in this
case. As commenters noted, SNOMED CT[supreg] is more appropriate for
clinical purposes and provides greater clinical accuracy. Thus, this
final rule requires that in order for EHR technology to be certified to
a certification criterion that references ``procedures'' data, it must
demonstrate compliance with the use of SNOMED CT[supreg] or CPT/HCPCS
(the latter is already adopted as part of the 2011 Edition EHR
certification criteria and was carried forward in the Proposed Rule).
However, in recognition that it may be beneficial for inpatient EHR
technology developers to demonstrate compliance with, and support for
the use of, ICD-10-PCS to represent procedures in the various
certification criteria that reference procedures, we have adopted ICD-
10-PCS as an ``optional'' vocabulary standard to which EHR technology
developers can seek certification for their EHR technology.
In consideration of the comment suggesting that we include CDT as
an alternative vocabulary for dentists, we have done so. However, we
have adopted this vocabulary as ``optional'' and in addition to (not in
lieu of) one of the primary vocabularies necessary for representing
procedures data. Therefore, in the event that an EHR technology
developer seeks to get its EHR technology certified to CDT, it will
have to also be certified to one of the mandatory standards we have
adopted for representing procedures, either SNOMED CT[supreg] or CPT/
HCPCS.
Comments. Commenters recommended that we delineate which data for
view is optional as which data is required.
Response. We decline to make this change. In order to be certified,
EHR technology must be capable of permitting a patient or their
authorized representative access to all of the data specified by the
certification criterion. What information is actually made available by
an EP, EH, or CAH and how it is displayed to a patient or their
authorized representative should be determined by the EP, EH or CAH.
Comments. Some commenters asked that we clarify that the term
``gender'' as proposed was really intended to mean ``sex'' given the
wide range of characteristics that could be encompassed by the term
gender.
Response. We agree. Both ONC and CMS have included the term ``sex''
in our final rules.
Comments. A commenter advocated that the substitution of patient
friendly terms for diagnoses should be permitted.
Response. We agree. We clarify and have modified the regulation
text to explicitly indicate that for view (and download) that where
certain coded data exists, the English language
[[Page 54179]]
descriptions and not the codes should be viewable to a patient or their
authorized representative.
Comments. Commenters recommended that we include the additional
flexibility of being able to import (save ``as is'') and view CCD/C32
and CCR documents in order to provide a transition between Stages 1 and
2. They stated that as a patient if they viewed an old CCD it should
still count towards the MU numerator.
Response. We did not accept this recommendation and have not
included this type of capability in the certification criterion. In
large part, these comments are out of scope for this rulemaking and
focus on measurement, which is relevant to the MU objective and measure
with which this certification criterion correlates. That being said,
the certification criterion does not specify how data is made viewable.
Taking this approach is not necessarily precluded by the certification
criterion and may somehow be able to address the view capability.
However, we are uncertain, without additional details, whether the use
of these older standard document formats would in practicality meet the
numerator and denominator requirements for the MU measure or the new
data required to be made viewable.
Comment. A commenter requested that we provide detailed
requirements to EHR technology developers on how to address potential
language barriers in their products (especially with regard to the use
of the patient portal). They stated that a language barrier would
negatively impact providers' abilities to engage patients and get them
to use the view, download, and transmit capabilities. They contended
that it would be inconsistent to require patient engagement through the
use of a patient portal and not provide common standards for multi-
lingual or predominantly non-English speaking communities where
providers might exclusively practice.
Response. While we appreciate this commenter's suggestion and
believe in the importance of multi-lingual accommodations, we believe
this suggestion is a significant departure from the certification
criterion proposed and would require additional study to determine how
to appropriately frame it as a certification requirement for EHR
technology. Thus, we have not changed the certification criterion in
response to this comment.
Comments. A commenter recommended that this certification criterion
should include more specific capabilities than we proposed such as,
accommodate patient generated data to ``upload'' into the EHR; include
linkages to patient specific education materials; and be based upon a
standing patient preference.
Response. We did not accept this recommendation. We believe the
certification criterion is properly scoped to support its correlated MU
objective and measure and do not seek to introduce additional burden
that could be value-added functionality outside the scope of
certification that EHR technology developers can include for
competitive purposes.
Accessibility
Comments. Commenters generally supported the underlying rationale
behind the proposal, with some endorsing the requirement as proposed.
Other commenters contended that achieving WCAG Level AA compliance in
the time available would be extremely difficult for EHR developers to
achieve. They stated that it is very complex to achieve compliance in a
real world scenario and that Level AA conformance imposes a burden too
great at this point in time. Further, they stated that the requirements
for interfacing to independent accessibility tools (also required by
WCAG 2.0), such as those that read screen text aloud can be impossible
to achieve for ``snappy'' and ``intelligent'' JavaScript-dependent
applications. One commenter noted that as of April 2012, two well-known
news sites reported 76 and 104 known problems, respectively. Some
commenters suggested removing this requirement altogether while others
suggested that we take a more incremental approach and start with Level
A conformance which could set the stage for a predictable progression
to Level AA at a later date. Commenters also requested that we clarify
that the WCAG standard would apply only to patient viewable information
as intended by this certification criterion.
Response. We appreciate commenters support for this proposal. As we
noted in the proposed rule, we believe that all patients should have an
equal opportunity to access their electronic health information without
barriers or diminished functionality or quality. We recognize that this
was a new requirement proposed for the 2014 Edition EHR certification
criteria and in considering the burden concerns identified by
commenters and need for greater experience with WCAG generally, we have
decided to require Level A conformance instead of Level AA. As some
commenters noted starting at Level A will provide a baseline from an
accessibility perspective and one on which we can build in future
rulemakings. Accordingly, we would like to express our intention to
propose requiring Level AA in our next rulemaking cycle and encourage
EHR technology developers to take the steps necessary to be on a path
towards Level AA conformance. We also clarify, as requested, that the
WCAG standards apply to the information that is viewable to the patient
or their authorized representative through the capabilities EHR
technology includes that would enable them to electronically view,
download, and transmit their health information to a 3rd party.
Comments. Comments stated that most patients want functions and
content provided in a more visually appealing manner than the standard
allows. Commenters requested that we clarify for certification whether
an EHR technology developer would need to show how the product can be
configured for WCAG 2.0 requirements by an implementer or whether the
EHR technology must be ``preconfigured'' to those requirements (e.g.
preset for font, contrast, color settings, etc). They stated, for
example, that an EHR technology developer might have a configuration
choice for accessibility that a consumer could opt for using that would
include setting the contrast, font, color scheme, etc. to be conformant
to accessibility requirements but allow other users to be able to
select other settings as a matter of choice. They suggested that for
certification it should be sufficient for an EHR technology developer
to show how the settings for accessibility can be configured, but not
predefined or preset.
Response. In order to demonstrate conformance with the
certification criterion, EHR technology will need to meet WCAG Level A.
So long as the EP, EH, or CAH (as the customer) can appropriately
configure the EHR technology for the patient, then that is sufficient.
The certification criterion does not specify that certain design
elements be predefined or preset.
Comment. A commenter suggested that we consider if there are third
parties that can provide supportive independent evidence of conformance
to the WCAG standards or if any self-attestation evidence can be
provided for review by the NVLAP-accredited testing laboratory so that
if a vendor has pursued such third party review, it does not have to do
so in repetition for the sake of 2014 certification.
Response. While we believe that such documentation could expedite
the review by a NVLAP-accredited testing laboratory, the EHR technology
would still need to be independently assessed by the testing laboratory
for
[[Page 54180]]
conformance following test procedures approved by the National
Coordinator.
Comments. Several commenters, in response to our request for
comment on the UAAG standard, did not support its adoption as part of
this certification criterion because they contended that it does not
apply to Web sites like patient portals. Rather, they stated that it
applies only to web browsers.
Response. We have not included or adopted the UAAG standards at
this time and appreciate commenters' detailed feedback.
Download
Comments. A couple of commenters stated their belief that in order
to meet the ``human readable'' aspect of this certification criterion
that an HTML view of the XML file for the Consolidated CDA should be
adequate for both viewing and downloading.
Response. As we have previously stated in the S&CC July 2010 final
rule (75 FR 44598) in response to questions about the meaning of human
readable, the use of a style sheet associated with a document formatted
according to the Consolidated CDA would be permitted.
Comments. Commenters asked that we specifically clarify that for
the ``download and transmit'' requirements, the data itself must be
downloaded and transmitted and not merely a link to the data is what is
downloaded and transmitted.
Response. Yes, the data itself must be downloaded and transmitted.
A hyperlink to the data would not be sufficient for EHR technology to
demonstrate compliance with this certification criterion.
Comments. Many commenters supported the proposed adoption of the
Consolidated CDA standard and our proposal to move to this as the
single standard. Some opposed this proposal altogether, while others
suggested that the previously adopted CCD standard as well as the CCR
standard should continue to be permitted because the Consolidated CDA
was immature.
Several commenters requested clarification related to the aspects
of the Consolidated CDA that are required for certification. More
specifically, they stated that the Consolidated CDA is an
implementation guide for nine different document types (eight
structured and one unstructured), and that it would not only be
inappropriate to require the use of all of these document types for all
environments but would in fact not make sense for elements like a
discharge summary for an EP). Many recommended that the certification
requirement be that the EHR technology should demonstrate the ability
to generate at least one of the available CCDA document types and that
providers will be able to use the document type most appropriate to the
clinical situation.
A couple of commenters stated that we should explicitly prohibit
the use of the unstructured document template because not doing so
would allow EHR technology developers to bypass using structured and
coded data.
Last, a couple of commenters noted that each time a ``care
summary'' is specified in the Proposed Rule that it was described
slightly differently. They contended that these differences will cause
unnecessary confusion and disruption throughout the care delivery
process. Additionally, they noted that none of the data sets specified
for the certification criteria that reference the Consolidated CDA
precisely matched any existing document-level templates in the
Consolidated CDA.
Response. We appreciate commenters support for the Consolidated
CDA, and have finalized its adoption in the final rule. We believe that
moving to a single standard is absolutely necessary to advance
interoperability. The Consolidated CDA represents a significant amount
of effort by industry stakeholders and we believe it is the best
available standard to require for certification and to meet our policy
objectives for interoperability. As noted by some commenters and, what
appeared to be unknown to others, the Consolidated CDA is not per se a
competing standard with the CCD because it contains within it a
document-template that describes how to implement a CCD according to
new, harmonized and consolidated implementation guidance (CCD v1.1). So
the CCD document-template represented in the Consolidated CDA is an
update to the CCD/C32 implementation guidance. That being said, as
precisely noted by commenters, none of the 8 specific structured
document-level templates in the Consolidated CDA neatly support the
data specified by this certification criterion as well as the others in
which it is also referenced (clinical summary, transitions of care, and
data portability). Accordingly, we clarify that, with respect to the
Consolidated CDA, certification will not focus on a specific document-
level template because none are particularly suited to support MU's
policy objectives and the data elements specified across the different
certification criteria that reference the Consolidated CDA. Rather,
certification will focus on an EHR technology's ability to properly
implement the US Realm header and the associated section-level
templates necessary to support each certification criterion in which
the Consolidated CDA is referenced and for the appropriate data
specified in each of those certification criteria. We intend for
testing and the test data made available for these certification
criteria to enable consistent Consolidated CDA implementations.
Further, based on our policy decision to focus testing and
certification on section-templates, we have performed additional
analysis of the Consolidated CDA. Based on our analysis, we note that
absent certain conformance requirements otherwise specified in a
particular document-level template, our approach could result in
implementation ambiguities. These ambiguities could exist because
section-templates when viewed independently of a particular document-
template permit the use of narrative text, coded entries optional, or
narrative text and required structured data, coded entries required.
Thus, we believe it is necessary to clarify for EHR technology
developers that in all instances where we have adopted a vocabulary
standard in Sec. 170.207 the accompanying section-template implemented
must be done so using the section-template with required structured
data, coded entries required.
We agree with the comments that suggested we prohibit the use of
the unstructured document-template included in the Consolidated CDA. As
referenced in the Consolidated CDA, an ``unstructured document is a
document which is used when the patient record is captured in an
unstructured format that is encapsulated within an image file or as
unstructured text in an electronic file such as a word processing or
Portable Document Format (PDF) document.'' We believe that permitting
this document template to be used as part of the Consolidated CDA or
leaving any ambiguity as to whether it can be used to meet this
certification criterion would be inconsistent with our policy
objectives. Thus, we have indicated in Sec. 170.205(a)(3) where we
have adopted the Consolidated CDA that the use of the unstructured
document template is not permitted.
We also take this opportunity to identify for stakeholders a
modification we believe must be made to this certification criterion in
order to align our final rule with clarifications made in CMS's final
rule and, ultimately, in order to ensure the CEHRT EHs and CAHs adopted
can support their achievement of MU. Further, this modification is only
applicable to the inpatient setting only and is designated in the
certification criterion as such. In its proposed rule (77 FR, 13730)
CMS
[[Page 54181]]
proposed that one of the information types, a patient should be able to
download would be their ``care transition summary and plan.'' In
response to comments, CMS clarified and has listed these two
information types as separate kinds of information that must be able to
be downloaded. Accordingly, we have included in this certification
criterion that for the inpatient setting a patient would need to be
able to electronically download transition of care/referral summaries
that were created as a result of a transition of care/referral
(pursuant to the capability expressed in the certification criterion
adopted at paragraph Sec. 170.314(b)(2)). We believe this addition
poses limited additional burden since EHR technology would just need to
be able to make available for download any transition of care/referral
summaries created as a result of a transition of care (so if a patient
has had multiple hospitalizations during the EHR reporting period and
been transitioned out of the hospital, the EHR technology would need to
be capable of making available both inpatient summaries and transition
of care/referral summaries that were created as a result of the
transitions).
We received comments on our proposal to adopt the Consolidated CDA
where it was proposed for other certification criteria. In drafting
this comment and response we considered those comments and included
them in the comment summary above. Accordingly, our response here to
the proposal to adopt the Consolidated CDA is not repeated in the other
certification criteria where its adoption was also proposed.
Comments. A couple of commenters stated that we mentioned in the
Proposed Rule that there needs to be a confidentiality type included in
the CCDA. They noted that it was unclear what that requirement meant in
the use case where a patient downloads their information. They
requested further clarification and guidance on the indication of this
element within this certification criterion.
Response. As we noted in the Proposed Rule, one of the metadata
elements required by the US Realm Header is the ConfidentialityCode
which should be populated with a value from the value set of
BasicConfidentialityKind (this value set includes 3 possible values:
``N'' Normal, ``R'' Restricted, and ``V'' Very Restricted). In this
context, we believe that ``N'' would likely be the default value.
Comments. Several commenters stated that we should require EHR
technology to include the capability to do a ``Blue Button'' download.
Other commenters opposed this idea because all that would be downloaded
would be a text file. They contended that such an outcome would be a
step backwards from requiring the Consolidated CDA.
Response. The view, download, and transmit capabilities required by
this certification criterion are fully aligned with the Blue Button
goals of empowering patients to be partners in their health care
through access to and use of personal health information. We expect the
Blue Button vision to evolve and expand to encompass a variety of
technical solutions beyond the traditional download of a text file,
including view, download, and transmit capabilities. Along those lines,
we strongly encourage every EHR technology developer to associate this
certification criterion's download capability related to a human
readable file with the increasingly popular ``Blue Button'' phrase and
logo. To be clear, we also require for certification that EHR
technology be capable of enabling a patient or their authorized
representative to be able to download a file formatted according to the
Consolidated CDA.
Comments. Commenters noted that the Consolidated CDA had been
updated since the Proposed Rule was published and urged us to adopt the
most recent version in the final rule.
Response. We agree with commenters and have adopted the HL7
Implementation Guide for CDA[supreg] Release 2: IHE Health Story
Consolidation, Draft Standard for Trial Use (DSTU) Release 1.1 (US
Realm) Draft Standard for Trial Use, July 2012. This version of the
Consolidated CDA constitutes the most recent balloted version--a
process which has been underway since the Proposed Rule was published.
It corrects errors in the prior version, and was modified to more fully
and closely support capturing the MU data that CMS requires for EPs,
EHs, and CAHs to meet certain MU objectives and measures related to
transitions of care, clinical summaries, and providing patients with
the ability to view, download and transmit their health information. As
noted by HL7 in its documentation, this DSTU version of the standard
will be open for comment for 24 months and following this evaluation
period, it will be revised as necessary and then submitted to ANSI for
approval as an American National Standard (normative standard).
Further, HL7 specifies that implementation of this DSTU version will be
valid during the ANSI approval process and ``for up to six months after
publication'' of the normative standard. Given the state at which this
DSTU version of the standard is and the fact that this version alone is
subject to the evaluation period, we believe that it is the best
possible choice for this final rule, especially in place of the draft
version we referenced in the Proposed Rule.
Comments. A few commenters stated that this certification criterion
did not expressly include privacy and security requirements. They
suggested that we should require EHR technology to be able to ensure
that a patient's online experience is secure. They recommended that we
specify requirements for authentication such as OAuth as well as a
specific level of assurance (NIST level 3). They also recommended that
we require EHR technology to be certified for its ability to establish
a secure channel for view and download.
Response. We are convinced by commenters that it is important and
necessary to add a more explicit requirement for security in this
certification criterion. In that respect, we have revised our proposed
criterion to accept commenters' suggestions in part. As suggested, we
have included a requirement that EHR technology must be able to
establish a secure channel through which a patient can access the
capabilities to view, download, and transmit their electronic health
information. We agree that certification can provide some assurance
that EHR technology can properly establish for a secure channel through
which health information can be viewed, downloaded, and transmitted.
This secure channel requirement mirrors that portion of the secure
messaging certification criterion. Thus, it is possible for an EHR
technology to be certified to both this certification criterion and the
secure messaging certification criterion, depending on how it is
designed.
We continue to decline to change the certification criterion in
response to commenters' recommendations that we prescribe a particular
form or ``level of assurance'' for authentication. It is not that we
disagree that some form of authentication will be necessary when EHR
technology certified to this certification criterion is implemented.
Rather, as some comments suggest, there is significant innovation
taking place with respect to authentication. Thus, we believe that
requiring a particular form in this certification criterion would be
overly prescriptive and have little practical effect on the eventual
authentication approach EPs, EHs, or CAHs implement.
[[Page 54182]]
Comment. A commenter noted that the Consolidated CDA stated that
vital signs are an optional section which may be included in CCDs,
while the Proposed Rule stated that this section is required. They
contended that if such discrepancies are allowed to persist, EHR
technology developers will inevitably make mistakes on what they choose
to include and marked heterogeneity will persist.
Response. We seek to make clear for this commenter (and this
response is generally applicable to any instance where we have adopted
certification criteria that reference standards and required data) that
this final rule and its requirements take precedence (i.e., override)
any ``optional'' requirements in a standard or implementation
specification if they are deemed required as part of a certification
criterion. For example, if sections or certain data in an
implementation guide are designated ``optional,'' but a certification
criterion requires compliance with such sections or data, EHR
technology must be designed to comply or accommodate those sections or
data in order to meet the certification criterion.
Transmit
Comments. Many commenters asked that we clarify why a SOAP-based
transport standard was not proposed as part of this certification
criterion when it was for the transitions of care certification
criterion. Commenters contended that this was an inconsistency and
asked that ONC and CMS reconcile the two. They also referenced CMS's
proposed rule and preamble that stated that transmission could occur
via any means of electronic transmission according to any transport
standards for the view, download, and transmit to a third party
objective. Other commenters stated that other transport standards
should be permitted for use, such as those for query and response.
Last, commenters asked questions about workflow and how transmission
should be implemented so that a patient's information can be
transmitted to a 3rd party.
Response. There was no inconsistency between the ONC and CMS
proposed rules. The proposed transport standard(s) for each
certification criterion were purposefully chosen and proposed to
specify the capabilities EHR technology would need to include in order
to demonstrate compliance with each certification criterion. Commenters
have confused two very distinct concepts: (1) What is required for EHR
technology to demonstrate compliance with a certification criterion;
and (2) how EHR technology, once certified, must be used to demonstrate
meaningful use. We seek to make this distinction clear to prevent any
further confusion.
The certification criteria adopted in this final rule apply to EHR
technology and only EHR technology. The final rule specifies the
technical capabilities that EHR technology must include and other
requirements that must be met in order for EHR technology to be
certified. This rule does not specify in any way how EHR technology,
once certified, must be used in order to achieve meaningful use. That
policy is expressed in CMS's rules and is identified for each MU
objective and associated measure. In this scenario with the view,
download, and transmit to a 3rd party and transitions of care
objectives and measures, CMS purposefully proposed two different
policies.
For view, download, and transmit to a 3rd party CMS expressly
indicated that other transport standards beyond those required for
certification could be used by EPs, EHs, and CAHs. However, for
transitions of care, CMS expressly indicated that only the transport
standards permitted for certification would count in an EP, EH, or
CAH's numerator for the measure. Thus, for the transitions of care
certification criterion, we included the SOAP-based transport standard
as an option for certification to expand the potential approaches EPs,
EHs, and CAHs could take to also include electronically transmitted
transition of care/referral summaries according to that standard in the
transitions of care measure's numerator. In other words, had we not
proposed the SOAP-based transport standard as an option in the
transitions of care certification criterion, EPs, EHs, and CAHs would
have been limited to meeting that MU objective and measure through only
the use of the Applicability Statement for Secure Health Transport
specification (the primary Direct Project specification). In the case
of view, download, and transmit to a 3rd party, we proposed the
adoption of the Applicability Statement for Secure Health Transport
specification because we believe it is necessary for EHR technology
certified to this certification criterion to include at least the
capability to use that transport standard, even though CMS permits EPs,
EHs, and CAHs to use alternative transport standards. We note that
consistent with the changes we have made in the transitions of care
certification criterion, we are requiring certification only to the
Applicability Statement for Secure Health Transport standard and not
also the second Direct Project specification (XDR and XDM for Direct
Messaging). Additionally, the Applicability Statement for Secure Health
Transport has been updated to Version 1.1 (July 10, 2012). We have
adopted this version of the specification because it improves EHR
technology implementation and the testing of the specification's
requirements and, consequently, makes the version of the specification
we proposed outdated. Version 1.1 was established by the stakeholder
community during this final rule's drafting. Version 1.1 of the
specification provides clearer instruction for implementation through
additional guidance on how certificates can be discovered in a
consistent manner. If we had adopted the proposed version, EHR
technology developers would have encountered difficulty with
consistently implementing EHR technology to the specification and
testing of the specification's requirements would have been hindered.
Last, we do not believe that it is within this rule's scope to
specifically describe a particular workflow or how transmission should
be implemented. Many commenters raised certification concerns related
to the Applicability Statement for Secure Health Transport
specification when they commented on the transitions of care
certification criterion. Thus, we do not repeat those concerns and our
responses and instead address them once in the transitions of care
certification criteria comment and responses.
Comments. Commenters stated that the reference to the Applicability
Statement for Secure Health Transport specification was the right
direction to take for provider-to-provider (or clinician or
organization) transmissions but that it was unclear whether this
specification was also appropriate for a patient-focused certification
criterion. They requested that the ``transmit to third party'' via this
standard should be clarified to express that the intended transmission
was to another provider or a personal health record (PHR). They
contended that the standard should not be required for transmission to
other individuals who are not providers (e.g., friends, relatives,
etc.). Additionally, they stated that in this latter case the word
``transmission'' may not necessarily mean it was transmitted
electronically (or in a manner that can be tracked) because the
information could be loaded onto a USB drive, DVD, or even printed in
being transferred to a new physician by a patient.
Response. We expect that if the Applicability Statement for Secure
Health Transport specification is used to complete a transmission to a
3rd party that the receiving party would be
[[Page 54183]]
another health care-oriented entity, like a PHR company the patient is
using and that it would not be a patient's friend or relative.
Furthermore, for the purposes of this certification criterion, the more
generic interpretation of the word ``transmission'' stated by the
commenter would not be within the scope of this certification criterion
as we do not consider transferring data to electronic media like a USB
drive or DVD to constitute an ``electronic transmission'' for the
purposes of certification.
Comments. Some commenters agreed that patients should be permitted
to transmit their health information to another entity, but stated that
we should not burden the health care provider to be the party that
transmits this information on their behalf. They contended that health
care providers should not be a relaying entity on behalf of their
patients.
Response. For clarity, we have revised this certification criterion
to state that EHR technology must provide patients (and their
authorized representatives) with an online means to view, download, and
transmit to a 3rd party the data required by the certification
criterion. In this sense, it is the EHR technology that an EP, EH, or
CAH has that is performing this function, not the EP, EH, or CAH. Thus,
we believe that the burden identified by commenters is misplaced.
Comments. A commenter recommended that we consider requiring the
transmittal of a provider's National Provider Identification (NPI)
number when an NPI has been assigned. They reasoned that including the
NPI would allow receiving systems to more easily cross reference
provider information that might already exist in the receiving system
database.
Response. We decline to change the certification criterion based on
this suggestion. We note that the US Realm Header for the Consolidated
CDA does require that at least one ``author'' be identified and further
that the ``assigned Author'' shall contain at least one ``id'' which
the standard recommends with a ``should'' as being the NPI.
Download and Transmission of Images
Comments. Commenters generally supported the principle of providing
patients with access to images, however, only a few commenters outright
supported our proposal. One commenter that supported our proposal
suggested that images also be included in the ``view'' part of the
certification criterion and stated that diagnostic quality is
unnecessary for patient viewing. They encouraged us not to suggest a
standard for image viewing by patients. Another commenter asked if we
intended for images to be available for viewing in a basic distribution
viewer or if small images embedded in the report or images viewed
without tools in a browser would meet the certification criterion's
intent. They suggested that we require a basic distribution viewer to
be part of the ``view'' portion of the certification criterion. One
commenter stated that if we did not specify DICOM as a requirement for
certification, that we should at least make available the option for
EHR technology to be certified to the standard for the purposes of
image downloads.
Several commenters strongly opposed or requested that we remove the
capability and proposed standard. These commenters stated that
including images for download and transmission by a patient would be a
challenging requirement. They also contended that this capability
exceeded the requirements in CMS's proposed rule. Additionally, these
commenters stated that images are typically stored in a system separate
from EHR technology (i.e., a PACS system) and that this requirement
would add significant complexity and burden to the certification
criterion. They followed this comment by stating that the industry norm
is for CDs with pertinent images to be given to a patient with an image
reader that allows for viewing. A similar point was made by other
commenters who stated that requiring DICOM for the transmission would
force the recipient of the images to have a DICOM compliant viewer and
to import the images into that viewer before they could be viewed. Many
commenters noted that an image's average file size would present
significant storage and cost challenges for online downloading and
transmitting. The JPEG file format was recommended as a potential
solution since patients did not necessarily need diagnostic quality
images.
Response. In consideration of the comments received and the
complexity and potential burden identified by commenters, we have
decided to remove the requirement for images to be available for
download and transmission to a third party. We believe further industry
dialogue needs to occur with respect to images and our policy goal of
enabling patients to have ready, online access to their images. We
expect to include this topic on the HITSC's agenda for the next edition
of EHR certification criteria we would adopt through rulemaking and
intend to propose a requirement for online image access in a future
edition of this certification criterion.
Comments. We received the following additional comments that did
not fall within the general scope of the comments summarized above. One
commenter proposed that a secure hyperlink to the image, supplied by
the radiologist and conveyed via the Direct Project standard, become
the method of making DICOM images and radiology reports available to
patients and ordering providers. A commenter suggested that for image
download a patient should be able to identify the location of a study
to be referred to another provider as acceptable for the certification
criterion. Last, a separate commenter asked that we specify for the
``download and transmit'' requirements, the IHE Portable Data for
Imaging (PDI) profile.
Response. We appreciate commenters' feedback. Given our decision to
remove the requirement for image downloading and transmission to a
third party, we will take this feedback into consideration for our
future work with the HITSC as well as our next rulemaking.
Patient Accessible Log
Comments. Several commenters opposed this proposed specific
capability in the certification criterion because they thought it was a
means to implement the HHS Office for Civil Rights (OCR) HIPAA Privacy
Rule accounting of disclosures proposal (76 FR 31426) for patients to
be able to get an ``access report.''
Response. These commenters are mistaken. This aspect of the
certification criterion was not intended to implement the Department's
proposal to give individuals a right to receive an ``access report.''
However, given this confusion, we have decided to change the paragraph
heading for this part of the certification criterion to state
``activity history log.'' The purpose of this paragraph in the
certification criterion is to simply require that EHR technology be
able to monitor when a patient or their authorized representative(s)
views, downloads, or transmits their health information to a third
party. Those are the actions to which this paragraph referred in the
proposed certification criterion. Put simply, this activity log is
meant to assist a patient track the history of their actions or those
of their authorized representatives.
Comments. Many commenters stated that the Proposed Rule did not
clarify or offer a statement regarding how far back in time a patient
accessible log should be able to retrieve log event data. They also
sought clarification on who a user could be and what would be
sufficient data to include in the log.
[[Page 54184]]
Response. The time period for which the activity history log should
be available is a policy determination that should be made by the
organization who implements EHR technology certified to this
certification criterion. Thus, we decline to specify a particular
retention period in this certification criterion. What is necessary for
certification is that an EHR technology can demonstrate that it can
properly create such a log. As noted in our response directly above, we
intend for ``user'' in this context to be the patient and any
authorized representative(s) to whom they have provided access to view,
download, and/or transmit their health information to a third party.
Comments. Several commenters supported the ``credit'' we sought to
provide if EHR technology leveraged its general auditing capabilities
to fulfill the requirements specified by this capability. However, they
asked that we clarify that our proposal did not imply electronic or
immediate access to the general audit trail via either the Complete EHR
or portal. Some commenters explicitly stated that they would oppose any
requirement for immediate electronic access to the general EHR
technology audit log online. They also requested confirmation that the
access does not need to be provided online. Rather, they suggested that
EHR technology could produce a printed document for a patient to
review, upon request. They also requested clarification that the log
could provide summary information, (e.g., that a patient summary was
sent to a third party) and not be required to list all the information
contained in the summary document that was transmitted.
Response. This certification criterion does not require an EP, EH,
or CAH's general EHR technology security audit log to be made available
to patients online. However, the activity history log must be available
online and readily accessible. We hope that the past two responses have
helped clarify many scope-oriented points for these commenters because
it was our proposal and our continued belief that the activity history
log should be online and readily available for a patient (or their
authorized representative) to review ``on demand.'' Given the
clarifications and the limited burden we believe is associated with
tracking when a ``view,'' ``download,'' and ``transmission'' has
occurred and by whom and when, we do not believe that this should be a
significantly challenging capability to include. Accordingly, we have
finalized this portion of the proposed certification criterion by
changing the paragraph heading and making clear that the actions that
need to be tracked are simply ``views,'' ``downloads,'' and/or
``transmissions'' that have occurred and by whom and when.
Comments. Commenters expressed support for our proposed
``synchronized clocks'' standard and our proposal to permit either
NTPv3 or NTPv4. They noted that the use of these synchronization
technologies is very common and supported in all major operating
systems. Along those lines, they stated that it was unclear why this
would be a requirement for EHR technology certification because it is
unlikely that the EHR technology itself will be directly implementing
this type of synchronization and more likely that it will be relying on
the lower level systems' clock functionality (e.g., the operating
system within which the EHR technology runs). One commenter stated that
it is important to avoid a requirement that would make the operating
system (that provides the standard clock) part of what is needed for
EHR certification as this would impose artificial limits on what
operating systems can be used without certifying multiple permutations.
This commenter contended that because the ability to use an operating
system clock is common, it was unnecessary for this standard to be
required for certification. They requested that if we did include it
for certification, that we acknowledge that: the operating system keeps
the time, the EHR technology gets the system clock, and that a
particular operating system is not required to be part of EHR
technology for certification.
Response. We thank commenters for supporting this proposal. As we
indicated in the Proposed Rule, our responses here also apply to
comments received on other certification criteria that also referenced
the ``synchronized clocks'' standard. We acknowledged in the Proposed
Rule and here again our understanding and expectation that EHR
technology will likely obtain a system time from a system clock that
has been synchronized following the NTPv3 or NTPv4 standard. We
expressly worded the standard to acknowledge this likely scenario by
stating ``[t]he date and time recorded utilize a system clock that has
been synchronized * * *.'' (Emphasis added.) We do not intend for this
specific capability to create a binding relationship between EHR
technology and a particular operating system. For certification, EHR
technology must be able to demonstrate, as the standard states, that it
can utilize a system clock that has been synchronized following NTPv3
or NTPv4. Accordingly, we have retained this proposal and finalized it
for the certification criteria to which it pertains.
Automated Numerator Recording
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
N/A
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(g)(1) (Automated numerator recording).
------------------------------------------------------------------------
To complement the ``automated measure calculation'' certification
criterion adopted at Sec. 170.314(g)(2), we proposed to adopt a 2014
Edition EHR certification criterion that would apply solely to EHR
Modules that include capabilities to support an MU objective with a
percentage-based measure. We stated that the focus of this new
certification criterion would be on the EHR Module's capability to
automatically record the numerator for those measures. We proposed to
adopt this new certification criterion at Sec. 170.314(g)(1).
We clarified that, while a Complete EHR would need to be capable of
meeting the ``automated measure calculation'' which requires the
capability to accurately calculate MU denominators, we did not believe
that it would be practicable for an EHR Module to do the same because,
in most cases, an EHR Module would likely be unable to record or have
access to an accurate denominator. We did, however, believe that EHR
Modules presented for certification to certification criteria that
include capabilities for supporting an MU objective with a percentage-
based measure should at least be able to readily and accurately record
the numerator for those capabilities.
Comments. Many commenters supported our proposal in concept and as
written. Some of these commenters stated that this certification
criterion was a welcome improvement and would ease the reporting burden
for small providers and hospitals. Other commenters contended that our
proposal had a logical flaw and requested that we clarify how an EHR
Module would be able to accurately capture the appropriate numerator
because the numerator is often a subset of the patients or actions that
qualify to be in the denominator. As such, some commenters echoed what
we had stated in the Proposed Rule (that it may be difficult for an EHR
Module to know the true denominator) and expressed concern that this
requirement could not be implemented without additional burden. Some
commenters suggested that we remove this certification criterion
altogether, while others requested that modify this certification
[[Page 54185]]
criterion to fix the logic challenge and asked that we clarify the
expected testing and certification process for this certification
criterion if it were to remain in the final rule.
Response. We appreciate commenters support for this certification
criterion. We have adopted a revised version of the certification
criterion. We acknowledge that this certification criterion requires
additional explanation and clarity related to our intended outcome. We
agree with commenters that, unless clarified, this proposed
certification criterion could pose logic problems for EHR technology
developers and, correspondingly, that the conditions we expected to be
met in our proposal would be difficult to achieve. Especially in
circumstances where the EHR Module has no basis on which to determine
the patients or actions that would be part of the denominator specified
for a given MU measure.
In response, we offer the following clarifications. We proposed
this certification criterion in order to make it easier and more
efficient for EPs, EHs, and CAHs who pursue an EHR Module approach to
meet the CEHRT definition to determine their EHR MU measure
percentages. As we acknowledged in the Proposed Rule, this
certification criterion could only help so much because of the
potential that an EHR Module would not necessarily have the ability to
determine the appropriate denominator for a given measure. We agree
with commenters that this limitation can extend to the numerator in
cases where the numerator is a subset of the denominator. To address
this logic issue, we have modified the certification criterion to focus
on what we believe an EHR Module will be able to determine without any
specific dependency on an MU measure's denominator. This certification
criterion now focuses on an EHR Module's ability to correctly identify
the patients or actions that would meet the numerator's requirements
generally and without the denominator's limitations applied. Thus, we
clarify that for the purposes of testing and certification, an EHR
Module would not need to be able to precisely identify the MU numerator
after all of the denominator's filtering had been applied. Instead, it
will need to be able to identify the patients or actions that would
generally meet the numerator and the minimum denominator criteria that
would be necessary to match the information provided by the EHR Module
to the full denominator criteria from other data sources. We have
revised the certification criterion to make this point clear.
Additionally, to reflect that in order for this information to be
useful to an EP, EH, or CAH to determine the true numerator, the EHR
Module (similar to the automated measure calculation certification
criterion) would need to be able to produce a file/report that
identifies those patients or actions that would meet the numerator. We
provide the following examples to illustrate the capability that an EHR
Module would need to include. We note that depending on the
certification criterion or criteria to which the EHR Module is
presented for certification that the potential approach to determine
the overall number of patients or actions may be different. We intend
to provide guidance as necessary with more examples for each MU
objective and measure that this certification criterion would need to
support. Ultimately, we believe this information will also help EHR
technology developers better understand the numerators and denominators
associated with the MU measures.
Example 1: An EHR Module presented for
certification that includes CPOE and seeks to be certified to
certification criterion at 170.314(a)(1). To meet the automated
numerator calculation certification criterion, the EHR Module would
need to be able to correctly identify a simple number, the number of
orders created using the EHR Module. An EP, EH, or CAH would then
need to take this output from the EHR Module and compare it to the
total number of orders made (inclusive of those where the EHR Module
was not used).
Example 2: An EHR Module presented for
certification that includes e-prescribing capabilities and seeks to
be certified to certification criteria at 170.314(a)(10) (drug
formulary check) and 170.314(b)(3) (electronic prescribing). To meet
the automated numerator calculation certification criterion, the EHR
Module would need to be able to correctly identify a slightly more
complicated number, number of permissible prescriptions for which
the existence of a drug formulary was queried and a prescription
subsequently electronically transmitted. Given this overall number,
an EP, EH, or CAH would then need to take this output from the EHR
Module and compare it to the total number of permissible
prescriptions written for drugs requiring a prescription, which
would need to be obtained from somewhere else.
Example 3: An EHR Module presented for
certification that includes the ability to record patient
demographics and seeks to be certified to certification criterion at
170.314(a)(3). To meet the automated numerator calculation
certification criterion, the EHR Module would need to be able to
correctly generate a list of patients that identifies each and every
patient in the EHR Module who have all of the demographic elements
recorded as structured data (or that the patient declined or not
collectable under state or local law). An EP, EH, or CAH would then
need to take this output from the EHR Module and compare it to the
data source they would use to identify unique patients seen during
the EHR reporting period (the denominator limitations for this MU
measure).
Example 4: An EHR Module presented for
certification that includes the ability to provide patients (and
their authorized representatives) with an online means to view,
download, and transmit to a 3rd party electronic health information
and seeks to be certified to certification criterion at
170.314(e)(1). To meet the automated numerator calculation
certification criterion, the EHR Module would need to be able to
correctly generate a slightly different list of patients that
identifies each and every patient in the EHR Module who have taken
one of those three actions. An EP, EH, or CAH would then need to
take this output from the EHR Module and compare it to the data
source they would use to identify unique patients seen during the
EHR reporting period (the denominator limitations for this MU
measure).
As illustrated by these examples, many MU measures share similar
denominators. Thus, we expect that once an EP, EH, or CAH identifies
the source they will use as the basis for a denominator (i.e., number
of unique patients seen during the EHR reporting period) that it should
be relatively straight forward given the information an EHR Module
would be required to produce for the EP, EH, or CAH to determine the
true numerator.
Comment. A commenter acknowledged that this proposed certification
criterion would be applicable to EHR Modules and requested that we
clarify whether this policy applied to EHR technology developers who
follow an incremental EHR Module certification approach on the way to
designing EHR technology that could satisfy the Complete EHR
definition. They stated that if our answer was yes, that it would be
overwork for such EHR technology developers and requested an exemption
for this scenario.
Response. This requirement is broadly applicable to every EHR
Module presented for certification and we decline to provide any
exemption. While an EHR technology developer may pursue this approach,
we do not believe that it would be prudent to offer such an exemption
because it is equally likely that the EHR technology developer could
decide to stop before it could seek certification for enough EHR
Modules that would cumulatively satisfy the Complete EHR definition. If
that were to occur, EPs, EHs, and CAHs that had adopted these EHR
Modules would be at a disadvantage. Given the revised CEHRT definition
and the fact that EPs, EHs, and CAHs do not
[[Page 54186]]
necessarily need to have the same quantity of EHR technology certified
to the 2014 Edition EHR certification criteria as they would have under
our prior CEHRT definition, we believe that this could reduce the
potential burden assumed by this commenter and, depending on its
customer base, reduce the need to seek Complete EHR certification in
the first place.
Comment. A commenter asked that we confirm whether it would be
permissible for an EHR Module presented for testing and certification
get certified to the automated measure calculation certification
criterion instead of the automated numerator certification criterion.
Response. Yes, this approach is permitted and encouraged in
instances where EHR technology developers have developed a sufficiently
large EHR Module such that it could meet the automated measure
calculation certification criterion for all of the capabilities it
includes and that correlate to percentage-based MU measures. We clarify
that this approach would satisfy the EHR Module certification
requirement specified in Sec. 170.550(f)(1). Where possible, we
encourage EHR technology developers to follow this approach in order to
provide EPs, EHs, and CAHs with the most efficient means of identifying
the numerators and denominators for an MU EHR reporting period. We also
note that it is also permitted and encouraged for EHR technology
developer to seek certification for a combination of automated
numerator and measure calculation certification criteria where the EHR
Module may have a reliable and known denominator that can be used as
the basis for calculating certain percentage-based MU measures.
Non-Percentage-Based Measure Use Report (not adopted)
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
N/A
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
N/A
------------------------------------------------------------------------
In the Proposed Rule, we proposed to adopt a certification
criterion at Sec. 170.314(g)(3) that would have applied to any EHR
technology presented for certification that included capabilities
associated with MU objectives and measures that were not percentage
based. We noted that this certification criterion would focus on a
Complete EHR's or EHR Module's capability to record that a user had
certain EHR technology capabilities enabled during an EHR reporting
period and had used those capabilities to demonstrate MU. Further, we
stated that in consultation with CMS, we believed that EPs, EHs, and
CAHs would benefit from this type of capability being required as a
condition of certification and that such a capability could provide
EPs, EHs, and CAHs with valuable evidence in the event of a MU audit.
We proposed that any EHR technology presented for certification to any
one of the following certification criteria would need to be certified
to this certification criterion.
--------------------------------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------------------------------
170.314(a)(2).................................. Drug-drug, drug-allergy interaction checks.
170.314(a)(8).................................. Clinical decision support.
170.314(a)(10)................................. Drug-formulary checks.
170.314(a)(14)................................. Patient lists.
170.314(a)(17)................................. Electronic medication administration record.
170.314(f)(2).................................. Transmission to immunization registries.
170.314(f)(4).................................. Transmission to public health agencies (surveillance).
170.314(f)(6).................................. Transmission of reportable laboratory tests and values/results.
170.314(f)(8).................................. Transmission to cancer registries.
--------------------------------------------------------------------------------------------------------------------------------------------------------
Comments. Several commenters opposed this proposed certification
criterion and suggested that it was unduly burdensome. Many indicated
that we had significantly underestimated the complexity involved with
accurately capturing this information. Commenters cited several
examples and noted that this proposed certification criterion required
different analysis far beyond just ``yes/no'' settings for many of the
certification criteria listed above. They noted that the use of eMAR is
not an on/off step and questioned how we expected enabling ``ongoing
submission'' for public health reporting to be recorded. Commenters
stated that requiring this certification criterion would take away from
the EHR technology development time necessary to address the
certification criteria that were necessary to support MU objectives and
associated measures. Last, commenters indicated that the fact the
capability was active should be sufficient for MU, as well as
attestation, because there is not a separate requirement in MU
associated with the frequency each particular capability is used.
Response. In response to commenters' feedback we have not included
this proposed certification criterion in the final rule. We acknowledge
some of the complexities raised by commenters and that additional
aspects as well as specificity would be necessary for a more effective
certification criterion. However, we continue to believe in the spirit
and direction of this certification criterion so that ultimately EPs,
EHs, and CAHs could be in a position to electronically report even the
non-percentage based MU objectives and measures. In light of the
questions raised by stakeholders we intend to engage the HITSC and
HITPC on how to best reach this goal.
Safety-Enhanced Design and Quality Management System
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
N/A
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(g)(3) (Safety-enhanced design).
Sec. 170.314(g)(4) (Quality management system).
------------------------------------------------------------------------
Safety-enhanced Design
In the Proposed Rule, we provided an overview of the ISO definition
of usability as ``[t]he extent to which a product can be used by
specified users to achieve specified goals with effectiveness,
efficiency, and satisfaction in a specified context of use.'' \9\ We
outlined that EHR technology certification could introduce some
improvements in usability, which we believed would enhance both the
safety and efficiency of CEHRT. In the Proposed Rule, we also reviewed
the November 2011 Institute of Medicine (IOM) report titled, ``Health
IT and Patient Safety: Building Safe Systems for Better Care,'' in
which the usability of EHR technology and quality management was often
referenced. The IOM noted that ``[w]hile many vendors already have some
types of quality management principles and processes in place, not all
vendors do and to what standard they are held is unknown.'' The IOM
recommended that ``[t]he Secretary of HHS should specify the quality
and risk management process
[[Page 54187]]
requirements that health IT vendors must adopt, with a particular focus
on human factors, safety culture, and usability.''
---------------------------------------------------------------------------
\9\ ISO 9241-11.
---------------------------------------------------------------------------
We proposed that a significant first step toward improving overall
usability would be to focus on the process of user-centered design
(UCD). While valid and reliable usability measurements exist, including
those specified in NISTIR 7804 ``Technical Evaluation, Testing and
Validation of the Usability of Electronic Health Records,'' \10\ we
expressed that it would be inappropriate for ONC to seek to measure EHR
technology in this way. Recognizing that EHR technologies exist and are
in use today, we prioritized eight certification criteria \11\ and
associated capabilities to which the proposed certification criterion
would require UCD to have been applied. We chose these eight because we
believed they pose the greatest risk for patient harm and therefore the
greatest opportunity for error prevention. As proposed, this approach
was designed to limit this certification criterion's potential burden.
---------------------------------------------------------------------------
\10\ http://www.nist.gov/healthcare/usability.
\11\ Sec. 170.314(a)(1) (CPOE); Sec. 170.314(a)(2) (Drug-drug,
drug-allergy interaction checks); Sec. 170.314(a)(6) (Medication
list); Sec. 170.314(a)(7) (Medication allergy list); Sec.
170.314(a)(8) (Clinical decision support); Sec. 170.314(a)(16)
(Electronic medication administration record); Sec. 170.314(b)(3)
(Electronic prescribing); and Sec. 170.314(b)(4) (Clinical
information reconciliation).
---------------------------------------------------------------------------
We proposed that the methods for how an EHR technology developer
could employ UCD are well defined in documents and requirements such as
ISO 9241-11, ISO 13407, ISO 16982, and NISTIR 7741. We proposed that it
would be best to enable EHR technology developers to choose their UCD
approach and not to prescribe specific UCD processes that would be
required to meet this certification criterion. Thus, the use of any one
of these processes to apply UCD would meet this certification
criterion. We acknowledged and expected that EHR technology developers
who have already followed UCD in previous development efforts for the
identified certification criteria would be performing a retrospective
analysis. However, if UCD had not been previously applied to
capabilities associated with the certification criteria, the EHR
technology would ultimately need to have such UCD processes applied
before it would be able to be certified. We proposed that testing \12\
to this certification criterion would entail EHR technology developers
documenting that their UCD incorporates all of the data elements
defined in the Customized Common Industry Format Template for EHR
Usability Testing (NISTIR 7742). We noted that with respect to
demonstrating compliance with this certification criterion that this
information would need to be available to an ONC-ACB for review, but
that the form and format for how the data would be presented for
testing would not necessarily need to be according to NISTIR 7742
(i.e., an EHR technology developer could capture information specified
in NISTIR 7742 without having to use the template). Finally, we
indicated that this documentation would become a component of the
publicly available testing results on which a certification is based.
---------------------------------------------------------------------------
\12\ The National Voluntary Laboratory Accreditation Program, as
administered by NIST, is responsible for accrediting testing
laboratories (who perform EHR technology testing) under the
permanent certification program (``ONC HIT Certification Program'')
(76 FR 1278).
---------------------------------------------------------------------------
Comments. A majority of commenters strongly urged ONC to include
this proposed certification criterion in the final rule. We note,
however, that of all of the proposed certification criteria, this one
appeared to be the most polarizing. Provider organizations, hospitals,
and consumer advocates supported its inclusion in certification and
most (but not all) EHR technology developers expressed some form of
opposition--with concern about the public availability of user-centered
design testing results.
Many commenters expressed support for our proposal adding, in many
cases, arguments about the critically important role that usability
plays in the aspect of the safety and reliability of EHR systems,
noting that if usability is not carefully analyzed it can cause design
induced errors. Other commenters were clear that they felt the results
of UCD and quality systems testing should not be made publicly
available, and that doing so would open the door for EHR developers'
intellectual property to be misappropriated. Some commenters were
simply opposed to this criterion, citing an unnecessary burden on the
industry.
Many commenters supported our proposal to not specify certain
standards or requirements for UCD processes. Commenters also agreed
with our proposal to require that the documentation for how UCD was
applied in the software development process would be publicly
available. These commenters noted that this transparency would foster
EHR technology developer competition to make UCD a competitive
advantage, thus spurring innovation, improving clinician adoption, and
enhancing patient safety. These commenters also suggested that the
proposed certification criterion would not compromise innovation nor
require the release of intellectual property. Most commenters agreed
with the decision not to include NISTIR 7804, and asked for
clarification regarding the proposed CIF template (NISTIR 7742) and
which specific elements are required. One commenter asked for
clarification of the testing methods, and whether self-attestation
would be sufficient for consumers and purchasers of Certified EHR
Technology.
Many commenters quoted an AHRQ report as follows, ``Usability
studies are often difficult to generalize or transfer across settings,
in part because medication management health IT (MMIT) effectiveness is
linked strongly to the culture, institutional leadership, and other
situation specific factors. Therefore, applicability of findings
related to usability is problematic in MMIT applications.'' \13\ Along
those lines, they suggested a slight alternative to what we proposed by
suggesting that EHR technology developers attest to and document their
current processes for incorporating UCD practices into their software
design, as well as any UCD approaches used for currently certified
products, but not be required to have the findings published publicly.
These commenters also suggested that summative testing, as used in the
referenced NIST template, can catch the most basic usability errors,
but is unlikely to have a significant impact on patient safety relative
to cost. These commenters advised that we broaden the criteria to
include other, formative UCD techniques instead of just summative
testing as valid for certification. Finally, these same commenters
expressed strong objections to the requirement for retrospective UCD
analysis and application. Many commenters were supportive of our
identification of several applicable UCD standards, but requested some
changes including the replacement of ISO 13407 with ISO 9241-11, and
the addition of ISO/IEC 62366 and ISO 9241-210.
---------------------------------------------------------------------------
\13\ http://www.ahrq.gov/clinic/epcsums/medmgtsum.htm.
---------------------------------------------------------------------------
One commenter asked for clarification on what was meant by
``retrospective analysis'' and whether it means summative testing or
simply asserting and providing evidence that a UCD process was
followed. Many commenters agreed that EHR technology developers should
be able to choose the UCD approach that best supports their design
principles and products, adding that this would help minimize the
burden of testing and will raise
[[Page 54188]]
awareness on the importance of usability from end-users. One commenter
noted that usability is a quality of interactive software that can be
objectively defined and evaluated. This commenter suggested that we
adopt the following standards for EHR technology certification:
Standard 13407, UCD/NISTIR 7804, ISO Standard 25062, and Common
Industry Format for Summative Usability Tests NISTIR 7742. This
commenter noted that some EHR technology developers have published
objections that the scope of this type of testing would be unrealistic
for an EHR that would be used in a wide variety of conditions, but also
noted that by limiting the scope to eight high priority certification
criteria identified in the Proposed Rule mitigates any such concerns.
One commenter expressed disagreement with the component of the
proposal that would require all testing elements to be made public and
strongly argued that this part be removed from the final rule. This
commenter stated that this equates to the public disclosure of trade
secrets and other proprietary information may force EHR technology
developers that are publicly-traded to violate their obligations to
shareholders, as defined in regulations enforced by the Securities and
Exchange Commission (SEC) that govern the disclosure of both financial
and non-financial information.
One commenter expressed the opinion that UCD is subjective, while
several others request clarification regarding this proposal and ask if
this certification criterion will allow each EHR technology developer
to implement the UCD approach which best suits their development
methodology.
Response. We thank commenters for the detailed and thoughtful
responses. We agree with those commenters who saw this proposed
certification criterion as an important way to improve both EHR
technology design and safety. Therefore, we have adopted this
certification criterion as proposed. We disagree with commenters who
argued that this certification criterion represented an unnecessary
burden. However, in response to those comments, we have issued several
clarifications to better explain the certification criterion's intent
and the requirements that are necessary to demonstrate compliance with
this certification criterion.
To demonstrate compliance with this certification criterion, UCD
must have been applied to each capability of an EHR technology that is
associated with the eight certification criteria named in this
certification criterion. We clarify that the application of UCD is
limited to only those eight certification criteria specified in this
certification criterion and for which certification is sought. For
example, if an EHR Module is presented for certification and includes
capabilities to which this certification criterion would apply, but for
which certification is not sought, then those other capabilities for
which certification is not sought would not have to have had UCD
applied because they would be beyond the scope of the EHR Module's
certification.
We clarify that what we meant by ``retrospective analysis'' is that
an EHR technology developer would not necessarily have to initiate new
UCD analysis to meet this certification criterion if they had already
completed UCD for the capability in the past. In other words, if an EHR
technology had never applied UCD to the capabilities to which this
certification criterion applies then UCD would need to be completed
before that EHR technology could be certified. However, if UCD had been
applied to an EHR technology for the capabilities relevant to this
certification criterion, UCD would not need to be redone and an EHR
technology developer could provide the required information specified
by NISTIR 7742 that reflects the UCD that they had previously
completed. We make this clarification to acknowledge that many EHR
technologies are designed to follow standard UCD processes and we did
not intend to disregard that prior work. We also believe this
clarification will help assuage commenters' concerns about the
potential burden posed by this certification criterion.
The method(s) that could be employed for UCD (e.g., ISO 9241-11,
ISO 13407, ISO 16982, and NISTIR 7741) and that were listed in the
Proposed Rule are examples of resources that EHR technology developers
may choose to review in order to select a UCD. We agree that ISO/IEC
62366 and ISO 9241-210 are also acceptable alternatives. Any UCD
process selected by an EHR technology developer is appropriate, and it
need not be listed in the examples we provided in order to be
acceptable. We do, however, strongly advise EHR technology developers
to select an industry standard process because compliance with this
certification criterion requires submission of the name, description,
and citation (URL and/or publication citation) of the process that was
selected. In the event that an EHR technology developer selects a UCD
process that is not an industry standard (i.e., not developed by a
voluntary consensus standards organization (VCSO)), but is based on one
or more industry standard processes, the developer may name the
process(es) and provide an outline of the process in addition to a
short description. Submission of the information specified in the
NISTIR 7742 template will need to be submitted for each and every one
of the applicable eight certification criteria specified in this
certification criterion and for which certification is sought. This
information will become part of the EHR technology's test report that
is required to be made publicly available.
The following information/sections in NISTIR 7742 are required for
submission:
Name and version of the product
Date and location of the test
Test environment
Description of the intended users
Total number of participants
Description of participants: their experience and
demographic characteristics
Description of the user tasks that were tested
List of the specific metrics captured during the testing
for effectiveness, efficiency and satisfaction
Data scoring
Results of the test and data analysis
Major test findings
Identified area(s) of improvement(s)
There are illustrative tables on pages 11 and 20 of the NIST 7742
document that may not need to be populated, depending on the tasks
tested. We clarify that all of the sections specified above must to be
completed, including ``major findings'' and ``areas for improvement.''
We note that EHR technology developers can perform many iterations of
summative user testing. Thus, the submission that is ultimately
provided for testing and certification may be the expression of a final
iteration in which few areas for improvement would be identified. We do
not expect EHR technology developers to include trade secrets or
proprietary information in these reports. We disagree that UCD is
subjective, and have offered several examples of industry standard UCD
processes above. Regarding one commenter's concern that the publication
of usability testing may violate SEC regulations regarding public
disclosure, this commenter provided no additional detail as to why this
would pose a conflict with SEC regulations, nor did it cite a
particular SEC regulatory provision that they believed was in conflict
with the proposed certification criterion. We are unaware of any
provision that would result in EHR technology developers violating any
SEC regulations.
[[Page 54189]]
Comments. One commenter expressed support for the certification
criterion, but disagreed with the assumption that user interface (UI)
validation testing must be performed by end-users. This commenter's
experience was that UI validation tests performed by internal design
experts are more effective than the same testing performed by end-
users. This commenter reported that engineering a UI to the needs of a
user who is encountering that interface for the very first time,
invariably results in an interface designed to accommodate the novice,
at the expense of denying power and efficiency to the same user who
will quickly gain familiarity with a well designed interface.
Response. The NISTIR 7742 includes several sections: Executive
Summary, Introduction, Method, Results, and Appendices. In each of
these sections, there are required data elements--and some of these
elements call for the expression of the number of study participants,
their level of experience with EHR technology, and other pertinent
details. Regarding comments about the participants of usability
testing, many UCD processes incorporate involvement of end-users in
formative and summative testing. The cohort of users who are selected
as participants will of course vary with the product and its intended
users.
Comments. One commenter supported this criterion, but expressed
concern that testing in a lab setting would be insufficient and would
need to be augmented by field testing as well, advocating for
provisional certification for this certification criterion until it had
been implemented and tested in the field.
Many commenters expressed support for this criterion, stating
agreement that EHR technology developers should conduct usability
testing. One commenter suggested that usability testing be conducted
and mandated by a third party such as a Sharp C grant recipient, and
strongly recommending standardization of EHR data output to make the
transfer of data more seamless, less administratively burdensome, and
less costly.
One commenter suggested that ensuring usability is the key to
successful physician adoption of EHRs, yet expressed concern that our
proposals as drafted gave no consideration as to the clinician
decision-making process or practice workflow.
One commenter expressed concern that the adoption of a particular
methodology does not guarantee that software will improve. Other
commenters suggested that the testers would need to be selected who are
professionals already familiar with more than one EHR technology and
are in the same specialty as the target market of the EHR technology
developer.
One commenter contended that the NISTIR 7804 would be appropriate,
and advocated for its inclusion as a certification requirement.
Many commenters suggested that we enhance our usability testing
requirements beyond what was described in our proposed rule such as:
(1) Requiring the collection of data based on an EHR user (physician)
satisfaction survey that can be included in the attestation phase of
the MU program; (2) collecting and disseminating survey results on
usability experiences based on practice size, specialty type, and
geographic location, and incorporation of this feedback into future
certification processes; (3) including usability and patient safety
criteria into the certification process as discussed in the IOM report;
(4) promoting innovation in EHR technology design that not only
addresses patient safety and usability, but can be more seamlessly
integrated into smaller practices that do not have the luxury of
resources to completely redesign the way they work to accommodate the
EHR; (5) seeking industry feedback--including physician feedback--on
what constitutes an appropriate level of risk as it relates to patient
safety; and (6) applying the principles in the NISTIR 7804 to the
entire EHR certification process.
Response. We thank these commenters for their thorough and
thoughtful feedback. Although the implementation of suggestions 1
through 5 may provide a better understanding of EHR usability today and
chart a path toward improved usability in the future, they fall outside
the scope of this certification criterion. We have not included NISTIR
7804 in the 2014 Edition EHR certification criteria, but may consider
it for future editions of certification criteria. We do believe that
UCD will--by definition--consider the clinical decision-making process
and disagree with the commenter that it does not. Finally, we agree
that both formative and summative testing are valuable, and we agree
that testing in a lab setting and testing in the field are also
important. This certification criterion is a first step toward formal
usability testing becoming part of the culture of EHR technology
development. We therefore clarify that, at a minimum, only lab-based
summative testing is necessary to be performed in order to demonstrate
compliance with this certification criterion. Nothing precludes field-
testing and formative testing from also being performed and we
encourage EHR technology developers to do so.
Quality Management System
In the Proposed Rule we noted that the IOM had also recommended
that we ``[establish] quality management principles and processes in
health IT.'' We stated that, working with other Federal agencies, we
intended to publish a quality management document that would be
customized for the EHR technology development lifecycle and express
similar principles to those included in ISO 9001, IEC 62304, ISO 13485,
ISO 9001, and 21 CFR part 820. We anticipated that this document would
provide specific guidance to EHR technology developers on best
practices in software design processes in a way that mirrors
established quality management systems, but would be customized for EHR
technology development We stated that we understood that some EHR
technology developers already have processes like these in place, but
did not believe, especially in light of the IOM recommendation, that
the EHR technology industry as a whole consistently follows such
processes. We indicated our expectation to publish the quality
management document around the same time as the Proposed Rule would be
available for public comment. We indicated that we were considering
including an additional certification criterion in the final rule that
would require an EHR technology developer to document how their EHR
technology development processes either aligned with, or deviated from,
the quality management principles and processes that would be expressed
in the document. We emphasized that this certification criterion would
not require EHR technology developers to comply with all of the
document's quality management principles and processes in order to be
certified. Rather, to satisfy the certification criterion, EHR
technology developers would need to review their current processes and
document how they do or do not meet the principles and processes
specified in the document (and where they do not, what alternative
processes they use, if any). We stated our expectation that this
documentation would be submitted as part of testing and would become a
component of the publicly available testing results on which a
certification is based.
We explained that we were considering adopting this additional
certification criterion as part of the 2014 Edition EHR certification
criteria for
[[Page 54190]]
three reasons. First, all EHR technology developers that seek
certification of their EHR technology would become familiar with
quality management processes. Second, the public disclosure of the
quality management processes used by EHR technology developers would
provide transparency to purchasers and stakeholders, which could inform
and improve the development and certification of EHR technology. Last,
EHR technology developers' compliance with the certification criterion
would establish a foundation for the adoption of a more rigorous
certification criterion for quality management processes in the future
without placing an immediate significant burden on EHR technology
developers. We requested public comment on this additional
certification criterion and the feasibility of requiring EHR technology
developers to document their current processes.
Comments. Most comments supported our proposal to adopt a
certification criterion for quality management practices. Several
commenters expressed concern that the quality management systems
document referenced in our proposal was not available for review during
the public comment period as we had proposed. Many commenters expressed
concern that public availability of the documentation produced for this
certification criterion might reveal proprietary and confidential
software information.
Other commenters expressed support for having quality management
systems in place and the general approach proposed of describing the
nature of each EHR technology developer's quality processes. These
commenters also expressed that the proposal is preferable to a specific
requirement for EHR technology developers to adopt a particular quality
management system.
One commenter observed that due to the recent FDA rule for Medical
Device Data Systems (MDDS), they are actively implementing these
quality principles across their enterprise development projects and
believe that the use of quality management systems will help to:
Improve traceability of clinician requirements to EHR system features,
keeping requirements at the forefront; improve consistency of
development and commissioning activities and thus increase the ability
to predict when EHR system updates will become available to the
clinicians; and lower the overall cost of quality by minimizing a whole
range of failure costs. This commenter also noted additional advantages
of quality management systems including: The opportunity to clarify
roles and responsibilities in the development organization allowing
more precise definition of scope, schedule, and resources needed to
develop its clinical systems; improved visibility into the development
project progress, providing greater predictability of when resources
assigned to projects will be available for other strategic priorities;
highlight needs for communication and safety/risk discussions on
critical issues; and creation of ownership of quality at all levels of
the organization.
One commenter did not support the requirement to provide a gap
analysis as part of the certification, due to the fact that this
commenter's EHR technology is comprised of many disparate self-
developed modules spanning multiple years of development and use,
multiple teams and multiple technologies where consistent processes
were not performed. This commenter also expressed concern that the
publication of this analysis is irrelevant to organizations that
develop their EHR technology and do not sell it to others. Finally,
this commenter stated that they are already familiar with quality
management systems and are actively tightening up their software
development lifecycle processes and other QMS related activities to
become compliant with the FDA MDDS rule.
One commenter stated that they are actively implementing a quality
management system, and that disclosing where [they] are in this process
to an agency that currently does not have jurisdiction in this area
would add no value. Several commenters expressed that they would not
support any requirement that did not align with international standards
such as ISO-62304, ISO-14971, ISO-13485, or with FDA's quality system
regulation in 21 CFR part 820.
Some commenters noted that the work required to meet this
requirement will be very time consuming and costly to provide a formal
assessment on each of the legacy development processes that have been
employed, and that the review for certification should focus on new
development rather than historical development. They stated that
certification bodies could perform a spot check quality management
systems audit on new processes instead of requiring EHR technology
developers to retrospectively define old processes. The commenter
expressed that this would be far less burdensome and would allow EHR
technology developers to appropriately focus efforts on future
development efforts, not past work.
Several commenters agreed that it is important for EHR technology
developers to follow rigorous quality management systems and welcomed
the inclusion of a quality management systems certification criterion.
These commenters suggested that optimal quality management systems for
EHR technology should expressly permit modern ``Agile'' development
processes, as Agile processes can efficiently yield higher quality
software than traditional methods. A commenter also noted that some of
the existing quality management regimes referenced (ISO 9001, IEC
62304, ISO 13485, and 21 CFR part 820) predate the development of Agile
software development methodologies and were written assuming an old-
fashioned stage-gate ``waterfall'' software development process. The
commenter stated, for example, that while medical device \14\
manufacturers have begun to successfully embrace Agile there has been
some confusion about whether Agile processes are even allowed under 21
CFR part 820. This commenter argued that a modern quality management
system for EHR technology should expressly permit Agile software
development, and should set high-level requirements for software
development process and work-product, without unnecessarily
constraining the order in which particular process steps are followed.
Comments indicated that a quality management system certification
criterion should cover the processes associated with custom software
development. They stated that unlike other medical devices covered by
the quality management systems mentioned (IEC 62304, ISO 13485, and 21
CFR part 820), EHR technology implementations often involve a
substantial amount of custom, site-specific, software (including
templates, interfaces, and custom code).
---------------------------------------------------------------------------
\14\ We note for readers that we interpreted the term ``medical
device'' used in this comment summary by commenters to refer to
those devices that fall under the meaning of `device' in section
201(h) of the Federal Food, Drug, and Cosmetic Act (FD&C Act), 21
U.S.C. 321(h). Generally, speaking when the term ``device'' is used
throughout this rule it is used in the general sense of the word and
not limited to the meaning assigned to ``device'' in section 201(h)
of the FD&C Act.
---------------------------------------------------------------------------
One commenter expressed agreement with IOM that it would be useful
to establish ``quality management principles and processes in health
IT.'' This commenter supported the proposed gradual introduction of a
generic quality management system certification criterion with key
requirements called out. They suggested that a gradual introduction
would support those EHR technology developers who already have quality
[[Page 54191]]
management systems in place without requiring them to rip and replace
to conform to a ``standard'' quality management system that may not
offer any significant improvement over what they already have in place.
These commenters also stated that it is important for EHR technology
developers who are currently following one of the existing ISO or FDA
standard processes not be disadvantaged by new MU equivalencies.
Response. We appreciate the very thorough and thoughtful comments
on our proposal to adopt a quality management system (QMS) oriented
certification criterion. We share the sentiments expressed by
commenters that selecting and implementing an optimal quality
management system (QMS) for EHR technology development can be complex.
We agree that existing standards may not explicitly state support for
agile development methodologies and that such methods may be part of an
optimal QMS. We appreciate the detailed comments that offered guidance
regarding the optimal components of an ideal QMS for EHR technology and
we agree with many of these suggestions. Because we were unable to
publish the quality management document referenced in the Proposed Rule
we recognize that there was an insufficient opportunity to comment on
this document and have not included an explicit requirement to use this
document.
We agree with the many commenters who described the advantages of
an incremental implementation of QMS requirements for EHR technology.
Additionally, we support the position of the commenters that stated
this requirement should strive not to burden EHR technology developers
with the task of documenting previous development processes. We
disagree with the commenter who believed that this requirement was
beyond our authority. The Secretary has the statutory authority to
adopt standards, implementation specifications, and certification
criteria for HIT and the National Coordinator has the statutory
authority to establish a certification program for the certification of
HIT to certification criteria adopted by the Secretary. Additionally,
we disagree with the commenter with internally developed EHR technology
that objected to our proposed gap analysis because we believe that the
purchasers of EHR technology are not the only stakeholders who would
take interest in the transparency provided by the submission of this
information. Patients, employees, business partners, and shareholders
of such organizations would be other such interested parties.
In consideration of comments received for and against this
proposal, we have decided to adopt a certification criterion in this
final rule at Sec. 170.314(g)(4) that will generally focus on QMS and,
as suggested by many commenters, is meant to be a first step that can
be built on in an incremental fashion. All EHR technology certified to
the 2014 Edition EHR certification criteria would need to be certified
to this certification criterion, and we have taken steps to ensure that
EHR Modules are certified to this certification criterion by revising
Sec. 170.550 as discussed in more detail under section IV.C.2 of this
preamble.
We have adopted a certification criterion that accounts for the
fact that we did not publish the quality management document as we had
proposed. The certification criterion we have adopted is more general
and provides more flexibility. The certification criterion expresses
that for each capability an EHR technology includes and for which that
capability's certification is sought, the use of a QMS in the
development, testing, implementation and maintenance of that capability
must be identified. Unlike our proposal, any QMS may be used to meet
this certification criterion and even an indication that no QMS was
used for particular capabilities for which certification is requested
is permitted. The commenter who stated that they are implementing the
FDA's Quality System (QS) regulations (for example, under the MDDS
rule) would--by definition--be meeting this certification criterion so
long as they cite their compliance with FDA's QS regulations for
certification. Given this flexibility, we cannot foresee any reason why
this certification criterion cannot be satisfied nor do we believe that
it will be a significant burden to indicate the QMS used (or not used)
in the development of capabilities for which certification is sought.
We understand that some EHR technology developers have several
teams who work on different functional components of EHR technology. In
the case where the whole development organization uses the same QMS (or
not at all) across all teams, then this certification criterion may be
met with one report. Where there is variability across teams, the EHR
technology developer will need to indicate the individual QMS' followed
for the applicable certification criteria for which the EHR technology
is submitted for certification.
We encourage EHR technology developers to choose an established
QMS, but developers are not required to do so, and may use either a
modified version of an established QMS, or an entirely ``home grown''
QMS. We also clarify that we have no expectation that there will be
detailed documentation of historical QMS or their absence. As specified
above, we believe that the documentation of the current status of QMS
in an EHR technology development organization is sufficient.
EHR Technology Safety Reporting
We also considered adopting a certification criterion (as mandatory
or optional) that would require EHR technology to enable a user to
generate a file in accordance with the data required by the Agency for
Healthcare Research and Quality (AHRQ) Common Format,\15\ including the
``Device or Medical/Surgical Supply, including HIT v1.1a.'' We
requested public comment on whether we should adopt such a
certification criterion and what, if any, challenges EHR technology
developers would encounter in implementing this capability.
---------------------------------------------------------------------------
\15\ http://www.pso.ahrq.gov/formats/commonfmt.htm
---------------------------------------------------------------------------
Comments. Many commenters requested that ONC not adopt a
certification criterion at this time, but take the opportunity to study
the role of EHRs in patient safety incident reporting in order to
determine if something more reflective of EHR technology's role in such
reporting as a future certification criterion would be appropriate.
Many of these commenters also stated that there is insufficient
experience with the AHRQ Common Format--especially in the ambulatory
domain, and that extension of the Common Format would be necessary for
it to be of value. Other commenters expressed additional concerns about
the maturity of the Common Format, and the ability of EHR technology to
generate the appropriate file format, and whether there would be any
near-term value to such reports without more experience with adverse
event reporting from EHR technology.
Response. We agree with these concerns and have not adopted a
certification criterion for reporting patient safety events according
to the Common Formats in the 2014 Edition EHR certification criteria.
Data Portability
[[Page 54192]]
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
N/A
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
------------------------------------------------------------------------
Sec. 170.314(b)(7) (Data portability).
------------------------------------------------------------------------
In the Proposed Rule we sought public comment on whether we should
adopt a certification criterion to focus on the portability of data
stored within CEHRT. We recited the scenario where a provider might
seek to change EHR technology (and EHR technology developers). We
stated that in such a scenario providers should have the ability to
easily switch EHR technology--at a low cost--and migrate most or all of
their data in structured form to another EHR technology. We noted that
in the absence of this capability, providers could be ``locked-in'' to
their current EHR technology, which could ultimately impede innovation.
With our belief that data portability is a key aspect of the EHR
technology market that requires maturity, we sought public comment on
specific questions that could inform our decision on whether to adopt a
certification criterion focused on data portability. We asked: (1)
Whether EHR technology is capable of electronically providing a
sufficient amount of a patient's health history using export summaries
formatted according to the Consolidated CDA for the scenario described
above; (2) whether all of the data in a provider's EHR 1 is
necessary to migrate over to EHR 2 in the event the provider
wants to switch (We noted that potential effect of medical record
retention laws, but sought to determine whether the loss of some data
would be tolerable and if so, which data.); (3) considering the
standards that have been adopted and proposed for adoption in the
Proposed Rule, what additional standards and guidance would be
necessary to meet market needs for data portability, including the
portability of administrative data such as Medicare and Medicaid
eligibility and claims; (4) whether a specific set of patient data
could be used as a foundation for an incremental approach to improve
data portability for the situation described above as well as other
situations; and (5) whether the concept of a capability to batch export
a single patient's records (or a provider's entire patient population)
poses unintended consequences from a security perspective and what
factors should be considered to mitigate any potential abuse of this
capability if it existed.
Comments. Commenters strongly supported our efforts to improve data
portability, including in the specific provider situation we outlined
in the Proposed Rule. Many commenters generally noted that medical
record retention laws, as well as those governing fraud and abuse
investigations, largely determine the amount and type of information
that must be retained, and therefore, needs to be portable. Commenters
also noted that there may be other reasons for retaining longitudinal
information on patient care, such as clinical trial participation, post
approval study requirements and other clinical reasons.
Many commenters stated that some data loss is inevitable, with some
commenters noting this was due to variations in clinical content and
data schema(s) between EHR systems. Commenters gave varying responses
on what specific data would be important to migrate to a new EHR. Some
commenters stated the decision would be situational, best left to the
provider, or, as previously noted, based on medical records retention
laws and requirements. Commenters stated that demographics, problems,
medications, medication allergies, allergies, immunizations, vital
signs, lab results, and encounter notes would fall into the category of
``not tolerable'' to lose in transfer. For all ``other'' data,
commenters stated that it would be sufficient for the data to be
accessible in a human readable form through, but not necessarily stored
within, the EHR. A few commenters also stated that documentation
metadata should be readily available for all databases. Some commenters
stated that the loss of data at a granular, visit-oriented level would
be tolerable. Other commenters stated that because administrative data
is normally stored in practice management systems--and not in EHRs--it
would not need to be transferred from one of these systems to another.
One commenter suggested an incremental approach starting with
requiring indexed and searchable documents including visit notes,
letters, and reports. The commenter noted that this might require
manual addition or automated generation of metadata and might need to
include only documents generated after a given date for complete header
information. The commenter noted that subsets of the patient's record
(records of children must include immunizations and growth data) could
be effective, but the commenter emphasized that the summary must be
focused on the patient's lifetime data and not the most recent clinical
events. Over time, the commenter stated that external standards for
data portability would govern the internal structure of data within an
EHR so that data can be exported and imported without data loss. The
commenter stated that a good example is retention of laboratory results
in LOINC[supreg] codes after import so that they can be exported in the
future and used in a different EHR to identify data elements needed for
clinical decision support or clinical quality measures.
Commenters stated that the Consolidated CDA would not be capable of
sufficiently capturing all patient information that would be needed.
Commenters stated that the Consolidated CDA is designed to be a summary
and would not capture longitudinal patient information, administrative
billing data, or other necessary data (e.g., trend analysis,
operational data, and master file data). A few commenters noted that
the CDA does not support the inclusion of information on whether
meaningful use measures were applicable to or addressed for patients.
Other commenters stated that CDA document types may not be the most
efficient means to migrate data from one EHR to another. These
commenters further stated that it is critical that such migration
happens as quickly as possible. Therefore, the commenters contended
that other data transfer mechanisms would be better suited for that
purpose, particularly when large data volumes are in play (e.g., large
multi-provider entities migrations).
A commenter stated that one possible solution would be to require
EHR technology developers to tag key data elements that would typically
be moved in an EHR transition with standardized XML. EHR technology
developers would also need to be able to receive and process data feeds
with this standardized XML, storing it in their native tables.
A few commenters stated that batch migrations are one of the more
typical migration methods used when a provider moves from one EHR to
another. Some commenters stated that batch exports of a patient's
record poses serious security risks, while other commenters stated that
current safeguards exist. These commenters pointed to the use of
business associate agreements, encryption, and the use other internal
controls to mitigate any security concerns.
Response. We thank commenters for the depth and breadth of their
responses to our questions and proposals. In consideration of comments
received, we have adopted a certification criterion for data
portability. As discussed later in this final rule, we have also
included this certification criterion as part of the Base EHR
definition in order to ensure
[[Page 54193]]
that all EPs, EHs, and CAHs, have this capability as part of the EHR
technology they use to meet the CEHRT definition. While we recognize
that no ``silver bullet'' exists with respect to data portability, we
strongly believe that more attention must be paid to this market
challenge and that with the interests of EPs, EHs, and CAHs in mind,
small steps can be taken to improve the data portability between EHR
technologies. We intend for this certification criterion to be a
starting point and have framed it in such a way as to leverage
capabilities that will already be included in an EP, EH, and CAH's
CEHRT.
The certification criterion leverages and requires the same
capabilities specified in the ``transitions of care--create and
transmit transition of care/referral summaries'' certification
criterion at Sec. 170.314(b)(2)(i). The only difference between the
capability specified in the data portability certification criterion
and the capability specified in the transitions of care certification
criterion is that the data portability certification criterion
expressly limits the scope of the data to the most current clinical
information about each patient for which an export summary is created.
For the purposes of certification and for all of the patients on which
an EP's, EH's, or CAH's CEHRT maintains data, the EHR technology must
enable a user to electronically create a set of export summaries for
all patients in EHR technology formatted according to the Consolidated
CDA that includes each patient's most recent clinical information.
While this is the minimum capability required for certification, we
encourage EHR technology developers to include patients' longitudinal
information for laboratory test results, immunizations, and procedures,
and intend to consider including this broader requirement in the next
edition of this certification criterion. We believe this initial
capability provides a strong starting point for the fluid transition
from one EHR technology to another. Primarily, we anticipate that this
capability will be enable transitions to be more efficient by reducing
the need for EPs, EHs, and CAHs to manually re-enter all of their
patients' recent data into a new EHR system.
b. Ambulatory Setting
We propose to adopt 3 certification criteria that would be new
certification criteria for the ambulatory setting.
Secure Messaging
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
Use secure electronic messaging to communicate with patients on relevant
health information.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(e)(3) (Ambulatory setting only--secure messaging).
------------------------------------------------------------------------
We proposed the 2014 Edition EHR certification criterion for secure
messaging (at Sec. 170.314(e)(3)) to support the MU objective and
measure recommended by the HITPC and proposed by CMS. We agreed with
the direction provided by both HITSC recommendations and merged the two
into a refined proposed certification criterion. We also proposed to
include in the certification criterion a baseline standard in terms of
the encryption and hashing algorithms that would need to be used to
implement secure messaging. More specifically, we proposed that only
those identified in FIPS 140-2 Annex A be permitted to be used to meet
this criterion and proposed to adopt a new standard in Sec. 170.210(f)
to refer to FIPS 140-2 Annex A's encryption and hashing algorithms.
Additionally, we referenced several standards and implementations
specifications that EHR technology developers could use to implement
various secure messaging approaches, including IETF RFC 2246 (TLS 1.0),
SMTP/SMIME, NIST Special Publication 800-52 (``Guidelines for the
Selection and Use of TLS Implementations''), and specifications
developed as part of nationwide health information network initiatives.
Comments. Several commenters conveyed that the certification and
testing process would need to accommodate the range of messaging
mechanisms permitted by CMS, while being certified within the proposed
standards. One commenter asked if there were approved modes of
electronic messaging and whether secured and encrypted email would be a
method. Another stated that use of a secure messaging capability from
within a portal application should be an acceptable method. One
commenter recommended that we equally support the standards and
specifications developed as part of the NwHIN Exchange with the intent
to support the broadest possible adoption of health information
exchange capabilities. Other commenters generally requested that we
provide some examples of common access mechanisms and acceptable
security protocols. Another commenter suggested that we consider
particular transport methods be certified similar to the certification
criteria discussed in the Proposed Rule that referenced the Direct
specifications and other acceptable transport methods. One commenter
stressed the importance of adequate privacy and security, but urged ONC
to take a reasonable approach and not make the use of secure electronic
messaging to communicate with patients unduly burdensome. One commenter
stated that functionality such as a patient portal would be handled
through normal browser HTTPS functionality and, therefore, should be
easily managed through a visual inspection and should not require
additional verification. One commenter supported secure messaging in
general, but did not support secure email as the only secure messaging
methodology. The commenter indicated that they currently send patients
an unsecure email prompt that they have a message and that upon receipt
the patient can securely log-in to their patient portal using an SSL-
protected session to retrieve the message and send new ones.
Response. We share commenters' sentiment that this certification
criterion needs to permit/accommodate a range of possible innovative
options. To that end, we intentionally proposed this certification
criterion to only specify the particular baseline security and
functional capabilities we believed were necessary to require for
certification. So long as the method included with EHR technology
presented for certification can meet these baseline requirements it
would be able to meet this certification criterion. Thus, secure email,
a secure portal, even some type of mobile application could all be
examples for secure messaging methods that could potentially meet this
certification criterion. Along those lines, we decline to specify or
restrict certification in this case to a particular transport standard
because, again, we intend to permit a wide range of different secure
messaging solutions, that will likely use different approaches and
transport standards.
In consideration of these comments and the ones responded to below,
we are finalizing this certification criterion as proposed with one
exception. The only modification we have made is to explicitly note as
we already have in the view, download, and transmit to a 3rd party
certification criterion that it could be the patient or their
authorized representative that engages in secure messaging.
Comment. A commenter stated that patients must be able to directly
communicate with health professionals via patient portals and OAuth.
Response. We decline to incorporate this suggestion into the
certification criterion because it would be
[[Page 54194]]
unnecessarily limiting. Our response, however, is not meant to preclude
this type of functionality from being used to satisfy this
certification criterion.
Comment. A commenter questioned how the capability to receive a
secure message from a patient would be tested and what we intended to
be certified. They asked whether it was a provider application that
would be used to send and receive secure messages or a consumer
application to do the same; or both. Further, the commenter stated that
an EHR technology developer presenting EHR technology for certification
may not have a patient portal or PHR technology from which to
demonstrate the sending of a message to the EHR technology and that
testing using a public email service is likely not to meet the FIPS
140-2 Annex A requirement for encryption. The commenter also indicated
that the certification criterion presumes the EHR technology developer
has a technology to support the consumer and that the EHR technology
developer must have both abilities (send and receive) within its span
of control to be able to present technology for certification.
Ultimately, the commenter suggested that either the provider
requirement to send a message be removed or that this be split into two
criteria. They reasoned that from a measurement perspective, only the
``receive'' from the provider perspective is required by the Stage 2
proposed rule for the associated objective, and the measurement
numerator is based on a consumer perspective and the vendor having
access to event data that may only be available in a portal or similar
consumer application. As an alternative to certifying send and receive
as two distinct criterion (or even as a single criterion to help EHR
technology developers who may only automate provider or consumer
messaging), the commenter suggested that ONC consider working with NIST
to provide a test harness for vendors to certify with to prove messages
are successfully sent and received.
Response. The EHR technology that enables secure messages to be
exchanged is what would be required to be tested and certified. Thus,
whatever would be necessary for a patient to communicate with an EP
(and vice versa) would need to be demonstrated for testing and
certification. We do not believe that separating the capability for
communication by send and receive would add any significant value or
provide any additional benefit because it is the capability as a whole
(to send and receive secure messages) that needs to be demonstrated for
testing and certification in order for EPs to have assurance that EHR
technology can enable bidirectional communication. We thank the
commenter for the recommendation to work with NIST to develop testing
methods that ensure messages can be successfully sent and received. We
will take this recommendation under consideration in discussions with
NIST and when approving a test procedure for this certification
criterion. Finally, we note that to keep the final rule as current as
possible at the time of publication, we have referenced the May 30,
2012 version of Annex A. The May 30, 2012 version replaces the version
we adopted in the S&CC July 2010 final rule and is the only readily
accessible version available. Further, NIST has included additional
reference guidance for the AES standard as well as updated references
to other FIPS publications that have been updated, such as changing the
reference to FIPS 180-3 to FIPS 180-4.
Comments. One commenter supported the proposed certification
criterion but requested clarification on the reference to the standard,
which they noted is a collection of many standards in several
categories. They asked if we could clarify which specific parts of FIPS
Annex A are applicable to secure messaging. In addition, the commenter
asked how the additional guidance we provided in the preamble related
to the standard we proposed to adopt. They requested clarification as
to whether we intended to say ``FIPS 140-2 Annex A plus TLS 1.0 and
SMTP/SMIME and * * *.'' or whether something else was intended.
Response. As noted in the standard proposed just the encryption and
hashing algorithms are in scope. Random number generator standards
would not necessarily be within scope. The other guidance we referenced
in the Proposed Rule is just that. It was not intended to be part of
the standard as questioned by the commenter.
Comment. One commenter recommended that we discourage the use of or
remove the allowance for 3DES as the encryption algorithm is on track
to be deprecated by NIST in the near future.
Response. We agree, please see our response to similar comments in
the ``end-user device encryption'' certification criterion.
Comment. One commenter recommended that we investigate evolving
secure email and other supporting technologies to protect and verify
transactions that include personally identifiable health information.
They noted that current Direct Project guidance requires the use of
organizational PKI certificates for which the FBCA does not include a
profile in its certificate policy. They stated that certificates cited
in the Direct project documentation also suggest that the encryption,
digital signature and non-repudiation bits all be turned on and that
this requirement is an unacceptable practice under the terms of RFC
3647. They concluded by recommending that federally approved NIST LOA
3, 2-factor credentials for patients to authenticate to secure email
and or/or portals should be used to fulfill this requirement.
Response. At this point, we decline to include such a specific
requirement as part of this certification criterion. As the industry
gains more experience with different secure messaging approaches, we
will consider whether additional specificity such as this is necessary.
Comments. A few commenters stated that because CMS' proposed rule
left it to the provider to determine the ``relevance'' of information,
the capability to assess or document relevance should not be in the
automated measure calculation certification criterion nor be part of
this certification criterion.
Response. Certification does not address the relevance of the
information that is part of a secure message. Please see CMS's
discussion related to secure messaging in the Stage 2 final rule
published elsewhere in this issue of the Federal Register.
Cancer Case Information; and Transmission to Cancer
Registries
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
Capability to identify and report cancer cases to a State cancer
registry, except where prohibited, and in accordance with applicable
law and practice.
------------------------------------------------------------------------
2014 Edition EHR Certification Criteria
Sec. 170.314(f)(5) (Optional--ambulatory setting only--cancer case
information).
Sec. 170.314(f)(6) (Optional--ambulatory setting only--transmission to
cancer registries).
------------------------------------------------------------------------
We proposed to adopt two new 2014 Edition EHR certification
criteria to support a new proposed MU objective and measure for
reporting cancer cases to cancer registries. One certification
criterion focused on the capability to electronically record, change,
and access cancer care information (data capture) and the other
certification criterion focused on the capability to electronically
create cancer case information for electronic transmission in
accordance with specified standards. Following consultation with the
Centers for Disease Control and Prevention (CDC), we proposed to adopt
HL7 CDA,
[[Page 54195]]
Release 2 as the content exchange standard. Additionally, we proposed
to adopt the Implementation Guide for Healthcare Provider Reporting to
Central Cancer Registries, Draft, February 2012. We stated in the
Proposed Rule that the CDC would consider comments received on the
Proposed Rule in finalizing the guide. We also stated that if the CDC
finalized the guide, we would consider adopting the final version of
the guide in this final rule with consideration of public comment
received on the appropriateness of the guide for certification. Last,
we proposed to adopt SNOMED CT[supreg] International Release January
2012 and LOINC[supreg] version 2.38 as applicable vocabulary standards.
Comments. Commenters expressed strong support for the proposed
certification criteria. Many of the commenters that supported the
certification criteria stated that they believed this requirement would
increase cancer reporting and improve it in various ways, including
improving the timeliness, efficiency, completeness, and quality of the
data reported as well as reducing the reporting burden on ambulatory
providers.
While many commenters supported the proposed certification
criteria, many also requested that the certification criteria be
designated ``optional'' for Complete EHR certification. The commenters
requesting that the certification criteria be designated optional
claimed that the certification criteria would only be relevant to a
small number of providers who report to cancer registries. Further,
they contended that the capability would be inappropriate for inclusion
in EHR technologies that are not focused on meeting the needs of EPs
who will report to cancer registries, since some of the cancer case
information data utilizes extensive cancer-specific, specialized fields
and vocabularies (e.g., NAACCR data standards) that are not typically
captured in EHRs beyond those specifically marketed as oncology
specialty products. A couple of commenters noted that few, if any, EHR
technology developers provide this functionality, and most applications
that are used for this purpose are not likely to meet the standard
cited in the Proposed Rule. A few other commenters stated that this
requirement is burdensome and should not be required.
Response. We appreciate the support expressed by commenters. We
also agree with commenters that it is appropriate to designate these
certification criteria as optional. By designating the certification
criteria as optional, EHR technology would not need to be certified to
these certification criteria in order to satisfy the Complete EHR
definition. The optional designation will permit EHR technology
developers that support EPs intending to report on the associated MU
menu objective and measure to still get certified to these
certification criteria, but will alleviate the requirement that all
Complete EHRs be certified to these certification criteria. Designating
these certification criteria as optional will mitigate any perceived
unnecessary costs and burden mentioned by commenters. To clarify for MU
purposes, if an EP seeks to meet the associated MU objective and
measure, they will need EHR technology certified to these certification
criteria, including the adopted standards and implementation guide, in
order to have EHR technology that meets the CEHRT definition.
Comments. Many commenters supported the adoption of the proposed
HL7 CDA, Release 2 and Implementation Guide for Healthcare Provider
Reporting to Central Cancer Registries, Draft, February 2012 for
registry reporting, stating that they had widespread support from the
CDC and cancer registry community. A few of these commenters
specifically stated that public health central cancer registries have
been operational for many years and the cancer registry community has
been preparing for the transition to CDA for some time. Commenters
noted that cancer reporting in most jurisdictions requires industry and
occupation information and stated that EHR technology certification to
support cancer reporting by EPs would facilitate their compliance with
applicable law and improve the quality and completeness of cancer
reporting. One commenter recommended that cancer laboratory results
reporting be included in addition to cancer case reporting.
Many commenters also pointed out that the implementation guide was
still in draft format and suggested that it should be finalized before
being adopted. A few commenters contended that it was premature to
adopt the proposed standard and implementation guide as a basis for
certification, stating that the standard was not in widespread use for
reporting cancer events to registries from EHRs. One commenter stated
that the proposed implementation guide is not harmonized with the
Consolidated CDA guide and that harmonization should be completed
before we adopted the implementation guide. A commenter stated that
centralized cancer registries receive batch reports containing large
numbers of cases and that the cancer-related information required by
the cancer registries is dense in its level of detail. Therefore, the
commenter was concerned that the CDA standard may not provide the
necessary content framework or the processing efficiency necessary to
transmit and receive complex, bulk data.
A commenter requested that the minimum data elements required for
the transmission of cancer case information be explicitly and clearly
stated. Another commenter noted concerns that the implementation guide
has requirements for structured data capture for social history that
may not reflect widespread current practice and, thus, represents a
change in practice for EPs. Other commenters stated that there is
potential for confusion in coding ``occupation'' and ``industry''
because there is a discrepancy between description and language in the
implementation guide and the descriptions for the corresponding
LOINC[supreg] codes. A commenter suggested that the implementation
guide needed values for cancer staging variables that allow for ``not
staged'' or ``unknown.'' The commenter stated that for every required
field (R), the value sets should be double checked to make sure that
there is a ``none'' or ``unknown'' option or the EP's EHR will not have
a value all the time.
Response. The implementation guide was jointly developed by the CDC
and the North American Association of Central Cancer Registries
(NAACCR). It is based on many years of harmonized cancer registry
reporting across the country. The finalized implementation guide,
Implementation Guide for Ambulatory Healthcare Provider Reporting to
Central Cancer Registries, Release 1, August 2012, reflects the
comments received on the draft and clarifies ambiguities such as
minimum data elements required and vocabularies for occupation, stage,
and other data elements where none/unknown should be an option. In
particular, the use of HL7 null flavor is better described such that it
may be used where appropriate to indicate lack of information and
clarifications were made to the use case scenarios in response to
questions about workflow and triggers. While this implementation guide
is based on the CDA, the guide was revised in some aspects to harmonize
it with the recently developed Consolidated CDA. The implementation
guide was revised to take advantage of the document format used by the
Consolidated CDA, including the formatting of the data element tables
and conformance statements. The new consensus conformance verbs used in
Consolidated
[[Page 54196]]
CDA (i.e., shall, should, may, and should not) were also adopted in the
implementation guide to clarify the optionality of data elements. These
improvements resolve the ambiguity on required data elements and
vocabularies. Overall, the revisions to the draft implementation guide
that have been incorporated into the final (Release 1) improve the
ability to test and certify EHR technology to the implementation guide
and make it easier for EHR technology developers to implement the
guide's requirements based on the corrections and clarifications.
Accordingly, we have adopted Release 1 of the implementation guide for
the ``transmission to cancer registries'' certification criterion.
Comments. Commenters generally supported the use of SNOMED
CT[supreg] and LOINC[supreg]. One commenter recommended the use of ICD-
9-CM and ICD-10-CM as well since many physician practices work with and
are familiar with these standards. Another commenter acknowledged that
SNOMED CT[supreg] and LOINC[supreg] are valuable for much of the
required content, but believed the context of data is not necessarily
included in these code systems. The commenter further noted additional
data requirements (e.g., medications) which will require RxNorm,
allergy data (medication in RxNorm, reaction in SNOMED CT[supreg]),
procedures performed, and patient characteristics to which other
sections of this report refer. One commenter stated that for dental
systems the HL7 CDA and SNODENT should be required.
Response. We appreciate the support commenters indicated for SNOMED
CT[supreg] and LOINC[supreg] and have adopted them as vocabulary
standards for this certification criterion. We acknowledge that the
implementation guide references other vocabulary standards, but believe
that the vocabulary standards we have adopted in this final rule are
the most important to focus on in support of cancer case reporting. We
decline to adopt SNODENT for the ``transmission to cancer registries''
certification criterion for the same reasons we gave when we declined
to adopt it for the ``problem list'' certification criterion in this
preamble (section III.A.9.a).
Comments. Commenters noted that both SNOMED CT[supreg] and
LOINC[supreg] code sets are updated regularly. Therefore, for the
purposes of certification, commenters recommended that we adopt these
standards in regulation as ``SNOMED CT[supreg]--current international
release'' and ``LOINC[supreg]--current release.'' Commenters also
recommended that we simply state in regulation that EHR technology can
be certified to the most recent version of the implementation guide,
which would acknowledge the evolving nature of implementation
specifications.
Response. We have established a process for adopting certain
vocabulary standards, including SNOMED CT[supreg] and LOINC[supreg],
which permits the use of newer versions of those standards than the one
adopted in regulation. We refer readers to section IV.B for a
discussion of ``minimum standards'' code sets and our new more flexible
approach for their use in certification and upgrading certified
Complete EHRs and certified EHR Modules. Readers should also review
Sec. 170.555, which specifies the certification processes for
``minimum standards'' code sets. In response to the commenters'
suggestion that we permit the use of the ``most recent version'' of the
implementation guide for certification, we refer the commenters to
section III.A.5 found earlier in this preamble. This section explains
why we cannot take such an approach.
Comments. A commenter recommended that CMS develop a common
national data submission standard in order to limit the burden on
providers and vendors operating in multiple states and therefore
connecting to multiple registries and other public health
organizations.
Response. We do not believe this comment fits within the scope of
the proposed certification criteria. We note, however, that for all
public health reporting, CDC is co-leading (with ONC) the efforts of
the S&I Framework Public Health Reporting Initiative to harmonize data
elements, vocabularies, and format across public health diseases and
conditions. The cancer registry community is an active participant in
this initiative. For cancer reporting, CDC, NCI SEER, and NAACCR have
worked closely with public health cancer registries to establish a
single data submission standard, which is already reflected in the
implementation guide.
Comments. A couple of commenters suggested that we make clear that
the state cancer registry, as it is used in the MU objective, may be
operated directly by a Public Health Authority (PHA) or under contract
or other delegation agreement with a designated entity, such as a
university. In either case, they stated that the cancer registry is a
part of the PHA and EPs should report to it if they choose this Menu
objective. A few commenters recommended changing ``state cancer
registry'' to ``public health central cancer registries'' to clearly
distinguish from hospital[hyphen]based cancer registries which they
asserted should not satisfy MU requirements.
Commenters also requested clarification and guidance. A commenter
requested clarification on what constituted an acceptable registry.
Another commenter noted that specialized disease registries are often
proprietary and require special consideration for use and suggested
that we, therefore, make a distinction for the support of an open and
public specialized disease registry. One commenter requested
clarification as to whether the reporting institution is responsible
for creating report events for residents outside of its respective
state. A couple of commenters requested clarification on ``in
accordance with applicable law'' and further explanation on ``except
where prohibited.'' Another commenter requested clarification regarding
whether state-specific requirements pertain to the state the provider
is in, or to the state the patient resides in. One commenter requested
guidance on meeting this objective due to new reporting methodology
being created and the readiness of registries to adopt the proposed HL7
CDA standard.
Response. We appreciate the submission of these comments, but they
are outside the scope of this rulemaking. This final rule does not
create or modify any obligations or choices of EPs to report to disease
registries or the operations of those registries. It seeks only to
facilitate such reporting through CEHRT. We direct commenters to the
Stage 2 final rule found elsewhere in this issue of the Federal
Register for a discussion of the MU objective and measure and a
response to these comments.
c. Inpatient Setting
We propose to adopt 3 certification criteria that would be new
certification criteria for the inpatient setting.
Electronic Medication Administration Record
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
Automatically track medications from order to administration using
assistive technologies in conjunction with an electronic medication
administration record (eMAR).
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(a)(16) (Inpatient setting only--electronic medication
administration record).
------------------------------------------------------------------------
We proposed to adopt a new ``eMAR'' certification criterion with
the inclusion of the ``synchronized clocks'' standard. We made this
proposal based on the recommendation of the HITSC for a new 2014
Edition EHR certification criterion
[[Page 54197]]
to support the MU objective and measure to automatically track
medications from order to administration. In our proposal, consistent
with the intent of the HITSC and HITPC, we emphasized that EHR
technology certified to this certification criterion must enable a user
to electronically confirm the ``rights'' (i.e., right patient, right
medication, right dose, right route, and right time) in relation to the
medication(s) to be administered in combination with an assistive
technology (e.g., bar-coding, location tracking, and radio-frequency
identification (RFID)) which provides automated information on the
``rights.'' We also noted that an electronic ``checklist'' through
which a user would manually confirm the ``rights'' without any
automated and assistive feedback from EHR technology would be
insufficient to demonstrate compliance with this certification
criterion.
Comments. Commenters requested clarification on the definition of
``assistive technology.'' One suggested that we should not define
assistive technology as barcode scanning, RFID or any other technology
solution. Another asked whether it could be a nurse at the bedside
recording medication on a handheld device such as a smart phone or
tablet; a bedside computer; or if it needed to be a barcode scanner
that scans the patient, the medication, and automatically records the
time. A few comments noted that if there is a future requirement to
progress towards RFID, advance notice would be appropriate because they
consider all technologies currently acceptable, including various bar
code formats.
Response. We have purposefully framed this certification criterion
to leave open a range of different technologies that could be used to
demonstrate compliance with the certification criterion. We do not
intend to single out only one particular technology that would meet
this certification criterion. We interpret ``assistive technology'' to
be a technological solution that when paired with EHR technology
automates the comparative aspects of the five rights that a user would
otherwise have to manually complete.
Comment. A commenter requested clarification on whether
``electronically'' recording the time, date, and user ID at the time of
administration is a function automatically performed by the system, or
whether allowing a user to manually enter this data is sufficient.
Response. We intend for this information to be automatically and
simultaneously recorded with the use of the assistive technology. A
manual entry feature for emergency/unanticipated circumstances is not
prohibited by this certification criterion from existing, but would not
alone allow for EHR technology to meet this certification criterion.
Comments. A few comments indicated support for the clarification we
issued in the Proposed Rule that ``automated'' tracking not simply be a
presentation of an electronic ``checklist'' to an end user, but that it
provide for electronic confirmation of the results of an automated
tracking event such as to scan a patient wrist band or a medication bar
code to match the right medication for the right patient. Commenters
suggested that we offer some additional guidance to make it clear that
the assistive technology used to automate the five rights should not be
a substitute for clinical judgment and that automated does not mean to
imply no user confirmatory action. They suggested that we clarify that
medication administration would include at least a confirmatory step
for an end user to validate the outcome of an automated check before
proceeding. They stated that just as manual work steps can lead to
error, automated tracking should not be relied upon absent a human
element to confirm (and take responsibility for) the outcome. The
commenter suggested that we strengthen the language in the
certification criterion to highlight that ``automated'' also requires
some type of user confirmatory action.
A couple of commenters asked whether ``automated'' means that all
``five rights'' are based on some automated method or if some manual
interaction is still allowed such as patient selection, signing the
administration event, performing witnessing if required for patient
identification as completed and other steps that still may depend on
user interaction to make an entry into the system. A commenter
requested clarification on the role of the assistive technology with
the care provider in ``providing information'' on the ``rights.''
Several commenters requested that we clarify the meaning of
``electronically verify'' in the certification criterion (or
``electronically confirm'' as we stated in the Proposed Rule's
preamble). Additionally, commenters suggested that we specifically
state that the EHR technology is not required to provide messaging to
the user unless one of the ``rights'' is compromised in the medication
administration process. Additionally, they stated that current systems
typically do not message a user when all of the five rights are in
compliance.
Response. We concur with commenters that the assistive technology
used to automate the five rights should not be a substitute for
clinical judgment. A professional clinical user is still responsible
for his or her actions and should utilize the assistive technology to
complement, not replace, his or her experience, training, and clinical
judgment. Along those lines, we interpret ``electronically verify'' in
the certification criterion to mean that upon the use of an assistive
technology a user would be able to review and compare within the EHR
technology the five rights information associated with the medication
to be administered. By being able to verify this information, the user
would be able to assess whether the five rights are correct and
subsequently administer the medication with appropriate documentation.
Consistent with the clarification requested by commenters,
``electronically verify'' does not require EHR technology to provide
some type of explicit notification to a user if all of the five rights
are correct. However, if one or more are incorrect, the EHR technology
must provide some indication to a user which ``right(s)'' are
incorrect/not within compliant parameters.
With respect to the automation expectations expressed by this
certification criterion, yes, upon the use of an assistive technology,
information about each of the rights would need to be automatically
available for a user to verify. We acknowledge that there are other
steps within the medication administration workflow for which user
interaction with, and entries into, EHR technology may be necessary.
This certification criterion is not meant to preclude those other steps
nor are they within the current scope of this certification criterion.
In considering these comments, stakeholder interactions during the
public comment period, and our own additional research, we would like
to call to readers attention an error in the certification criterion
with respect to the ``fifth right'' that we specified. Instead of
specifying ``right time'' as it is commonly understood--to refer to the
information about when the medication is to be administered relative to
the current time--we specified ``right time'' in the proposed
certification criterion as what is commonly understood to mean ``right
documentation.'' In light of this oversight, and to ensure that the
true ``five rights'' are included in this certification criterion, we
have added in the correct description for ``right time''
[[Page 54198]]
into the certification criterion and revised the proposed capability to
be called ``right documentation.'' This latter concept remains
unchanged from our proposal and would require the EHR technology to
record the time, date, and user identification when a medication is
administered. We have finalized the eMAR certification criterion with
the discussed revisions in Sec. 170.314(a)(16) (the CFR paragraph was
changed due to the combination of two other certification criteria).
Comment. A commenter requested clarification on how automation can
determine the ``right route.'' They contended that technology can
determine the ordered route, and whether the medication can be
delivered via that route, but only manual actions and manual
documentation can provide evidence of the route administered.
Response. The automated aspect of this certification criterion is
the provision of information associated with the medication to be
administered; in other words, that the dosage form of the medication is
appropriate to the ordered route. Thus, when an assistive technology is
used, the information about the route of medication delivery would need
to be automatically available for a user to verify.
Electronic Prescribing
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
Generate and transmit permissible discharge prescriptions electronically
(eRx).
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(b)(3) (Electronic prescribing).
------------------------------------------------------------------------
We proposed to adopt for the inpatient setting the same revised
electronic prescribing certification criterion that we proposed to
adopt for the ambulatory setting (i.e., we proposed to adopt the
certification criterion at Sec. 170.314(b)(3) for both settings). We
proposed to require the use of RxNorm as the vocabulary standard and
NCPDP SCRIPT version 10.6 as the only content exchange standard for
this certification criterion. In our discussion of this certification
criterion for the ambulatory setting, we proposed to not include the
NCPDP SCRIPT version 8.1 in the 2014 Edition EHR certification
criterion. This proposal was premised on our understanding that CMS was
planning to propose the retirement of NCPDP SCRIPT version 8.1 for the
Medicare Part D e-prescribing program soon after our proposed rule was
to be published. We noted that if we received information indicating a
change in CMS' plans prior to the issuance of our final rule, we may,
based also on public comment, retain this standard in a final revised
certification criterion. We stated that we were proposing to adopt this
certification criterion for both the ambulatory and inpatient settings
because it supports our desired policy and interoperability outcome for
content exchange standards to be used when information is exchanged
between different legal entities.
Comments. Many commenters supported our proposal to require
certification to NCPDP SCRIPT 10.6 for this certification criterion.
Other commenters suggested that we should continue to permit
certification to NCPDP SCRIPT 8.1 until it is officially retired from
the Part D e-prescribing program by CMS.
Response. We appreciate commenters support for our proposal to
require certification to NCPDP SCRIPT 10.6 and have finalized the
certification criterion as proposed. We are not including NCPDP SCRIPT
8.1 in this certification criterion. CMS has recently proposed (77 FR
45022) to retire version 8.1 and only permit version 10.6 as of 11/1/
2013. More importantly, NCPDP SCRIPT 10.6 is backwards compatible with
version 8.1, so 10.6 users will be able to communicate with version 8.1
users. Therefore, even in the event that CMS does not retire version
8.1 before the FY/CY 2014 EHR reporting period, use of version 10.6
should not have an adverse impact on stakeholders. Moreover, we
understand that version 10.6 includes much needed improvements and
better supports stakeholders' e-prescribing needs across a variety of
health care settings.
Comments. A number of commenters requested that we establish a
deeming provision as part of our e-prescribing certification criterion
that would make Surescripts certification for participation in its
network an acceptable method to demonstrate compliance with this
certification criterion. That is, in lieu of being certified by an ONC-
ACB according to the adopted certification criterion and standards, EHR
technology could be deemed to be certified to meet this certification
criterion if it were certified according to Surescripts certification
requirements.
Response. As we did not propose deeming authorities in the Proposed
Rule, these suggestions are outside the scope of this final rule.
Furthermore, we believe that the best way to ensure that EHR technology
includes the capabilities specified by the certification criteria
adopted by the Secretary is to require EHR technology to be tested and
certified to these certification criteria under the provisions and
procedures specified by the ONC HIT Certification Program.
Comments. Several commenters requested that we include HL7 v2.x
standards for discharge e-prescribing. They reasoned that discharge
prescriptions filled by a pharmacy within the walls of a hospital
facility frequently use HL7 v2.x prescribing messages. Some commenters
also stated that EHR technology certified to the HL7 v2.x standards for
discharge e-prescribing should be permitted even in cases where the
pharmacy inside the hospital facility may be a different legal entity
from the source of the discharge medication. Commenters asserted that
hospitals currently use HL7 transmissions to send their prescriptions
to an onsite pharmacy that is a separate legal entity. Another
commenter requested clarification as to whether NCPDP SCRIPT needed to
be used by an EH/CAH to transmit electronic prescriptions for discharge
medications that would be filled by that EH/CAH's hospital-based
pharmacy, including when that pharmacy is a separate legal entity.
Other commenters supported our approach of focusing on interoperability
between different legal entities and not on transactions within a legal
entity.
Response. We appreciate the support for our e-prescribing approach
to certification. We continue to believe, as we stated in the Proposed
Rule that it would be inappropriate and without sufficient benefit to
require certification of EHR technology for transmissions that would be
conducted within a single legal entity. We continue to believe, as we
stated in the Proposed Rule (77 FR 13845), that doing so would be
inconsistent with our approach of adopting standards for the electronic
exchange of health information between different legal entities. We
encourage commenters to read the Stage 2 proposed rule (77 FR 13710)
because it discusses the various ways in which the e-prescribing MU
objectives can be met such that it should address the concerns
expressed by these comments. We also encourage commenters that
indicated that HL7 transmissions were used even in situations where a
pharmacy is considered a different legal entity to carefully read the
Medicare Part D e-prescribing rules at 42 CFR 423.160(a)(3)(iii)
(noting that HL7 transmissions are only permitted when the sender and
recipient are part of the same legal entity). In light of the Part D e-
prescribing program bar on the use of HL7 between different legal
entities, we are not considering allowing it in our certification
criterion.
[[Page 54199]]
Comments. A commenter requested that we clarify what the use of
RxNorm as the sole vocabulary would entail. The commenter asked whether
RxNorm would be a drug description or a drug qualifier and urged ONC to
reference RxNorm as a drug qualifier, specifically via the use of
RxNorm concept unique identifiers (RXCUIs), similar to how NDC
identifiers are currently being used. The commenter stated that since
most EHR technologies use proprietary commercial drug databases for
their clinical terminology needs, that there is a critical and urgent
need for RxNorm RXCUI mappings to proprietary drug database codes to be
made readily available to the industry by either drug database
companies or a third party in order to foster the adoption of RxNorm.
Response. The use of RxNorm as the sole vocabulary standard would
entail its use to represent medications within an electronic
prescription formatted according to the SCRIPT 10.6 standard. We intend
for the RxNorm concept unique identifiers (RXCUIs) to be used as drug
qualifiers. Mappings are not something within the scope of this
rulemaking and we decline to make any changes in response to this
comment.
Comments. Many commenters agreed with our proposal to adopt RxNorm,
but requested certain clarifications. These commenters noted that not
all medications in source vocabularies have an equivalent RxNorm code.
Further, they suggested that the standard should state that the RxNorm
vocabulary will be utilized when there is an equivalent concept
mapping. Others requested clarification that the reference to RxNorm
means that RxNorm codes must be included in transmitted messages, not
that only RxNorm codes can be transmitted because there are some
prescriptions that do not have corresponding RxNorm codes and will
require other code sets. A commenter expanded on these concerns with
the following observation: Some drug descriptions in RxNorm are over
105 characters in length, but the NCPDP SCRIPT standard limits drug
descriptions to 105 characters, which means that transmission of some
e-prescriptions that include RxNorm drug descriptions would be either
truncated or not possible. As such, they suggested that certification
criteria for RxNorm should be limited to use of this standard for drug
qualifiers only. They also cautioned that RxNorm is not yet a complete
drug compendium, and that RxNorm qualifiers are not available for all
prescriptions that are currently sent electronically (e.g., medical
supplies). Similar to other commenters, they also suggested that we
clarify that the transition to the certification criterion would not
preclude use of other drug databases and qualifiers if circumstances
require it.
Response. We acknowledge that all medications may not yet have an
equivalent RxNorm code. We do not believe it is necessary to modify the
standard to explicitly state that RxNorm ``be utilized when there is an
equivalent concept mapping'' because certification is meant to verify
that EHR technology can properly use this standard. This certification
criterion requires the capability to use RxNorm, specifically RXCUIs as
noted in our prior response. Thus, where no RxNorm code exists, nothing
prohibits another code from being used. However, where corresponding
RxNorm codes exist, EHR technology must be able to use those codes. As
RxNorm continues to expand, we expect that the concerns raised by
commenters about its comprehensiveness will subside.
Comment. Commenters noted that the same e-prescribing certification
criterion applies to both ambulatory and inpatient settings. They
stated that it would be important for the final rule and subsequently
developed test procedures to identify any differences between the two
settings.
Response. With the exception of which test data elements might be
required, this certification criterion applies equally to both
settings. EHR technology certified to this certification criterion will
need to enable a user to electronically create prescriptions and
prescription-related information in accordance with NCPDP SCRIPT 10.6
and RxNorm.
Comment. A commenter stated that there needs to be a clear way to
differentiate whether a prescription is merely sent ``in house''
(scenarios 1 and 2 in the Stage 2 proposed rule or ``transmitted''
(scenario 3)).
Response. Given the flexibility provided by CMS, we believe this
will need to be determined on an implementation-by-implementation basis
and would be difficult to assess for the purpose of certification in a
simulated testing laboratory environment.
Comment. A commenter recommended that EHR technologies support
integration with HIEs in support of the e-prescribing process.
Response. This suggestion is outside the scope of our final rule.
We appreciate the commenter's feedback and will consider whether a
certification criterion to address this type of capability would be
appropriate for a future rulemaking.
Comments. A few commenters discussed the electronic prescribing of
controlled substances. Some encouraged ONC and CMS to work to include
controlled substances into future meaningful use measures. Others
agreed with CMS's proposal to continue to exclude controlled substances
from the e-prescribing objectives and asked that we make clear that the
electronic prescribing of controlled substances (EPCS) is not required
(and will not be tested) from a certification standpoint. They noted
that e-prescribing of controlled substances involves many other
workflow requirements for prescription review and acknowledgment,
technical requirements for electronic signature and security of the
transmitted prescription that go well beyond the scope of what was
proposed. One commenter stated that adopting NCPDP SCRIPT version 10.6
without also mandating e-prescribing of controlled substances is
contradictory and will create unnecessary costs and undesirable results
due to the lack of synchronization. They contended that NCPDP SCRIPT
version 10.6 should not be required for certification because it will
slow the progress being made by the industry as stakeholders are
coupling their development efforts for NCPDP SCRIPT version 10.6 and e-
prescribing of controlled substances together. Last, a commenter
suggested that we should require that EHR technology that includes e-
prescribing capabilities to be implemented according to the recently
released DEA requirements for all e-prescribing.
Response. While we intend to continue to work with CMS on the issue
of controlled substance e-prescribing, we believe it is premature to
include controlled substances in the 2014 edition of the certification
requirements. We will need to carefully evaluate the practicality of
what would amount to duplicating DEA's regulatory requirements for
certification in our regulations and the potential unintended
consequences of taking such a step. Furthermore if we were to adopt
some or all of the provisions in the DEA's interim final rule in our
program and, if DEA were to make any changes as it finalizes its
interim final rule, our adopted certification criteria would be out of
compliance with DEA's requirements. Further, DEA permits a
certification option in its interim final rule and has approved at
least one certification body's processes to perform certifications for
EPCS. Thus, we question the value in ONC replicating these already
established processes.
[[Page 54200]]
Finally, we do not see how the adoption of NCPDP SCRIPT 10.6 without
mandating EPCS could be contradictory. They are both separate and
distinct regulatory requirements and one does not necessarily depend on
the other to succeed.
Comment. A commenter recommended that we revise the certification
criterion as follows, ``generate and transmit permissible discharge
prescriptions electronically.''
Response. We do not believe that this editorial suggestion adds any
tangible value or clarifies the wording in the certification criterion
in a major way. Thus, we decline to modify this certification criterion
in response to this suggestion.
Comment. A commenter recommended that we include a capability in
the certification criterion that ensures a provider is actively alerted
when an e-prescription fails.
Response. This suggested capability is beyond the scope of the
proposed certification criterion and we decline to modify the
certification criterion. We will consider whether such a requirement
would be appropriate to include in later editions of EHR certification
criteria.
Comment. A commenter recommended that there be a way for patients
to review e-prescriptions and participate in medication reconciliation
with both their doctors and pharmacists via a patient portal.
Response. This suggested capability is beyond the scope of the
proposed certification criterion and we decline to modify the
certification criterion. We will consider whether such a requirement
would be appropriate to include in later editions of EHR certification
criteria.
Comment. A commenter stated that they would like standards and
testing to demonstrate using e-prescribing for refills that allows
multiple medications to be refilled from a single screen through a
single transaction. They explained that for some EHR technologies the
refill process is more problematic than the initial prescription
process and that certification should ensure this is not the case.
Response. We do not believe that this is an issue that can be
readily addressed through certification. Rather, this comment appears
to focus on a particular user interface and workflow design
shortcomings of certain EHR technology. This aspect is outside the
scope of what is required by this certification criterion.
Transmission of Electronic Laboratory Tests and Values/
Results to Ambulatory Providers
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
Provide structured electronic laboratory results to eligible
professionals.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(b)(6) (Inpatient setting only--transmission of electronic
laboratory tests and values/results to ambulatory providers).
------------------------------------------------------------------------
We proposed a certification criterion that was similar to the one
recommended by the HITSC to support the MU objective and measure
recommended by the HITPC for EHs and CAHs to send electronic laboratory
tests and values/results to EPs. CMS did not specifically propose the
HITPC recommended MU objective and measure for Stage 2, but requested
public comment on whether the objective and measure should be
incorporated into MU Stage 2.
We proposed to include in the certification criterion the standards
and implementation specification recommended by the HITSC and HITPC for
the transmission of laboratory tests and values/results. In particular,
we referenced the work of the Standards and Interoperability Framework
Laboratory Results Interface Initiative which focused on the
identification of a consistent set of data content that would need to
be exchanged when laboratory tests and values/results are
electronically delivered. We proposed to include the HL7 2.5.1 standard
and the HL7 Version 2.5.1 Implementation Guide: Standards and
Interoperability Framework Laboratory Results Interface, Release 1 (US
Realm) (S&I Framework LRI). We proposed to adopt LOINC[supreg] version
2.38 as the vocabulary standard, at the recommendation of the HITPC and
agreement of the HITSC. We noted that the LRI specification was
undergoing HL7 balloting and that we would monitor its progress in
relation to the publication of this final rule.
With respect to testing and certification for this certification
criterion, we stated that, among other aspects, inpatient EHR
technology would need to demonstrate its compliance with the ``Common
Profile Component'' and other required profiles included within the LRI
implementation guide. We also noted that we had proposed to adopt a
revised certification criterion for the ambulatory setting that would
require EHR technology to be capable of incorporating laboratory tests
and values/results according to the standards and implementation
specifications we proposed for this certification criterion.
In proposing this certification criterion, we stated that requiring
inpatient EHR technology to be capable of creating for transmission
laboratory tests and values/results formatted in accordance with the
LRI specification could make it more cost effective for electronic
laboratory results interfaces to be set up in an ambulatory setting
(i.e., minimal additional configuration and little to no additional/
custom mapping) and that the electronic exchange of laboratory tests
and values/results would improve.
Comments. Many commenters supported this certification criterion.
Some commenters stated that we should not adopt this certification
criterion without CMS establishing a corresponding MU objective and
measure, while other commenters did not support this certification
criterion for concerns related to implementation costs, the proposed
standards, and the inclusion of this functionality in EHR technology.
Response. We are adopting this certification criterion for the 2014
Edition EHR certification criteria at Sec. 170.314(b)(6). After
consideration of public comments, CMS has included a corresponding
objective and measure in the MU Stage 2 menu set and the adoption of
this certification criterion will support that objective and measure.
We discuss our responses to the other commenters' concerns in our
responses below.
Comments. Commenters recommended that the transmission of
electronic laboratory tests and values/results from inpatient EHR
technology should follow the same standard that applies to the
incorporation of laboratory tests and values/results in ambulatory EHR
technology. Some of these commenters stated that this certification
criterion should not be adopted without ambulatory EHR technology
having the same requirements.
Response. We agree with commenters. We proposed and have adopted in
the ``incorporate laboratory tests and values/results'' certification
criterion (Sec. 170.314(b)(5)) a requirement that EHR technology
designed for the ambulatory setting must be certified to be able to
receive and incorporate laboratory tests and values/results in
accordance with the LRI specification. The certification criterion
discussed here, and which is applicable to inpatient EHR technology,
requires that such EHR technology be able to create laboratory test
reports in the same manner.
Comments. Many commenters supported the proposed standards and
implementation guide. Other commenters stated that while the S&I
Framework LRI is based on previously
[[Page 54201]]
used standards, it is not in widespread production and may not be
sufficiently mature for nationwide use. A few commenters noted that
pilots currently in process were using the LRI specification. One
commenter stated that the LRI specification was developed for the types
of tests commonly ordered in the ambulatory setting and does not
address electronic messaging of complex test results such as molecular
genetics, anatomic pathology, and cytology. The commenter contended
that messaging for these test results needs further development and
testing before they can be included in routine electronic messaging
transmission of laboratory results from hospitals to ambulatory
providers. Therefore, the commenter recommended postponing inclusion of
the LRI specification until the next edition of certification criteria.
Response. We believe that the S&I Framework LRI implementation
guide is mature enough for adoption and inclusion in this certification
criterion. As we noted above and in the Proposed Rule, the LRI
implementation guide has been undergoing balloting by HL7. The LRI
implementation guide was approved by HL7 as a Draft Standard for Trial
Use (DSTU) in July 2012. This confirms its adoption as a consensus-
based standard ready for use. This DSTU version of the standard updates
the version we proposed by correcting errors and clarifying
requirements. These corrections and clarifications will assist EHR
technology developers in implementing the standard and will improve
testing to the standard. As noted by HL7 in its documentation, this
DSTU version of the standard will be open for comment for 24 months and
following this evaluation period, it will be revised as necessary and
then submitted to ANSI for approval as an American National Standard
(normative standard). Further, HL7 specifies that implementation of
this DSTU version will be valid during the ANSI approval process and
``for up to six months after publication'' of the normative standard.
Given the state at which this DSTU version of the standard is and the
fact that this version alone is subject to the evaluation period, we
believe that it is the best possible choice for this final rule,
especially in place of the draft version we referenced in the Proposed
Rule. Accordingly, we have adopted this version of the LRI
implementation guide for requiring the electronic creation of
laboratory tests and values/results for electronic transmission and to
support the associated MU objective and measure.
As we acknowledged in a response to a comment on the revised
``incorporate laboratory tests and values/results'' certification
criterion (Sec. 170.314(b)(5)), we erred in referencing the HL7 2.5.1
standard in addition to the LRI specification. Thus, we have removed
the reference to the HL7 2.5.1 standard in this certification
criterion. We also clarify that with the exception of the baseline
minimum version of LOINC[supreg] that must be supported by EHR
technology, we expect, in adopting this specification that it will be
followed and implemented as authored.
Comments. Some commenters agreed that this certification
requirement could potentially lead to reduced costs for laboratory
interfaces, while other commenters thought it was unlikely to reduce
costs. Commenters stated that lab system vendors are not necessarily
bound to conform to the LRI specification which would create an
undesirable situation where EHRs would be forced to provide conforming
and non-conforming interfaces (one set to comply with certification and
the other to be used for communication with lab systems). Commenter
also stated that laboratory information systems (LIS) typically produce
the reportable results. Commenters stated that these systems are not
normally integrated with the hospital EHR. Rather these systems send
lab results directly to the ordering physicians based on rules defined
by CLIA (Clinical Laboratory Improvement Amendments) and are often
further refined by state regulation.
Commenters noted that this certification criterion may serve to
open up the strong possibility that laboratory information systems
(LISs) will become certified as EHR modules on a more regular basis,
and may motivate some vendors to seek certification on that basis both
for this criterion as well as the public health reporting of lab
results (which some LIS vendors have already done).
Response. The MU objective and measure that this certification
criterion supports is in the MU Stage 2 menu set. Based on the revised
CEHRT definition, the final rule provides EHs and CAHs the regulatory
flexibility to determine whether to adopt EHR technology certified to
this certification criterion in order to meet this MU objective and
measure. Further, as noted by some commenters, the relevant LIS
capabilities could potentially be certified to this certification
criterion, perhaps as an EHR Module, and used to meet the associated MU
objective and measure. Considering these points, we do not believe this
certification criterion creates any undue burden and, as agreed to by
commenters, could facilitate more cost effective electronic laboratory
results interfaces in the ambulatory setting.
Comments. Some commenters suggested we focus on a ``standard
receiver'' or ``universal interface'' that could accept multiple types
of results in one interface. These commenters stated that it is cost-
prohibitive to providers to purchase different interfaces for each set
of information received. Therefore, these commenters recommended that
we permit the use of existing interfaces or postpone certification and/
or MU requirements related to use of the LRI, while efforts are pursued
towards a ``universal interface.''
Response. The adopted LRI specification for the ambulatory setting
is intended to provide the desired interface uniformity commenters have
noted for the receipt of laboratory test results. We believe this
standard is appropriate and mature for the purposes of EHR technology
certification. As we have indicated in other responses in this final
rule certification addresses the technical capabilities that EHR
technology must include. It does not address how it must be used, once
certified. Therefore, we do not agree with the comment that we should
postpone adoption of this certification criterion until a ``universal
interface'' is developed. In the Stage 2 final rule published elsewhere
in this edition of the Federal Register, CMS specifies the requirements
and flexibilities related to the incorporation of laboratory test
results.
Comments. Commenters supported the adoption of the LOINC[supreg]
standard for transmitting laboratory test results. Commenters stated,
however the full LOINC[supreg] coding of all tests and analytes is
unnecessary. Rather, the commenters stated that the subset that
accounts for most frequent ambulatory use and alignment with quality
measures and public health requirements should be the requirement.
Response. To meet this certification criterion, EHR technology must
meet the LRI specification using LOINC[supreg]. For the purposes of
testing and certification, we expect that EHR technology will be
evaluated based on its ability to use most commonly reported
LOINC[supreg] codes. We expect that the test procedure developed for
this certification criterion will leverage LOINC[supreg] materials
published by the Regenstrief Institute and available through the
National Library Medicine,\16\ which in this case
[[Page 54202]]
would be the ``LOINC[supreg] Top 2000+ Lab Observations and Mapper's
Guide.'' This guide is an empirically-based list of the most common
LOINC[supreg] result codes for laboratories, practices, researchers,
and others who wish to map their laboratory test codes to universal
LOINC[supreg] codes. This list contains over 2000 of the most commonly
reported LOINC[supreg] codes that represent about 98% of the test
volume carried by three large organizations that mapped all of their
laboratory tests to LOINC[supreg] codes. We believe this scope for
testing and certification will help aid EHR technology developers and
focus development efforts toward these top 2000+ codes first.
---------------------------------------------------------------------------
\16\ http://www.nlm.nih.gov/healthit/meaningful_use.html--click
on helpful subsets under the LOINC heading.
---------------------------------------------------------------------------
Comments. Commenters suggested that we simply state in regulation
that EHR technology can be certified to the most recent versions of
LOINC[supreg].
Response. We have established a process for adopting certain
vocabulary standards, including LOINC[supreg], which permits the use of
newer versions of those standards than the one adopted in regulation.
We refer readers to section IV.B for a discussion of ``minimum
standards'' code sets and our new more flexible approach for their use
in certification and upgrading certified Complete EHRs and certified
EHR Modules. Readers should also review Sec. 170.555, which specifies
the certification processes for ``minimum standards'' code sets.
Comment. A commenter requested a list of CPT codes that define
imaging studies and a listing of CPT codes that define a laboratory
test.
Response. The commenter did not provide any supporting rationale as
to why a list of CPT codes would be relevant to the capabilities
expressed by this certification criterion. Thus, we decline to provide
any additional information.
Comments. A commenter recommended inclusion of a date/time stamp on
all values sent to ambulatory providers.
Response. The LRI specification's message header includes a
required date/time stamp and the result segment (OBX) includes a test
performed date/time stamp that is required if it exists.
Comments. A commenter suggested that NwHIN query-and-response
protocol be required for use in sharing laboratory test results as part
of this certification criterion. The commenter stated that such a
requirement would encourage EHR technology developers to use the NwHIN
protocol to have providers in different care settings access clinical
information, including laboratory tests.
Response. We appreciate the commenter's suggestion, but did not
propose specific transport approaches to require for certification and
intend to focus certification on the proper implementation of the LRI
specification.
Comments. Commenters requested clarification about to whom the
transmission may occur, whether directly to EPs or through an HIE
structure.
Response. This certification criterion focuses on the proper
implementation of the LRI specification. How or by what means the
laboratory test report gets to an EP is not currently within the scope
the certification criterion and, in part, is likely dictated by other
regulatory requirements, such as the CLIA rules.
Comments. A few commenters suggested that ONC work with CMS to
encourage laboratories to adopt and use the S&I Framework LRI
specification. They contended that without the ``source systems'' on
board that requiring capabilities on receiving systems (EHR technology)
would fall short of the intended purpose of reducing development time
and costs and improving quality.
Response. We appreciate these comments and will continue to work
with our sister agencies in HHS to advance health IT policy in other
programs and regulations that affect stakeholders that are not eligible
to receive EHR incentive payments.
Comment. A commenter stated that patients should also have access
to all laboratory tests and results immediately, both inpatient and
ambulatory, as a matter of patient safety.
Response. We appreciate this comment, but it is not something a
capability in EHR technology, per se, can resolve. Through the EHR
Incentive Programs, EPs, EHs, and CAHs, will have to provide online
access to patients to view their electronic health information. This
should provide a means for patients to get prompt access to their
laboratory test results. We also note that CMS and OCR have engaged in
rulemaking to permit patients to directly access their lab test reports
(75 FR 56712).
10. Revised Certification Criteria
In the Proposed Rule, we described certification criteria that we
considered ``revised.'' We noted the following factors that we would
consider when determining whether a certification criterion is
``revised:''
The certification criterion includes changes to
capabilities that were specified in the previously adopted
certification criterion;
The certification criterion has a new mandatory capability
that was not included in the previously adopted certification
criterion; or
The certification criterion was previously adopted as
``optional'' for a particular setting and is subsequently adopted as
``mandatory'' for that setting.
For clarity, we explained that, in some cases, a certification
criterion could be both ``revised'' and ``new.'' For example, a
previously adopted certification criterion could have been adopted for
only the ambulatory setting. Subsequently, we could revise the
certification criterion by adding a new capability and making it
mandatory for both the ambulatory and inpatient settings. Once adopted,
the certification criterion would be ``new'' for the inpatient setting
and ``revised'' for the ambulatory setting.
Comments. We did not receive comments questioning our description
of revised certification criteria.
Response. Given that we received no comments, we will continue to
use this description of revised certification criteria to categorize
the following certification criteria we have adopted as part of the
2014 Edition EHR certification criteria. We note that the following
adopted revised certification criteria included certification criteria
that were not only proposed as revised certification criteria, but also
certification criteria that were proposed as unchanged certification
criteria in the Proposed Rule.
a. Ambulatory and Inpatient Setting
We propose to adopt the following revised certification criteria
for both the ambulatory and inpatient settings.
Vital signs, body mass index, and growth charts
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
Record and chart changes in the following vital signs: height/length and
weight (no age limit); blood pressure (ages 3 and over); calculate and
display body mass index (BMI); and plot and display growth charts for
patients 0-20 years, including BMI.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(a)(4) (Vital signs, body mass index, and growth charts).
------------------------------------------------------------------------
We proposed the ``vital signs, body mass index, and growth charts''
certification criterion (Sec. 170.314(a)(4)) of the 2014 Edition EHR
certification criteria as an unchanged certification criterion. We
proposed to replace the terms ``modify'' and ``retrieve'' with
``change'' and ``access,'' respectively. We also proposed to add the
alternative term ``length'' to go with ``height'' as it
[[Page 54203]]
is the clinically appropriate term for newborns and assisted in
clarifying the intent of the ``vital signs'' capability. The only other
refinements that we proposed were for the plot and display growth
charts capability. First, we proposed that this capability be
designated ``optional'' within this certification criterion because
some EPs, EHs, and CAHs would not (or would never) use such a
capability due to scope of practice or other reasons. Thus, to reduce
regulatory burden and to not require EHR technology developers to
include a specific growth chart capability when they do not intend to
market their EHR technology to EPs, EHs, or CAHs that would use such a
capability, we proposed to designate growth charts as ``optional'' for
certification. Second, we proposed to remove the age range reference
(2-20 years old) from this capability. We noted that this proposed
refinement was consistent with other certification criteria such as
``smoking status'' where the MU objective it supports specifies an age
threshold (13), but the capability is not dependent on a patient's age.
Comments. Many commenters recommended that this certification
criterion remain unchanged. A couple of commenters recommended the use
of the LOINC[supreg] (for observations), SNOMED CT[supreg] (for
qualitative results), and UCUM (for units of measure), as applicable,
for the recording of the data elements specified in this certification
criterion. One commenter recommended that requirements for specific
data elements that would be included as part of vital signs data in MU
Stage 2, such as ECG waveforms, be defined so that the appropriate
device integration standards can be developed to support
interoperability and certification standards and criteria for these
important physiologic signals.
A commenter stated that the capability to plot and display growth
charts should be a required capability and should be specified in more
detail. Another commenter requested clarification on what type of
growth charts were applicable based on age ranges. In particular, the
commenter pointed to the World Health Organization for growth standards
for children 0 to 2 years old and CDC growth charts for ages 2 and
older.\17\ Another commenter requested clarification that growth charts
would not need to be included in a transition of care/referral summary
formatted in accordance with the Consolidated CDA because they are not
listed as a ``vital sign'' in the Consolidated CDA. Commenters also
requested guidance on how the optional capability of plotting and
displaying growth charts would be indicated in an EHR technology's
certification and for marketing purposes.
---------------------------------------------------------------------------
\17\ http://www.cdc.gov/growthcharts/who_charts.htm.
---------------------------------------------------------------------------
Response. We thank commenters for generally supporting this
certification criterion. We decline to revise this certification
criterion in response to the comment that recommended we require EHR
technology to natively record vital signs data in specific
vocabularies. We did not propose this requirement and believe that the
complexity of wholesale change to the data capture processes of
existing EHR technologies for this purpose cannot be understated.
Additionally, it is our understanding that many EHR technologies
capture this information, but do not currently map it to standardized
terminologies such as LOINC[supreg]--and there are currently many
different workflows, templates, and forms that are used to capture this
information. Thus, we believe that requiring vital signs data that is
recorded to, for example, be mapped to LOINC[supreg] is too burdensome
a requirement to impose for certification to the 2014 Edition EHR
certification criteria. Moreover, our concern stems from the
possibility that such a requirement could cause EHR technology
developers to map vital signs capture to a standardized terminology in
one workflow but perhaps not others--which would then cause providers
to be forced to use a given workflow/form/template to achieve MU that
is not consistent with optimal workflow/usability. We do intend,
however, to require as part of the next edition of EHR certification
criteria that EHR technology would need to be able to record all vital
signs according to standardized terminologies. Further, we emphasize to
EHR technology developers that nothing precludes you from taking this
step for certification to the 2014 Edition EHR certification criteria.
Nonetheless, in response to these comments we evaluated the
specificity and clarity of the certification criterion and believe that
it needs to be revised. First, we believe the grammar in the
certification criterion makes it more difficult than necessary to read.
Second, while we have declined to revise this certification criterion
in the way commenters suggested (that we require explicit recording of
vital signs in standardized codes), we believe that an important, but
modest, intermediate step must be taken to improve the certification
criterion's specificity and its ability to affect patient safety.
Accordingly, we have revised this certification criterion to explicitly
state that the data recorded by EHR technology for height/length,
weight, and blood pressure must be in numeric values only (i.e.,
alphabetic characters such as ``lbs,'' ``kg,'' or ``cm'' would not be
permitted to included as part of the value recorded). This restriction
has significant clinical and patient safety benefits because it
prevents the inappropriate recording of text in fields that should be
constrained to numeric values. Additional attributes that may be used
to document (e.g., which arm a blood pressure is taken from, whether
the patient is sitting or standing, or a reason that the value could
not be obtained) should be recorded in a supplemental field rather than
the field for the value itself. We expect that a significant majority
of EHR technologies already function this way. Thus, we anticipate that
this revision poses little, if any, practical burden to most EHR
technology developers. However, in cases where this revised
certification criterion will cause EHR technology to be updated for
certification, we believe that better patient safety outweighs the
burden.
With respect to the commenter's recommendation for defining and
including data elements such as ECG waveforms as part of vital signs
data in MU Stage 2, we note that this data element goes beyond the
requirements of the associated MU objective and measure. Thus, we have
not made any changes in response to this recommendation.
We do not believe that the capability to plot and electronically
display growth charts should be a required capability because, as we
noted in the Proposed Rule, not all EP, EHs, and CAHs will necessarily
need this capability. For certification to this certification
criterion, we clarify that EHR technology is not required to
demonstrate the capability to provide growth charts based on subsets of
age ranges within the 0-20 age range required by the MU objective.
However, we encourage EHR technology developers to include the
specificity that best addresses their customers' needs. We further
clarify that the growth chart capability included in this certification
criterion requires EHR technology to be capable of plotting and
electronically displaying growth charts of patients. We do not expect
growth charts to be transmitted in a transition of care/referral
summary formatted in accordance with the Consolidated CDA. Last, we
expect that certifications issued to EHR technology certified to this
certification criterion will indicate
[[Page 54204]]
whether the EHR technology is capable of plotting and electronically
displaying growth charts and that such information would be accessible
on the CHPL.
Drug-Formulary Checks
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
Implement drug formulary checks.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(a)(10) (Drug formulary checks).
------------------------------------------------------------------------
We proposed the ``drug-formulary checks'' certification criterion
(Sec. 170.314(a)(10)) of the 2014 Edition EHR certification criteria
as an unchanged certification criterion.
Comments. Many commenters supported this certification criterion
remaining unchanged for the 2014 Edition EHR certification criteria. A
few commenters suggested that EHR technology developers who had
completed Surescripts' Eligibility and Formulary certification could be
permitted to attest to this certification criterion. Commenters
recommended that EPs be able to obtain drug-formulary information that
is accurate, in real-time, and includes the necessary details for the
prescriber's review. One commenter recommended that we specifically
include a capability in this certification criterion to capture the
plan name, plan identification number, group identification number, and
pharmacy benefit management care coverage in structured data. A couple
of commenters recommended that we adopt the NCPDP Formulary and Benefit
Standard Implementation Guide, Version 3.0, or alternatively, at a
minimum, the NCPDP Formulary and Benefit Standard Implementation Guide,
Version 1.0 as the standard to enable electronic formulary checking. A
commenter suggested that we require EHR technology to be capable of
making available all necessary formularies, which the commenter stated
would help address situations where there is a lack of consistent
access to Medicaid formularies, including Medicaid Managed Care
formularies.
Response. We appreciate the support expressed for the certification
criterion and the specific feedback commenters provided. In response to
this feedback and clarifications issued by CMS in its final rule for
the MU objectives and measures this certification criterion supports,
we have determined that it is necessary to revise this certification
criterion. The revised certification criterion is designed to ensure
that a drug formulary check poses minimal burden on EPs, EHs, and CAHs.
Further, the revision we have included specifies that EHR technology
must perform an automated check for the existence of a drug formulary
that is specific to a patient for the medication to be prescribed. In
other words, an EHR technology would not satisfy this revised
certification criterion if it provided a hyperlink to a patient's drug
formulary that an EP, EH, or CAH then had to manually open and
navigate. With respect to commenters' suggestions to further modify
this certification criterion to include additional capabilities, such
as those that would ensure real-time information, capture of specific
information (e.g., plan name, plan identification number, etc.) in
structured data, and making available all necessary formularies, we
believe these suggestions exceed the baseline requirements for
certification that we have included to support MU. Thus, we decline to
make any further revisions to the certification criterion except those
noted above. As discussed in the e-prescribing comment and responses
part of this final rule, CMS has issued a proposed rule (77 FR 45022)
that would update Medicare Part D e-prescribing standards, including a
new version of the formulary and benefit standard. We strongly
encourage EHR technology developers to utilize these standards, but do
not believe that it is necessary at this time to require them as a
condition of certification--as having current drug formularies stored
locally in the EHR technology would also be a permitted approach.
Further, as we discussed in the S&CC July 2010 final rule (75 FR
44602), because some EPs, EHs, and CAHs, do not have external access to
a drug formulary and would be able to satisfy the MU requirements by
checking an internally managed drug formulary, we believe the
flexibility provided by the certification criterion is still warranted.
We intend to seek recommendations from the HITSC on further
requirements related to this certification criterion in developing the
next edition of our EHR certification criteria.
Last, the ONC HIT Certification Program does not include any form
of reciprocity for certification under other private sector
certification programs, including Surescripts' certification program.
The ONC HIT Certification Program will be a ``new'' certification
program that will replace the temporary certification program upon the
effective date of this final rule. At its onset, we believe that the
best way to ensure that EHR technology has the capabilities included in
the certification criteria adopted by the Secretary is to require the
EHR technology to be tested and certified to the certification criteria
under the provisions and procedures specified by the ONC HIT
Certification Program.
Smoking Status
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
Record smoking status for patients 13 years old or older.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(a)(11) (Smoking status).
------------------------------------------------------------------------
The 2011 Edition EHR certification criterion for smoking status
(Sec. 170.302(g)) specifies a list of six smoking status types that
EHR technology must be capable of recording, modifying, and retrieving.
For the 2014 Edition EHR certification criteria, we proposed a
``smoking status'' certification criterion that replaced the terms
``modify'' and ``retrieve'' with ``change'' and ``access,''
respectively. We also proposed to specify the six smoking status types
included in the 2011 Edition EHR certification criterion as a standard
at Sec. 170.207(l). We stated that this refinement would provide
additional clarity for the certification criterion and consistency with
the structure of similar certification criteria.
Comments. Multiple commenters expressed agreement with this
certification criterion as proposed. More commenters, however,
recommended that we adopt an industry developed and accepted standard
and pointed to SNOMED CT[supreg] as the appropriate standard. If SNOMED
CT[supreg] was not adopted, commenters asked that we provide a
crosswalk from the smoking status types included in the certification
criterion to the appropriate SNOMED CT[supreg] codes.
Commenters raised questions about the definitions/categories of the
smoking status types. One commenter suggested that all tobacco use
should be captured. Another commenter recommended that the smoking
status types reflect the questions used in community health assessment
that track smoking and tobacco use cessation interventions or medical
assistance such as: (a) Advising smokers and tobacco users to quit
``patient has been offered a smoking cessation program;'' (b)
discussing smoking and tobacco use cessation medications; (c)
discussing smoking and tobacco use cessation strategies or ``assistance
in setting a quit date.'' A few commenters asked whether mapping to the
smoking status types included in the certification criterion would be
permitted for certification and, if so, for further clarification of
potential categories that would suitably
[[Page 54205]]
map to the smoking status types included in the certification
criterion. For example, commenters asked whether mapping would apply to
only cigarettes or other forms of combustible tobacco use as well.
A few commenters noted that the smoking status types adopted for
the 2011 Edition EHR certification criteria and proposed for the 2014
Edition EHR certification criteria do not align with those used in the
quality measures in Stage 1 and proposed for Stage 2, such as NQF 0028
(Preventive Care and Screening: Tobacco Use: ``Screening and Cessation
Intervention (percentage of patients aged 18 years and older who were
screened for tobacco use one or more times within 24 months AND who
received cessation counseling intervention if identified as a tobacco
user''). The commenters noted that NQF 0028 goes beyond documenting
smoking status to encourage cessation counseling. Consequently, the
commenters suggested that we could alleviate reporting burdens and
workflow issues by agreeing on a single tobacco use value set for all
meaningful use objectives and clinical quality measures.
Response. We thank commenters for their feedback and agree with
much of what was said. We have now provided mappings to a set of SNOMED
CT[supreg] concepts to assist the developers and implementers of EHR
technology in the implementation of this requirement. We have also
expanded the number of available concepts from six to eight in order to
better reflect the way that many EPs capture smoking status. We clarify
that the eight smoking statuses provided here need not be the exact
words that are displayed for a user. Rather, any appropriate concept or
concepts that the EHR technology displays for an EP may be mapped to
one or more compatible smoking status codes, but if an alternative
approach is used, the EHR technology must ultimately be able to record
the semantic representation of a patient's smoking status in at least
one of these eight status. Further, these eight codes must be used as
specified elsewhere in this final rule when smoking status is
referenced, such as within the transitions of care certification
criterion. We clarify that smoking status includes any form of tobacco
that is smoked, but not all tobacco use. Working with CMS, we have
added these eight value sets to NQF 0028, so that (for the portion of
NQF 0028 that captures smoking status) an EP or EH can capture this
data only once rather than twice.
------------------------------------------------------------------------
Description SNOMED CT[supreg] ID
------------------------------------------------------------------------
Current every day smoker....................... 449868002
Current some day smoker........................ 428041000124106
Former smoker.................................. 8517006
Never smoker................................... 266919005
Smoker, current status unknown................. 77176002
Unknown if ever smoked......................... 266927001
Heavy tobacco smoker........................... 428071000124103
Light tobacco smoker........................... 428061000124105
------------------------------------------------------------------------
As described above, these eight smoking statuses have been provided
in order to permit EHR technology developers to incorporate the capture
of smoking status as part of an efficient, fluid user experience. We
have added two smoking statuses to the standard adopted in Sec.
170.207(h) in order to better reflect clinically relevant differences
between smokers, and provide options that may in fact be preferable to
many providers, while retaining the existing six codes from the 2011
Edition certification program in order to give EHR developers the
option of migrating to the newer codes over time. ``Light smoker'' is
interpreted to mean fewer than 10 cigarettes per day, or an equivalent
(but less concretely defined) quantity of cigar or pipe smoke. ``Heavy
smoker'' is interpreted to mean greater than 10 cigarettes per day or
an equivalent (but less concretely defined) quantity of cigar or pipe
smoke. Since many EHR technology developers have asked questions about
this certification criterion, we offer the following example of an
implementation that would be acceptable: an EP user of CEHRT ABC is
taking the social history from patient XYZ. The EP is using a template
for facilitated data entry in the CEHRT. The template has options such
as ``smoker'' and ``nonsmoker.'' When the EP selects ``smoker,''
several other options become available including ``1-9 cigarettes/day''
and ``\1/2\ pack/day'' and ``1 pack/day'' and ``greater than 1 pack/
day.'' The EP selects ``1 pack/day,'' and moves on to other parts of
the discussion with the patient. The CEHRT records (and displays) ``1
pack/day'' and maps this internally as SNOMED CT[supreg] concept
428071000124103 (``Current Heavy Smoker''). When a transition of care/
referral summary is generated for exchange, the SNOMED CT[supreg]
concept must be included, as well as the text description ``heavy
smoker'' (``1 pack/day'' and any other metadata could also be included
as appropriate). Note that ``heavy smoker'' is not the only concept
that is appropriate here, and we leave the decision regarding which of
the eight codes is the most accurate descriptor of clinical intent to
the judgment of those implementing the form, template, or other EHR
data capture interface. In the case above, the developer of the
template chose ``heavy smoker'' rather than ``current every day
smoker'' because this is more clinically relevant with respect to the
patient's risk for disease and the urgency of intervention.
Nonetheless, ``Current every day smoker'' would have been technically
acceptable and would therefore be acceptable for certification testing.
Patient List Creation (proposed ``Patient Lists'' and
``Patient Reminders'')
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
Use clinically relevant information to identify patients who should
receive reminders for preventive/follow-up care.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(a)(14) (Patient list creation).
------------------------------------------------------------------------
We proposed the 2014 Edition EHR certification criteria for
``patient'' lists and ``patient reminders'' as ``unchanged''
certification criteria (as described in section III.A.11 of this
preamble). In our proposal for the ``patient reminders'' certification
criterion, we clarified and emphasized that EHR technology certified to
this certification criterion would need to be capable of creating a
patient reminder list that includes a patient's communication
preferences, which would be consistent with current testing procedures
for this capability as included in the 2011 Edition EHR certification
criterion (Sec. 170.304(d)). We also noted that, consistent with
patient communication preferences, we would
[[Page 54206]]
anticipate that EPs, EHs, and CAHs could use communication mediums made
available by EHR technology certified to the proposed ``secure
messaging'' certification criterion (Sec. 170.314(e)(3)) or the
``view, download and transmit to 3rd party'' certification criterion
(Sec. 170.314(e)(1)) to send patient reminders. Last, we stated that
we anticipated that other modes of communication would be available and
may be preferred by patients for sending patient reminders, such as
regular mail.
We also proposed the ``patient lists'' certification criterion for
the 2014 Edition EHR certification criteria as unchanged and without
any refinements. The proposed ``patient lists'' certification criterion
specified that EHR technology enable a user to electronically select,
sort, access, and create lists of patients according to, at a minimum,
the data elements included in: (i) Problem list; (ii) Medication list;
(iii) Demographics; and (iv) Laboratory tests and values/results.
Comments. One commenter agreed that being able to provide
information to patients in the manner they prefer is important, but
expressed concern about the adoption of the ``patient reminder''
certification criterion for Stage 2. They stated that their comments to
CMS indicated that non-CEHRT systems that provide the actual reminders
should be exempt from certification criteria.
Response. This adopted 2014 Edition EHR certification criterion
focuses on an EHR technology's capability to electronically create a
patient reminder list for preventive or follow-up care according to
patient preferences based on certain data elements. It does not focus
on the IT systems that may be used to provide the reminders.
Comment. A commenter suggested that the proposed ``patient
reminders'' certification criterion include the element of when
patients were last seen so that the EHR technology user can perform
date range searches (i.e., diabetics not seen for 6 months).
Response. We agree with this commenter's suggestion. Although we
proposed the ``patient reminders'' certification criterion as an
unchanged certification criterion, we believe this commenter has
identified a critical flaw in the way the certification criterion is
currently expressed. We interpret the commenter's request to mean that
as an EHR technology user they would want to be able to create a
patient reminder list on an ad-hoc basis according to at least the
parameters specified in the certification criterion. As we considered
this comment and analyzed the way the certification criterion is
specified, we realized that it does not necessarily express this
outcome, which was our intent for this certification criterion. Rather,
we believe that as currently worded, the certification criterion could
permit an EHR technology developer to design and get EHR technology
certified that could only permit a user to generate patient reminder
lists based on a few static reports. We believe that kind of outcome is
unacceptable and does little to support an EP's ability to engage in
follow-up care communications--especially if the EP wants to focus on a
patient population that should be supported by virtue of certification,
but is not because the EP cannot dynamically (i.e., on-the-fly) and
while interacting with the EHR technology add or subtract certain
factors from the underlying query. Additionally, in the continued
context of reducing redundancy and regulatory burden as well as our
continued efforts to improve the clarity of our regulation, we compared
this certification criterion with the ``patient lists'' certification
criterion (proposed at Sec. 170.314(a)(14)) and have determined that
these two certification criteria should be combined into a single
certification criterion. At a high-level, both require EHR technology
to be able to electronically create a list of patients. However, where
the ``patient lists'' certification criterion includes more specific
filtering, the ``patient reminders'' does not, but it does include two
additional data elements (medication allergies, patient's communication
preference).
Accordingly, we have finalized a single certification criterion
that merges the strengths of each certification criterion as well as
this commenter's suggestion for a date/time component. We believe this
single certification criterion will be clearer for EHR technology
developers and will more clearly express the kind of capability EHR
technology must include in order to be certified. Within the
certification criterion, we interpret ``select'' to mean filter and
``sort'' to mean that the user gets to provide a sequence or range
(e.g., by hemoglobin A1C levels). For consistency purposes, we have
included the same revisions we have made in other certification
criteria and state ``each one and at least one combination* * *'' to
indicate that EHR technology must be able to create a list based on
each element separately as well as based on at least one combination of
any of the data. Finally, we seek to indicate our expectation that for
the next EHR certification criteria edition, we would propose that EHR
technology be able to initiate a patient reminder based on a patient's
identified communication preference (where it is electronically
feasible).
Comment. A commenter asked that we provide additional guidance as
to what constitutes ``patient preference.''
Response. In the Proposed Rule we indicated that patient preference
constituted the communication method by which the patient preferred to
be contacted. This could include but is not limited to: email, secure
messaging, regular mail, phone, and text message. EHR technology
designed for an ambulatory setting must support an EP, EH, or CAH's
ability to record a patient's communication preference, which we
believe is now explicitly clear in the revised combined certification
criterion. We encourage EHR technology developers to include a variety
of the most common choices patients may select.
Comments. Many comments were not focused on the capability that EHR
technology would need to provide a user in order to meet the
certification criterion, but on: how a reminder needed to be provided;
what an acceptable reminder would be; whether the purpose of the
reminder and its clinical relevance mattered; how a reminder could be
reported; and that exclusions to the meaningful use objective and
measure should be established for specialists.
Response. All of these comments go beyond the scope of capabilities
for which EHR technology certification is required.
Drug-Drug, Drug-Allergy Interaction Checks
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
Implement drug-drug and drug-allergy interaction checks.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(a)(2) (Drug-drug, drug-allergy interaction checks).
------------------------------------------------------------------------
We proposed a ``drug-drug, drug-allergy interaction checks''
certification criterion (Sec. 170.314(a)(2)) that included the
recommendations of the HITSC to eliminate for certification the ability
for EHR technology to permit users to adjust drug-allergy interaction
checks, replace the term ``real-time'' with ``before the order is
executed,'' revise the language to specify that notifications should
happen during CPOE, specify that the level of severity of the
notifications is what can be adjusted, and limit the ability to make
adjustments to an identified set of users or available as a system
administrative function. We also expressed agreement with the HITSC
that drug-allergy
[[Page 54207]]
contraindications should be interpreted to include adverse reaction
contraindications. We also clarified that the phrase ``identified set
of users'' means that the EHR technology must enable an EP, EH, and CAH
to assign only certain users (e.g., system administrator) with the
ability to adjust severity levels. We noted that in other certification
criteria that use the phrase ``identified set of users,'' a similar
principle would apply (i.e., assigning the capability to only certain
users).
Comments. Of the comments received on this proposed certification
criterion, many supported it as proposed. A set of commenters
recommended that we change the language at the beginning of the
certification criterion to state, ``Before an order is being completed
and acted upon * * *'' instead of ``Before a medication order is placed
* * *.'' They noted that this change would clearly define the
interaction notification's ``real-time'' nature and make it clear that
the licensed provider would need to see the interaction intervention
and be able to act on it. Similarly, with respect to this proposed
language, a commenter questioned how EHR technology workflow would be
tested to know if the check is completed before the order is entered.
Response. We appreciate this detailed feedback and agree with
commenters' revisions. We have modified this language in the
certification criterion to reflect the recommended text by replacing
``placed'' with ``completed and acted upon.'' We believe that this
revision should also address the testing timing question raised by the
last comment. Additionally, due to this revision, we removed ``at the
point of care'' from the certification criterion's language because we
believe the prior clarification appropriately indicates when the drug-
drug or drug-allergy interaction needs to be indicated to a user.
Comments. Some commenters focused on our proposal to not include in
the 2014 Edition EHR certification criterion the capability for EHR
technology to permit users to adjust drug-allergy interaction checks.
One commenter stated that it was unclear in the Proposed Rule whether
this also applied to drug-drug interactions. The commenter appeared to
presume that we were also applying this proposal to drug-drug
interactions because the commenter explained that such a limitation
would not comport with the current state of interaction databases
available in practice. Specifically, the commenter stated that current
systems, especially those based on shared excipients (i.e., substances)
or other components across formulations, are often strongly biased
toward sensitivity (i.e., an alert is generated even when a low
probability of a clinically significant interaction exists). As a
result, the specificity of alerts, and hence their positive predictive
value, is low. The commenter stated that the phenomenon of ``alert
fatigue'' is well-documented and the inflexible approach promoted by
the Proposed Rule contributes to this phenomenon. Similarly, another
commenter expressed concern that EHR technology developers may
interpret this section to prohibit physicians in small practices from
tailoring alerts to fit their practice. The commenter also noted that
alert fatigue is a well-known problem and expressed concern that our
proposal may lead to a diminution in safety through alert fatigue
rather than an improvement.
One commenter stated that we should reword paragraph (ii)(B) to
ensure that EHR technology has the capability to permit a limited set
of users to make adjustments to the severity levels of drug-allergy
interaction checks, in addition to drug-drug. In contrast to this
position, another commenter expressed agreement with the proposed
change from the 2011 Edition EHR certification criterion to the 2014
Edition EHR certification criterion and stated that adjusting
notifications of drug-allergy interaction checks is inconsistent with
clinical work and confusing in the current certification process.
One commenter contended that providers should retain the ability to
define thresholds for any alert which they would like to receive.
Without this capability, the commenter argued EPs are liable to
experience ``alert fatigue'' due to high ``noise to signal''; that is,
the presentation of a large number of alerts which are simply
irrelevant to the care which the physician is providing.
Response. On our proposal to remove the drug-allergy adjustment
capability expressed in the 2011 Edition version of this certification
criterion, we believe that the negative reaction expressed is due to
misinterpreting our proposal. We are fully aware of the concerns
expressed regarding alert fatigue. The certification criterion
addresses this concern by requiring that EHR technology include the
capability to adjust the severity level of interventions provided for
drug-drug interaction checks. This capability should allow for EPs,
EHs, and CAHs to find an appropriate balance with respect to the
frequency of interventions. In regards to severity level adjustments
for drug-allergy interactions, the proposal in question sought to
remedy a concern raised by the HITSC and other stakeholders after the
S&CC July 2010 Final Rule that certification focused on ensuring that
EHR technology had the capability to adjust the severity of drug-
allergy interventions when there were few clinical reasons to do so.
Unlike drug-drug alerts, the rationale we provided was that it is
important for drug-allergy interventions to be indicated and continue
to believe that this will generally be the case. Thus, we have
finalized the ``adjustments'' paragraph (Sec. 170.314(a)(2)(ii)) as
proposed and decline to include for the purposes of certification a
severity adjustment requirement for drug-allergy interventions.
Comment. A commenter requested clarification on paragraph
(a)(2)(ii)(A). They asked whether the certification criterion would
require that the severity level be able to be changed from what a
pharmaceutical company's research recommended. Additionally, they asked
if we were suggesting that a provider or person with appropriate
administrative privileges be able to downgrade that alert level to
moderate or minor or simply that they be able to modify the type of
interaction that triggers a warning. They concluded by stating that a
valid clinical use case is that many commonly prescribed combinations
are labeled as having a potential drug-drug reaction and the provider
wants to prevent being alerted each time.
Response. The certification criterion does not specifically address
a particular drug-drug intervention. Rather it is meant to ensure that
EHR technology that meets this certification criterion includes a
capability that permits certain users to adjust the severity level of
interventions. So in response to the commenter's question, this
certification criterion is meant to make it possible for a health care
provider to reduce the frequency of/threshold for certain
interventions.
Comments. A commenter asked that we clarify the definition of
``adverse reaction contraindication.'' Additionally, they asked what
vocabulary or vocabulary subsets would be used for the input of the
adverse reaction and whether EHR technology would need to be able to
distinguish between alerts for allergy contraindications and alerts for
adverse reaction contraindications. They stated that many EHR
technologies are not configured to register other reactions that are
not true allergies. A second commenter stated that we should recommend
specific vocabularies/codes and referenced RxNorm for the drugs as well
as the drugs to which the patient is allergic and SNOMED CT[supreg] for
the type of allergy.
[[Page 54208]]
Response. We agree that there is a clinical distinction between
``adverse reaction'' and ``allergic reaction,'' and we hope to be able
to support such a distinction in future rulemaking. However, for the
purpose of this certification criterion, we do not make a clinical
distinction between ``medication adverse reaction'' and ``allergic
reaction.'' In many cases, the use of a medication will be
contraindicated because a patient has a history of an adverse reaction
to the medication. While this may be clinically distinct from an
allergic (antibody-mediated hypersensitivity) reaction, it is a
contraindication nonetheless. The same clinical vocabulary (e.g.,
RxNorm) that would be used for allergic reactions will be required for
adverse reactions.
Comment. A commenter requested that we clarify the meaning of
``identified set of users'' with respect to the severity adjustments.
They asked whether each facility would have the ability to define this
for its users.
Response. As stated in the Proposed Rule, identified set of users
means that the EHR technology must enable an EP, EH, and CAH to assign
only certain users (e.g., system administrator) with the ability to
adjust severity levels. With respect to the follow-up question, EHR
technology certified to this certification criterion would need to
enable certain users to be assigned with the ability to adjust the
severity levels of interventions provided for drug-drug interactions.
How that capability is subsequently implemented and used is not within
the scope of certification and we are unable to determine what the
commenter had in mind when they referenced ``each facility.''
Comment. A commenter requested that we clarify the alignment of
drug-drug, drug-allergy alerts with CDS. Specifically, they asked us to
confirm that the proposed adoption of the HL7 ``Infobutton'' standard
for retrieving referential information would not apply to the drug-
drug, drug-allergy alerts certification criterion.
Response. As with the past edition of EHR certification criteria,
the drug-drug, drug-allergy certification criterion is a separate and
distinct certification criterion from the CDS certification criterion.
We did not propose the adoption of the HL7 Infobutton standard for this
certification criterion and its use would not be necessary to
demonstrate compliance with this certification criterion.
Comment. A commenter agreed with the certification criterion but
recommend that we consider expressing additional capabilities to
support food-drug interactions (i.e., changes in how medications work
caused by food, caffeine or alcohol).
Response. We appreciated this comment but decline to make such
changes at this time. EHR technology developers are encouraged and free
to include this functionality which would be outside the scope of
certification. We will keep this addition in mind as we work with the
HITSC on the next edition of EHR certification criteria.
Comment. A commenter suggested that it is important to specify in
this certification criterion and the CDS certification criterion that
EHR technology be able to provide timely access to FDA Drug Safety
Alerts (Boxed Warnings, Risk Evaluation and Mitigation Strategies
(REMS) programs and Drug Safety Alerts). Further, they stated that
these FDA Drug Safety Alerts include drug-drug interactions, allergic
reactions and critical safety information directly related to clinical
decision making.
Response. We wholeheartedly agree with this comment and encourage
EHR technology developers to make FDA Drug Safety Alert information
accessible to health care providers as part of their normal workflows.
We believe this capability and the availability of such information is
best addressed by the specific capability included in the CDS
certification criterion related to referential CDS. Additionally, as
part of an EHR technology's CDS we could see this capability being
enhanced through the use of the HL7 Context-Aware Knowledge Retrieval
(``Infobutton'') Standard so that EHR technology could gain access to
new REMS/drug alerts on an ongoing and dynamic basis.
Demographics
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
Record the following demographics: preferred language; sex; race;
ethnicity; date of birth; and for the inpatient setting only, date and
preliminary cause of death in the event of mortality in the EH or CAH.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(a)(3) (Demographics).
------------------------------------------------------------------------
We proposed to adopt the ISO 639-1 code set as the vocabulary
standard for preferred language \18\ based on the recommendation of the
HITSC. We also proposed to adopt ICD-10-CM for recording the
preliminary cause of death, stating that its use will permit additional
specificity.
---------------------------------------------------------------------------
\18\ http://www.loc.gov/standards/iso639-2/php/code_list.php--
Also note that The Library of Congress has been designated the ISO
639-2/RA for the purpose of processing requests for alpha-3 language
codes comprising the International Standard.
---------------------------------------------------------------------------
As for the Office of Management and Budget (OMB) standards for the
classification of federal data on race and ethnicity, we noted that the
standard for classifying federal data according to race and ethnicity
requires that the option for selecting one or more racial designations
be provided. The standard also permits the use of more than the minimum
standard categories for race and ethnicity as long as the data can be
aggregated to the minimum standard categories, which would be confirmed
through the testing and certification processes. We proposed to clarify
the reference to the adopted standard as the ``Revisions to the
Standards for the Classification of Federal Data on Race and
Ethnicity,'' which was issued on October 30, 1997, as referenced at
Sec. 170.207(f). Last, we proposed to revise the certification
criterion to require that EHR technology be capable of recording that a
patient declined to specify his or her race, ethnicity, and/or
preferred language.
We received comments that generally applied to the certification
criterion and comments that focused on each of the specific data
elements in the certification criterion. We have categorized and
respond to these comments in a similar manner.
Comments. A few commenters expressed general agreement with the
proposed certification criterion, while a commenter recommended that
this certification criterion should remain unchanged.
Response. We appreciate the commenters support for the proposed
certification criterion and our adopting it as a revised certification
criterion for the reasons discussed below.
Preferred Language
Comments. Some commenters expressed support for the ISO 639-1
standard. One commenter recommended the ISO 639-3 standard as being
more comprehensive. Another commenter suggested adopting the 2009 IOM
recommendations on how to ask for language data. Multiple commenters
suggested that we should use ISO 639-2. The HITSC clarified in their
comments that their recommendation to ONC was that preferred language
should be expressed by constraining 639-2 to those that are in ISO 639-
1, noting that 639-1 includes only active languages, while 639-2
includes languages no longer in use. A few commenters asked for
clarification as to whether all languages listed in the standard must
be visible for a customer to select.
Response. We agree with the clarification provided by the HITSC.
Accordingly, we are adopting ISO 639-
[[Page 54209]]
2 constrained by ISO 639-1. This will constrain ISO 639-2 to only the
active languages in ISO 639-1, but will permit the use of the alpha-3
codes of ISO 639-2. As such it is a better approach than adopting
solely ISO 639-2 or 639-1. We believe that ISO-639-3 exceeds the
baseline we seek to specify for certification and have not adopted it.
Last, in response to the commenters' request for clarification, EHR
technology is not required to display all the languages of the standard
to meet the certification criteria. But, it must be capable of
recording a patient's language according to any of the languages in the
standard.
Race and Ethnicity
Comments. Some commenters suggested the use of other vocabulary
standards such as CDC vocabulary standards, standards based on the 2009
IOM recommendations, or the HHS survey standards recently adopted by
HHS in compliance with ACA section 4302. A few commenters recommended
that EHR technology only record the ``primary'' race and ethnicity
value as identified by the individual and that the eligible
professional regards as clinically significant because the commenters
contended that most EHR technology is unable to accommodate multiple
values for patients. Commenters also suggested that a multiple question
approach for patients that may wish to designate multi-race or
ethnicity be acceptable. A commenter asked for clarification as to
whether the data elements must be stored as aggregated to the standard
(i.e., it must be done this way), or could it be aggregated to the
standard by a third party and not the EHR technology. Commenters also
requested clarification as to how the OMB race and ethnicity codes must
be used in conjunction with providing patients the option to not
respond to questions regarding race and ethnicity.
Response. The OMB race and ethnicity codes constitute a government-
unique standard. We have adopted this standard because it provides an
easily understood structure and format for electronically transmitting
the data elements identified by the associated MU objective. The
standard is readily available, was previously adopted as part of the
2011 Edition EHR certification criteria and, in general, provides the
best standard to use to support our policies goals. Therefore, we
believe this standard is more appropriate than the alternative CDC, IOM
and HHS survey standards.
EHR technology must be capable of meeting the standard and the
other requirements of the certification criterion in order to be
certified. As such, EHR technology must record race and ethnicity
according to the OMB standard by providing the option for one or more
racial designations to be selected in a manner consistent with the
standard. EHR technology must also be capable of aggregating/mapping
more granular race and/or ethnicity data to the minimum race and
ethnicity categories in the standard if an EHR technology developer
implements such an approach. Additionally, to meet the certification
criterion, EHR technology must, in conjunction with complying with the
OMB standard, be capable of recording that a patient declined to
specify his or her race and/or ethnicity. As noted in the Proposed
Rule, this ensures inclusion of such patients in the numerator of the
MU percentage-based measure.
Gender/Sex
Comments. Commenters requested clarification regarding the data
element ``gender,'' asking whether it was intended that sex and/or
gender be collected.
Response. We have clarified that the certification criterion
requires the recording of sex, which is consistent with the change made
by CMS for its MU objectives and measures.
Comments. Commenters recommended that gender identity and/or sexual
orientation be recorded.
Response. We appreciate the submission of these comments, but the
certification criterion includes only data required to support the
associated MU objective and measure. Therefore, we decline to include
these additional data elements.
Preliminary Cause of Death
Comments. A few commenters stated that ICD-10, not ICD-10-CM, was
the appropriate standard. A commenter stated that the preliminary cause
of death should be in the same vocabulary standard as the problem list
(i.e., SNOMED CT[supreg]). Conversely, many commenters stated that no
standard should be required. These commenters suggested that a text
entry for ``preliminary cause of death'' is most appropriate. These
commenters stated that this would avoid the need for provider education
on the use of the standard, the difficulty in narrowing down the
standard code list to one that might be usable for coding the
preliminary cause of death, and workflow changes. Commenters stated
that the significance of the preliminary cause of death being a
codified value is not of great importance when compared to the final
cause of death determined by a coroner through autopsy or as may be
required for death certificate purposes. Commenters further stated that
the information required by this capability is preliminary and by its
very nature will not carry the same weight as a later more final
determination. Overall, commenters questioned the cost and burden
involved in collecting this information in accordance to a standard
versus any perceived benefit as a means of meeting this certification
criterion.
Response. We agree with the commenters that the burden and costs,
as outlined by commenters, outweigh the potential benefits of recording
the preliminary cause of death in accordance with a standard.
Therefore, we are not adopting a standard for this data element and
free text entry will continue to be permitted.
Comments. A few commenters stated that the preliminary cause of
death should not be collected as a data element. A commenter stated
that if EHs are not required to record a preliminary cause of death
within a specified timeframe from the death, then the commenter
requested confirmation that deceased patients must simply have a
preliminary cause of death recorded in their charts in order to be
included in the MU measure. Otherwise, the commenter stated that it was
unclear how EHs would be expected to report on patients who died near
the end of the reporting period and have not yet had a cause of death
recorded. Commenters also requested clarification for the proposed
exclusion that specified if a demographic element is prohibited to be
captured by state law, that the EP or EH is excluded from capturing
that demographic. Commenters asked if it was acceptable to note once in
CEHRT the state law prohibition or if it needed to be recorded for each
patient.
Response. Collection of preliminary cause of death data supports
the associated MU objective and measure and, therefore, EHR technology
must be capable of collecting it. Comments on when the preliminary
cause of death must be recorded and the measure exclusion are beyond
the scope of this rulemaking. We direct commenters to the Stage 2 final
rule for a discussion of the MU objective and measure and responses to
these comments.
Additional Data Elements
Comments. Commenters recommended a wide range of additional data
elements for inclusion in the certification criterion based on the
rationale that the capturing of the data elements could contribute to
[[Page 54210]]
identifying health disparities and potential reasons for the health
disparities. The recommended additional data elements are: residency
information (state, county, zip code, street address); country of
origin; nationality; type of employment; primary place of employment;
highest education level completed; and hobbies.
Response. We appreciate the recommendations for inclusion of
additional data elements, but have chosen to limit this certification
criterion's scope to only include the data required to support the
associated MU objective and measure. Therefore, we decline to include
any of the recommended additional data.
Problem List
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
Maintain an up-to-date problem list of current and active diagnoses.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(a)(5) (Problem list).
------------------------------------------------------------------------
In the Proposed Rule, we proposed to replace the terms ``modify''
and ``retrieve'' in the certification criterion with ``change'' and
``access,'' respectively. Consistent with the interpretation we
provided in the S&CC July 2010 final rule, we also reiterated and
clarified that ``longitudinal care'' is used to mean over an extended
period of time. For the ambulatory setting, we stated that this would
be over multiple office visits. For the inpatient setting, we stated
that this would be for the duration of an entire hospitalization, which
would include the patient moving to different wards or units (e.g.,
emergency department, intensive care, and cardiology) within the
hospital during the hospitalization. We noted that the HITSC suggested
we consider longitudinal care to cover multiple hospitalizations, but
we stated that this could be difficult to achieve and may not offer
added value based on the duration of time between a patient's
hospitalizations and the reason for the hospitalizations. We stated
that our clarification of the meaning of longitudinal care also applies
to its use in the certification criteria for medication lists and
medication allergy lists. We further stated that if we were to
interpret longitudinal care as suggested by the HITSC, it would apply
to these certification criteria as well and could constitute a change
in the capabilities included in the criteria, which in turn would cause
them to become revised certification criteria.
We proposed to adopt the International Release January 2012 version
of SNOMED CT[supreg].\19\ We stated that we agreed with the HITSC that
the use of ICD-9-CM should no longer be required due to the pending
move to ICD-10-CM, but also stated that it would be inappropriate to
require the use of ICD-10-CM for problem lists. We stated that SNOMED
CT[supreg] (and not ICD-10-CM) would be required for calculation of
CQMs and proposed only SNOMED CT[supreg] as the appropriate standard
for the recording of patient problems in a problem list. We noted that
this proposal did not, however, preclude the use of ICD-10-CM for the
capture and/or transmission of encounter billing diagnoses.
---------------------------------------------------------------------------
\19\ http://www.nlm.nih.gov/research/umls/licensedcontent/snomedctfiles.html.
---------------------------------------------------------------------------
Comments. One commenter asked why it is necessary to specify a
vocabulary for the problem list within an EHR. The commenter agreed
with the necessity of SNOMED CT[supreg] for exchange, but suggested
that we permit the flexibility to either use the vocabulary internally
or map to it when exchanging information.
Response. We agree with this commenter that SNOMED CT[supreg] is
the best vocabulary to use in those certification criteria that focus
on electronic health information exchange. It is necessary that we
specify a vocabulary for the problem list within EHR technology because
it supports the current requirement that EPs, EHs, and CAHs need to
meet to demonstrate MU. Since CMS's initial proposal for meaningful use
Stage 1 (75 FR 1860), it has explicitly prioritized recording problems
in the adopted standards. Further, at 75 FR 44337, CMS states ``[w]e
further specify that in order to meet this objective and measure, an
EP, eligible hospital, or CAH must use the capabilities Certified EHR
Technology includes as specified and standards at 45 CFR 170.302(c)''
which is the 2011 Edition EHR certification criterion for problem list
that requires EHR Technology be able to record problems in either ICD-9
or SNOMED CT[supreg] in order to be certified. We also responded to
similar questions such as this in our S&CC July 2010 final rule (75 FR
44603).'' In the Proposed Rule, we proposed to only permit EHR
technology to be certified to record, change, and access problems in
SNOMED CT[supreg] because we believe that it is the best vocabulary
standard for the representation of clinical data and should be used to
represent problems beginning in FY/CY 2014. We clarify that this
certification criterion does not preclude the use of interface terms,
local terms, or other terms from being displayed to a health care
provider in lieu of SNOMED CT[supreg] to find, select, or view a
patient's problem list. However, if such an approach is taken, the EHR
technology must ultimately be able to record the semantic
representation of the problem list in SNOMED CT[supreg]. For example,
if a user of a given EHR technology is using a set of interface terms
or any other clinical vocabulary that has been mapped to SNOMED
CT[supreg], this user may perform a search for a term that represents
the patient's problem, select the appropriate term, and ``save'' that
term to the patient's problem list, where it may be displayed. The EHR
technology is required to record the problem in SNOMED CT[supreg]
because this is the requirement described above for alignment with the
EHR Incentive Programs. For information exchange, the EHR technology
must send the problem in SNOMED CT[supreg] because this is the
requirement of other certification criteria specified elsewhere in this
final rule.
Comments. Commenters expressed support for use of only SNOMED
CT[supreg] and stated that it is the best standard for optimal clinical
data capture and reuse of information captured in problem lists. Some
of these commenters stated that the use of a classification system such
as ICD-10-CM limits data analysis for clinical research, quality of
care measurement and communication between care providers and patients.
These commenters stated that ICD-10-CM is a classification, and it is
still designed to capture diagnoses and reasons for encounters, not
every ``problem.'' The commenters recommended that ICD-10 CM and PCS,
where appropriate, should continue to be required for billing purposes.
The commenters also recommended that EHR technology developers should
not utilize the problem list for billing since billing practices and
national coding guidelines require that claims only reflect those
conditions attended to during the encounter being billed and the
problem list includes all conditions that may or may not be active and
may or may not have been attended to during the encounter.
Conversely, commenters were concerned that they would face
additional costs and burden by having to adopt and implement SNOMED
CT[supreg] as well as ICD-10-CM or ICD-9-CM until ICD-10-CM is required
for implemented. Commenters also stated that SNOMED CT[supreg] is not
currently in widespread use among hospitals. For these reasons,
commenters suggested that they be able to use ICD-10-CM for problem
lists in lieu of adopting
[[Page 54211]]
SNOMED CT[supreg]. A few commenters suggested this same approach, but
also recommended signaling a move to adopt only SNOMED CT[supreg] for
the next edition of certification criteria. One commenter suggested
that we pursue development of a national problem list and centralized
services developed and maintained by a cooperative partnership between
the public and private sectors.
Response. We appreciate the comments supporting the use of only
SNOMED CT[supreg]. We agree with commenters that SNOMED CT[supreg]
provides much better clinical data capture than ICD-10 CM, ICD-9, and
ICD-10 PCS, while ICD-10-CM is more appropriate for encounter billing
purposes. With the adoption of the 2011 Edition EHR certification
criteria we permitted the use of either ICD-9-CM or SNOMED CT[supreg]
to demonstrate compliance with this certification criterion. In our
response to comments in the S&CC July 2010 final rule, we stated that a
single standard for clinical information would be desirable in the long
term. While SNOMED CT[supreg] may not currently be used by a majority
of EPs, EHs, and CAHs, we cannot expect its usage to dramatically
increase without some encouragement. By requiring EHR technology to be
certified to this standard, soon all EPs, EHs, and CAHs will have the
capability to record patient problems with SNOMED CT[supreg]. This will
improve the semantic interoperability of clinical systems, improve the
accuracy of data capture, and may in fact provide a better transition
to ICD-10-CM. With mapping tools from SNOMED CT[supreg] to ICD-10-CM,
available from the National Library of Medicine, we anticipate that
clinical users will be able to use a clinician-friendly terminology
(SNOMED CT[supreg]) while administrative users can interact with ICD-
10-CM, an administrative terminology. Guidance from the HITSC and our
own research has indicated a clear need for clinicians to interact with
SNOMED CT[supreg] rather than ICD-10-CM, and we view this as an
opportunity to improve the usability, accuracy, and safety of problem
list management.
The development of a national problem list and centralized services
is beyond the scope of our certification program and this rule, but we
will consider this as we look to how ONC and other Federal agencies can
best prepare the industry for successful EHR technology development and
implementation.
Comment. A commenter stated that while SNOMED CT[supreg] is the
appropriate standard for clinical use (as opposed to ICD for billing
and epidemiological purposes), clinicians' experience with this
standard is limited, and therefore suggest that we consider requiring
the addition of a mapping tool within the EHR technology.
Response. We agree with this commenter, as stated above, that
SNOMED CT[supreg] is the appropriate standard for clinical use, and we
agree that mapping from SNOMED CT[supreg] to appropriate administrative
codes such as ICD-10-CM will be necessary. The National Library of
Medicine is developing mapping tools, and such mappings are also
available from commercial vocabulary vendors. We do not, however,
intend to require the use of such mappings as part of this 2014 Edition
EHR certification criterion.
Comment. A commenter suggested that for dental systems, SNODENT,
the dental subset of SNOMED CT[supreg], is the appropriate code set for
the recording of dental patient problems in a problem list.
Response. While the commenter may be correct in regards to SNODENT,
certification to this certification criterion requires that EHR
technology be able to record a patient problem list in accordance with
SNOMED CT[supreg]. It is our understanding that novel SNODENT content
produced by the American Dental Association will be incorporated into
SNOMED CT[supreg] or the U.S. Extension to SNOMED CT[supreg]. This will
cause all dental diagnoses to be available in SNOMED CT[supreg]. We
believe this will be beneficial to EPs that rely more on SNODENT. We
also encourage EHR technology developers to include SNODENT in EHR
technology when it would be beneficial to providers.
Comments. Commenters stated that SNOMED CT[supreg] codes should not
be required for display in the EHR. Commenters explained that an EP,
EH, or CAH should be able to use whichever code set they prefer for
display.
Response. We agree with commenters. As noted above, SNOMED
CT[supreg] codes are not required for display in the EHR technology in
order for it to meet this certification criterion.
Comments. Commenters stated that the SNOMED CT[supreg] standard
should include the U.S. Extension to SNOMED CT[supreg] (citation to
National Library of Medicine) and apply to all uses of the standard in
certification criteria. Commenters stated that the US extension
includes terms important for the MU program, specifically those used in
the US but not found in the SNOMED CT[supreg] International Release
(e.g. for adopting pre-coordinated terms in SNOMED CT[supreg] to match
those found in ICD-10-CM).
Response. We agree with the commenters that, although not proposed
for use, the U.S. Extension is necessary to support the MU program and,
therefore, have adopted it in conjunction with SNOMED CT[supreg].
Comments. Commenters stated that to accommodate the regular updates
that occur to SNOMED CT[supreg] we should establish a mechanism for
updating the minimum regulatory standards. Alternatively, a commenter
suggested we simply adopt ``SNOMED CT[supreg]--current International
release'' as the vocabulary standard.
Response. We appreciate the suggestions by commenters. We have
established a process for adopting certain vocabulary standards,
including SNOMED CT[supreg], which permits the use of newer versions of
those standards than the one adopted in regulation. We refer readers to
section IV.B for a discussion of ``minimum standards'' code sets and
our new more flexible approach for their use in certification and
upgrading certified Complete EHRs and certified EHR Modules. Readers
should also review Sec. 170.555, which specifies the certification
processes for ``minimum standards'' code sets. In response to the
commenter's suggestion that we adopt in regulation ``the current
release of SNOMED CT[supreg]'' as the standard, we refer the commenter
to section III.A.5 earlier in this preamble. This section explains why
we cannot take such an approach.
Longitudinal Care
Comments. Commenters expressed agreement with our clarification of
the meaning of the term ``longitudinal care'' for the purposes of this
certification criterion and the certification criteria for medication
lists and medication allergy lists. However, commenters recommend that
we eliminate the term ``longitudinal care'' from this certification
criterion and the ``medication list'' and ``medication allergy list''
certification criteria. Commenters stated that our use of the term as
described in the Proposed Rule was inconsistent with the common
understanding of the term among the health care community. These
commenters stated that ``longitudinal'' should be reserved for
referring to care provided across care settings and across episodes or
encounters of care. Some commenters suggested replacing the term with
``encounter of care,'' ``episode of care,'' or ``durational care.'' A
commenter suggested that for hospital patient problems that are
longitudinal across encounters be acceptable given ONC's proposed
definition of longitude for hospital inpatients of an admission. This
commenter noted that some EHRs are designed such that problems as
clinical data objects are distinct from
[[Page 54212]]
encounter diagnosis, and are longitudinal in concept and design.
Response. We agree with commenters that our use of longitudinal
care in this certification criterion and in the certification criteria
for medication lists and medication allergy lists has the potential to
create confusion. Accordingly, we have replaced this term in the
certification criteria with the descriptions we provided in the
Proposed Rule and with a terminology change recommended by commenters.
Specifically, for the ambulatory setting, we have replaced the term
``longitudinal care'' with ``over multiple encounters.'' We believe
using ``encounters'' instead of ``office visits'' is a more clinically
appropriate. We note that this revision has no substantive impact on
current or future testing and certification processes. For the
inpatient setting, we have replaced the term ``longitudinal care'' with
``duration of an entire hospitalization,'' which would continue to
include situations where the patient moves to different wards or units
(e.g., emergency department, intensive care, and cardiology) within the
hospital during the hospitalization and continue to maintain that it
would not cover multiple hospitalizations for the purpose of
certification. As we stated above and in the Proposed Rule, capturing
patient problems over multiple hospitalizations could be difficult to
achieve and may not offer added value based on the duration of time
between a patient's hospitalizations and the reason for the
hospitalizations.
Clinical Decision Support
------------------------------------------------------------------------
---------------------------------------------------------------------------
MU Objective
Use clinical decision support to improve performance on high-priority
health conditions.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(a)(8) (Clinical decision support).
------------------------------------------------------------------------
We proposed to adopt a revised clinical decision support (CDS)
certification criterion as part of the 2014 Edition EHR certification
criteria. We noted in the Proposed Rule that we refined the HITSC's
recommended certification criterion to provide a clearer understanding
of the capabilities that must be tested and certified and to provide
greater flexibility to EHR technology developers in designing EHR
technology to meet this proposed certification criterion. We proposed
to replace the term ``clinical decision support rule'' used in the 2011
Edition EHR certification criteria and the HITSC recommended criterion
with the term ``clinical decision support intervention'' to better
align with, and clearly allow for, the variety of decision support
mechanisms available that help improve clinical performance and
outcomes. We described that a CDS intervention is not simply an alert,
notification, or explicit care suggestion. Rather, it should be more
broadly interpreted as the user-facing representation of evidence-based
clinical guidance. Our goal in clarifying the nomenclature was to focus
more on the representation of the guidance (the CDS intervention) that
the EHR technology should offer to the user rather than prescribe the
form of either the logical representation of the clinical guidance or
how the intervention interacts with the user.
We also proposed to require the use of the HL7 Context-Aware
Knowledge Retrieval (``Infobutton'') Standard, International Normative
Edition 2010, for retrieving diagnostic or therapeutic reference
information and proposed to require the use of CDS when a summary care
record was incorporated. We noted that the Infobutton standard has been
in active use for several years with many reference content vendors now
providing their products in this form, and we proposed to adopt its
most recent edition (International Normative Edition 2010) in order to
enable a user to retrieve diagnostic or therapeutic reference
information. We stated our belief that the use of standard reference
information retrieval formats would accelerate the delivery of content
to providers and hospitals, and would enhance the flexibility of such
implementations because these formats reduce the need to ``hard wire''
the content databases to installed EHR technology. We indicated that
this flexibility would allow EPs, EHs, and CAHs more choices and easier
migration across content providers, encouraging innovation and
competitiveness among these content providers.
We asserted that it is important for CDS interventions to be
triggered when new information is incorporated into EHR technology as a
result of a care transition. Consistent with this belief, we proposed
that EHR technology enable interventions to be triggered when the
specified data elements are incorporated into a summary care record
pursuant to the capability specified at Sec. 170.314(b)(1). In
consideration of whether EHR technology should be capable of importing
or updating value sets for the expression of CDS vocabulary elements
using the HL7 Common Terminology Services, Revision 1, standard, we
requested comment on industry readiness to adopt this standard and on
the benefits it could provide if required as a part of this
certification criterion.
Consistent with the HITSC's stated intent, for EHR technology to be
certified to this criterion we proposed that it must be capable of
providing interventions and the reference resources in paragraph
(a)(8)(ii)(A) of Sec. 170.314 by leveraging each one or any
combination of the patient-specific data elements listed in paragraphs
(a)(8)(i) and (ii) of Sec. 170.314 as well as one or any combination
of the user context data points listed in paragraph (a)(8)(iii)(A) of
Sec. 170.314. We asserted that EHR technology must also be capable of
generating interventions automatically and electronically when a user
is interacting with the EHR technology.
Last, expanding on the HITSC's recommendation that the source
attributes of suggested interventions be displayed or available for
users, we proposed that, at a minimum, a user should be able to review
the: bibliographic citation (i.e., the clinical research/guideline)
including publication; developer of the intervention (i.e., the person
or entity who translated the intervention from a clinical guideline
into electronic form, for example, Company XYZ or University ABC);
funding source of the intervention development; and release and, if
applicable, revision date of the intervention. We asserted that the
availability of this information would enable the user to fully
evaluate the intervention and enhance the transparency of all CDS
interventions, and thus improve their utility to healthcare
professionals and patients.
To aid readers, we have done our best to group comments and
corresponding responses under subheadings that align with the specific
capabilities proposed for the CDS certification criterion.
General Comments on CDS Interventions
Comments. There was overwhelming support for replacing the term
``rule'' with ``intervention.'' A few commenters suggested that we
provide an expanded list of example CDS interventions such as patient-
specific order sets, dosing guidance, documentation forms, and display
of patient-specific relevant information.
Response. We appreciate the support for the more expansive term,
``CDS intervention'' and have used it in the final rule. We would like
to note that the examples of CDS interventions in the NPRM were
illustrative only, as our focus is not the type of intervention but the
clinical intent of an intervention that offers guidance.
[[Page 54213]]
Comments. Several commenters commented on the specific capability
proposed at Sec. 170.314(a)(8)(i) ``Evidenced-based decision support
interventions.'' They stated that they were confused by and would like
clarification on the statement ``each one or any combination of the
following.''
Response. As noted in the section III.A.4 of this preamble
(``Explanation and Revision of Terms Used in Certification Criteria''),
in any certification criterion where we had this or similar language,
we have revised it to clarify its intent. We refer readers to this
section of the preamble for further clarification.
Comments. We received many comments and questions about the
mechanism of counting or measuring that the CDS event was enabled or
activated. Many commenters believed that that it would be very
difficult to track CDS interventions ``live'' in multiple locations
within the EHR technology and within many workflows. As such, some
commenters believed this requirement should just be met thorough
provider attestation, while others commented that the occurrence,
rather than the enabling, of the CDS intervention should be measured.
Commenters expressed concern about providers needing or choosing to
modify or replace interventions during a reporting period based on
quality improvement or clinical needs and how that might endanger their
ability to meet MU requirements.
Response. The Stage 2 final rule, published elsewhere in this
edition of the Federal Register, provides guidance regarding how an EP
or EH would report CDS interventions, or how activation would be
managed relative to the EHR reporting period. We thank commenters for
their suggestions regarding other methods of tracking CDS, but we
believe that the best method of tracking CDS interventions is to
capture when they are enabled. So long as EHR technology is capable of
recording such an event, then the EHR technology will be capable of
generating a report that expresses the CDS interventions that were
enabled across a given time-frame such as during an EHR reporting
period. In response to these comments, we have revised the first
specific capability of this certification criterion to clarify two
points: 1) that we intended for an identified set of limited users to
be able to select CDS interventions (thus, per the statements above, it
should be apparent when these users have enabled certain
interventions); and 2) when we used the parenthetical (or activate) we
did not mean to imply that activate was a separate functionality from
select. In that respect we have clarified the parenthetical to say
(i.e., activate).
Comments. Some commenters requested that we not limit CDS
interventions to only those tied to CQMs so that providers, hospitals,
and specialists could target specific areas where they feel improvement
is needed. Other commenters asked that we permit locally defined and
developed CDS content and references.
Response. We appreciate both of these suggestions. We refer readers
to the EHR Incentive Programs final rule published elsewhere in this
edition of the Federal Register for a description of CDS objectives for
Meaningful Use. Locally defined and developed CDS content and
references are certainly permitted to be used with the capabilities for
which certification is required by this certification criterion.
Comments. Several commenters were concerned about ``hard coding''
CDS to CQMs in EHR technology.
Response. We share this concern and agree that EHR technology
presented for certification should leverage standards where possible to
retrieve CDS content from external sources (which can be maintained and
updated independently from the software release cycle). The Proposed
Rule noted that referential sources such as medical texts, primary
research articles, and clinical practice guidelines have long been
available in electronic form, but the means and manner of accessing
them have historically been disconnected from the points in providers'
patient care workflows when the immediate availability of the reference
sources would optimize clinical decisions. We noted that these tools
are being made available through links in EHRs, offering information at
relevant points within the clinical workflow. The Infobutton standard
was proposed in order to enable a user to retrieve diagnostic or
therapeutic reference information. We suggested that the use of
standard reference information retrieval formats would accelerate the
delivery of content to providers and hospitals, and would enhance the
flexibility of such implementations because these formats reduced the
need to ``hard wire'' the content databases to installed EHR
technology. This flexibility would allow EPs, EHs, and CAHs more
choices and easier migration across content providers, encouraging
innovation and competitiveness among these content providers.
Comment. One commenter requested clarification concerning proposed
Sec. 170.314(a)(8)(i), expressing an interpretation that an EHR Module
can be certified to this paragraph (as well as meeting other 4
paragraphs) if it implements one or more CDS interventions, that none
of the interventions need be drug-drug or drug-allergy related, but
only if it uses data from the enumerated list in Sec.
170.314(a)(8)(i)(A)-(F). This commenter noted that the EHR Module may
address high priority health conditions not included by CMS as a
Clinical Quality Measure, and recommended that there not be any
inconsistency between the two rules (i.e. a CQM that does not use one
of the enumerated data elements present in Sec. 170.314(a)(8)(i)(A)-
(F)).
Response. This certification criterion specifies the minimum
capabilities EHR technology needs to include in order to be certified.
It does not preclude the incorporation of CDS interventions that
address health conditions not included in CQMs identified in the EHR
Incentive Programs. We expect to have tighter alignment with CDS and
CQM in future editions of EHR certification criteria.
Comment. One commenter noted that there would be ``mixed ability to
meet'' several of the specific capabilities proposed in Sec.
170.314(a)(8).
Response. We thank the commenter for their feedback, and understand
the concern. We have modified several of the specific capabilities
expressed by this certification criterion as well as clarified them in
our responses to provide better guidance and more flexibility.
HL7 Common Terminology Services
Comments. Many commenters expressed that additional, ground-laying
work would be necessary before the adoption of the HL7 Common
Terminology Services could be a requirement for certification. These
commenters noted that there would need to be a standardization of value
sets, certification of a value set service, and mechanisms to update,
maintain, and distribute value sets.
Response. We thank commenters for their feedback and agree that
there is not currently a set of publicly available resources that are
accessible using this standard. We are coordinating efforts with other
Federal agencies to create a value set repository that will be hosted
by the National Library of Medicine. This repository will provide value
sets in a manner consistent with the HL7 Common Terminology Services in
the very near future, and we encourage EHR technology developers to use
this valuable resource in order to capture and maintain value sets for
CDS and CQM in the future. We intend to reconsider this for
certification in a future edition of certification criteria.
[[Page 54214]]
Linked Referential CDS
Comments. Many commenters expressed concern that our reference to
the HL7 Context-Aware Knowledge Retrieval (``Infobutton'') standard was
intended to be required for interactive CDS interventions, and
suggested that it was an inappropriate standard for such interventions.
Some commenters disagreed with our inclusion of linked clinical
references in the CDS certification criterion. Several commenters
expressed support for the ``Infobutton'' standard for referential CDS,
while some did not because they were concerned that there was
insufficient industry adoption for this standard to be a requirement.
One commenter suggested that while this standard is appropriate for
linked referential CDS, there may be other methods of providing access
to relevant clinical references, and that we should allow for other
methods as well.
Response. We agree that the HL7 Infobutton standard is an
inappropriate standard for ``interactive'' CDS interventions. As we
described in the Proposed Rule, we intended to require this standard be
applied only for referential CDS. Thus, for the purposes of referential
CDS, we agree with commenters that expressed concern as to whether
there is sufficient industry adoption of this standard. We agree that
there may be other methods of providing context aware reference
information and, that in some cases, it may be appropriate to use other
methods. Nonetheless, we remain convinced that the widespread adoption
of HL7 Context-Aware Knowledge Retrieval standard for the retrieval of
clinical reference information is an important capability for EHR
technology to include. In response to commenters concerns, we have
adopted this standard as an alternative to a general capability for
referential decision support that does not require a standard. We took
this approach because we recognize that in order for CDS to benefit
from the HL7 Context-Aware Knowledge Retrieval standard a large enough
pool of publishers providing content in a standards-compliant manner
need to be available. Thus, had we required that the HL7 Context-Aware
Knowledge Retrieval Standard be implemented in order to meet this
certification criterion, our requirement could have caused many EHR
technology developers to invest in work that would have resulted in no
clinical value to an EP or EH--as there may not be a desirable
selection of referential CDS content available for consumption through
the use of this standard. In future rulemaking, we do expect to require
this standard for certification, and we encourage EHR technology
developers to begin plans to implement functionality that would support
the incorporation of knowledge resources made available with this
standard, and seek optional certification for 2014. While we do not
certify knowledge publishers, we also encourage such organizations to
adopt this standard as a method of providing patient and/or provider
facing clinical content to EHR technology. We clarify that because we
have expressed the HL7 Context-Aware Knowledge Retrieval Standard-
enabled capability in the certification criterion with an ``or,'' EHR
technology that is presented for certification with this capability
would not also need to meet the general capability in order to be
certified (i.e., one capability or the other will be sufficient to
satisfy the certification criterion). Finally, we note that consistent
with our adoption of the HL7 Context-Aware Knowledge Retrieval
implementation guides (discussed in the patient-specific education
resources certification criterion), we have also applied both
implementation guides to this standard here.
CDS Configuration; CDS Interventions Automatically and Electronically
Occur
Comments. Commenters requested that we clarify our language
regarding the configuration of CDS for a given ``setting,'' when CDS
interventions occur in the workflow, and requested that we clarify
``user'' to mean licensed healthcare professional.
Response. After further evaluation and consideration as to whether
they could be unambiguously tested, we have removed references to
setting and workflow from this portion of the certification criterion.
However, we have retained the first requirement--that CDS can be
configured ``based on a user's role.'' We do not constrain ``user'' to
mean ``licensed healthcare professional,'' because some users of CEHRT
may not be licensed healthcare professionals. For example, a clerical
user or a patient user may interact with CEHRT in some way, and there
is no reason that the CDS should not be configurable to expose
appropriate interventions (screening reminders, for example) to a
patient or clerical user. Our requirement here is simply that the
system be capable of configuration based on the user's role in the
system. We expect that a physician, nurse, clerical worker, and patient
would all have different settings, as the CDS interventions to which
they should be exposed may differ--or may have different presentation
formats.
Comments. Many commenters expressed concern about the term ``when
incorporated'' and the timing of CDS interventions being ``triggered''
based on data incorporated from the transition of care/referral
summary.
Response. We agree that reconciling information into EHR technology
requires many steps in order to determine what information is
clinically significant and valid. We also understand that there are
semantic interoperability challenges for data at this granular level
that may make accurate and responsive CDS intervention triggers overly
difficult and/or unreliable. In the Proposed Rule, we proposed that EHR
technology would need to be able to ``enable interventions to be
triggered, based on the data elements specified in paragraph (a)(8)(i)
of this section, when a transition of care/referral summary is
incorporated pursuant to Sec. 170.314(b)(1).'' We have revised this
language to make explicit three instances that this certification
criterion implicitly required:
(1) CDS interventions must be triggered based on data that is
already recorded and stored within EHR technology;
(2) CDS interventions must be triggered when a patient's
medications, medication allergies, and problems have been incorporated
by EHR technology upon receipt of a transition of care/referral summary
formatted in accordance with the Consolidated CDA; and
(3) For the ambulatory setting only, CDS interventions must be
triggered when laboratory test results/values are incorporated by EHR
technology upon receipt of a laboratory test report formatted in
accordance with the LRI specification.
We clarified our interpretation of the term ``incorporate'' earlier
in this final rule and have also clarified that the only time
incorporation is implicated by the adopted certification criteria is
for the incorporation of certain data as a result of a transition of
care and, for the ambulatory setting only, when lab results/values are
received and incorporated by EHR technology according to the LRI
specification. This modification reduces the ``incorporated data'' that
would be expected to trigger a CDS intervention to at most four out of
the six originally proposed data elements (three out of six for
inpatient EHR technology) (i.e., for the ambulatory setting it would be
problems, medications, medication allergies, and laboratory tests and
[[Page 54215]]
values/results and for the inpatient setting it would be problems,
medications, and medication allergies). Thus, for the purposes of this
certification criterion, we clarify that EHR technology must be capable
of demonstrating that it behaves differently in two states: before and
after the incorporation of new information. We make no specification
regarding the timing of events. That is--we do not specify that the EHR
technology must ``trigger'' an intervention at the time of
incorporation. For example, if a transition of care/referral summary is
incorporated into a patient's record with a new medication allergy, the
EHR technology will behave differently in this state (would alert the
EP who attempts to prescribe this medication) than it did before the
transition of care/referral summary had been incorporated.
CDS Source Attributes
Comment. Many commenters expressed support for transparency of the
source attributes for CDS interventions. Some commenters expressed
concern that requiring the display of such information could be
distracting and not well accepted by end users. Commenters wanted
clarification that the EHR technology must only enable the display, not
be required to supply the content of the CDS intervention and reference
source attributes.
Response. The intent of the source attribute requirement is to
permit end users of EHR technologies to have transparent access to
information about their CDS resources, interventions, and reference
information. We do not require the automatic display of the source
attributes, just the availability of the information to the end-user.
For example, additional action may be required for a user to ``drill
down'' or ``link out'' to view the source attributes of CDS. We are
also not requiring that the EHR technology create the content for the
source attributes. In a scenario where the EHR technology developer
uses a third party content provider for a clinical reference or
interventions it would be the third party from which the EHR technology
developer would get this information.
Comment. One commenter suggested that the CDS source attributes
should supply not only (A)-(D) but also the specific CQMs associated
with the CDS intervention.
Response. We appreciate this comment, which aligns with the
direction we stated in the Proposed Rule to align the capabilities of
EHR technology, CQMs, and CDS for future stages of the EHR Incentive
Programs. Since many CDS interventions are not today directly linked to
CQMs, we will not implement this as a certification requirement. This
does not prevent CDS intervention developers or EHR technology
developers from providing and leveraging this additional attribute to
assist EPs, EHs, and CAHs in meeting the expectations of the EHR
Incentive Programs.
Comment. Several respondents wanted to eliminate the source
attribute requirements for drug-drug and drug-allergy CDS
interventions.
Response. Drug-drug and drug-allergy interventions are clinical
decision support resources. We proposed that EHR technology be required
to enable the user to review the attributes for each intervention or
reference source for all CDS resources. We believe that this is
important because most EHR technology developers acquire the clinical
knowledge that is represented in CDS from external sources. These
sources should be available to the EP, EH, or CAH for reasons stated in
the Proposed Rule and above. We agree with the commenter that it may be
unnecessary or inappropriate for each and every such intervention to
offer all of the source attributes. For example, a drug-allergy alert
that warns a user not to prescribe a medication to which that patient
is allergic may not merit the same scrutiny by the EP, EH, or CAH as an
intervention that informs a provider of an opportunity to prescribe a
new medication for which a given patient may be a candidate. We
therefore have modified this criterion to constrain the required
information to a bibliographic citation and identification of the
developer of the intervention, and further clarify that global
citations are permitted in cases where all interventions of a given
type are provided by the same reference. For example, if all drug-drug
and drug-allergy alerts are part of product ABC, provided by company
XYZ, then one global statement that attributes these references to this
product and company is acceptable, and need not be made available for
each and every intervention.
Comment. Some respondents requested additional clarity regarding
the source attribute requirement. One commenter noted that further
clarification is required for ``revision dates'' ``funding source,''
and ``developer of the intervention'' and noted that some CDS
recommendations are developed in-house and may not be the result of
published work. Additionally, they noted that ``developer of the
intervention,'' and ``funding source'' may not be easily obtained.
Response. We describe these requirements as follows:
``Bibliographic citation'' (clinical research/guideline)
is a reference (if available) to a publication of clinical research
that documents the clinical value of the intervention. If no such
reference exists, as may be the case for a locally developed
intervention, the EHR technology should make this information available
as well. In this scenario, an EP, EH, or CAH who is interacting with
guidance offered by the EHR would see that there is no clinical
evidence available. The absence of such information is, in this case,
valuable information and may (or may not) cause the EP, EH, or CAH to
heed or ignore the guidance. Note that our goal here is not to assess
the quality or evidence basis of decision support, but to enable the
EP, EH, or CAH to do so.
``Developer of the intervention (translation from clinical
research/guideline)'' is the team, person, organization, department, or
other entity that interpreted the clinical research and translated it
into computable form. In some cases, this is a ``knowledge vendor.'' In
some cases, this is the EHR technology developer, and in some cases it
is an EP or an employee of an EH/CAH. In all cases, there is
interpretation and translation from prose to logic that can be
interpreted and managed by the EHR technology.
``Funding source of the intervention development technical
implementation'' is the source of funding for the work performed by the
``developer of the intervention.'' In many cases, this will be the same
organization as the developer of the intervention, but in some cases,
this may be a government agency or Department of Health, commercial
insurance carrier, employer, or biomedical product developer. For
example, if the Health Department of State XYZ funds company JKL to
create an intervention that translates a clinical practice guideline
for management of disease ABC that can be incorporated into certified
EHR technology as decision support, company JKL would be the
``developer of the intervention,'' while Health Department of State XYZ
would be the ``funding source.'' In cases where this information is
unknown, then the EP, EH, or CAH should have access to the fact that
this information is unknown.
Patient-Specific Education Resources
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
[[Page 54216]]
Use clinically relevant information from Certified EHR Technology to
identify patient-specific education resources and provide those
resources to the patient.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(a)(15) (Patient-specific education resources).
------------------------------------------------------------------------
We proposed to adopt a revised 2014 Edition EHR certification
criterion that does not have the language ``as well as provide such
resources to the patient'' at the end of the paragraph. This language
is in the 2011 Edition EHR certification criterion, but is redundant of
the capability expressed at the beginning of the paragraph.
Additionally, we proposed to adopt the HL7 Context-Aware Knowledge
Retrieval (Infobutton) standard, International Normative Edition 2010,
as the required standard. We stated that HL7 Context-Aware Knowledge
Retrieval standard is being increasingly used by more providers to
electronically identify and provide patient-specific education
resources. Therefore, we stated that it was appropriate to require EHR
technology to enable a user to identify and provide patient-specific
education resources based on the specified data elements and in
accordance with HL7 Context-Aware Knowledge Retrieval standard.
Comments. With respect to patient-specific education materials,
commenters focused on some aspect, or the potential affect, of the
proposed inclusion of the HL7 Context-Aware Knowledge Retrieval
standard. Some commenters supported its adoption as part of this
certification criterion. Many commenters requested clarification on
whether the use of the HL7 Context-Aware Knowledge Retrieval standard
was mandatory (as a replacement of existing functionality). They
qualified their support for the standard by suggesting that EHR
technology developers (and their customers) be permitted to present
education materials for any reference content using existing product
capabilities or through a partnership with a content provider of such
reference materials. These commenters reasoned that many EHR
technologies are designed to allow for self-developed content or for
use of third party content without the EHR technology having to go an
external source. Some commenters suggested that the HL7 Context-Aware
Knowledge Retrieval standard be positioned to augment, rather than
completely replace other patient education mechanisms currently in
place (e.g., vendor supplied, physician defined). Other commenters
opposed the standard's adoption with some stating that its adoption was
immature and that limiting the certification to just this standard
would create limitations that could have negative effects on workflow
and efficiency.
Response. Our goal is to enable EPs, EHs, and CAHs to provide
patients with the best possible information in the most efficient and
cost-effective ways possible. While we believe Infobutton meets this
goal, we also agree with commenters that alternative means for
identifying patient-specific education materials could meet this goal
and should be available to EPs, EHs, and CAHs. Therefore, we are
adopting a certification criterion that requires EHR technology to
demonstrate a capability to identify patient-specific education
materials using the HL7 Context-Aware Knowledge Retrieval standard
(with the applicable implementation guide) as well as through another
means (i.e., at minimum, 2 different ways, one of which is through the
use of the HL7 Context-Aware Knowledge Retrieval Standard). By doing
so, we believe EPs, EHs, and CAHs will have added flexibility in
meeting the MU objective and measure and an improved ability to provide
quality care to patients.
Comments. A few commenters recommended that we change the wording
in the certification criterion. Specifically, they recommended that we
change the phrasing in the proposed certification criterion from ``each
one of the data elements'' to ``one or more of the data elements.''
Response. As noted above, we have revised the certification
criterion to require that EHR technology demonstrate the capability of
using HL7 Context-Aware Knowledge Retrieval Standard and another means
to identify patient-specific education resources. We have also revised
the language referenced by this certification criterion to make it
clearer. The certification criterion requires that EHR technology be
capable of identifying patient-specific education resources based on
data included in a patient's problem list, medication list, and
laboratory tests and values/results. To clarify, EHR technology must be
capable of identifying patient-specific education resources based on
data from any one of these categories. The identification of patient-
specific education resources based on a combination of data from these
categories would also be acceptable, but in order to demonstrate
compliance with this certification criterion EHR technology must be
able to identify patient-specific education materials, in some manner,
for all of the categories (i.e., a combination of 2 out of 3 categories
would be insufficient to satisfy this certification criterion's
requirements).
Comments. A commenter stated that the HL7 Context-Aware Knowledge
Retrieval Standard, International Normative Edition 2010 (Infobutton)
by itself is not implementable, but it can be implemented in
conjunction with one of the two available implementation guides: the
URL-based Implementation Guide and/or the SOA-based Implementation
Guide. They recommended that the certification criterion explicitly
require implementation to at least one of the two implementation
guides. Other commenters echoed the same point and recommended that the
URL-based Implementation Guide as the best implementation guide to
accompany the standard.
Response. We agree with the commenters that guidance is necessary
for the implementation of the Infobutton standard. Accordingly, as
recommended by the commenters, we are adopting the URL-Based
Implementation Guide and the SOA-based Implementation Guide. We have
adopted them as an ``or'' meaning that only one would need to be used
to demonstrate compliance with this certification criterion. While we
recognize that more EHR technology developers may use the URL-based
version, we also wanted it to be possible for EHR technology to get
certified to the SOA-based version.
Comment. One commenter suggested that CEHRT should permit
integration of MedlinePlus Connect to enhance patient education with
other languages and topics that may not be available in the vendor's
patient education product. They reasoned that this would also help
standardize patient education content across different EHR technology
developers.
Response. We do not preclude the integration of MedlinePlus Connect
in EHR technology and note that MedlinePlus Connect supports the
Infobutton standard.
Comments. One commenter recommended that we amend the certification
criterion to require that EHR technology identify patient-specific
education resources that are compliant with low health literacy
standards and provide those resources to the patient in the patient's
preferred language. Another commenter provided an opposing view in
stating that meaningful users should not be required to provide
materials at specific reading and cultural competency levels. They
reasoned that for short hospital visits (such as emergency department
visits) identifying patients who would need
[[Page 54217]]
materials at different levels could be difficult.
Response. We appreciate the commenters' recommendations on both
sides of the matter. The capability we require EHR technology to
demonstrate to meet this certification criterion for the 2014 Edition
EHR certification criteria sufficiently supports the correlated MU
objective and measure. Therefore, we decline to require a more explicit
capability at this time. We note, however, that a patient's preferred
language should be recorded per the ``demographics'' certification
criterion (Sec. 170.314(a)(3)). We would anticipate that, in an effort
to be responsive to a patient and provide quality care, EPs, EHs, and
CAHs would take the patient's recorded preferred language into
consideration when providing patient education materials.
Comments. Many comments also included aspects about: The MU
numerator and denominator associated with this certification criterion;
the proposal to move the meaningful use objective to core from menu;
when education materials needed to be provided; how they needed to be
provided; principles behind providing education materials; the quality
of the education materials; and that patient educational material need
to be provided digitally and free of charge as well as free of any
advertising and produced either without sponsorship by parties with
conflicts, or with full editorial control vested in the authors, not
the sponsors.
Response. We do not believe it is within the purview of
certification to regulate some of these matters in the manner suggested
by the commenters (e.g., requiring all education materials be free) and
believe it best to have the policy for providing education materials
set first through MU and then supported by certification. We direct
commenters to the Stage 2 final rule for a discussion on the MU
objective and measures, including how to interpret the measure, its
requirements, and the numerator and denominator of the measure.
Transitions of Care
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
The EP, EH, or CAH who transitions their patient to another setting of
care or provider of care or refers their patient to another provider of
care should provide summary care record for each transition of care or
referral.
------------------------------------------------------------------------
2014 Edition EHR Certification Criteria
Sec. 170.314(b)(1) (Transitions of care--receive, display, and
incorporate transition of care/referral summaries).
Sec. 170.314(b)(2) (Transitions of care--create and transmit
transition of care/referral summaries).
------------------------------------------------------------------------
We proposed two revised certification criteria for the 2014 Edition
EHR certification criteria at Sec. 170.314(b)(1) and (2). The first
certification criterion we proposed would have required EHR technology
to be able to incorporate a summary care record formatted according to
the Consolidated CDA. The second certification criterion we proposed
would have required that EHR technology be capable of creating and
transmitting a summary care record in accordance with the Consolidated
CDA, with certain specified vocabulary standards, and two specified
transport standards. As noted in the Proposed Rule, the HITSC
recommended a merged revised certification criterion for the 2014
Edition EHR certification criteria that would be generally applicable
to both the ambulatory and inpatient settings, with a deviation based
on the setting-specific information that would be included in the
summary care record. However, based on stakeholder feedback received
after the publication of the S&CC July 2010 final rule, we stated our
belief that the criterion should be split into two separate
certification criteria based on the capabilities required. We explained
that this approach would provide developers greater flexibility for
certification.
For the same reasons we discussed in the proposal for the new
``view, download, and transmit to 3rd party'' certification criterion
(Sec. 170.314(e)(1)), we proposed to adopt the Consolidated CDA for
this certification criterion because its template structure can
accommodate the formatting of a summary care record that includes all
of the data elements that CMS proposed be available for inclusion in a
summary care record. We acknowledged that care plan, additional care
team members, referring or transitioning provider's name and contact
information as well as certain hospital discharge information are not
explicitly required to be captured by separate certification criteria,
unlike most other data included in the summary care record. We noted
that the ability to capture these data elements is both implicit and
necessary to satisfy this certification criterion (as well as the other
certification criteria that rely on the same data). Therefore, we
considered, but did not propose, adopting separate data capture
certification criteria for each of these data elements in order to make
it clear that they are required to be captured. We requested public
comment on whether we should create separate certification criteria for
all of these data elements in this final rule.
For certain other data elements in Sec. 170.314(b)(2), we proposed
to require that the capability to provide the information be
demonstrated in accordance with the specified vocabulary standard. We
noted that these vocabulary standards were either previously adopted or
proposed for adoption in the Proposed Rule, consistent with HITSC
recommendations. Additionally, we requested public comment on whether
we should require, as part of the ``incorporate summary care record''
certification criterion proposed at Sec. 170.314(b)(1), that EHR
technology be able to perform some type of demographic matching or
verification between the patient in the EHR technology and the summary
care record about to be incorporated. We believed this would help
prevent a summary care record from being combined with or attributed to
the wrong patient.
We proposed that EHR technology would need to be capable of
transmitting a summary care record according to both of the Direct
Project's specifications for secure transport. We also proposed to
adopt as an optional standard at Sec. 170.202(a)(3) the SOAP-Based
Secure Transport RTM version 1.0 \20\ which was developed under the
nationwide health information network Exchange Initiative and to which
we stated EHR technology should be able to be certified. We included
this option to provide added flexibility to those EPs, EHs, or CAHs
that may seek to use EHR technology with the ability to transmit health
information using SOAP as a transport standard in addition to SMTP to
meet MU. We noted that, while we would only permit EHR technology to be
certified to these two transport standards, we intended to monitor
innovation around transport standards and would consider including
additional transport standards, such as a RESTful implementation in
this certification criterion.
---------------------------------------------------------------------------
\20\ http://modularspecs.siframework.org/NwHIN+SOAP+Based+Secure+Transport+Artifacts.
---------------------------------------------------------------------------
Further, we requested public comment on whether equivalent
alternative transport standards exist to the ones we proposed to
exclusively permit for certification. We also requested comment on our
proposed approaches for deciding whether additional transport standards
would be appropriate and for adopting any such standards through
interim final rulemaking with comment.
[[Page 54218]]
Additionally, in the context of the proposed limitations included as
part of the proposed MU Stage 2 measure associated with this objective
(which is percentage-based), we requested public comment on any
difficulties EHR technology developers might face in determining the
numerator and denominator values to demonstrate compliance with the
automated numerator calculation or automated measure calculation
certification criteria we proposed to adopt.
General Summary
Many commenters reiterated or pointed to the comments they issued
in response to the view, download and transmit to a 3rd party
certification criterion. Many commenters also repeated points about a
consistent set of data to be referenced across the certification
criteria that proposed the adoption of the Consolidated CDA. In that
respect, we do not repeat those responses where we have already
addressed comments in other parts of this preamble that would also be
applicable to the transitions of care certification criteria. Similar
to the other certification criteria where we received detailed groups
of comments on distinct concepts, we have used subheadings to improve
the preamble's overall readability.
Receipt/Receive
Comments. Some commenters expressed that the certification
criterion proposed at Sec. 170.314(b)(1) was ambiguous. They also
indicated that ``upon receipt'' in the certification criterion implied
a capability that should be explicitly stated--that the EHR technology
be able to receive a transition of care/referral summary according to
the same transport standards we require (and permit) for certification
for the transmission of a transition of care/referral summary. These
commenters argued that we needed to include this specificity because
EHR technology should be tested for both its ability to send and
receive data. Further they suggested that we change the paragraph
heading to include ``receive.''
Response. We agree with commenters that the capability to receive
transition of care/referral summaries according to the proposed
transport standards was implied and that we should make it explicit.
Further, in revising the proposed certification criterion to do so, we
also noticed that Sec. 170.314(b)(1) should mirror the same structure
as Sec. 170.314(b)(2) with its ``ambulatory setting only'' and
``inpatient setting only'' because we had just included a list of data
in our proposal that mixed both settings. We are finalizing these
changes as well as changing the paragraph heading to better describe
the overall capabilities specified by this finalized certification
criterion. Any changes to Sec. 170.314(b)(2) in response to public
comments, such as the applicability of certain transport standards are
discussed in our responses below.
Display
Comments. Several commenters recommended that, at the very least,
we include some form of ``backwards compatibility'' in this
certification criterion by requiring EHR technology to be able to
display transition of care/referral summary formatted according to the
standards adopted as part of the 2011 Edition EHR certification
criteria. They reasoned that many EPs, EHs, and CAHs will have 2011
Edition CEHRT capable of creating and displaying a transition of care/
referral summary according to the CCD/C32 and CCR. Additionally, they
stated that by not doing so, we would significantly limit the ability
of trading partners to continue to communicate with each other as they
each separately upgraded their EHR technology to the capabilities
required by the 2014 Edition EHR certification criteria. These
commenters indicated that this requirement would be a relatively low
burden since it is already required for certification.
Response. We agree with commenters. We have revised the final
certification criterion to require that EHR technology must be able to
display in human readable format the data included in transition of
care/referral summaries received and formatted according to each of the
transition of care/referral summary standards we have adopted (i.e.,
CCD/C32; CCR; and Consolidated CDA). We believe this modification to
the certification criterion, as expressed by commenters, results in a
significant benefit while imposing very limited practical burden
because it essentially builds on the 2011 Edition version of the
certification criterion that we proposed to revise.
Comments. A couple of commenters expressed concern regarding
hospitalizations with large volumes of data such as lab results and how
this information would display in a summary document of considerable
length.
Response. This certification criterion expresses that EHR
technology must be able to display transition of care/referral
summaries received according to any one of the three adopted standards
mentioned in the above response. It does not, however, dictate how that
information is displayed to a user. Those design decisions are fully
within an EHR technology developer's discretion.
Incorporate
Comments. We received a significant number of comments related to
the specific ``incorporate'' capability expressed in this certification
criterion. Many contended that the general description we provided at
the beginning of the Proposed Rule was too generic, ambiguous, or
inconsistent with their understanding of what it meant to
``incorporate'' data as this certification criterion described.
Commenters offered many perspectives on what incorporation should mean
for this certification criterion. Most commenters described
incorporation to mean the EHR technology's ability to store and
reference data from a transition of care/referral summary.
Many commenters stated that this proposal went far beyond what was
required in the 2011 Edition EHR certification criterion's requirements
and that it seemed to require that each and every data element
referenced be incorporated as structured data. These commenters argued
that for the 2011 Edition certification criterion, EHR technology only
had to be able to incorporate the CCD or CCR transition of care/
referral summary as a whole, thus maintaining its integrity. Some
commenters stated that incorporating an entire clinical summary might
trigger the creation of a new encounter. Further, they added that for
the 2014 Edition version, the only data that should be required to be
incorporated (and that should be decomposed from the transition of
care/referral summary) should be the same data specified in the
``clinical information reconciliation'' certification criterion (i.e.,
problems, medications, and medication allergies) and focus on these
data ``at a minimum.'' Other commenters argued that it made no sense to
incorporate all of the data specified in the Proposed Rule because the
data would be contextually specific--and could lose its semantic value
if removed from the context of the whole document.
Response. We agree with commenters that the single description for
``incorporate'' in the Proposed Rule was insufficient to provide the
clarity necessary for this certification criterion. As many comments
expressed, and as we clarified in the beginning of this final rule, we
intended for the term ``incorporate'' to mean that EHR technology would
be able to process the structured data contained in those three
[[Page 54219]]
Consolidated CDA sections (medications, problems, medication allergies)
such that it could be combined (in structured form) with data already
maintained by EHR technology and would subsequently be available for
use, such as to be used as part of the clinical information
reconciliation capabilities (expressed in the certification criterion
adopted at (Sec. 170.314(b)(4)). We have revised this certification
criterion to make this distinction clear.
In consideration of comments, such as those that indicated it may
make no sense to incorporate specific data, we believe that there is
clinical value to the extraction and individual display of the
individual sections of the Consolidated CDA. To ensure that an EP, EH,
or CAH, can reap the most benefit from a Consolidated CDA formatted
transition of care/referral summary, we have added to this
certification criterion a specific capability that EHR technology be
able to extract and allow for individual display each additional
section or sections (and the accompanying document header information
(i.e., metadata)) that were included in a transition of care/referral
summary received and formatted in accordance with the Consolidated CDA.
For example, if a user wanted to be able to review other sections of
the transition of care/referral summary that were not incorporated (as
required by this certification criterion), such as a patient's
procedures and smoking status, EHR technology would need to provide the
user with a mechanism to select and just view those sections without
having to navigate through what could be a lengthy document. We intend
for testing and certification to verify that the document header
information can be displayed with whatever individual sections are
selected, but leave the ultimate quantity of header data to be
displayed through implementation up to the EHR technology developer and
its customers' preferences.
We recognize this certification criterion is more rigorous than the
2011 Edition EHR certification criterion, but believe that it is
necessary to continue to introduce more demanding certification
requirements for interoperability in order to advance our policy
objectives for widespread electronic health information exchange. We
stress that an EHR technology's ability to incorporate data for
medications, medication allergies, and problems in structured form from
a Consolidated CDA formatted document is the bare minimum necessary for
EHR technology to meet this certification criterion. Even though we do
not explicitly require more data to be incorporated in a structured
form from a Consolidated CDA formatted document, we highly encourage
EHR technology developers to go beyond this minimum as we intend to
consider a more rigorous incorporation requirement in our next edition
of EHR certification criteria. Finally, we believe our response under
the ``display'' heading addresses the comments about incorporating a
transition of care/referral summary as a whole, since such a capability
would be addressed by the display requirement in this certification
criterion.
Comments. A few commenters stated that incorporation should not be
automated and that there is a potential safety issue with bringing in
data elements that have not been reconciled. Another commenter noted
that one of the reasons incorporation cannot be automated is because
many EHR technologies require that a term be in their ``problem list
master file'' in order to get onto the problem list and that many EHR
technologies have local problem terms that are mapped to SNOMED-CT. As
a result, they stated that one cannot assume that two CCDs, each having
a problem mapped to the same SNOMED-CT code, are both referring to
exactly the same thing. They suggested that this capability be
designated as optional. A couple of commenters noted that EPs, EHs, and
CAHs should have some control over how exactly they want to be able to
incorporate data into their EHR technology as part of their practice/
organization.
Along these same lines, commenters responded to our question
regarding whether some form of demographic matching would be important
to include for this certification criterion. Commenters responded
favorably, but requested that we not dictate a standard or any
particular matching methodology so as to permit a range of different
options and to let innovation continue in this area. One commenter
stated that EHR technology must perform patient matching in order to
aggregate PHI from multiple sources that provide electronic feeds into
the EHR technology. Additionally, the commenter noted that the EHR
technology developer typically determines the most appropriate patient
matching algorithm based on a number of factors relating to the data
available in order to facilitate a correct patient match. They also
stated that some EHR technology developers may choose a very robust
matching capability based on available demographics or practice size.
Another commenter requested guidance on what data would be used for
patient demographic matching. While a different commenter recommended
that we establish a minimum set of demographic information that could
be used to accurately match patient records.
Response. We appreciate commenters' feedback and expressed
concerns. We anticipate that EHR technology developers will be able to
automate the incorporate capability in some manner, but this
certification criterion does not necessarily require that it be fully
automated. It is our understanding and, it was implied by the
certification criterion, that some form of matching would occur when a
transition of care/referral summary is received in order to correctly
determine that the document as a whole (as discussed under the
``display'' heading) was attributed to the right patient. Further, that
upon receipt of a transition of care/referral summary is the
appropriate point at which to verify that the transition of care/
referral summary is being attributed to the correct patient.
Accordingly, we have not included this type of matching as part of the
clinical information reconciliation certification criterion since the
data will have already been attributed to a particular patient at the
point in time reconciliation is executed. Finally, we have revised this
certification criterion to include a general statement that the EHR
technology must be able to demonstrate that a transition of care/
referral summary received is or can be properly match to the correct
patient. As requested by commenters, we have intentionally left this
requirement flexible to permit many different ways for this capability
to be designed. As such, we decline to provide specific guidance on
particular demographic information except to note that the demographics
certification criterion would be a good starting point in addition to
any data that may be available in the header of a transition of care/
referral summary. We encourage EHR technology developers to apply this
specific capability to other capabilities where it may prove
beneficial.
Comments. Some commenters asked that we clarify that information
made available in an HIE or a portal counts as incorporation for this
certification criterion.
Response. Considering the response above and how we have explained
our interpretation of ``incorporate,'' we do not believe or see how
this could satisfy the capability required by the certification
criterion.
Comment. A commenter in support of incorporating problems,
medications,
[[Page 54220]]
and medication allergies suggested that this data should be
incorporated into EHR technology in such a way that those data elements
can be used for real-time clinical decision support and recommend that
the ONC consider this as an additional criterion.
Response. We refer readers to our discussion of the clinical
decision support certification criterion.
Create and Transmit (now Also Applicable To Receive as Part of Sec.
170.314(b)(1))
Comments. As noted in the view, download, and transmit to a 3rd
party certification criterion's comment and response section, we
indicated that the only place where the data type ``encounter
diagnoses'' would be included was as part of a transition of care/
referral summary in the transition of care certification criterion.
Similar to the comments we received and discussed related to
``procedures,'' some comments supported the use of ICD-10-CM while
others stated that we should refer to SNOMED CT[supreg] and only SNOMED
CT[supreg] for the same reasons they stated before (e.g., clinical
accuracy versus a billing diagnosis code set). One commenter stated
that both ICD-10-CM and SNODENT should be a requirement for diagnoses
coding in dental systems. They reasoned that SNODENT has been mapped to
ICD-9-CM and the mappings between SNODENT and ICD-10-CM are being
developed.
Response. We appreciate commenters' feedback. As with procedures,
commenters provided many different perspectives on the appropriate
vocabulary to adopt for encounter diagnoses. Because this is a billing
data type, we have decided to finalize our proposal to allow for the
use of ICD-10-CM to represent encounter diagnoses in addition to
permitting SNOMED-CT. We believe this is the best approach to take for
all parties involved. Additionally, the National Library of Medicine
has created a publicly available mapping from SNOMED-CT to ICD-10-CM,
available at http://www.nlm.nih.gov/healthit/meaningful_use.html. This
mapping is available to any EHR technology developer, or practice
management/billing system developer for the translation of SNOMED
CT[supreg] to ICD-10-CM. In this way, EHR technology may send a
representation of encounter diagnosis using either SNOMED-CT or ICD-10-
CM. Since providers will most likely be using SNOMED CT[supreg] for the
selection of problems, this criterion allows for the use of only
clinical vocabularies in such clinical systems and the association of
problems with encounters, thereby encouraging the translation of SNOMED
CT[supreg] to ICD-10-CM to occur in an administrative system. By
permitting ICD-10-CM to be used to represent encounter diagnosis for
certification, we also accommodate EHR technology developers who choose
to make this translation within the clinical system as well. We decline
to accept the recommendation for us to adopt SNODENT for the same
reasons we provide elsewhere in this final rule in response to this
comment.
Comments. In response to our question as to whether we should
create separate certification criteria for the data elements implicit
and necessary to satisfy this certification criterion (as well as the
other certification criteria that rely on the same data) some comments
expressed support while others opposed doing so and suggested it was
unnecessary. Those who opposed the adoption of separate certification
criteria for the additional data (e.g., care plans) stated that while
standards do not exist at the present time for these elements, they can
be incorporated in the Consolidated CDA as text. They did, however, add
that because no standards exist, we should consider deferring their
adoption until the next edition of EHR certification criteria.
Response. We thank commenters for responding to the question we
posed. As suggested by those commenters that opposed the adoption of
explicit certification criteria for each of these additional elements,
we have not done so. We agree with the logic provided by commenters. So
long as the Consolidated CDA can support this information, we believe
it is sufficient to continue our approach of referencing this data
within the applicable certification criteria. Consistent with our
general approach to support MU, we have made sure to align all of the
data specified and expected by CMS in applicable certification
criteria. Thus, unless CMS removed a particular data element/type, we
have included the data element/type in our final rule for the
applicable certification criteria.
Comment. A commenter stated that there appeared to be a hidden
requirement for CEHRT to translate local codes to standard codes for
all data in all instances, including when the original source of the
data did not provide the data in standard codes. They suggested that in
instances where the EHR technology simply passes-through the data that
the requirement to use a standard vocabulary for outbound data exchange
be waived. They further explained that when source data such as
laboratory results or documentation from non-CEHRT/HIT is received by
the CEHRT it may not contain data according to the adopted standard
vocabulary. They contended that translating such data to a standard
vocabulary should be the responsibility of the data source (to ensure
the standard vocabulary is used most appropriately). They noted that
downstream translation may not capture the translation subtleties that
are clear within the source system's environment. They concluded by
stating that it was unreasonable for us to implicitly or explicitly
require that outbound data exchange from the CEHRT always apply a
standard vocabulary to data that the CEHRT did not itself create until
all relevant source systems utilize standard vocabularies.
Response. We agree that there could be scenarios in which an EP,
EH, or CAHs CEHRT receives data from a source that has not formatted
the data according to the applicable adopted vocabulary standard. In
instances where the EP, EH, or CAH's CEHRT receives data from an
outside source, we acknowledge that requiring the CEHRT to translate
the data into an adopted standard vocabulary could alter its intended
meaning. We understand that there may be scenarios in which local or
proprietary codes are transmitted in a transition of care/referral
summary, laboratory report, or other exchanged document. Further, we
agree with this commenter that the responsibility of the sending EP or
EH/CAH is to send information with standard terms, and in the case when
such standard terms are not used, it should not be the responsibility
of the receiving EP or EH to translate local or proprietary codes into
standard codes. However, we emphasize that for the purposes of
certification, and demonstrating compliance with this certification
criterion, EHR technology will need to be tested and certified as being
able to apply all of the adopted standard vocabularies to data required
to be included in a Consolidated CDA formatted transition of care/
referral summary. This response is applicable to the other
certification criteria to which this clarification would apply.
Comments. Many commenters supported our proposal to require the
Applicability Statement for Secure Health Transport specification (the
primary Direct Project specification) and the second Direct Project
specification (XDR and XDM for Direct Messaging). Others supported our
reference to the SOAP-based transport standard as well. Some commenters
contended that we should require both transport approaches for
certification. Other commenters stated that we should only
[[Page 54221]]
require the primary Direct Project specification. While others
specified that we should reference the XDR and XDM for Direct Messaging
specification as a bridge for the primary Direct Project specification
and the SOAP-based transport standard.
Response. In considering the range of comments received, we have
finalized a modified certification approach with respect to transport
standards. We have adopted, as proposed, that the Applicability
Statement for Secure Health Transport specification be a required
condition of certification as part of this certification criterion. We
have removed the XDR and XDM for Direct Messaging specification as also
being required in lieu of a broader range of options for certification.
Thus, to be certified to this certification criterion an EHR technology
must enable a user to electronically transmit a transition of care/
referral summary in accordance with the Applicability Statement for
Secure Health Transport specification. This requirement sets a baseline
for EHR technology certification and enables simple and secure SMTP-
based exchange. Additionally, because this certification criterion is
part of the Base EHR definition, all EHR technology used by EPs, EHs,
and CAHs and that meets the CEHRT definition will, at a minimum, be
capable of SMTP-based exchange. For the reasons we discussed under the
``view, download, and transmit to 3rd party'' certification criterion
earlier in this preamble, we have adopted the updated version of this
specification that was established by the stakeholder community during
this final rule's drafting.
To permit additional flexibility and options for EHR technology
developers to provide their customers with EHR technology that has been
certified to support an EP, EH, or CAH's achievement of the
``transitions of care'' MU objective and associated measure, we have
adopted two optional certification approaches for transport standards.
For each option, EHR technology would need to demonstrate its
compliance with both of the identified specifications in that option in
order to be certified to the option.
The first option would permit EHR technology to be
certified as being in compliance with our original proposal:
Certification to both the Applicability Statement for Secure Health
Transport specification and the XDR and XDM for Direct Messaging
specification.
The second option would permit EHR technology to be
certified to: The Simple Object Access Protocol (SOAP)-Based Secure
Transport Requirements Traceability Matrix (RTM) version 1.0 standard
and the XDR and XDM for Direct Messaging specification.
We have included the XDR and XDM for Direct Messaging specification
as a required specification for both of these options because it serves
as the bridge or translator for electronic exchange partners that
engage in SMTP to SOAP and SOAP to SMTP exchanges.
Comments. A few commenters noted that the proposal to adopt the
Simple Object Access Protocol (SOAP)-Based Secure Transport
Requirements Traceability Matrix (RTM) version 1.0 specification was
confusing and requested that we clarify whether its adoption permitted
the use of other nationwide health information network specifications
to be used (e.g., patient discovery, document query, document
retrieval). Some of the same commenters also suggested that we added
the IHE-XDR profile as an implementation guide for the proposed
standard. Last, these commenters requested that we change the paragraph
heading for the transport standards so as not to imply their use is
limited to directed exchange.
Response. We seek to clarify any confusion that may have been
caused by our proposed adoption of the SOAP-Based Secure Transport
Requirements Traceability Matrix (RTM) version 1.0 specification. As
indicated within the specification, its purpose is to ``define the
primary set of security and transport protocols needed to establish a
messaging, security, and privacy foundation for health information
exchange.'' Further, it is ``constrained to technical specifications
for security and transport protocols and does not address any content
specifications.'' Last, it is ``intended to provide an understanding of
the context in which the web service interface is meant to be used, the
behavior of the interface, the Web Services Description Language
(WSDLs) used to define the service, and any Extensible Markup Language
(XML) schemas used to define the content.
This specification, and not IHE designated specifications, was
purposefully adopted because it serves as the baseline SOAP
specification on top of which other (March 1, 2012 effective)
Nationwide Health Information Network Exchange specifications can be
implemented. If an EHR technology is presented for certification to
this optional transport standard, we intend for testing and
certification to establish that the SOAP specification is properly
implemented (i.e., EHR technology's ability to send and receive
messages in accordance with the specification). Because this
specification serves as the underlying set of web services protocols
for other more detailed context/use case specific specifications, we
clarify that so long as EHR technology is certified to this baseline
SOAP specification other more detailed/use case specific specifications
may be used in addition to, or on top of, this specification (i.e., not
in lieu of).
With respect to the recommended IHE profile, we did not accept this
recommendation. We have included the bridge specification in the XDR
and XDM for direct messaging specification and have concerns about the
testability of the IHE-XDR profile. As we understand it and as
currently described in the IHE Technical framework, the IHE XDR is a
``pattern'' of a transaction that can be tailored and implemented by
EHR technology developers as they wish, based on a particular use case.
Additionally, both of the transport standards adopted in this final
rule can be used independent of IHE XDR profile. This does not preclude
EHR technology developers from also implementing it outside of
certification, but we decline to require it as a condition of
certification.
Finally, we have removed the paragraph heading in Sec. 170.202 as
indicated by commenters so as not to imply that the specifications can
only be used in the context of directed exchange.
Comments. Commenters raised several questions and concerns related
to the proposed Direct Project specifications and how EHR technology
would be tested and certified to the transitions of care certification
criteria. Commenters indicated that there are multiple ways to deploy,
configure, and implement EHR technology to meet the specifications.
Some asked that we clarify whether all implementation options must be
simultaneously supported or if some were intended to be prohibited.
Further these commenters stated that only one test of a particular
implementation/configuration would be necessary to verify that an
appropriate SMTP + S/MIME communication was correctly structured, but
all implementations would rely on that capability to be present.
Commenters recommended that we clarify what would be required to
demonstrate compliance with these certification criteria. They
recommended that testing and certification focus on EHR technology's
ability to correctly create and receive messages formatted in
accordance with the Applicability Statement for Secure Health Transport
specification. They concluded by stating that this approach would
enable EPs, EHs, and CAHs to utilize other email infrastructures
without requiring EHR technology
[[Page 54222]]
developers to test with multiple infrastructures.
Response. We thank commenters for the detailed comments and in some
cases illustrations to describe the different deployment and
configurations anticipated by the Applicability Statement for Secure
Health Transport specification. These detailed comments greatly aided
our policy deliberations. We agree with commenters on the approach that
should be used to test and certify whether EHR technology is in
compliance with the Applicability Statement for Secure Health Transport
specification. Specifically, we agree that testing and certification
should not focus on particular deployments or configurations, but
rather on what will remain constant across those variances--EHR
technology's ability to correctly produce and receive SMTP + S/MIME
messages formatted in accordance with the Applicability Statement for
Secure Health Transport specification. We further clarify that we do
not intend for testing and certification to focus on the particular
email protocols that may be implemented to support the routing of these
messages, such as Internet Message Access Protocol (IMAP), Post Office
Protocol (POP) and other vendor-specific proprietary protocols. These
capabilities and others such as mailbox management, storage, and
forwarding of received messages that would be implementation or
deployment specific would not be assessed as part of testing or as a
condition of certification.
Further, we expect that the National Coordinator will approve a
test procedure for the transitions of care certification criteria that
rigorously assesses EHR technology's ability to transmit and receive
electronic health information according to the adopted transport,
content exchange, and vocabulary standards. We anticipate that this
test procedure will be specified to ascertain the EHR technology's
ability to engage in standards-based exchange with any other EHR
technology that has also implemented the standards we have adopted. To
enable this form of electronic testing, the NIST has developed a
conformance test tool that receives and validates a Consolidated CDA
formatted file from the EHR technology under test. The conformance tool
will be a part of a ``test bed'' that simulates exchange between a test
EHR technology and a standards-compliant EHR technology. This will
eventually allow for all levels of interoperability to be assessed in
the electronic exchange of transition of care/referral summaries. This
capability will also provide a future platform for testing more
comprehensive forms of interoperability between EHR technologies.
Comment. A commenter requested that we clarify whether a health
information exchange using only CONNECT to exchange could meet the
certification criterion. Another commenter asked that we confirm that
the transport capabilities can be demonstrated by a Complete EHR or EHR
Module itself, or through demonstration by the Complete EHR or EHR
Module to achieve the transport capability through integration with a
service provider--such as a network or health information service
provider (HISP). They stated their interpretation that the current
definition of an EHR Module permits a combination of a service and a
component to be certified.
Response. While we would need to examine a specific fact pattern to
issue a definitive response, it seems possible for a health information
exchange using CONNECT to seek certification to this certification
criterion. We have always maintained and reaffirm that any EHR
technology that can demonstrate compliance with a certification
criterion can be issued an EHR Module certification as evidence that
the capability the EHR technology included was certified. We interpret
and use the term EHR technology (and intentionally not the term EHR)
broadly so as to permit innovative market-based electronic exchange
solutions to be paired with other EHR technology that performs
clinically focused capabilities. Thus, to the degree that a HISP or
like entity would be performing a capability for which certification is
required and an EP, EH, or CAH would like to use the entity's
technological capabilities as a way to meet the definition of CEHRT,
the entity would need to seek certification for the technical
capabilities that its systems can perform as if those capabilities were
natively part of the EP, EH, or CAH's CEHRT. In these situations, we
highly encourage EHR technology developers to work together to make the
use of these capabilities as seamless as possible.
Comments. Commenters suggested that ONC offer guidance on how the
sending system will know the transport protocol understood by the
receiving system unless that is something the Health Information
Service Provider (HISP) would be responsible for indicating so the
sending system sends using XDR or XDM appropriately.
Response. Pursuant to our responses above, we believe this comment
drifts into a specific implementation dependent scenario. However, we
will consider whether additional guidance is required after this final
rule to assist stakeholders.
Comments. Several commenters stated that they reviewed potential
RESTful transport alternatives and concluded that the alternatives
lacked maturity and sufficient testing. A few commenters supported
RESTful as an optional standard.
Response. We agree with those commenters that have concluded
potential RESTful transport alternatives lack sufficient maturity at
this time for adoption. We will, however, continue to monitor the
testing and implementation of RESTful transport alternatives to
determine whether they have reached a maturity sufficient enough to
consider for adoption.
Clinical Information Reconciliation
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
The EP, EH, or CAH who receives a patient from another setting of care
or provider of care or believes an encounter is relevant should perform
medication reconciliation.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(b)(4) (Clinical information reconciliation).
------------------------------------------------------------------------
In the Proposed Rule, we proposed to revise this certification
criterion and adopt as part of the 2014 Edition EHR certification
criteria an expanded version that focuses on the reconciliation of data
in each of a patient's medication, problem, and medication allergy
lists. We proposed to adopt a revised certification criterion at Sec.
170.314(b)(4) which we labeled as ``clinical information
reconciliation'' to express the three specific capabilities that EHR
technology would need to include.
We specified that EHR technology would first need to be able to
electronically display the data from two or more 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 of the
information. We proposed that the second specific capability EHR
technology would need to include would be to enable a user to merge and
remove individual data. We clarified that, while not required or
expected for certification, this capability could be designed to
automatically suggest to the user which medications could be merged or
removed. The third and final specific capability we proposed that EHR
technology would need to include would be to enable a user to review
and validate the accuracy of a final set of data elements and, upon a
user's confirmation, automatically update the patient's medication,
problem, and/or medication allergy list.
[[Page 54223]]
In our proposal, we emphasized that EHR technology's role is to be
assistive and not to determine without human judgment which data
elements should be reconciled. Thus, we noted that this third specific
capability would require EHR technology to present a final set of
merged data for a user to validate and confirm before updating the
prior list. Finally, we requested public comment on whether as part of
this certification criterion we should require EHR technology to
perform some type of demographic matching or verification between the
data sources used.
Comments. Commenters were generally in favor of the proposed
clinical information reconciliation certification criterion. Many
agreed with our proposal to expand reconciliation to include problems
and medication allergies, but some stated that it exceeded what was
minimally required for meaningful use and that we should just keep the
certification criterion focused on medication reconciliation. A couple
of commenters stated that the certification criterion was over
specified, premature, and prescribed workflow. One followed suit and
stated that the requirement to merge the data from a source and
automatically update from a foreign source requires common data models
and terminology sufficient to instantiate the medication, medication
allergy, or problem into the receiving system and that these models and
terminologies are not fully defined.
Response. We appreciate commenters support and constructive
feedback. We have finalized this certification criterion with specific
modifications as detailed below in other responses. We believe these
changes may address some commenters concerns, however, we have
maintained this certification criterion's scope to include medications,
medication allergies, and problems. We believe this is the minimum that
EHR technology should be able to assist EPs, EHs, and CAHs reconcile.
Further, as we have noted in the transitions of care certification
criterion Sec. 170.314(b)(2), we intend for these same three data
types to be able to be incorporated from a transition of care/referral
summary formatted according to the Consolidated CDA standard and
subsequently available to use for reconciliation as part of this
capability. We anticipate that test procedures will be developed to
thread these steps together where EHR technology presented for
certification includes both capabilities (transitions of care
incorporation and clinical information reconciliation). While we
typically do not express capabilities in certification criteria that
exceed what would be necessary to support meaningful use, we remind
readers that our authority to adopt certification criteria is not
limited by meaningful use. That is, meaningful use does not set a
ceiling for certification. Rather, we generally use it as the baseline
upon which we propose and adopt, in some cases, more rigorous
requirements.
Comments. Some commenters asked for clarification regarding the
term ``source'' in the certification criterion and what would be used
to indicate source. They asked if the information would be needed in
the future, would be stored as part of the patient record, or if a link
could be used to get to the source. Some did not support including this
information.
Response. We believe that, at a minimum, EHR technology needs to be
able indicate to a user the data's source (i.e., where the data came
from). For the purposes of this certification criterion and its linkage
to the transitions of care certification criterion (Sec.
170.314(b)(2)), we intend to focus certification on the identification
of the source from the transition of care/referral summary's header.
However, we do not preclude other sources, such as patients from being
able to be identified as part of this certification criterion. Given
the additional specificity in this 2014 Edition version, we intend to
incrementally increase and enhance the assistive power of this
capability over time.
Comments. Commenters asked what ``last modification date'' in the
certification criterion meant. They asked whether it was the last date
of medication reconciliation or the date that the medication was added
or updated. Some did not support including this information.
Response. For the purpose of this certification criterion, ``last
modification date'' should be interpreted differently for each data
type. For medications, it should be interpreted as the last date the
medication was documented, ordered, prescribed, refilled, dispensed or
edited. For problems it should be interpreted as the last date the
problem was documented or edited. For medication allergies, it should
be interpreted as the date that the medication allergy was last
documented, edited, or updated.
Comments. Some commenters requested clarification on the term
``merge'' in the certification criterion and what our expectation was
for merge. They also asked that we clarify that merging would only be
for medications, medication allergies, and problems.
Response. We interpret ``merge'' to generally mean that EHR
technology assists a user in creating a single list that is
representative of the medications, medication allergies, or problems
that are relevant to a patient. However, we believe that an approach
using plain language to express the desired outcome would make this
certification criterion clearer. It would also represent the many
acceptable approaches we had in mind when we drafted this proposed
certification criterion. Accordingly, we have modified Sec.
170.314(b)(4)(ii) to state that EHR technology would need to enable a
user to ``create a single reconciled list of medications, medication
allergies, or problems.'' How this would be accomplished is up to the
EHR technology developer, but could include a user's ability to merge
equivalent elements and remove/deactivate no longer relevant
information.
Comments. Some commenters requested clarification that ``confirm''
was meant to be interpreted as the list itself and not each individual
element within the list.
Response. Confirm is meant to apply to the single reconciled list
(not each element) once it meets a user's satisfaction.
Comments. A couple of commenters requested that we expand this
certification criterion to require that EHR technology be capable of
conducting medication reconciliation using electronic health
information exchange to obtain a medication history.
Response. We appreciate this suggestion and recognize its value,
however, we did not propose this type of extended capability, nor does
meaningful use presently require it. Thus, we encourage EHR technology
developers to consider including this capability if they have not
already and we intend to bring this topic to the HITSC for
recommendations on our next edition of certification criteria.
Comments. Commenters requested that we clarify that the
reconciliation process does not require all reconciliation activities
to occur in one system function but may be performed in more than one
function so that the functions can be placed in appropriate workflows.
Commenters also asked that we clarify that each list type was expected
to be separately reconciled and not that we expected two or more
different list types to be reconciled at the same time (e.g.,
medication list and problem list). They suggested that we revise the
certification criterion to expressly indicate that it would be at least
two lists or at least two sources.
Response. To clarify, we did not intend to imply that the
reconciliation capability had to happen all in one step. For instance,
if medications are reconciled at a different points in the
[[Page 54224]]
clinical workflow than problems, this would not be precluded by the
certification criterion. However, the same underlying reconciliation
capability required by the certification criterion would need to be
initiated for each of those different list reconciliations. To make
this clear we have modified the certification criterion, as commenters
suggested to say ``from at least two list sources.'' We also wish to
further explain for commenters that as the certification criterion
begins to express each specific capability there is the following
introductory text, ``For each list type:'' This should and is meant to
be interpreted as separately applying to each list type. For instance,
(b)(ii) would be interpreted as ``For each list type enable a user to
create a single reconciled list of medications, medication allergies,
or problems''. As in, there would be a single list for medications, a
single list for medication allergies, and a single list for problems.
Comments. A few comments asked that we provide an example for what
an acceptable capability for this certification criterion would be. A
commenter explicitly suggested (as part of our example) we clarify
that, at a minimum, the EHR technology should have the ability to
simultaneously display and update the appropriate list type.
Response. First, we agree with the commenter that EHR technology
should have the ability to simultaneously display the list type that is
actively being reconciled. We have modified the certification criterion
to make this implicit requirement explicit. We believe this is a
critical clarification so as to prevent EHR technology from being
certified that requires a user to toggle between different views to
reconcile data for one list type. As far as an example goes, (and
keeping in mind the revisions we have made to this certification
criterion) assuming a transition of care/referral summary has been
received as part of a transition of care, an EP's CEHRT would need to
be able to receive the transition of care/referral summary and make a
logical identification of the medications, medication allergies, and
problems from the Consolidated CDA formatted transition of care/
referral summary pursuant to the incorporation requirement. Next, at
the appropriate points in the EP's workflow, the EP would be able to
interact with CEHRT to create a single reconciled list for each of the
data included in the medication, medication allergy, and problem lists.
For each of these lists, once the EP has the data reconciled to his or
her satisfaction, the EP would be able to review the list and confirm
the reconciled list, which would then be updated and saved as the
single medication, problem or allergy list.
Comments. Commenters requested clarification regarding the scenario
where the source list is unstructured data. One stated that if the
source list is unstructured, then whatever manner the EHR enables
unstructured data to be presented which could subsequently be
reconciled through manual transcription should be acceptable for
certification. One commenter suggested that medications should be
reconciled in whatever process the EHR technology supported for the
2011 Edition EHR certification criterion. Other commenters requested
clarification that a document received as a Consolidate CDA must
contain structured data. They stated that for unstructured data,
certification should not require corresponding items to appear on the
reconciliation screens.
Response. We agree with commenters suggestions. In the event that
data is in unstructured form, any method implemented by which the EHR
is capable of assisting in reconciliation is acceptable. Presumably,
this is how (at a minimum) reconciliation is performed in accordance
with the 2011 Edition EHR certification criterion. With respect to data
received from a document formatted in accordance with the Consolidated
CDA, we expect EHR technology to be tested on its ability to utilize
structured data to assist in the reconciliation process.
Comment. One commenter stated that reconciliation based on two or
more lists has been and would continue to be artificial. They stated
that the purpose of reconciliation is to reset and consider the patient
at transitions of care. Further, they stated that a transition of care
may or may not require reconciliation between two or more autonomous,
overlapping lists. As an example they indicated that they support both
ambulatory and acute care and that a transition from ambulatory to
acute care involves a pruning, adding, and filtering the problem list
from the ambulatory setting to a working problem list in the acute care
setting. They stated that this does not require a demographic match nor
does it involve foreign lists. They stated that if the intent of the
Proposed Rule was to include lists coming from different legal entities
or systems that we should state that it is.
Response. While we understand this commenter's concern, we believe
it is somewhat misdirected. This certification criterion is appropriate
and broadly applicable to a vast majority of EPs, EHs, and CAHs, many
of which will be getting data from multiple sources. Further, this
certification criterion applies to EHR technology as a capability
required for certification and does not prevent the actions described
by the commenter from taking place.
Incorporate Laboratory Tests and Values/Results
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
Incorporate clinical laboratory test results into Certified EHR
Technology as structured data.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(b)(5) (Incorporate laboratory tests and values/results).
------------------------------------------------------------------------
In the Proposed Rule, we noted that, although the HITSC did not
recommend that we revise the ``incorporate laboratory test results''
certification criterion (adopted as part of the 2011 Edition EHR
certification criteria at 45 CFR 170.302(h)), we believed that we
should leverage the significant progress made by the S&I Framework LRI
initiative. We believed that we could achieve this by proposing
revisions to this certification criterion for the ambulatory setting.
We acknowledged that, by requiring ambulatory EHR technology to be
capable of receiving laboratory tests and values/results formatted in
accordance with the HL7 2.5.1 standard and the LRI implementation
guide, it would be significantly easier and more cost effective for
electronic laboratory results interfaces to be set up in an ambulatory
setting (i.e., minimal additional configuration and little to no
additional/custom mapping). Moreover, we stated that it would increase
the likelihood that data would be properly incorporated into ambulatory
EHR technology upon receipt and thus, facilitate the subsequent use of
the data by the EHR technology for other purposes, such as CDS. We
proposed to adopt LOINC[supreg] version 2.38 as the vocabulary
standard, because the LRI specification requires the use of
LOINC[supreg] for laboratory tests. We requested public comment on
whether the proposed standards for the ambulatory setting should also
apply for the inpatient setting and whether the LRI specification (even
though it was developed for an ambulatory setting) could be adopted for
certification of the inpatient setting as well. Besides the proposed
revisions discussed, we also proposed to use the term ``incorporate''
to replace the terms ``attribute,'' ``associate,'' and ``link'' which
were used in the 2011 Edition EHR certification criterion.
[[Page 54225]]
In the Proposed Rule, we acknowledged that the LRI specification
was undergoing HL7 balloting and stated that we intended to continue to
monitor its progress and anticipated that a completed specification
would be available prior to the publication of this rule.
Comments. A few commenters commented on our proposal to specify HL7
2.5.1 as the content exchange standard for the receipt of laboratory
test results. A couple of these commenters recommended that we should
permit HL7 2.3.1 and signal a direction to the market. Another opposed
this requirement because they opposed any meaningful use requirement
that would restrict laboratory results sent in HL7 2.5.1 to count
towards the meaningful use objective this certification criterion
supports. They contended that a vast majority of lab results are in HL7
2.3.1.
A couple of commenters indicated that we had erred in specifying
HL7 2.5.1 because the Laboratory Results Interface (LRI) specification
references both HL7 2.5.1 elements and HL7 2.7.1 elements. Thus a
literal interpretation of what we proposed would create conflicts for
implementers. These commenters suggested that only the LRI
specification should be referenced as the standard. Another commenter
suggested that we clarify that code sets should be used in accordance
with the guidance provided in the LRI specification. One commenter
recommended that we reference a transport standard to transmit
laboratory test results.
Response. As we have stated in other places in this final rule,
just because EHR technology is required to demonstrate certain
capabilities for certification, it does not necessarily mean that those
capabilities must always and only be used to demonstrate MU. Those
policies are established by CMS.
After conducting additional research, we agree with commenters that
we erred in referencing the HL7 2.5.1 standard in addition to the LRI
specification. We have removed the reference to the HL7 2.5.1 standard
in this certification criterion. We also note, for the same reasons we
discussed earlier in this preamble in adopting it for the
``transmission of electronic laboratory tests and values/results to
ambulatory providers'' certification criterion (Sec. 170.314(b)(6)),
we have adopted for this certification criterion the LRI implementation
guide approved as a Draft Standard for Trial Use in July 2012 by HL7.
We clarify that with the exception of the baseline minimum version of
LOINC[supreg] that must be supported by EHR technology, we expect, in
adopting this specification that it will be followed and implemented as
authored. Further, we note that consistent with other certification
criteria that rely on lab test results, we expect that EHR technology
certified to this certification criterion will be able to make
available for subsequent use (such as clinical decision support) the
structured laboratory tests and values/results data received. Because
we have specified a standard by which EHR technology designed for an
ambulatory setting must be capable of receiving lab results, we clarify
that testing and certification for this setting will examine whether
EHR technology can properly extract lab tests results/values and
incorporate the data from the LRI specification for subsequent use. We
have included the term incorporate in this portion of the certification
criterion for clarity. Last, because this certification criterion only
focuses on receipt and not transmission of laboratory orders we decline
to modify this certification criterion in response to the commenter's
recommendation that we reference a transport standard for transmission
of laboratory orders.
With the exception of the change already noted, the only additional
modification we have made in response to public comment was to reinsert
the phrase ``attribute, associate, or link'' in 170.314(b)(5)(iii) to
reflect the 2011 Edition version of this certification criterion due to
the confusion we caused by overloading the term ``incorporate.''
Comments. Commenters supported the adoption of LOINC[supreg] but
expressed concern that LOINC[supreg] is subject to frequent updates and
that the version we adopt in the rule would be quickly out dated.
Response. We refer commenters to our responses later in this
document on our approach to ``minimum standards'' code sets.
Comments. A few commenters suggested that ONC work with CMS to
encourage labs to adopt and use the S&I Framework LRI specification.
They contended that without the ``source systems'' on board that
requiring capabilities on receiving systems (EHR technology) would fall
short of the intended purpose of reducing development time and costs
and improving quality.
Response. We appreciate these comments and will continue to work
with our sister agencies in HHS to advance health IT policy in other
programs and regulations that affect stakeholders that are not eligible
to receive EHR incentive payments.
Comment. A commenter asked that we confirm that ``internal
exchanges'' within an organized health care arrangement (OHCA) (e.g.,
between the OHCA's clinical laboratories and its EHR systems) are not
subject to this certification criterion.
Response. This certification criterion specifies the capabilities
that EHR technology must include in order to be certified. It does not
implicate organizational exchanges.
Comments. Several commenters echoed that the LRI specification
should not be applied for the inpatient setting.
Response. We agree and have not referenced it for the inpatient
setting in the final certification criterion.
Comment. A commenter requested a list of CPT codes that define
imaging studies and a listing of CPT codes that define a laboratory
test.
Response. We received this same comment on the ``transmission of
electronic laboratory tests and values/results to ambulatory
providers'' certification criterion. As with the comment on that
certification criterion, the commenter did not provide any supporting
rationale as to why a list of CPT codes would be relevant to the
capabilities expressed by this certification criterion. Thus, we
decline to provide any additional information.
Comments. A couple of commenters stated that the LRI specification
includes a number of different ``profiles'' that provide options for
users. They added that this approach was taken because the authors of
the LRI specification recognized that not all systems or users would or
should be able to meet a single set of requirements. These commenters
recommended that the profile choice be left to the EHR technology
developer and that we not require all combinations of all profiles to
be required.
Response. We do not intend to specify a particular profile or limit
the use of the LRI specification to only one profile at this time. We
understand that the LRI specification was drafted to create a path
toward more constrained and specific implementations, the most rigorous
being the Base + GU + RU (GU = Globally Unique Identifiers and RU =
Unique Filler or Order Number Required). We intend to move toward this
direction in our future rulemakings. We also seek to clarify for EHR
technology developers that we do not expect the optional portions of
the LRI specification/profile to be tested.
Comment. A commenter asked that we clarify that the certification
criterion only applies to the electronic receipt of
[[Page 54226]]
laboratory results and does not apply to the electronic transmission of
the laboratory test order to the laboratory.
Response. This certification criterion only applies to the
electronic receipt of laboratory tests and does not focus on the
transmission of orders.
Comments. A couple of commenters requested we clarify that because
EHR technology would need to include the capability to display all of
the test report information specified in the CLIA rules at 42 CFR
493.1291(c)(1)-(7) in order to meet this certification criterion, that
doing so with transport standards that provided an acknowledgement back
to the laboratory that the complete message was received as sent would
satisfy the CLIA requirements for the delivery of a laboratory report.
These same commenters touched on a different point and suggested
that because the capability expressed by this certification criterion
required EHR technology to be capable of displaying all of the test
report information specified in the CLIA rules at 42 CFR
493.1291(c)(1)-(7), that such capability should be enabled by default
and must not be capable of being changed, overwritten, or deleted. They
suggested this modification to the certification criterion because
``CLIA mandates that the physician actually view the information.''
Response. As we stated in the S&CC July 2010 Final Rule (75 FR
44608) ``the scope of our authority under this final rule only applies
to capabilities that Certified EHR Technology must include. As a
result, we cannot provide the regulatory relief that these commenters
seek.'' However, we would note that what the commenters have described
could go a long way towards meeting the requirements set forth in 42
CFR 493.1291. We encourage commenters to consult with CMS regarding
particular implementations and questions with CLIA regulatory
compliance. We also note that significant progress has been made to
ensure that Direct Project specifications can be implemented in a CLIA
compliant manner.
With respect to the interpretation provided by the commenters, that
``CLIA mandates that the physician actually view the information,'' we
have consulted with CMS and seek to clarify that this interpretation is
incorrect. The CLIA rules do not specify how results can be viewed by a
provider, just that they can be accurately, timely, confidentially and
reliably transmitted to the final destination. Laboratories need to
verify that this occurred, as well as that the CLIA required elements
were sent, but there is no requirement in the CLIA rules that a
provider must be able to immediately view all of the information. Thus,
we did not modify this certification criterion in response to the
additional requirements suggested by the commenters as they would
artificially lead to design limits that are unnecessary to impose as
part of certification. We do, however, encourage EHR technology
developers to present the laboratory test data in a format that is most
useful to the provider who will use them.
Clinical Quality Measures
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
N/A.
------------------------------------------------------------------------
2014 Edition EHR Certification Criteria
Sec. 170.314(c)(1) (Clinical quality measures--capture and export).
Sec. 170.314(c)(2) (Clinical quality measures--import and calculate).
Sec. 170.314(c)(3) (Clinical quality measures--electronic submission).
------------------------------------------------------------------------
For the 2014 Edition EHR certification criteria, we proposed to
revise previously adopted CQM certification criteria for the ambulatory
and inpatient settings to more explicitly specify the capabilities EHR
technology would need to include. These revisions focused on:
Data capture--the capability of EHR technology to record
the data that would be required in order to calculate CQMs.
Export--the capability of EHR technology to create a data
file that can be incorporated by another EHR technology which could be
used to calculate CQMs.
Calculate--the capability of EHR technology to incorporate
data (from other EHR technology where necessary) and correctly
calculate the result for CQMs.
Report--the capability of EHR technology to create a
standard data file that can be electronically accepted by CMS.
We noted that by explicitly proposing separate CQM certification
criteria focused on these discrete capabilities user experiences
relative to CQMs could be enhanced, the burden of capturing data
elements necessary for CQMs could be reduced, and ultimately, EPs, EHs,
and CAHs would be better positioned to assess in real-time the quality
of care they provide.
Data Capture
We explained in the Proposed Rule that prior to the EHR Incentive
Programs, measure stewards did not routinely or traditionally specify
CQMs with consideration of EHR technology and its capacity to capture
certain data. We further explained how the National Quality Forum
(NQF), under contract with CMS, created the Quality Data Model
(QDM),\21\ which today serves as the information model from which new
CQMs are specified. We explained that because older CQMs were not
specified as ``EHR-ready'' when initially developed, they may
implicitly specify certain data capture requirements that most EHR
technologies cannot perform (or do not perform in any structured way)
as well as constructs that would still require human intervention or
judgment (i.e., ``chart abstraction''). Despite the best efforts to
``re-tool'' older measures for inclusion at the beginning of the EHR
Incentive Programs, we acknowledged in the Proposed Rule that we
understood that the CQMs required for certification as part of the S&CC
July 2010 final rule did not, in some cases, adequately reflect a pure
``EHR-ready'' CQM. We further noted that as a result, EHR technology
developers created new data fields and/or advised their customers to
use specified (and in some cases alternative and atypical) workflows,
templates, or form elements to capture these data in a consistent
manner in order to facilitate CQM calculation.
---------------------------------------------------------------------------
\21\ Quality Data Model--National Quality Forum: http://www.qualityforum.org/Projects/h/QDS_Model/Quality_Data_Model.aspx.
---------------------------------------------------------------------------
In the Proposed Rule, we explained that the CQM lifecycle in the
EHR starts with the determination of data to be captured and the
subsequent capture of clinical or demographic data. Thus, the first
specific capability we proposed for CQM certification (Sec.
170.314(c)(1)(i)) focused on the capability of EHR technology to
electronically record all of the data elements that are represented in
the QDM. More specifically, we stated that EHR technology would need to
be able to record data in some representation that can be associated
with the categories, states, and attributes represented by the QDM. We
provided the following simple example: EHR technology would need to be
able to record a representation of ``Medication active'' or ``Problem
active'' where the first term represents the QDM category and the
second represents the QDM ``state of being.'' We noted that in certain
cases, such as in the prior example with ``Problem active,'' the data
capture necessary is already specified by another certification
criterion proposed for adoption as part of the 2014 Edition EHR
certification criteria (i.e., Sec. 170.314(a)(5) to record active
problems). However, we acknowledged that in other cases an EHR
technology developer would need to review the QDM to ensure the EHR
technology presented for certification captures data elements that are
not
[[Page 54227]]
explicitly required to be recorded in other proposed certification
criteria. We explained that because the QDM is agnostic to health care
settings (e.g., ambulatory and inpatient settings) and all of the CQMs
ultimately adopted by CMS in a final rule would be based on the QDM, we
did not believe that it would be necessary or possible to propose
specific separate ambulatory and inpatient setting certification
requirements as we have with other proposed certification criteria.
Thus, we stated that all EHR technology regardless of the setting for
which it is designed would need to meet Sec. 170.314(c)(1)(i) if it is
presented for certification to this certification criterion.
We recognized in the Proposed Rule that the gap between the data
defined by the QDM and the data traditionally captured in EHR
technology is, in some areas, broad. We requested comments regarding:
(1) Industry readiness for the expansion of EHR technology data
capture; (2) how this would impact system quality, usability, safety,
and workflow; and (3) how long the industry believes it would take to
close this gap. We also acknowledged that some specialty-focused EHR
technologies may not need to capture all of the data that the QDM
describes and requested public comment on how certification could
accommodate specialty EHR technology developers so that they would not
have to take on development work (solely to get certified) for
functionality that their customers may not require. Finally, we
requested public comment with respect to whether we should pursue one
or more of the alternative approaches below for certification in the
final rule and made specific requests for public comment on those
alternatives.
CQM-by-CQM Data Capture: As an alternative to our proposal
on certification for data capture, we considered a data capture
approach that would be based on the data elements reflected in the
individual CQMs selected by CMS instead of the entire QDM.
Explicit Certification Criteria: We recognized that, in
some cases, many EHR technologies already capture data elements
included in the QDM even though they are not explicitly required by an
adopted certification criterion. In these cases, we considered and
believed that it would be clearer (and easier for EHR technology
developers) if we were to either add specific CQM data capture
requirements to already existing certification criteria or adopt new
certification criteria in order to explicitly require the data that is
specified by the QDM to be captured. In other cases, we noted that
despite a measure steward specifying that certain data capture occur,
we are unaware of a consistent or established method with which EHRs
capture certain information. For example, we stated that most EHR
technology of which we are aware does not consistently capture why a
particular medication was not prescribed, nor do they systematically
make a distinction between ``patient reason,'' ``system reason,'' and
``medical reason.''
CQM Exclusions: In cases where a CQM specifies a negation
exclusion,\22\ we proposed that EHR technology would not be required to
capture the ``reason'' justification attribute of any data element in
an encoded way. Rather, we proposed to permit ``reason'' to allow for
free text entries. For calculation and reporting purposes, we proposed
that the presence of text in the ``reason'' field may be used as a
proxy for any ``reason'' attribute.
---------------------------------------------------------------------------
\22\ A negation exclusion or exception is a factor that removes
a given patient from the denominator of a CQM with a statement about
why a given event or intervention did not occur. For example, a CQM
may state that all patients with X condition must have Y
intervention, except patients who did not receive the intervention
for reason Z. A CQM may state that all patients over the age of 6
months should have an influenza vaccine between October and February
(Y intervention), except patients with allergy to egg albumin
(reason Z-1) or patients who decline vaccination (reason Z-2). In
some measures, the unit of analysis is not a patient, but an
encounter or a procedure. In such measures the exclusion or
exception can apply to individual patient factors or factors
affecting the specific unit of analysis. Additionally, exclusions
for ratio measures can also remove a patient from the numerator.
---------------------------------------------------------------------------
Constrain the QDM: Based on our work with CMS and NQF, we
considered the creation of a draft ``style guide'' to constrain the QDM
in a manner that would identify a subset of data types and their
associated attributes that we believe EHR technology could reasonably
be expected to be captured. We noted that measure stewards would then
need to constrain CQMs to reference only data elements that are within
the boundaries of the data types/attribute pairs expressed in the
constrained QDM style guide. We expressed that such CQMs would be
identified as ``2014-EHR-ready'' while other CQMs would not. We stated
that we would subsequently collaborate with CMS to remove CQMs that did
not qualify as ``2014-EHR-ready'' from the EHR Incentive Programs
requirements and, as discussed above, could add certification criteria
in our final rule in order to explicitly define the data types and
attributes that will be necessary for complete CQM data capture
according to the constrained QDM style guide. We believed this option
would serve to align the capabilities of EHR technology with the
expectations of CQMs and would provide a solid path toward an
additional alignment of CQMs with CDS for future stages of the EHR
Incentive Programs. We suggested that CDS could provide the interactive
capability that would be required in order to capture the granular
exclusion data that is expected today by many CQMs. We noted that with
the inclusion of CDS in the clinical quality improvement strategy for
future stages of this program, we expected to be able to remove the
flexibility for the capture of ``reason'' attributes. This would
improve the accuracy of CQMs while retaining optimal clinical workflow
because CDS would ideally be engaged to prompt for this information
only where indicated rather than in all cases.
Explicit Data Capture List: The last approach we
considered was (instead of specifying the QDM) to publish the complete
list of unique data elements that would be required for data capture in
order to be assured that CQMs could be calculated. We explained that
the advantage of this list is that it would provide explicit guidance
to EHR technology developers and could potentially reduce the upfront
work that each individual EHR technology developer would need to do in
order to prepare their EHR technology for certification.
Data Export
In addition to being able to capture data elements for CQMs, we
proposed that EHR technology presented for certification must be able
to export this data in the event that an EP, EH, or CAH chooses to use
a different certified EHR Module to perform the calculation of CQM
results. We included the export capability as part of the certification
criterion proposed at Sec. 170.314(c)(1). We indicated that this
approach would preserve portability and flexibility and offer the EPs,
EHs, and CAHs the option of using regional or national CQM calculation
and/or reporting solutions, such as registries or other types of data
intermediaries that could obtain an EHR Module certification for the
services that they offer. We acknowledged that we were unaware of the
existence of a widely adopted standard to export captured CQM data. We
also proposed that it would be at the EHR technology developer's
discretion to determine the format of the data file that its EHR
technology would be able to produce as well as whether the data would
be exported in aggregate or by individual patients. We recognized that
this
[[Page 54228]]
scenario would not be ideal, but we believed that it could also create
a market in which EHR Modules focused on CQM calculation (and
reporting) could be designed to exploit the disparate data files that
EHR technologies produce. Finally, we requested comment on whether any
standards (e.g., QRDA category I or III, or Consolidated CDA) would be
adequate for CQM data export as well as whether Complete EHRs (that by
definition would include calculation and reporting capabilities) should
be required to be capable of data export.
Import and Calculate
In the S&CC July 2010 final rule (75 FR 44611) and finalized in the
respective certification program rules (75 FR 36170, 76 FR 1276), we
discussed requirements that ONC-Authorized Testing and Certification
Bodies (ONC-ATCBs) and ONC-Authorized Certification Bodies (ONC-ACBs)
must report to ONC the CQMs to which a Complete EHR or EHR Module has
been certified and that ONC-ATCBs and ONC-ACBs must ensure that
Complete EHR and EHR Module developers include on their Web sites and
in all marketing materials, communications statements, and other
assertions related to a Complete EHR or EHR Module's certification the
CQMs to which the Complete EHR or EHR Module was certified. These
requirements can be found at Sec. 170.423(h)(5) and (k)(1)(ii) and
Sec. 170.523(f)(5) and (k)(1)(ii). The posting of this information on
the Certified HIT Products List (CHPL) combined with Complete EHR and
EHR Module developers making this information available in association
with their certified Complete EHRs and EHR Modules provides both
transparency and useful information for potential purchasers (e.g.,
EPs, EHs, and CAHs) that are trying to determine what EHR technology
best meets their needs.
We discussed that we previously adopted at Sec. 170.304(j) the CQM
certification criterion for EHR technology designed for an ambulatory
setting and expressed that it was treated as a threshold. We explained
that, if an EHR technology included all 6 of the core CQMs specified by
CMS and at least 3 other additional CQMs, it could meet the
certification criterion. We noted that if there was an additional CQM
that the EHR technology included, CMS permits the EP to report on that
CQM, even though it was not expressly listed on the CHPL. We also
explained that some EHR technology developers sought certification to
only the 9 CQMs required to meet the threshold, and thus the criterion,
but subsequently communicated to EPs that their EHR technology was
certified for all of the CQMs it included. We noted that other EHR
technology developers took the opposite approach and sought
certification for more than the 9 CQMs and consequently, those EHR
technologies were listed on the CHPL as being certified to more CQMs.
We sought to eliminate this disparity by proposing that EHR
technology presented for certification to Sec. 170.314(c)(2) would
need to be certified to each and every individual CQM for which the EHR
technology developer seeks to indicate its EHR technology is certified.
We believed this approach would provide transparency and greater
certainty regarding the ``certified CQMs'' that EHR technology
includes, given CMS' proposal to only permit EPs, EHs, and CAHs to
report on CQMs with EHR technology that has been certified to capture
and calculate those CQMs.
We proposed a separate certification criterion at Sec.
170.314(c)(2) for the calculation of CQMs in anticipation that, in many
cases, the calculation of CQMs could be performed by an EHR technology
that is different from the one that was certified to capture the CQM
data. For example, the calculation of CQMs could be performed with a
commercial solution or the popHealth tool.\23\ The certification
criterion we proposed included two specific capabilities. The first
capability (Sec. 170.314(c)(2)(i)) would require that EHR technology
presented for certification would need to be able to electronically
incorporate all of the data elements necessary to calculate CQMs for
which it is to be certified. We explained that, for cases where an EHR
technology developer presents an EHR technology for certification that
is also being certified to Sec. 170.314(c)(1) and (3) (i.e., the EHR
technology would be able to do all three capabilities: capture,
calculate, and report), we did not believe that it would be necessary
for an EHR technology to demonstrate its compliance to Sec.
170.314(c)(2)(i). However, we specifically requested public comment on
this assumption before we added this exception to the certification
criterion. In all other cases, an EHR technology would need to meet
Sec. 170.314(c)(2)(i) and (ii).
---------------------------------------------------------------------------
\23\ http://projectpophealth.org/.
---------------------------------------------------------------------------
The second specific capability (Sec. 170.314(c)(2)(ii)) we
proposed focused on an EHR technology's ability to calculate each CQM
for which it is presented for certification. We clarified that if an
EHR technology is presented for certification with test results for 20
CQMs, then the most CQMs that could be included as part of its
certification and listed on the CHPL would be 20. Furthermore, we
emphasized that an ONC-ACB would need to review each of the 20 CQMs for
which the EHR technology is presented for certification and make a
separate determination as to whether the calculation test results for
each CQM are satisfactory and accurate. We expressed our expectation
that EHR technology certified to this criterion would be capable of
accurately, and without errors, calculating CQMs and that the accuracy
of these calculations would be verified through testing. We requested
public comment, especially from measure stewards and EHR technology
developers, on the best way for CQM test data sets to be developed.
Given the separation between capture and calculation, combined with
CMS's policy that only CQMs calculated by CEHRT would count for
attestation and electronic submission, we acknowledged that a scenario
could arise where an EP's, EH's, or CAH's CEHRT (composed of certified
EHR Modules--perhaps from different vendors) could capture more data
than it is certified to calculate. Recognizing that this scenario could
present challenges for providers who possess licenses to such
mismatched certified EHR modules, we requested comment regarding this
scenario and its likelihood and any additional methods we could employ
to mitigate this risk.
Reporting
We proposed a certification criterion at Sec. 170.314(c)(3) to
require EHR technology to enable a user to electronically create for
transmission CQM results in a data file defined by CMS. We noted our
expectation that this capability would require EHR technology to
generate an eXtensible Markup Language (XML) data file with aggregate
CQM calculation results in the format CMS would have the capacity to
accept. We also anticipated that CMS would make available the XML data
file template in time for us to adopt it in our final rule. We believed
that this approach would give EPs, EHs, and CAHs a default solution for
reporting CQMs electronically. We noted that if EPs, EHs, and CAHs
elect to use their CEHRT to pursue an alternative reporting mechanism
permitted by CMS for the EHR Incentive Programs, then it would be the
EP, EH, or CAH's responsibility for ensuring compliance with the
alternative mechanism's requirements.
We organized the comments and responses below using the same
[[Page 54229]]
subheadings we used in the Proposed Rule as well as other more specific
subheadings on particular topics.
Capture
Comments. Many commenters stated that certification to the entire
QDM would place too much of a burden on EHR technology developers,
noting that the QDM includes many data elements not traditionally
captured in the EHR. Many commenters stated that ONC should require
capture of only data elements that are contained within the CQMs that
EHR technology developers chose to implement for calculation via their
technology as opposed to a requirement that EHR technology capture all
of the data elements required for calculation and reporting for all of
the clinical quality measures or the entire QDM. Some commenters also
noted that design and development for capture of the entirety of the
QDM would be a distraction from much needed development of features and
enhancements to existing technology. Many commenters also expressed
concern with the clinical relevance of the entire QDM. Several
commenters suggested ONC require EHR technology to capture to a
constrained QDM as described in our Proposed Rule.
Several commenters noted that the QDM is not intended as a
certification standard, but as an extensible model for discussing the
types of data that are included in quality measures, and that for an
EHR to be usable, each of these pieces of information would need to be
captured with appropriate standard terms, at appropriate points in the
appropriate user's workflow. These commenters also stated that the
scope of the work to be done to capture all of the data elements
envisioned in the QDM is ``enormous.'' One commenter compared the
capabilities of EHR software today against 2,100 of the category and
attribute combinations in the QDM, and found that only 400 of the 2,100
were always or usually captured in EHR workflows. More than half were
never captured in EHR workflows. This commenter suggested that we
publish a list of all data elements required for the CQMs included in
the Stage 2 final rule rather than reference the QDM.
One commenter suggested that ONC work to constrain the QDM by
aligning parts of the QDM with ``core'' and ``optional'' CQMs.
Some commenters suggested that EHR technology be required to
capture all data elements that are components of the EHR Incentive
Programs CQM measure set.
One commenter suggested that we perform a full assessment of the
data elements and associated attributes that are required by the QDM to
determine if each of these are appropriate and required for CQM
reporting.
Some commenters stated that all EHR technology developers should be
required to certify their EHR technology to all CQM data elements in
the EHR Incentive Programs measure set to ensure that EPs, EHs and CAHs
have the flexibility of selecting appropriate CQMs from the entire set
to avoid situations where EHR technology developers have too much
influence over provider quality improvement measures rather than the
local institutions' quality improvement goals.
One commenter stated that some Stage 1 CQMs require a level of
clinical documentation and the capture of data that are far more
extensive than the 2011 Edition EHR certification requirements and are
not necessarily in common use. Furthermore, this commenter stated that
some data for the inpatient measures comes from documentation that may
be contained in written or dictated notes in the EHR and therefore not
available in encoded form.
A commenter stated that is critical that EHR systems support the
collection of data from all sources, including from patients, nurses,
other providers, and other systems and that quality measurement should
not be dependent on the direct entry of data by EPs.
Response. We agree that capture of the entirety of the QDM as a
requirement for certification is not appropriate, and we know of no
systematic constraints to the QDM, including a distinction between
``core'' and ``optional'' measures that would meet the needs of our
certification program for 2014. Yet, we are optimistic that a future
version of the QDM may provide guidance for CQM developers on the
feasibility of certain elements or element types for EHR technology. We
may therefore incorporate the QDM and a QDM ``style guide'' in future
rulemaking. We do not believe that it is appropriate for all EHR
technology developers to have to seek certification for their EHR
technology to all of the data elements necessary for all CQMs included
in the Stage 2 final rule. We understand that there exist many EHR
technologies that have been developed for specialty markets such as
chiropractics, dentistry, ophthalmology, and wound care. Some CQMs are
not relevant to the providers in these specialties and are therefore
unnecessary to be built into the systems that they purchase. Such a
requirement would cause these EHR technology developers to divert
development resources away from the features and functionality that
these providers need in future releases to functionality that would be
present only for certification--and would never be used. It is our
intent that this program aligns the functionality of CEHRT with the
true clinical needs of EPs, EHs, and CAHs and, by extension, their
patients. We agree that EHR technology developer selection of measures
may impact the options available to providers, and we encourage the
developers of EHR technology submitted for certification to present the
broadest range of measures for certification possible, in order for
EPs, EHs, and CAHs to have as much flexibility as possible in selecting
measures for reporting under the EHR Incentive Programs. If EHR
technology developers create sufficient functionality to meet EP, EH,
and CAH needs in the future, we will not need to mandate an expansive
requirement (such as a requirement to certify EHR technology for all
CQMs selected for the EHR Incentive Programs) in subsequent rulemaking.
We will therefore require EHR technology submitted for
certification to Sec. 170.314(c)(1)(i) to be capable of capturing the
data elements specified in the standard adopted at Sec. 170.204(c)
(Data Element Catalog) \24\ as required for each and every CQM for
which the technology is to be certified (the ``CQM-by-CQM Data
Capture'' option discussed in our Proposed Rule (77 FR 13851)). For
example, if EHR technology developer XYZ is seeking to certify their
EHR technology for CQMs 1 through 10, 13, 15 and 22, then the EHR
technology developer will need to review the list of data elements in
the standard adopted at Sec. 170.204(c) for each of these CQMs and
demonstrate that each of these data elements can be captured by the EHR
technology. Also included in the standard adopted at Sec. 170.204(c)
is a list of ``supplemental'' data elements required for CQM data
submission to CMS. The list of supplemental data elements will be
required for capture and transmission in each and every CQM report and
includes (but is not limited to) race, ethnicity, sex, payer, Medicare
HIC number, and where appropriate, NPI, CCN and TIN.
---------------------------------------------------------------------------
\24\ http://www.nlm.nih.gov/healthit/dec/.
---------------------------------------------------------------------------
We selected this option for several reasons. First, as noted above,
there was strong support for this option in response to the Proposed
Rule. Second, this option provides flexibility for EHR technology
developers because it allows them to clearly understand the necessary
data elements required to be captured for their customers (based on the
CQMs for which they intend to seek
[[Page 54230]]
certification) rather than the entirety of the QDM. This is a
significant improvement from our 2011 Edition CQM certification
criteria, and will, in combination with a publicly available value set
repository that the National Library of Medicine will release, assist
EHR technology developers in meeting the requirements of CQM reporting.
We believe that many of the historical problems with CQM reporting were
due to the absence of accurate and complete data capture. A provider
cannot accurately report on data from EHR technology that was not
captured by EHR technology. With specific guidance and defining of the
data that will be required for each CQM, we are now providing the
foundation on which more accurate and reliable CQM reporting can be
based. The supplemental data elements mentioned above are required by
CMS, and will be important for the accurate processing, stratification,
and assignment of CQM reports.
EPs, EHs, and CAHs may employ many methods to capture the
information required by CQMs and we do not intend for this criterion to
imply that technology submitted for certification would be required to
demonstrate manual data entry through a user interface (such as form
fields or templates). Rather, the technology must be capable of
capturing the information in some manner, and this includes information
transferred from other systems (such as a practice management system,
PHR, portal or kiosk).
We appreciate the comments on the CQM measure set from the Stage 1
Final Rule. Some EHR technology certified to the 2011 Edition EHR
certification criteria do not capture all data elements of these CQMs
as structured data, and we note that this was not explicitly required
for 2011 certification. This will be required for 2014 certification,
as described above.
CQM Exclusions
Comments. One commenter stated that only exclusions that are
clinically meaningful to ongoing care of the patient, for example, an
allergy or drug intolerance should be required for CQMs in order to
reduce the burden on documentation. Other commenters stated that
negation rationales, exclusions and exceptions, should be minimized and
be clinically relevant. Multiple commenters also suggested that
negation rationales should not allow any free text submissions by
providers, because free text would be very difficult to codify, use for
decision support, or normalize or perform analytics.
Many commenters expressed support for linking CQM and CDS to
improve the quality of care and patient outcomes. Some commenters
expressed concern that the linkage of CDS to CQM would lead to alert
fatigue and if a 1:1 CQM:CDS intervention was required and that would
be a burden to both developers and users of EHR technology. Commenters
also expressed concern that our Proposed Rule does not include criteria
for ``linking'' or ``relating'' CDS and CQM.
Response. We appreciate the comments on our proposal regarding CQM
exclusions. We agree that all data elements needed for CQM calculation
should be discrete and codified. We don't believe that exclusions and
exceptions must be captured to the granular level of detail described
by a CQM that was developed for manual chart abstraction, but agree
that where this granular data is available in coded form, it can and
should be employed. In light of these comments, we will not require
free text, but will permit that free text be captured and made
available in addition to a codified entry. Codified entries may include
specific terms as defined by each CQM, or may include codified
expressions of the three global concepts: ``patient reason,'' ``system
reason'' or ``medical reason.'' In addition, we appreciate the comments
regarding linkage of CDS to CQM, and agree that this should not be an
explicit requirement for 2014 certification, as we have not formally
defined how CDS and CQM should be ``linked'' or how this would be
tested. We do not intend to require a 1:1 requirement of CDS
interventions to CQM. Rather, we suggest that EHR technology developers
incorporate CDS interventions for the clinical areas in which they have
selected to submit CQMs for certification. For example, if an EHR
technology developer has selected to seek certification for NQF 0028
``Preventive Care and Screening: Tobacco Use: Screening and Cessation
Intervention,'' then we would recommend that they incorporate CDS that
would enable their customers to assess their patients' smoking status
and facilitate the documentation of smoking cessation interventions.
Data Export
Comments. Several commenters supported standardized patient level
data export capability as a certification criterion. A few commenters
stated concern regarding the use of QRDA category I as an export
standard noting that requiring a separate export format to support
clinical quality measurement is an extra step in quality improvement
with ``little value added'' that increases maintenance costs and
represents an additional potential point of failure. One commenter also
noted that many EHRs are, in fact, particularly highly modularized in
the inpatient setting, noting that it is rare for a single module to
include all the data necessary for calculation. Others noted that QRDA
Category I standard is too narrow in focus to support calculation and
analytics because not all of the data elements that would be required
for calculation are included in a QRDA Category I report. A few
commenters encouraged investigation to determine the feasibility of
using the Consolidated CDA or other applicable standard to support the
required export.
Several commenters stated they did not believe that ``complete
EHRs,'' which can calculate CQMs, should be required to support data
export and that patient-level data export, should be optional.
Other commenters argued in support of this requirement, and one
noted that there would be value in a ``simple and standardized CQM data
export format.'' One commenter expressed support for our approach to
CQM export and believes that this approach ``will support both the
development of certification standards for all CQMs and encourage
interoperability among systems.''
Response. We appreciate the comments on export of clinical quality
data, and after careful review of these comments, we have decided to
require this functionality for certification at Sec.
170.314(c)(1)(ii). As stated in our Proposed Rule, for many care
delivery settings, CQM calculation and reporting may occur through the
use of different EHR technologies from those used to capture data. For
example, certified EHR Module 1 may be part of an EH's EHR
technology that meets the Base EHR definition, but the EH may use
certified EHR Module 2 to perform the analytics needed for CQM
calculation and reporting. By requiring that all EHR technology
presented for certification capture CQM data and also export the data,
we believe EPs, EHs, and CAHs will be provided the flexibility to use
separate EHR Modules for calculation and/or reporting, even if they
have purchased or licensed an integrated solution.
We believe this approach preserves portability and flexibility and
offers the EPs, EHs, and CAHs the option of using regional or national
CQM calculation and/or reporting solutions, such as registries or other
types of data intermediaries that could obtain modular certification
for the services
[[Page 54231]]
that they offer. We requested comment regarding the appropriate data
standard for this export functionality, and at the time of publication
of our Proposed Rule, the HL7 QRDA Category I standard had not yet been
successfully balloted. Several commenters noted that it was at that
time too immature for inclusion in our regulation. QRDA Category I has
now been successfully balloted through HL7, has been selected by CMS as
an accepted form of quality data reporting, and will therefore be
required for certification to Sec. 170.314(c)(1)(ii). We disagree that
this criterion or this standard format provide little ``value added.''
Indeed, this standard provides, for the first time--a method of moving
a ``snapshot'' of patient data from one EHR technology to another
without loss of semantic integrity. We anticipate that there may be
opportunities for this model to be of value beyond quality measurement
in the future--such as in the domain of clinical decision support
services.
Import and Calculate
Comments. Many commenters supported certification of incorporation
and calculation capabilities to each CQM. One commenter noted that some
EHR technology developer products have been certified for CQMs with
very light testing requirements and that the certification process for
EHRs did not include testing the accuracy of the embedded measure
calculations, nor did it examine whether the needed data were, in fact,
available in the EHR. Several commenters described frustration with the
lack of testing devoted to CQMs under the temporary certification
program. One commenter expressed concern about errors encountered in
measures that have been transcribed from paper abstraction to e-
specification. This commenter noted that the original measure developer
specified measures for non-EHR use and in many cases did not e-specify
the measures for EHR-use and that subsequent changes in measures occur
with e-specification. This commenter called for a process to ensure
comparable data calculations across EHR technology developers and
hospitals and a systematic process to ensure these changes are broadly
communicated and systematically incorporated. Multiple commenters
suggested methods for the field testing of new measures. One commenter
noted that there was minimal feasibility testing of CQM measure
specifications for the Stage 1 CQMs.
Response. We appreciate the comments on CQM calculation and
testing. Through the rulemaking comment period and via additional
channels, we have become aware of challenges that providers have faced
in the use of technology certified under our 2011 Edition EHR
certification criterion. Our proposed changes were intended to rectify
these concerns. Notably, we have modified our proposal for Sec.
170.314(c)(2) to finalize a more specific and clear certification
requirement that EHR technology be able to import a QRDA category I
file that has been generated by the ``export'' capability in Sec.
170.314(c)(1)(ii) specified above. Unlike for the 2011 Edition EHR
certification criteria for CQMs, EHR technology will be tested and
certified for conformance with this capability. As we noted in the
Proposed Rule, we now seek to provide express guidance to ONC-ACBs that
when an EHR technology is presented for certification and includes
capabilities to meet all three CQM certification criteria (i.e., the
certification criteria adopted at Sec. 170.314(c)(1), (2), and (3))
that the capability to ``import'' as specified in Sec.
170.314(c)(2)(i) will not need to be assessed. Given that the CQM
capabilities within the EHR technology are in essence ``self-
contained,'' we believe that it is unnecessary to require EHR
technology to be able to import data from itself. EHR technology that
is eligible for this treatment would still have to meet all of the
other specific capabilities required by all three of the CQM
certification criteria. Finally, consistent with other terminology
changes we have made, we changed the term ``incorporate'' to ``import''
in this certification criterion to provide more clarity regarding the
action that is required to be demonstrated for certification. Note that
in our discussion of Sec. 170.314(c)(1) (Clinical quality measures--
capture and export), we did not require that all data be directly
entered through a user interface. Some data may flow into EHR
technology through other means. These functions are not required for
certification, nor will they be tested as part of the certification
process.
We appreciate the comments on e-specification of chart-abstracted
measures, but note that many comments about the selection, content, and
management of the CQMs are beyond the scope of this final rule. We
appreciate the value of reliability and validity testing for CQM
technical specifications and support testing of CQMs prior to public
release. CMS is responsible for CQM testing and we defer to their
comments on this subject in their Final Rule that is published
elsewhere in this issue of the Federal Register. We also appreciate the
many comments in reference to feasibility testing. Feasibility testing
in preparation for Stage 2 of MU has been enhanced in order to minimize
variation and post-specification modifications to electronically
specified CQMs.
Electronic Submission
Comments. Commenters were supportive of our proposal. One commenter
suggested that the XML file format should be a valid standard that has
been tested for accuracy and completeness. Another commenter expressed
agreement with the use of aggregate XML and recommend that the
technical structure align with 2011 Physician Quality Reporting System
registry reporting. One commenter suggested that we employ the Core
Measure XML and particularly The Joint Commission's ``HCD'' XML.
Response. We referred to this capability as ``reporting'' in the
Proposed Rule, but now refer to this capability as ``electronic
submission'' in this final rule and in regulation. This renaming more
accurately reflects the required capability, which is the ability to
create a file in a particular format and be capable of submitting that
file to CMS in a manner that CMS is able to accept. We appreciate the
supportive comments regarding a standard XML format and aggregate
reporting methods. In order to provide CQM file submission flexibility
for EPs, EHs and CAHs, CMS intends to offer several reporting methods
from which providers will choose, as described in the Stage 2 final
rule published elsewhere in this issue of the Federal Register and is
considering other mechanisms/methods that could be implemented or
relied upon in the future. In this regard, we believe that EHR
technology should be capable of creating CQM data files that would
support the forms of electronic submission that CMS makes available to
EPs, EHs, and CAHs. Therefore, we have adopted both the HL7 QRDA
Category I standard to support a patient level data submission approach
and HL7 QRDA Category III to support an aggregate level data submission
approach.
As noted above, we proposed that the electronic submission
capability would require EHR technology to generate an (XML) data file
with aggregate CQM calculation results in the format CMS would have the
capacity to accept. CMS has since specified that the optimal XML format
for aggregate reporting will be the HL7 QRDA Category III. CMS has also
made a policy decision to provide an option for patient-level
reporting. CMS has specified that the optimal XML format for patient-
level reporting will be
[[Page 54232]]
the HL7 QRDA Category I. Although these standards were in development
at the time of our Proposed Rule, QRDA Category I has now been balloted
through HL7, and QRDA Category III is much more complete than it was at
the time of the Proposed Rule, with balloting scheduled in the near
future. We understand that the timing of the QRDA Category III
balloting is suboptimal, but note that the alternative would have been
for CMS to develop its own XML specification for a format that performs
precisely the same functionality as QRDA Category III. This would have
been redundant of the QRDA Category III effort and could have adversely
affected its progress. We also note that the patient-level reporting
standard (QRDA Category I) is the same standard as the standard we have
adopted for the ``export'' capability in Sec. 170.314(c)(1).
Therefore, we anticipate that the burden on EHR technology developers
that also submit EHR technology for certification to this certification
criterion will be minimal.
In general, we expect that providers who choose to submit aggregate
reports will use the standard specified at Sec. 170.205(k) (HL7 QRDA
Category III), and providers who choose to submit patient-level reports
will use the standard specified at Sec. 170.205(h) (HL7 QRDA Category
I). We require that EHR technology, regardless of the setting
(inpatient or ambulatory) for which it was designed, be certified to
produce CQM data that could be submitted by an EP, EH, or CAH according
to either standard. While the HL7 QRDA Category III standard has not
yet been successfully balloted, we expect it to become a normative
standard in the near future. Further, we agree with and support CMS's
decision to select this format rather than developing its own CMS-
defined XML template because QRDA Category III is a product of several
years of industry consensus work. EHR technology presented for
certification will therefore need to be certified as being capable of
creating results for transmission to CMS according to both reporting
standards (Sec. 170.205(h) (HL7 QRDA Category I)) and Sec. 170.205(k)
(HL7 QRDA Category III)).
We note for readers that we have modified this certification
criterion to more explicitly address the fact that CMS must be able to
receive an electronic data file created by EHR technology and submitted
by an EP, EH, or CAH. If this could not occur then, arguably, the most
important aspect of what certification was intended to support would go
unmet. Accordingly, we have added to this certification criterion, not
only that EHR technology be able generate both QRDA Category I and QRDA
Category III data files, but that such files can also be electronically
accepted by CMS. This explicit requirement creates two benefits while
also reducing regulatory burden due to CMS' intended programmatic
alignment efforts. It benefits providers and CMS in that each will know
as a result of certification that when EHR technology is used to
electronically submit a QRDA Category I or III that CMS will be able to
receive it. With respect to testing, we expect to approve a test
procedure for this certification criterion that will assess an EHR
technology's ability to create data files conformant to the QRDA
Category I and III standards, and upon a positive conformance
assessment, verify that these data files could be accepted by CMS. If
the data files were conformant and verified by the accredited testing
laboratory in terms of their ability to be accepted by CMS, then the
EHR technology would have fully demonstrated compliance with this
certification criterion.
Auditable Events and Tamper-Resistance; and Audit
Report(s)
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
Protect electronic health information created or maintained by the
Certified EHR Technology through the implementation of appropriate
technical capabilities.
------------------------------------------------------------------------
2014 Edition EHR Certification Criteria
Sec. 170.314(d)(2) (Auditable events and tamper-resistance).
Sec. 170.314(d)(3) (Audit report(s)).
------------------------------------------------------------------------
We proposed two revised certification criteria at Sec.
170.314(d)(2) and (3)--one focused on the capability to record
auditable events and another focused on the capability to create audit
reports--in place of the single 2011 Edition EHR certification
criterion for audit logs adopted at Sec. 170.302(r). We also proposed
to move the specific capability ``detection'' from the integrity
certification criterion (Sec. 170.302(s)(3)) to the proposed auditable
events and tamper-resistance certification criterion. We made these
proposals based on HITSC recommendations as well as stakeholder
feedback that indicated splitting the 2011 Edition certification
criterion into two separate certification criteria would permit a wider
variety of EHR technologies to be certified as EHR Modules. We also
expanded upon the scope of the HITSC's recommendation to address input
from the HHS Office of Inspector General (May 2011 report \25\) and to
reflect our general belief that a more stringent certification policy
for audit logs will ultimately assist EPs, EHs, and CAHs to better
detect and investigate breaches. The proposed expansion included the
specific capabilities that the audit log must be enabled by default
(i.e., turned on), immutable (i.e., unable to be changed, overwritten,
or deleted), and able to record not only which action(s) occurred, but
more specifically the electronic health information to which the action
applies. The proposed certification criterion would also require that
the ability to enable and disable the recording of actions be limited
to an identified set of users (e.g., system administrator). Further, to
accommodate these changes, we proposed a revised standard at Sec.
170.210(e) and proposed to require that: (1) When the audit log is
enabled or disabled, the date and time (in accordance with the standard
specified at Sec. 170.210(g) (synchronized clocks)), user
identification, and the action(s) that occurred must be recorded; and
(2) as applicable, when encryption for end-user devices managed by EHR
technology is enabled or disabled, the date and time (in accordance
with the standard specified at Sec. 170.210(g) (synchronized clocks)),
user identification, and the actions that occurred must be recorded.
Finally, we acknowledged, as recommended by the HITSC, that an example
standard that could be followed in designing EHR technology to meet
these certification criteria could include, but is not limited to ASTM
E2147-01, Standard Specification for Audit and Disclosure Logs for Use
in Health Information Systems.
---------------------------------------------------------------------------
\25\ http://oig.hhs.gov/oas/reports/other/180930160.pdf.
---------------------------------------------------------------------------
General Comment Summary. Many commenters generally supported the
more detailed certification criteria and the standards we proposed.
Comments on the two certification criteria and standards we proposed
focused on a number of different dimensions. The following comment
summaries and responses address each of these dimensions.
Comments. Many commenters requested clarifications related to the
proposed certification criterion's first specific capability--that the
auditable events capability be ``enabled by default.'' Many commenters
noted that our proposal essentially skipped a step from an
implementation perspective. They contended that the certification
criterion should include, make reference to, or that we should make
clear that the certification criterion did not prohibit the audit
recording capability or service from being be subject to some type of
initial configuration. Further they stated that once initial
configuration was
[[Page 54233]]
complete the audit log could be ``enabled by default.'' Another
commenter stated that audit logs should not be enabled by default by
EHR technology developers because the decision of whether settings in
the software are enabled or disabled are the responsibility of each
organization, not the EHR technology developer. Additionally, this
commenter and others indicated that EHR technology developers cannot
enable the audit logs of organizations that already have this
capability in use.
Response. We understand the concerns raised by commenters and seek
to clarify this proposal as follows. It appears that by including the
parenthetical ``(i.e., turned on)'' that we confused many commenters
because, as they noted, steps needed to occur before the auditing
service could actually be ``turned on.'' We acknowledge that 2014
Edition EHR technology will need to be setup and configured at each
practice or hospital in which EHR technology with this capability is
installed. This certification criterion is not meant to prohibit such
configuration. Rather, what this certification criterion expresses (and
what we have made clear in modifications to the certification
criterion) is that in order for the EHR technology to be certified it
must be set by default to record the actions and information specified
in the standards referenced by the certification criterion. Thus, this
part of the certification criterion is meant to ensure that at the
point of installation or upgrade EHR technology certified to this 2014
Edition EHR certification criterion, the EHR technology will be set by
default for an EP, EH, or CAH to record the actions and information
specified in the standards referenced by the certification criterion.
Comments. Commenters also expressed a set of concerns with respect
to another element included in the proposed certification criterion's
first specific capability--that only a limited set of identified users
be permitted to be disable (and re-enable) the capability to record
auditable events. Some commenters, typically EHR technology developers,
referenced that some EHR technologies do not include any capability at
all for users to change (enable/disable) auditable event recording. As
such, these commenters stated that the final rule should accommodate
this approach with respect to certification. Further, commenters agreed
that if auditable events can be disabled, that it only be able to be
done so by a limited set of users. Echoing that this provided
separation of duties, so that a user who is able to access or make
changes to a patient's health information is not also able to modify
the audit log to remove traces of suspicious activity. One commenter
stated that since EHR technology cannot interpret the meaning of
``limited,'' that we should change the wording to `` * * * by
authorized users.'' Another commenter noted that it may be necessary to
turn off the auditable events capability for performance, patching, or
other events.
Response. In response to comments, we have modified the
certification criterion to make the accommodations requested. As noted
by at least one commenter, the practice indicated by others to never
permit anyone to be able to disable an audit log is not uniformly
applied in EHR technology. Therefore, we have reframed and reordered
the specific capabilities within the certification criterion. As a
general rule, the certification criterion identifies the actions and
statuses that EHR technology must be able to record. The actions
related to electronic health information are listed first; the change
in audit log status second; and the change in encryption status of
electronic health information locally stored by EHR technology on end-
user devices third. With respect to the latter two (the two status
oriented requirements), we have included conditional statements as
requested by commenters to permit EHR technology to meet this
certification criterion if the EHR technology developer can demonstrate
that no user has the ability to change those statuses. Further, we have
reworded and moved to the third specific capability within this
certification criterion the separation of duties aspect that many
commenters endorsed. This modified requirement specifies that if EHR
technology permits the recording of auditable actions or statuses to be
disabled the ability to do so must be restricted to a limited set of
identified users. We decline to modify this certification criterion in
response to the commenter's suggestion to change the wording related to
``limited'' set of identified users because the commenter has
misinterpreted the requirement that the certification criterion
specifies. EHR technology does not have to interpret the meaning of
``limited.'' Rather, to meet this certification criterion, EHR
technology would need to include a capability that allows only a
limited set of identified users (by the EP, EH, or CAH) to be have the
privileges necessary to change when auditing is enabled or disabled. In
general, we do not expect and would discourage any general EHR
technology user from being permitted to perform such actions.
Comments. Some commenters requested clarification on the meaning of
``as applicable'' in the ``auditable events'' certification criterion
and accompanying standard with respect to auditing the encryption
status of end-user devices managed by EHR technology. Consistent with
other comments provided in terms of the capabilities within the scope
of an EHR technology's control, commenters noted that ``as applicable''
in this context should be if an EHR technology developer supplied the
end-user device and if the sole purpose of the device is to use the EHR
technology. In other words, tracking the enabling and disabling of
encryption on health care providers' personal devices (such as smart
phones) should not apply.
Response. The phrase ``as applicable'' was originally intended (in
this proposed certification criterion and standard) to accommodate
situations where the EHR technology did not locally store electronic
health information on any end-user devices. In general, we agree with
commenters that tracking the enabling and disabling of encryption on
health care providers personal devices would not apply, because the
primary certification criterion implicated by this requirement
(170.314(d)(7)) is not applicable to all end-user devices. However, we
note for commenters that this situation is fact dependent and could
apply to the health care provider's personal device if EHR technology
is run on the device and locally stores electronic health information
on the device after use has stopped. Consistent with the changes
discussed in our responses above, we believe the certification
criterion has been clarified. Further we have removed the phrase ``as
applicable'' in the standard listed at 170.210(e) in favor of more
plain language usage in the certification criterion itself.
Comments. Several comments applied to the standards we proposed to
adopt and associate with the proposed ``auditable events''
certification criterion. Consistent with other comments summarized
above, commenters asked that we accommodate situations where EHR
technology does not allow for an audit log to be disabled or when it
does not permit the encryption of electronic health information managed
by EHR technology on end-user devices to be disabled. Other commenters
suggested that we rely on SDO standards compared to the enumerated
requirements we specified in the proposed standard at 170.210(e). They
reasoned that an SDO standard has undergone much more extensive review
[[Page 54234]]
and socialization than the list of requirements embedded in the
proposal and that an SDO standard is much more broadly adopted than a
``standard'' embedded in a regulation, and therefore more likely to
take on uniform interpretation. Along those lines, they suggested that
the ASTM E2147 standard we referenced in the proposed rule would be
preferred over enumerating a list of requirements embedded in
regulation. One commenter further suggested that a variety of HL7 and
ASTM standards be referenced by this certification criterion to denote
information objectives, actions, structural roles, participation
function codes with security permissions, and data types to encode user
identification. Another commenter asked that we clarify if the part of
the ASTM E2147-01 standard that deals with disclosures has
applicability to this certification criterion. One commenter suggested
that we clarify that audit logging requires at a minimum date, time,
and user id to determine who accessed certain electronic health
information. With limited exceptions, commenters generally supported
the adoption and application of the clock synchronization standards we
had proposed.
Response. As discussed in the responses directly above related to
changes already made to the certification criterion, we do not believe
that it would be necessary or appropriate to include the conditional
language suggested by commenters in the standards (and have since
removed it from what we proposed). We agree with commenters that we
should leverage SDO produced standards wherever possible and not embed
an enumerated list in regulation. Accordingly, and as suggested by
commenters, we analyzed ASTM E2147-01(2009) and believe that it
includes an equivalent set of requirements as we proposed. Thus, the
standards we express now refer to the appropriate sections of ASTM
E2147-01(2009), rather than an enumerated list. For the first specific
capability related to actions involving electronic health information,
we have required that the data elements specified in sections 7.2
through 7.4, 7.6, and 7.7 of ASTM E2147-01(2009) be captured. For the
other two specific capabilities related to the status of the audit log
or the encryption status of electronic health information managed by
EHR technology on end-user devices, we have required that the data
elements specified in sections 7.2 and 7.4 of ASTM E2147-01(2009) be
recorded. All three of these standards require that the user ID, date
and time be recorded. We note that not all of the section 7.X parts of
the ASTM E2147-01(2009) standard have been specified as they go beyond
what we proposed to include. Thus, we seek to make clear that only
those sections in section 7 that we have explicitly included in our
standards are the minimum required for certification.
We decline to modify the certification criterion in response to the
commenter's suggestion that we include a variety of standards to denote
information objectives, actions, structural roles, participation
function codes with security permissions, and data types to encode user
identification. We did not propose such specificity, nor did the HITSC
recommend that we include such specificity in the certification
criterion. As we have noted in other responses, certification is a
minimum. Thus, where additional standards exist and can be used to
further improve capabilities for which certification is required, we
encourage EHR technology developers to consider doing so. As requested
by a commenter, we confirm that the ``disclosure log'' section (section
8) of ASTM E2147-01(2009) has no applicability to this particular
requirement.
Last, we are finalizing the changes we discuss in this response as
well as our proposal to adopt the clock synchronization standards we
proposed.
Comments. Numerous commenters requested different clarifications
related to the expected granularity of actions and information to be
recorded. A commenter suggested that the granularity of electronic
health information be limited to the metadata involved in identifying
the patient whose record has been accessed, be sufficient for recording
actions, and that it not require lower level clinical data objects to
be logged if appropriate context of what kinds of information is logged
is otherwise recorded. Another recommended that the certification
criterion be more explicit in describing the level of how the ``action
taken'' should be captured in terms of what was done, the data, and how
it was changed. Yet another suggested that the information logged
should be sufficient to enable a system administrator to identify, for
example, that a specific patient's order that was modified, deleted,
etc., or that a user accessed a patient's medication list. Other
commenters raised concerns about the about the granularity of the
information recorded in the audit log and its potential to include
electronic health information. They contended that requiring this level
of specificity would inappropriately duplicate clinical information in
the audit log and could cause greater security issues. Instead, they
suggested that the type of data acted upon should be the proper scope
of this certification criterion and that implementing this approach
would be more feasible and less costly. Further, these commenters
expressed concern that the certification criterion could be interpreted
to require very granular auditing which would adversely impact system
performance and place undue burden on security auditors who may not be
able to find the information they need. They argued that requiring this
type of very granular auditing may introduce a burden on EHR adopters
because of the amount of disk space required to store these audit logs.
Other commenters stated that the scope of the data recorded should not
be at the same level as a ``history table'' or ``action/event history
table.'' Commenters indicated that the clinical level of detail
included in those tables is appropriate to maintain the wholeness of
clinical documents and data, but not for security audit trails.
Instead, commenters suggested that HHS consider adopting a ``medical
record history and completeness'' objective that is not related to
security auditing.
Response. We appreciate the detail and thoughtfulness of the
comments submitted on this certification criterion. In consideration of
comments received, we agree that further explanation is necessary
related to the scope and granularity of the information expected to be
recorded. Given that we are now referencing relevant sections of ASTM
E2147-01(2009), we believe that this standard reinforces what we would
have said had we maintained our enumerated requirements. Section 7.7 of
ASTM E2147-01(2009) discusses the ``identification of patient data that
is accessed.'' It states that the ``granularity should be specific
enough to clearly determine if data designated by federal or state law
as requiring special confidentiality protection has been accessed.''
And, more to the point, Section 7.7 goes on to state that ``[s]pecific
category of data content, such as demographics, pharmacy data, test
results, and transcribed notes type, should be identified.'' We agree
with commenters and understand the burden and security and privacy
concerns issued as well as the disk space limitations referenced. Thus,
we believe that it is appropriate for actions made to electronic health
information and recorded in the audit log to be identified at a
categorical (or type) level--this is also consistent with the guidance
[[Page 54235]]
included in ASTM E2147-01(2009). For instance, as noted by a commenter,
we believe that the ability of the audit log to record that a user
accessed a patient's medication list would be sufficient for
certification and that the audit log would not have to also record the
specific medication.
Comment. One commenter asked whether we intended for the
certification criterion to require that relevant information be
captured in a manner that supports the forensic reconstruction of the
sequence of changes to a patient's chart or if we intended for the
certification criterion to require that users be provided with on-
demand snapshot views of the patient chart at any point in time with a
highlighted comparison of data which is changed at any given moment.
This commenter preferred the former because it stated that in order to
implement the latter EHR technology developers would need to expend
substantially more effort into the development of user interface
capabilities, which would be used only in rare circumstances.
Response. We intend for the former, as stated by the commenter,
that the actions and information can be captured in a manner that
supports the forensic reconstruction of the sequence of changes to a
patient's chart.
Comments. Commenters almost unanimously focused on the scope of the
proposed certification criterion's third specific capability--that
actions record must not be capable of being changed, overwritten, or
deleted. Commenters' feedback included a range of different opinions.
One commenter noted that this certification criterion should focus on
access and alterations, while being cautious about pursuing attainment
of immutable audit logs and detection of audit logs because the EHR
technology can still be circumvented by select individuals with
malicious intent. Another indicated that there were other techniques
such as using separate hardened audit log technologies and suggested
that this capability be met by proving separation of duty for security
auditors and clinical EHR end users, detection of changes in audit
system configuration to the extent it is allowed by the audit system
for recording, and audit log abilities that may be present in the audit
log solution itself for detecting accesses to the log. The majority of
commenters noted that from a technological perspective there is only so
much that is within the control of the EHR technology. These commenters
sought clarifications in terms of the extent to which EHR technology is
responsible for preventing changes, overwrites or deletions to the
audit log. Several provided similar examples referencing the fact that
users could access a file or database used by the EHR technology
through the operating system on top of which the EHR technology may run
or by directly accessing the database in which the audit information is
stored. In general, all of these commenters requested that we should
limit the scope of this specific capability to make clear that the
audit log should not be able to be changed, overwritten or deleted
through the EHR technology by its users.
Response. We appreciate the detailed responses and examples offered
by commenters. As noted by many commenters, we acknowledge that there
is only so much that is within the control of EHR technology and that
nothing is ever 100% impenetrable. Thus, we have revised this specific
capability within the certification criterion to state that the audit
log must not be capable of being changed, overwritten, or deleted by
the EHR technology. We believe this addition properly scopes the
capability for which certification is required and will address
commenters' concerns. As discussed in other responses, where the EHR
technology permits the auditable actions and statuses to be disabled,
we have required that some form of separation of duty be implemented in
that only a limited set of identified users should be able to modify
audit settings.
Comments. Several commenters expressed concern that the proposed
certification criterion's third specific capability we proposed--that
actions recorded must not be capable of being changed, overwritten, or
deleted--did not permit the deletion of the audit log. Further
commenters stated that this specific capability disallows the purging
of audit logs after the required legal retention period has expired.
They recommend adding ``except when disposing of log information after
a legally defined retention period.'' Another commenter expressed a
similar concern with the implications of an ``immutable'' audit log.
They stated that data may not be kept on the same physical device as it
ages and that data is ``added'' to another device and ``deleted,'' and
thus cannot be ``immutable.'' They also stated that immediate storage
of an audit log on ``write once read many'' (WORM) technology is not
practical in all configurations.
Response. We are uncertain as to what in the Proposed Rule led
commenters to make this interpretation since this certification
criterion focuses on a capability that EHR technology would need to
include. It was not our intention, nor did the certification criterion
specify, that audit logs could not be deleted or purged after a legal
retention period. Such a step would be an organizational policy
decision and not within the scope of certification. Thus, we decline to
make the more detailed suggested modifications. However, to make it
clear that such steps are not prevented by the certification criterion,
we have added to the specific capability related to the audit log's
immutability that the audit log must not be capable of being changed,
overwritten, or deleted by the EHR technology. We believe this addition
properly scopes the capability for which certification is required and
will address commenters' concerns.
Comments. A few commenters indicated that they believed an
inconsistency existed between the proposed certification criterion's
third and fourth specific capabilities. Commenters noted that if the
certification criterion requires that an audit log not be capable of
being changed, overwritten, or deleted that it was unclear why we would
also require EHR technology to detect an alteration to the audit log.
The commenters questioned whether the third specific capability
rendered the fourth capability moot and if the fourth was still
necessary. Last, a commenter requested clarification regarding what
would constitute an alteration of an audit log.
Response. Given the reordering of the specific capabilities within
this certification criterion and the clarification that we made above
regarding the scope of the now finalized fourth specific capability
``(iv)'' (that requires that an audit log not be capable of being
changed, overwritten, or deleted by the EHR technology), we believe
that it is also necessary to clarify the scope of the specific
capability we proposed regarding EHR technology's ability to detect an
alteration to the audit log. This specific capability, which is now
designated as the fifth specific capability ``(v),'' has been revised
to state that ``EHR technology must be able to detect whether the audit
log has been altered.'' We believe that this specific capability
complements the other capability specified at (d)(2)(iv) from a
defense-in-depth perspective. Further, we clarify that this specific
capability requires EHR technology to be able to determine whether
activity outside of its control has in some way altered the audit log
(e.g., that the operating system was exploited to modify the EHR
technology's database). In this respect, the EHR technology will be
able to detect whether its audit log has been corrupted. While this may
not
[[Page 54236]]
be the only approach EHR technology developers can use, we encourage
the use of hashing algorithms specified in FIPS 180-4 (Secure Hash
Standard) to determine whether the audit log has been altered.
Comments. Commenters strongly supported the two certification
criteria we proposed from the single 2011 Edition EHR certification
criterion. Further, a commenter encouraged that testing and
certification for these two certification criteria should be done
independently to allow for separate security audit log technologies to
be presented for certification as EHR Modules. This commenter urged
that there should not be a dependence for an EHR technology developer
of a free standing audit log reporting technology to certify with each
and every source EHR that may send it audit events and data as if a
business partnership were required to do so. In essence the commenter
sought clarification that it was possible for the certification
criterion proposed at 170.314(d)(3) to be certified independently and
on a standalone basis.
Response. Yes, it is possible for EHR technology to be
independently certified to 170.314(d)(3). We proposed two separate
certification criterion for exactly this reason. Previously the 2011
Edition EHR certification criterion required that EHR technology
demonstrate both the recording of auditable events and the report
generation in order to be certified. With this separation EHR
technology can be separately certified to perform these two
capabilities. A stand-alone EHR Module for audit log reporting would
not need to certify with each and every source EHR technology that may
send it auditable events. In order to meet the certification criterion
the EHR technology would need to demonstrate that it could capture the
required data.
Comments. We received only a few comments on the proposed audit
reports certification criterion at 170.314(d)(3). They expressed
support for the proposed certification criterion and one commenter
requested clarification of the expectation for reports generation.
Response. We appreciate commenters' support. We are finalizing the
certification criterion as proposed. This certification criterion
expresses the capability that EHR technology must enable a user to
create an audit report for a specific time period and to sort entries
in the audit log according to each of the elements specified in the
standards at Sec. 170.210(e). Anything beyond that requirement is
beyond the scope of certification and likely depends upon
organizational policy.
End-User Device Encryption
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
Protect electronic health information created or maintained by the
Certified EHR Technology through the implementation of appropriate
technical capabilities.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(d)(7) (End-user device encryption).
------------------------------------------------------------------------
In the Proposed Rule, we proposed to revise the ``general
encryption'' certification criterion adopted at Sec. 170.302(u) as
part of the 2011 Edition EHR certification criteria in favor of a
certification criterion focused on the capability of EHR technology to
encrypt and decrypt electronic health information managed by EHR
technology on end-user devices if such electronic health information
would remain stored on the devices after use of EHR technology on that
device has stopped. We proposed this revised approach because we
thought it would be more practical, effective, and easier to implement
than the otherwise general encryption requirement adopted at Sec.
170.302(u). Further, we agreed with the HITSC that we should focus more
attention on promoting EHR technology to be designed to secure
electronic health information on end-user devices (which are often a
contributing factor to a breach of protected health information \26\).
The OIG provided similar rationale in its May 2011 report (previously
cited under the discussion of the ``auditable events and tamper-
resistance'' and ``audit report(s)'' certification criteria) in which
it recommended that ONC address IT security controls for encrypting
data on mobile devices. The proposed certification criterion was
drafted to permit EHR technology developers to demonstrate in one of
two ways that a Complete EHR or EHR Module is compliant.
---------------------------------------------------------------------------
\26\ http://www.hhs.gov/ocr/privacy/hipaa/administrative/breachnotificationrule/breachrept.pdf.
---------------------------------------------------------------------------
The first proposed way, Sec. 170.314(d)(7)(i), accounted for
circumstances in which EHR technology was designed to manage electronic
health information on end-user devices and on which electronic health
information would remain stored on the end-user devices after use of
the EHR technology on the devices has stopped. We clarified that we
intended for the term ``stopped'' to mean that the session had been
terminated, including the termination of the network connection. We
stated that in these circumstances, EHR technology presented for
certification must be able to encrypt the electronic health information
that remains on end-user devices. And, to comply with paragraph
(d)(7)(i), that this capability must be enabled (i.e., turned on) by
default and only be permitted to be disabled (and re-enabled) by a
limited set of identified users. We did not include ``decrypt'' in the
proposed certification criterion because we determined it was best to
focus certification on the most critical capability, the act of
encryption after use of the EHR technology on the end-user device has
stopped. Last, we explained that the phrase ``manages electronic health
information'' in the certification criterion meant that the EHR
technology was designed in a way that it could exert control over the
electronic health information that remains on an end-user device after
the use of EHR technology on that device has stopped. We stated, for
example, that if an EHR technology was designed to manage a client
application that can be executed on a laptop or tablet, and electronic
health information would remain stored--even in temporary storage--on
that end-user device when a user stops using the client application on
the laptop or tablet, the EHR technology would need to meet the
requirements specified at Sec. 170.314(d)(7)(i) in order to be
certified.
The second proposed way to demonstrate compliance with this
certification criterion was for an EHR technology developer to
demonstrate that its EHR technology could meet Sec. 170.314(d)(7)(ii)
and prove that electronic health information managed by EHR technology
never remains on end-user devices after use of EHR technology on those
devices has stopped. We explained that this alternative method was
important to include because it: (1) Verifies as part of certification
that the EHR technology was, in fact, designed in a way such that it
does not enable electronic health information to remain on end-user
devices after use of EHR technology on those devices has stopped; (2)
provides EHR technology developers a way to demonstrate compliance with
this certification criterion; and (3) it encourages an outcome that is
more secure (i.e., when no electronic health information is permitted
to remain, the potential for a breach is mitigated).
Comments. Many commenters offered their support for this
certification criterion. One applauded the decision to allow the option
to either encrypt end-user devices or make sure no data remains on end
user devices managed by the EHR technology. Several noted that since a
majority of breaches by
[[Page 54237]]
HIPAA covered entities or their business associates have been due to
lost or stolen unencrypted portable media, requiring default encryption
functionality for end-user devices managed by CEHRT should help reduce
health data breaches. Another commenter indicated that this security
measure has largely been ignored and agreed that making encryption a
requirement for EHR certification should help spur industry to protect
data security.
Response. We thank commenters for the positive feedback. As we have
stated elsewhere in this final rule, we believe that certification can
help to ensure that in adopting CEHRT EPs, EHs, and CAHs have technical
capabilities that they can use to enhance their security practices and
make compliance with other regulatory requirements more efficient.
Comments. A few commenters requested clarification of the term
``stopped.'' One suggested that we include ``in the prescribed
manner.'' A second referenced ``prescribed manner'' and stated that
they thought it would be difficult to test that an EHR technology never
leaves electronic health information on an end-user device when it is
terminated in the prescribed or non-prescribed manner. They encouraged
that attestation be permitted for the test procedure. Another suggested
that we consider whether ``stopped'' includes abnormal termination of a
session and a network connection versus normal termination. They
explained that routines that manage temporary storage may only be part
of normal session termination whereas there may be processes to
preserve images or caches for session resumption in the case of an
abnormal termination that could pose risk by persisting health
information in order to prevent data loss when an abnormal interruption
such as battery failure or power outage to the device occurs.
Response. We decline to modify this certification criterion to add
``in a prescribed manner.'' We do not believe that this qualifying
phrase is necessary or adds significant clarity to the proposed
certification criterion. We continue to believe that our general
description of ``stopped'' in the proposed rule (``that the session has
been terminated, including the termination of the network connection'')
is sufficient for this certification criterion. In other words, use of
EHR technology is considered to be stopped when a user closes or exits
the EHR technology application and would need to re-execute the EHR
technology application to again engage in use. However, we acknowledge,
as commenters pointed out, that there could be predictable/prescribed
stops and unpredictable/abnormal stops (i.e., power or battery
failure). For the purposes of certification to this 2014 Edition EHR
certification criterion, we clarify that testing and certification will
focus on normal terminations. We will consider whether more advanced
and rigorous testing and certification requirements for future editions
of certification criteria would be necessary. In the following
responses when we refer to ``stop'' or ``stopped,'' we are referring to
normal stops.
Comments. Numerous commenters requested clarification regarding the
phrase ``managed by'' in the certification criterion. Along those lines
many asked that we clarify the certification criterion's scope and
applicability. Some stated that we should clarify that it only applies
to storage capabilities that are designed for use with EHR technology
developer provided or supported technologies for desktop, laptop,
mobile, cellular based technologies or similar technologies, and not to
capabilities that may be present in technology components such as
operating systems, swap files, and memory management technologies that
are embedded and non-configurable as to their use by the EHR system
(since the EHR technology developer is unable to change those
capabilities). These commenters suggested that this certification
criterion be applied to the deliberate use of storage capabilities that
are configurable or to the management of caching files that the EHR
technology developer, by design, elects to use and manage on such
devices. One commenter asked whether the EHR technology is expected to
enforce encryption or if it must be capable of notifying the receiving
device that the data being downloaded contains electronic health
information and therefore such data must be encrypted.
A few sets of comments on the ``managed by'' concept included
detailed information on two points. The first asked whether we had
intended for the certification criterion to apply only in cases where
the EHR technology has control over the ability of the user to store
data on their device, installs a client application, etc. This
commenter suggested that the language in the certification criterion
may be unclear when it is read in isolation, outside of the preamble.
Further, this commenter noted (as was echoed in a different comment)
that the meaning of the term ``managed by'' was missed by many of its
contributors and that many assumed that the certification criterion
required the EHR technology to enforce encryption on any mobile or
portable device. The second point addressed a technical concern and
limitation. Commenters stated that the operating system or other
technology on the end-user device may cache electronic health
information and retain it after use of the EHR technology on an end
user device has stopped. They indicated that, for example, swap and
cache files, sleep and hibernate features, and application context
switching in Windows 8 Metro apps or iOS may all cause electronic
health information to be cached to disk. Similarly, they stated that
some browsers do not respect ``no-cache'' headers, potentially leading
to electronic health information being cached on the end-user device if
users access the EHR with a non-vendor supported browser. Additionally,
commenters indicated that these instances were beyond the control of
the CEHRT and are subject to user configuration and control to achieve
the desired objective. These commenters requested a reasonable
clarification of the term ``manage'' and stated that it would be
unreasonable to expect EHR technology to control how operating systems
and other technologies perform memory management and that they did not
consider this information to be managed by the EHR technology.
Last, a commenter asked who was responsible for encryption on end-
user devices (e.g., EHR developer, covered entity/business associate,
etc.). They stated that in practice this requirement will affect all
desktops--even home computers--that cache content from web-based EHR
systems. Further, they questioned how this requirement interacted with
the proposal that the encryption capability must only be disabled by a
limited set of identified users.
Response. We appreciate the detailed and thoughtful feedback
provided by commenters. Because all of the comments revolved around the
phrase ``managed by,'' we believe it will be most effective to respond
to the general clarifications up front and then explain the revisions
we have made to this proposed certification criterion. We believe this
approach will be clearer and more efficient with respect to how we
interpret this certification criterion than if we were to individually
address each specific comment within this comment summary.
As noted in the Proposed Rule, we proposed this certification
criterion to focus and encourage EHR technology developers to design
secure implementations and equip EHR technology with the ability to
assist users in keeping end-user devices
[[Page 54238]]
secure. End-user devices can pose a specific vulnerability, especially
as they become more prevalent and computationally powerful.
Given the uniform confusion surrounding the phrase ``managed by,''
we have revised this certification criterion to functionally describe
the event that we had intended to capture with the phrase--the local
storage and persistence of electronic health information on end-user
devices. The general policy we express in this certification criterion
requires EHR technology designed to locally store electronic health
information on end-user devices to encrypt such information after use
of EHR technology on those devices stops. We clarify that in this
context, locally stored electronic health information is intended to
mean the storage actions that EHR technology is programmed to take
(i.e., creation of temp files, cookies, or other types of cache
approaches) and not an individual or isolated user action to save or
export a file to their personal electronic storage media. Similar to
the changes we made to the auditable events certification criterion, we
have clarified that in this scenario, the EHR technology must be set by
default to perform this capability and, unless this configuration
cannot be disabled by any user, the ability to change the configuration
must be restricted to a limited set of identified users. While it may
not ``enforce'' encryption per se, this certification criterion does
require that EHR technology designed in this way be set by default to
encrypt when electronic health information is locally stored on end-
user devices.
We agree with commenters and clarify that this certification
criterion focuses on, and only applies with respect to, the storage
capabilities that are designed for use with EHR technology developer
provided or supported technologies for desktop, laptop, or mobile
technologies (and similar variations of such technologies) (i.e., it is
generally not intended to apply to personally owned end-user devices,
unless an EHR technology developer supported technology is loaded/
installed on such a device). The certification criterion does not apply
with respect to capabilities that may be present in the underlying
technology on which EHR technology may run, but is unable to control
through the EHR software, such as operating systems, swap files, and
memory management technologies that are embedded and non-configurable
by the EHR technology. Thus, these revisions are consistent with the
sentiments issued by commenters that suggested this certification
criterion be applied to the deliberate use of storage capabilities that
are configurable or to the management of caching files that the EHR
technology developer, by design, elects to use and manage on such end-
user devices. We recognize that a spectrum of different implementations
exist and that they may range from a ``thin client,'' \27\ to a viewer
that shows the screen of remote virtual server, to a web browser that
accesses a remote web service, to more traditional client/server
``thick client'' \28\ implementations, and to where EHR technology in
its entirety could run entirely on single a device. On one end of the
spectrum no electronic health information would persist when a user
stops using EHR technology. Toward the other end of the spectrum
electronic health information would always persist when a user stops
using EHR technology. Ultimately, as expressed in the paragraph
(d)(7)(i) of this certification criterion, if the EHR technology
developer designs EHR technology that requires or utilizes locally
stored electronic health information, it is the EHR technology
developer's responsibility to ensure that such information is set to be
encrypted by default in order to meet this certification criterion. We
expect that this capability could be accomplished through a number of
different technical mechanisms, including techniques to ``sandbox''
\29\ and limit the extent to which data can be accessed and used to
only be within a secure session.
---------------------------------------------------------------------------
\27\ In some cases referred to as lean or slim, a thin-client
typically does not perform/provide any computational assignments.
Rather, it serves as a terminal through which a user can access
computational resources on a server.
\28\ Compared to thin-clients, thick-clients typically perform/
provide for computational assignments to be completed on the thick-
client rather than the server, but may also utilize certain
features/resources that a server includes.
\29\ ``Sandbox'' or ``sandboxing'' is typically used to describe
an information security approach that allows programs to run in a
separate and secure environment. Programs run within a sandbox
typically have limited access to certain system resources and may be
restricted from performing certain actions.
---------------------------------------------------------------------------
With respect to paragraph (d)(7)(ii) of this certification
criterion, we have revised the language to acknowledge that despite an
EHR technology developer's best effort to design EHR technology in such
a way (as suggested by our proposal) that electronic health information
never remains, we understand from commenters that such absolutes cannot
always be guaranteed (especially when an EHR technology developer is
unable to modify the functionality a particular web browser or
operating system employs). With this in mind, we have revised this
portion of the certification criterion to state that an EHR technology
developer would not have to demonstrate that its EHR technology can
encrypt electronic health information locally stored on end-users
devices if the EHR technology is designed to prevent electronic health
information from being locally stored on end-user devices after use of
EHR technology on those devices stops. We interpret ``prevent'' to
include, for example, situations where EHR technology is designed to
and would normally disallow electronic health information to be locally
stored on end-user devices after use of EHR technology on those devices
stops, but is run in a browser that does not respect ``no-cache''
headers. In this circumstance, and if shown under normal circumstances
(i.e., running in a browser that does respect ``no-cache'' headers),
the EHR technology could meet paragraph (d)(7)(ii) of this
certification criterion.
Comment. A commenter stated that they considered information that
has been sent to a print queue or downloaded by the user (such as
downloading a PDF report) to no longer be managed by the EHR
technology.
Response. We generally agree with this statement.
Comment. A commenter asked that we clarify whether data at rest on
a server located at a secure data center must be encrypted and, if yes,
to please reconsider this requirement because they believed it would
slow down response times in large cloud-based EHR systems.
Response. As indicated above, this certification criterion does not
focus on server-side or data center hosted EHR technology. We
recognized that these implementations could employ a variety of
different administrative, physical, and technical safeguards, including
hardware enabled security protections that would be significantly more
secure than software oriented capabilities.
Comment. One commenter recommended that disk level encryption,
which is implemented outside of CEHRT, be deemed an acceptable means
through which to fulfill this criterion. They contended that EHR
technology developers should not be forced to create their own
proprietary encryption implementations, when this capability is already
available through other means.
Response. We cannot deem this approach acceptable to fulfill this
certification criterion because it would not be a capability that could
be demonstrated by EHR technology. However, in situations where a user
has implemented disk encryption hardware
[[Page 54239]]
and would be using EHR technology that is designed to save electronic
health information to local storage on end-user devices, the user may,
through a risk analysis, determine that disabling the EHR technology's
encryption capability is prudent since its data will be protected
through the disk encryption hardware.
Comment. A commenter recommended that we discourage the use of or
remove the allowance for 3DES because the algorithm is on track to be
deprecated by NIST in the near future.
Response. We agree with this commenter and encourage EHR technology
developers to use the other encryption algorithms, such as AES, that
are included in FIPS 140-2 Annex A.
Comment. A commenter expressed concern that this certification
criterion would cause financial hardship related to the additional
involvement of copy machines, EKG machines, etc., and stated that
health care practices need to be aware of the cost.
Response. Given our responses above, we do not believe that this
concern is valid.
Comment. In the context of this certification criterion, a
commenter encouraged ONC to evaluate the necessary steps to incorporate
the ability to access a patient's health information during urgent or
emergency situations.
Response. We have considered this comment and do not believe that
any change to the certification criterion is warranted given the
clarifications we have made above.
Comments. A commenter indicated that the proposed certification
criterion could be interpreted to exceed the requirements set forth in
the HIPAA Security Rule, which provides that encryption is addressable
requirement (evaluated as part of a risk assessment), rather than a
required control. They stated that one might infer that the
implementing organization must use this capability if their EHR
technology was required to be certified to it. The commenter suggested
that we clarify any distinction between the HIPAA Security Rule and the
proposed certification criterion. Last, they suggested that if the
encryption of data on connecting devices is truly considered a best
practice, that it seems that it is best first addressed by OCR as a new
required control in the HIPAA Security Rule, which could then be
incorporated into the MU requirements (compared to using the MU
requirements to indicate best practice for a limited set of HIPAA
regulated entities).
Response. This certification criterion applies to EHR technology
and does not supersede or affect the HIPAA Security Rule's requirements
or associated flexibilities. As we have stated in this preamble and
prior rules, we believe that by requiring these capabilities to be part
of an EP, EH, or CAH's CEHRT that it will assist and enable them to
more efficiently comply with security requirements such as the HIPAA
Security Rule. We note that HHS \30\ has issued guidance around
encryption as a possible risk management strategy to address storage of
electronic protected health information.\31\ In addition, HHS has
issued guidance on how to render unsecured protected health information
unusable, unreadable, or indecipherable to unauthorized
individuals.\32\
---------------------------------------------------------------------------
\30\ Please note that CMS originally issued HIPAA Security Rule
guidance.
\31\ http://www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule/remoteuse.pdf.
\32\ http://www.hhs.gov/ocr/privacy/hipaa/administrative/breachnotificationrule/brguidance.html.
---------------------------------------------------------------------------
Immunization Information; and Transmission to Immunization
Registries
------------------------------------------------------------------------
---------------------------------------------------------------------------
MU Objective
Capability to submit electronic data to immunization registries or
immunization information systems except where prohibited, and in
accordance with applicable law and practice.
------------------------------------------------------------------------
2014 Edition EHR Certification Criteria
Sec. 170.314(f)(1) (Immunization information).
Sec. 170.314(f)(2) (Transmission to immunization registries).
------------------------------------------------------------------------
We proposed two certification criteria for immunization registries
that were essentially a split of the 2011 Edition EHR certification
criterion for submission to immunization registries (Sec. 170.302(k)).
We proposed one certification criterion that focused just on the
capabilities to electronically record, change, and access immunization
information (data capture) and another that focused on the capability
to electronically create immunization information for electronic
transmission in accordance with specified standards. We discussed these
two proposed certification criteria together in the Proposed Rule for
simplicity and to prevent confusion, but noted that we did not consider
the certification criterion we proposed to focus on data capture to be
a revised certification criterion. Rather, we stated that we believed
that the certification criterion would constitute an unchanged
certification criterion because all the capabilities included in the
criterion were the same as the capabilities included in the
corresponding 2011 Edition EHR certification criterion (Sec.
170.302(k)). Additionally, for this certification criterion, we
proposed to replace the terms ``retrieve'' and ``modify'' in the
revised criterion with ``access'' and ``change,'' respectively.
For the certification criterion focused on electronically creating
immunization information for electronic transmission, we clarified that
this criterion focuses on the capability of EHR technology to properly
create immunization information for electronic transmission in
accordance with the applicable standards and implementation
specifications. We further emphasized that the criterion does not
address the ability to query and evaluate immunization history from the
immunizations information systems (IIS) to determine a patient's
vaccination need, nor does it address the specific connectivity
requirements that an EP, EH, or CAH would need to establish or meet to
successfully transmit immunization information, as such requirements
are likely to vary from state to state and are outside the scope of
certification. We proposed the use of only the HL7 2.5.1 standard for
formatting immunization information because immunization registries are
rapidly moving to this standard. We also proposed to adopt the HL7
2.5.1 Implementation Guide for Immunization Messaging Release 1.3 as
the implementation specification which provides corrections and
clarifications to Release 1.0 and contains new guidance on how to
message vaccines for children (VFC) eligibility. Finally, we proposed
to adopt the August 15, 2011 version of CVX code sets.
Comments. Commenters supported our proposed ``two certification
criteria approach.'' One commenter noted strong support for ONC's
change in terminology from ``retrieve and modify'' to ``access and
change'' and the clarification that this criterion does not include in
scope the retrieval of immunization data from an external source to the
EHR.
Response. We appreciate the support for the proposed certification
criteria and the change in terminology. We are adopting these
certification criteria as proposed, but with the inclusion of an
updated implementation guide as discussed below.
Comments. Commenters expressed support for moving to only HL7
2.5.1. Commenters stated that requiring all EHR technology developers
to consistently adopt the same standards would promote the access and
use of immunization data and further boost
[[Page 54240]]
interoperability and exchange. A couple of commenters recommended that
HL7 2.3.1 and HL7 2.5.1 both be accepted for certification as part of
the 2014 Edition EHR certification criteria. These commenters also
recommended that HL7 2.5.1 could be required and HL7 2.3.1 could be
optional as a means of allowing a reasonable transition period.
Response. We appreciate the support for the moving solely to HL7
2.5.1. We do not believe that permitting EHR technology to continue to
be certified to HL7 2.3.1 as a means of meeting this certification
criterion promotes improved exchanged and interoperability. Therefore,
we are adopting only HL7 2.5.1 for the ``transmission to immunization
registries'' certification criterion.
Comments. Commenters generally agreed with our proposal to adopt
the HL7 2.5.1 Implementation Guide for Immunization Messaging Release
1.3 as the implementation specifications. One commenter contended that
the implementation guide is vague on several important points regarding
requirements for specific types of data and the circumstances in which
specific data should be sent. The commenter recommended using the HL7
2.3.1 standard for certification because the HL7 2.3.1 Implementation
Guide for Immunization Messaging is more clear on these important
points than the 2.5.1 guide.
Response. We appreciate the support for the implementation guide.
The CDC has worked to clarify ambiguities in Release 1.3 of the
implementation guide and has published a new version of the
implementation guide, Release 1.4, which reflects these clarifications.
In particular, Release 1.4 clarifies the separate usage
responsibilities for senders and receivers, provides conformance
statements identifying core data elements that must be supported based
on the National Vaccine Advisory Committee (NVAC) core data elements,
adds support for messaging Vaccine Information Statement (VIS) data
based on a 3D barcode, and provides HL7 version 2.7.1 usage guidance
that improves clarity for conformance criteria and the requirements for
HL7 message elements. Overall, these revisions do not establish
additional substantive requirements in comparison to Release 1.3.
Rather, the revisions improve the ability to test and certify EHR
technology to the implementation guide and make it easier for EHR
technology developers to implement the guide's requirements based on
the corrections and clarifications. Accordingly, in lieu of adopting
Release 1.3 of the implementation guide as we had proposed, we have
adopted Release 1.4 for the ``transmission to immunization registries''
certification criterion. For the reasons stated above, we are not
adopting HL7 2.3.1.
Comments. One commenter recommended that EPs, EHs and CAHs comply
with the public health agency's local HL7 specifications guide as these
guides describe what data elements are required within the jurisdiction
that may go beyond those described in the CDC HL7 implementation guide.
Conversely, another commenter stated variances at the local public
health agency level in the content and transmission specifications
continue to add challenges and cost to the adoption of immunization
reporting (e.g., additional requirements or proprietary
specifications). The commenter stated these challenges are further
exacerbated by the fact that there are no standard specifications for
the transmission of immunization reports. The commenter urged ONC to
work with the CDC to identify ways to improve the adoption of the CDC
implementation guides (content and transmission specifications) by the
state immunization registries.
Response. Release 1.4 of the implementation guide reduces
variability and standardizes the required data elements across public
health jurisdictions. Release 1.4 also notes a standard format for
states to indicate any variability. The certification criteria do not
address transport standards, as this is left to the receiving public
health authority. However, an expert panel convened by CDC and American
Immunization Registry Association (AIRA) has recommended a SOAP-based
standard for transport of immunization data.
Comments. Commenters stated that at least several states have made
recording a patient's consent decision relative to the disclosure of
immunization data by the provider (or consent to its re-disclosure by
the external agency collecting it) a de facto requirement for
electronic submission of immunization data. Commenters noted that
recording patient consent was not part of the testing and certification
for the 2011 Edition EHR certification criterion, but asked whether
recording a patient's consent will be part of certification to the 2014
Edition EHR certification criteria. Some commenters more specifically
asked whether patient consent would not to be recorded per the PD1-12
Protection Indicator of the referenced implementation guide.
Response. We believe that Release 1.4 of the implementation guide
reduces the variability and standardized the required data elements
across public health jurisdictions, including requirements for consent.
Comments. Commenters expressed support of the continued use of the
CVX code sets and the August 15, 2011 version. Commenters requested
that we specify that the vaccine administered be coded by the CVX and
MVX (where known) as the combination would allow a specific vaccine to
be identified accurately. One commenter recommended that a detailed
review be conducted between ONC, the AIRA, CDC, and selected public and
commercial stakeholders, for the purpose of revising the current CVX
immunization code set to account for a small but significant number of
remaining common discrepancies between data necessary to comprise an
accurate and minimally complete immunization record which remains
unaccounted for in current certified EHR systems. A few commenters
recommended the inclusion of the National Vaccine Advisory Committee
(NVAC) approved Immunization Information System Core Data Elements as
required elements. One commenter noted that these are currently under
review and revision but expected to be in place for 2013. One commenter
requested clarification on what data should be included in immunization
history.
Response. As we required for the 2011 Edition EHR certification
criterion for immunization reporting, we continue to believe that the
adoption of CVX is appropriate and that no other vocabulary standard
need to be expressly adopted for the purposes of certification. We do,
however, appreciate the points raised by commenters and will discuss
them with our colleagues at CDC for consideration in proposals for the
next edition of EHR certification criteria we propose.
Comments. One commenter noted a challenge facing transitioning data
entry immunization registry challenges relating to replacing the
``Vaccines for Children'' inventory tracking and ordering functionality
with EHR functionality.
Response. It is not clear exactly what the commenter was
specifically addressing. The Implementation Guide defines a
standardized way to record and track VFC eligibility. However, it does
not address issues of inventory tracking.
Comments. A commenter expressed concern about specifying a
particular CVX code set in regulation, particularly as the code set has
been updated since the August 15, 2011 version. Commenters recommended
the
[[Page 54241]]
following wording change: ``HL7 2.5.1 and Implementation Guide for
Immunization Messaging Release 1.3, or the most recent version as
published by CDC'' for adoption of the implementation guide in
regulation.
Response. We have established a process for adopting certain
vocabulary standards, including CVX, which permits the use of newer
versions of those standards than the one adopted in regulation. We
refer readers to section IV.B for a discussion of ``minimum standards''
code sets and our new more flexible approach for their use in
certification and upgrading certified Complete EHRs and certified EHR
Modules. Readers should also review Sec. 170.555, which specifies the
certification processes for ``minimum standards'' code sets. In
response to the commenters' suggestion that we permit the use of the
``most recent version'' of the implementation guide for certification,
we refer the commenters to section III.A.5 found earlier in this
preamble. This section explains why we cannot take such an approach. To
note, as discussed above, in lieu of adopting Release 1.3 of the
implementation guide as we had proposed, we have adopted Release 1.4.
Comments. A commenter noted concerns about the meaning of the
language regarding reporting immunizations after receipt of a CCDA. It
should be the responsibility of the EHR transmitting the CCDA to report
the original immunization information. Requiring EHRs to report
immunizations not administered within the context of the EHR may lead
to duplicate results and require additional reconciliation at state
immunization registry level.
Response. We cannot locate the exact language in the Proposed Rule
that would have led this commenter to raise these concerns. The
triggering event for reporting of an immunization is not part of the
certification criteria. Certification focuses on the ability of EHR
technology to properly create immunization information for electronic
transmission according to the adopted standard and implementation
specification.
Comments. One commenter disagreed with the requirement to transmit
data to an immunization registry. The commenter stated that a process
where data is directly entered into a state's certified application
that is provided by the state immunization registry should be
acceptable. The commenter noted that this information is stored
directly in the state's immunization database and then the commenter's
EHR technology hosts the state's immunization application. The
commenter argued that this obviates the need for an interface and does
not put the data at risk. The commenter stated that because of the
inflexibility of the certification requirements, it has had to create a
costly and inefficient interface to send data from its EHR technology
to the state's registry. Therefore, the commenter recommended that
Sec. 170.314(f)(2) be made optional for those institutions that use a
certified module provided by a state registry to directly enter
immunization information as part of their EHR technology.
Response. The purpose of this certification criterion is to support
interoperability between EHR technology and public health. Thus, any
EHR technology that meets the certification requirements can be
utilized to submit data to an Immunization Registry. Again, to meet
this certification criterion, EHR technology must be able to properly
create immunization information for electronic transmission according
to the adopted standard and implementation specification. How this
standardized data created by CEHRT gets to public health is not within
the scope of certification. Additionally, we are aware that some states
are considering modular certification of the state immunization
registry to accomplish this function.
Comments. Commenters noted that the HITSC commented that it would
be useful to have a standard for updating registries with groups or
lists of patients instead of only individual patient transactions. The
commenters stated that we should consult standards development
organizations (i.e., HL7 for the v.2.5.1 message) to determine the most
appropriate standard to achieve this goal.
Response. It is our understanding that most state immunization
registries can accept batch reporting via the HL7 2.5.1 message
standard and we previously indicated this approach was acceptable in
FAQ 9-10-002-1.
Comments. Commenters expressed confusion over whether EHR
technology must be certified to a transport standard to meet this
certification criterion and whether EPs, EHs, and CAHs must use certain
transport standards for submitting immunization information to
immunization registries. Several commenters supported the requirement
that eligible professionals utilize the transport method or methods
supported by the public health agency to achieve meaningful use.
Conversely, commenters requested that ONC require EHRs be certified in
SOAP web services as well as Direct. These commenters also recommended
that SOAP web services requirements should include the Centers for
Disease Control and Prevention (CDC)'s Transport Layer Expert Panel
WSDL specifications.
Response. We want to make clear that we do not require EHR
technology to be certified to any transport standard, including Direct,
to meet this certification criterion. There is no consensus transport
standard that states and public health agencies use for the reporting
of immunization information. Therefore, we believe that it is
appropriate for EHR technology developers to have the flexibility to
include in their EHR technology and implement the transport standards
that permit EPs, EHs, and CAHs to report in their states and to local
public health agencies.
Comments. Several commenters suggested using the preferred term
``Immunization Information Systems'' for the ``transmission''
certification criterion rather than ``Immunization Registries.''
Response. We appreciate this suggestion, but are retaining the same
naming convention for the certification criterion to prevent confusion
with the associated MU objective and measure. The associated MU
objective specifically references immunization registries.
Comments. Commenters stated that EPs, EHs, and CAHs that are
currently successfully submitting immunization data in an ongoing
manner using the HL7 2.3.1 and its implementation guide should continue
to be able to do so for MU. One commenter suggested we explore offering
additional incentives to early-adopting EPs, EHs, and CAHs that upgrade
to the HL7 2.5.1 standard. A few commenters stated that, although bi-
directional communication is not proposed for MU Stage 2, we should
indicate that it will likely be required for MU Stage 3.
Response. We appreciate the submission of these comments, but they
are outside the scope of this rulemaking. We direct commenters to the
Stage 2 final rule found elsewhere in this issue of the Federal
Register for a discussion of the MU objective and measure and a
response to these comments.
Comments. A commenter stated that patients should be able to have
access to immunization records and receive an accounting of all
disclosures for public health surveillance. Another commenter requested
that interoperable immunization registries which require all registries
to accept the proposed standards without requiring additional data.
[[Page 54242]]
Response. We thank commenters for these comments, but they are
outside the scope of this rulemaking.
Comments. One commenter requested that Federal sources build a
common portal for connectivity to immunization registries and other
external data sources (e.g., HIEs, public health agencies, cancer
registries, and non-cancer registries) so that the financial burden on
EHR technology developers and end users is reduced.
Response. We appreciate this feedback, but it is outside the scope
of certification and this rulemaking. We note that while no proposal
for a single interface to all immunization registry exists, an expert
panel convened by CDC and AIRA recommended standards for transport that
include a standard WSDL which should help reduce the financial burden
on EHRs to interface with immunization registries.
Transmission to Public Health Agencies--Syndromic
Surveillance
------------------------------------------------------------------------
---------------------------------------------------------------------------
MU Objective
Capability to submit electronic syndromic surveillance data to public
health agencies except where prohibited, and in accordance with
applicable law and practice.
------------------------------------------------------------------------
2014 Edition EHR Certification Criteria
Sec. 170.314(f)(3) (Transmission to public health agencies--syndromic
surveillance).
------------------------------------------------------------------------
We proposed two certification criteria for reportable laboratory
tests and values/results that were essentially a split of the 2011
Edition EHR certification criterion for reportable lab results (Sec.
170.302(l)). We proposed one certification criterion that focused just
on the capabilities to electronically record, change, and access
syndrome-based public health surveillance information (data capture)
and another that focused on the capability to electronically create
syndrome-based public health surveillance information for transmission
in accordance with specified standards. We discussed these two proposed
certification criteria together in the Proposed Rule for simplicity and
to prevent confusion, but noted that we did not consider the
certification criterion we proposed to focus on data capture to be a
revised certification criterion. Rather, we stated that we believed
that the certification criterion would constitute an unchanged
certification criterion because all the capabilities included in the
criterion were the same as the capabilities included in the
corresponding 2011 Edition EHR certification criterion (Sec.
170.302(1)).
For the certification criterion focused on creating syndrome-based
public health surveillance information for transmission, we proposed
the use of only the HL7 2.5.1 standard for formatting syndrome-based
public health surveillance. We stated that we proposed only the HL7
2.5.1 standard because public health agencies are rapidly moving to
this standard and all stakeholders would benefit from focusing on a
single standard for public health surveillance. We also proposed to
constrain the standard for hospitals with the PHIN Messaging Guide for
Syndromic Surveillance: Emergency Department and Urgent Care Data HL7
Version 2.5.1 (Release 1.0). We further proposed that certification to
this guide be optional for the ambulatory setting because certification
of ambulatory EHR technology to this guide could be useful for EHR
developers that provide EHR technology to EPs that practice in urgent
care settings.
Comments. Commenters supported our proposed ``two certification
criteria approach.'' Commenter also stated that proposing the
certification criteria in the manner that we had would permit HIEs to
be certified to the certification criterion that includes the
capability to create syndrome-based public health surveillance for
transmission in accordance with specified standards and then serve as
intermediaries for the transport of syndromic information to public
health agencies. Another commenter noted that there should be no
certification requirement required of the HIE to support this MU
measure.
Response. We appreciate the support expressed by commenters for our
approach. We are adopting as part of the 2014 Edition EHR certification
criteria the certification criterion focused on the capability to
create syndrome-based public health surveillance in accordance with the
standards we have specified (Sec. 170.314(f)(3)). We are not, however,
adopting the certification criterion we proposed that focused on data
capture. We have chosen to drop this proposed certification criterion
because we do not believe that it is essential to focus on from a
testing and certification perspective. It is our understanding that
EPs, EHs, and CAHs will not necessarily be recording, accessing, and
capturing separate kinds of ``syndromic surveillance'' information to
facilitate the transmission of syndrome-based public health
surveillance information to public health agencies. Rather, they will
simply be ``passing on'' or reporting the information that already
exists in their CEHRT to public health agencies. Thus, upon further
reflection, this ``data capture'' certification criterion is
unnecessary for certification.
We agree with commenters regarding HIEs and noted in the Proposed
Rule that our approach to the public health certification criteria
could enable additional EHR technologies (likely in the form of EHR
Modules) to be certified and provides additional pathways and
flexibility to EPs, EHs, and CAHs to have EHR technology that can be
used to satisfy the proposed revised definition of CEHRT. In regard to
the commenters assertion that HIE should not be required to be
certified, we note that there is no such requirement. However, if an
HIE performs a capability for which certification is required and an
EP, EH, or CAH uses that capability for MU, then that capability must
be certified.
Comments. Many commenters supported the use of the HL7 2.5.1
standard and moving to a single standard. Some commenters asserted that
imposing new standards, like a move from HL7 2.3.1 or HL7 2.5.1 to a
requirement for HL7 2.5.1 only, on all systems will penalize early-
adopting providers. One commenter suggested that newer data formats
supported through the consolidated CDA be acceptable alternatives for
transmission to public health agencies for medical research and public
health.
Response. We appreciate the support for the HL 2.5.1 standard we
proposed and have now adopted this standard as the sole standard for
this certification criterion. We are adopting only the 2.5.1 standard
because, as noted above and in the Proposed Rule, public health
agencies are rapidly moving to this standard and all stakeholders would
benefit from focusing on a single standard for public health
surveillance. In regard to the concern expressed by commenters that our
approach would punish early adopters using HL7 2.3.1, we direct
commenters to the Stage 2 final rule found elsewhere in this issue of
the Federal Register for a response to this comment. Last, we do not
believe that the Consolidated CDA is appropriate for this certification
criterion at the present time.
Comments. A commenter believed that it would be sufficient to
simply adopt the implementation guide itself for this certification
criterion because it incorporates the HL7 2.5.1 standard.
Response. We believe it is appropriate to specifically adopt this
standard and not just the implementation guide that references this
standard to provide clarity around the certification requirements for
this certification criterion. In particular, the implementation guide
is optional for the ambulatory setting. Therefore, clearly specifying
the standard will ensure that
[[Page 54243]]
EHR technology designed for the ambulatory setting will be certified to
the HL7 2.5.1 standard.
Comments. Commenters supported the adoption of the PHIN Messaging
Guide for Syndromic Surveillance: Emergency Department and Urgent Care
Data HL7 Version 2.5.1 (Release 1.0). Commenters also supported having
certification to the implementation guide optional for the ambulatory
setting, while one commenter requested that it be mandatory and another
commenter stating that it was unnecessary to have for the ambulatory
setting.
Response. We appreciate the support expressed for the
implementation guide. The CDC has recently published Release 1.1 of the
implementation guide. Release 1.1 reflects the work of the CDC to
correct errors and clarify ambiguities that were present in Release 1.0
as well as provide information that was missing in Release 1.0. The CDC
also recently published an addendum to the implementation guide, titled
``Conformance Clarification for EHR Certification of Electronic
Syndromic Surveillance.'' The addendum consolidates Release 1.1
information and clarifies existing conformance requirements of the
implementation guide. For example, it specifies conformance statements
and conditional predicates that clarify message requirements. It also
specifies value set requirements and provides general clarifications
and PHIN MG corrections. Overall, Release 1.1 and the addendum do not
create additional substantive requirements in comparison to Release
1.0. Therefore, we believe the adoption of Release 1.1 and the addendum
is appropriate as they will improve the ability to test and certify EHR
technology to the implementation guide, as well as make it easier for
EHR technology developers to implement the guide's requirements.
EHR technology designed for the inpatient setting seeking
certification to this certification criterion must be certified to the
implementation guide, while EHR technology designed for the ambulatory
setting will have the option of being certified to the implementation
guide. We believe that the guide can provide necessary clarity for
ambulatory EHR developers that provide EHR technology to EPs that
practice in urgent care settings.
Comments. Several commenters recommended replacing ``Inpatient''
with ``Hospital or urgent care.'' The commenters asserted that such a
change more appropriately reflects the clinical settings that transmit
syndromic surveillance data to health departments.
Response. While we appreciate the commenters' recommendation, the
designation ``inpatient'' is a general designation that we use to
distinguish certification criteria and capabilities that apply to a
particular setting for certification. We currently designate only two
settings for certification, the inpatient setting and the ambulatory
setting without variation. EHs use ``inpatient-certified'' EHR
technology for their inpatient department and emergency departments.
For urgent care settings that are not the emergency department, the
providers would be non-hospital-based EPs and would require
``ambulatory-certified'' EHR technology. Therefore, we are retaining
the ``inpatient'' designation.
Comment. Commenters recommended adding in regulation after the
implementation guide the following statement ``or the most recent
version as published by CDC.''
Response. We refer the commenters to section III.A.5 found earlier
in this preamble. This section explains why we cannot take such an
approach.
Comments. Commenters expressed confusion over whether EHR
technology must be certified to a transport standard to meet this
certification criterion and whether EPs, EHs, and CAHS must use certain
transport standards for submitting syndrome-based public health
surveillance information to public health agencies. Some commenters
requested that we require EHR technology to be certified in SOAP web
services as well as Direct. One commenter encouraged us to expand the
required transport standards to include commonly used transports, such
as MLLP (HL7) and IHE XDS, or define specific data types and
transactions for each transport type.
Response. We want to make clear that we do not require EHR
technology to be certified to any transport standard, including Direct,
to meet this certification criterion. There is no consensus transport
standard that states and public health agencies use for the reporting
of syndrome-based public health surveillance information. Therefore, we
believe that it is appropriate for EHR technology developers to have
the flexibility to include in their EHR technology and implement the
transport standards that permit EPs, EHs, and CAHs to report in their
states and to local public health agencies.
Comment. One commenter suggested that this certification criterion
include the capability to capture adverse drug events for reporting to
public health agencies. Another commenter recommended that we should
require the capture of occupational exposure and industry worker health
information.
Response. The certification criterion does not preclude other types
of reportable events from being captured and reported by EHR
technology. We do not believe, however, that it is appropriate to
modify the certification criterion to explicitly reference adverse drug
events or any other specific syndrome-based surveillance information
for the purposes of EHR technology certification.
Comments. A commenter recommended that the ONC tighten the message
structures within the HL7 message, such that one single message works
with all registries of the same type. Specifically, there should not be
50 different flavors of the HL7 2.51 format for 50 different states for
each transmission type. In addition, to make transmission simple, the
registries captioned above should be required to accept messages via
the Direct Project messaging system only as this will reduce the burden
on providers for making dozens of point-to-point connections with
registries.
Response. We acknowledge this commenter's recommendation, but do
not believe that the recommended outcome can be effectively reached
through certification. While certification can ensure that EHR
technology can create a single, standardized message it cannot affect
the additional data states may also require be submitted or the IT
system differences across states.
Comments. One commenter stated that in consideration of the
challenges for many public health agencies to receive this data
electronically, the objective and associated criterion should be
removed.
Response. We appreciate the submission of this comment, but it is
outside the scope of this rulemaking. We direct the commenter to the
Stage 2 final rule found elsewhere in this issue of the Federal
Register for a discussion of the MU objective and measure and a
response to this comment.
Automated Measure Calculation
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
N/A.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(g)(2) (Automated measure calculation).
------------------------------------------------------------------------
We proposed to adopt a revised ``automated measure calculation''
certification criterion for the 2014 Edition EHR certification
criteria. We revised the certification criterion to clearly identify
that the recording, calculating, and reporting capabilities
[[Page 54244]]
required by this certification criterion apply to the numerator and
denominator associated with the capabilities that support an MU
objective with a percentage-based measure. We clarified that the
capabilities are the capabilities included in the certification
criteria to which a Complete EHR or EHR Module is presented for
certification.
We emphasized that testing to this certification criterion would
not only include verification of the ability of EHR technology to
generate numerators and denominators, but would also verify the
accuracy of the numerators and denominators generated by the EHR
technology. We stated testing to ensure the accuracy of these
calculations would significantly reduce the reporting burden for MU
attestation. Additionally, we stated that testing and certification to
this revised certification criterion would include testing and
certifying the ability to electronically record the numerator and
denominator and create a report including the numerator, denominator,
and resulting percentage associated with each applicable MU measure
that is supported by a capability in the new certification criteria
proposed and adopted in a final rule.
Comments. Commenters supported this certification criterion and
emphasized the value of automated measure calculation for EPs, EHs, and
CAHs. Commenters noted that it is important to ensure that EHR
technology can accurately calculate these measures and stated that
accurate measure calculations are critical to reducing the burden of
reporting and for promoting adoption. One commenter noted that although
``automated measure calculation'' suggests a simple process is required
for physicians to calculate their data for meeting MU measures, they
recommended that ONC explicitly require that EHR technology enable the
automatic creation of reports.
Response. We thank commenters for supporting this certification
criterion and agree that the improved accuracy of measure calculations
will reduce reporting burdens for EPs, EHs, and CAHs. We have adopted
this certification criterion as proposed. This certification criterion
requires EHR technology to demonstrate the capability to automatically
create reports based on the numerator and denominator for MU objectives
with percentage-based measures.
Comments. A commenter stated that this certification criterion does
not fall into patient-centric care and while a necessary component of
reporting, the functionality it includes could be performed by another
technical component outside the EHR.
Response. As stated in the S&CC July 2010 final rule (75 FR 44642),
we adopted this certification criterion to reduce the reporting burden
associated with participating in MU. This certification criterion is
required in order for EHR technology presented for certification to
meet the Complete EHR definition. We permit, but do not require, EHR
technology presented as an EHR Module for certification to also be
certified to this certification criterion. In instances where an EHR
Module is not presented for certification to this certification
criterion, it would need to be certified to the ``automated numerator
calculation'' certification criterion adopted in this final rule. We
also note that CMS permits reporting outside certified EHR technology
per FAQ 3063, which can be found at https://questions.cms.gov/faq.php?id=5005&faqId=3063.
Comments. A commenter recommended that EHR technology developers be
required to provide not only the numerator, denominator, and percentage
for the selected reporting period, but also offer the capability to
display a detail level that includes patient identifiers and data
elements and if the patient record assessed met or did not meet the
objective.
Response. While we realize such detailed information may have value
for an EP, EH, and CAH, but we do not believe that we need to require
such level of detail be displayed to the user for purposes of
certification and to support the calculation and reporting of
objectives with percentage-based measures. We note, however, that this
level of detail may be useful to demonstrate an EHR technology's
compliance with this certification criterion during testing.
Comments. Commenters requested clarification on the testing
procedures that will be used for this certification criterion.
Commenters also provided many recommendations for testing EHR
technology to this certification criterion. One commenter suggested not
moving forward with this criterion unless a test data set is provided
from ONC that validates the ability of EHR technology to generate these
accurate calculations and reports. Other commenters requested
clarification on whether test data would be provided and EHR technology
would be expected to match some predetermined calculations by the
tester. These commenters stated if EHR technology developers are
expected to demonstrate each measure calculation on the report, then
they are concerned about the time that could be required to validate
such accuracy and thus added to the time it takes to certify EHR
technology. Another commenter suggested providing specifications on how
the numerators and denominators for these measures should be
calculated. The commenter also requested that in giving EHR technology
developers a test data set, they are also given multiple ways to
accommodate the different approaches that exist to importing practical
data sets.
Some commenters expressed concerns that testing tools similar to
Cypress are not accurate. For an accuracy test, commenters recommended
that test scripts be developed that can be used by EHR developers. The
commenters further recommended that the test scripts be based on real-
world clinical workflows where a patient should be included or excluded
from the numerators and denominators of an objective in an expected
manner. The commenters noted that the test would determine the accuracy
of the EHR technology based on whether the patient is included or
excluded from the numerators and denominators according to
expectations. Commenters also recommended that testing include time-
based elements to simulate an EHR reporting period.
Response. We appreciate the many comments on testing to this
certification criterion. Consistent with the process we outlined in the
Permanent Certification Program final rule (76 FR 1280), we anticipate
approving a test procedure for this certification criterion that, at
minimum, is clearly traceable to the capabilities included in the
certification criterion, sufficiently comprehensive (i.e., assesses all
required capabilities) for NVLAP-accredited testing laboratories to use
in testing a Complete EHR's or EHR Module's compliance with the
certification criterion, and was developed using an appropriate public
comment process. With CMS, we intend to be more proactive about
explaining numerator and denominator requirements so that
misinterpretations are reduced to a minimum. To that end, we will work
with CMS to provide education materials and any additional guidance
necessary to help EHR technology developers better understand the
numerator and denominator requirements for MU objectives and measures.
Finally, we wish to make clear that for MU objectives which CMS has
provided flexibility in its final rule for EPs, EHs, and CAHs to pursue
alternative approaches to measuring a numerator and denominator, the
EHR technology must be able to support all CMS-
[[Page 54245]]
acceptable approaches in order to meet this certification criterion.
For example, there are two options for counting emergency department
admissions. If an EHR technology developer only included one option in
its EHR technology for certification, the EHR technology developer
would take away the flexibility granted to the EP, EH or CAH by CMS. We
believe that this flexibility should be available to all EPs, EHs, and
CAHs regardless of what Certified EHR Technology they utilize.
b. Ambulatory Setting
We propose to adopt the following revised certification criteria
for the ambulatory setting.
Electronic Prescribing
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objectives
Generate and transmit permissible prescriptions electronically (eRx).
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(b)(3) (Electronic prescribing).
------------------------------------------------------------------------
We proposed to adopt a revised certification criterion for the
ambulatory setting that requires the use of RxNorm as the vocabulary
standard. We proposed to continue to permit the use of NCPDP SCRIPT
version 10.6 to meet this certification criterion, but also to no
longer include the use of NCPDP SCRIPT version 8.1 as a way to meet the
2014 Edition EHR certification criterion. We stated that we made this
proposal because we understood CMS was planning to propose the
retirement of NCPDP SCRIPT version 8.1 (adopted as a Medicare Part D e-
prescribing standard) in a proposed rule that was scheduled to be
issued soon after the Proposed Rule was published. We noted that if we
received information indicating a change in CMS' plans prior to the
issuance of our final rule, we may, based also on public comment,
reinstate this standard in a final revised certification criterion. We
stated that we were proposing to adopt this certification criterion for
both the ambulatory and inpatient settings because it supports our
desired policy and interoperability outcome for content exchange
standards to be used when information is exchanged between different
legal entities.
In the interest of providing readers with a clear, cohesive, and
consistent recitation of comments and our response and to also avoid
redundancy, we direct readers to our discussion of the adopted
``electronic prescribing'' certification criterion (Sec.
170.314(b)(3)) under section III.A.8.c.
Clinical Summary
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
Provide clinical summaries for patients for each office visit.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(e)(2) (Ambulatory setting only--clinical summary).
------------------------------------------------------------------------
We proposed to revise the ``clinical summaries'' certification
criterion for the 2014 Edition EHR certification criteria to reflect
the proposed new and revised standards for problem lists and other
vocabulary standards. We noted in the Proposed Rule that we made
several refinements to the HITSC recommended certification criterion to
ensure that EHR technology meets the appropriate standards and is
capable of making available the information CMS is proposing be
provided to a patient after an office visit.
We proposed that when information is provided electronically, the
information should be provided according to the Consolidated CDA
standard. We stated in the Proposed Rule that adopting the Consolidated
CDA for this certification criterion is advantageous since its template
structure can accommodate the formatting of a summary of care record
that includes all of the data elements that CMS proposed be provided to
a patient after an office visit. We requested public comment on whether
we should adopt separate certification criteria to explicitly require
the capture of unique data elements included in clinical summaries,
such as care plans and future scheduled tests. For certain other data
elements in Sec. 170.314(e)(2), we proposed to require that the
capability to provide the information be demonstrated in accordance
with the specified vocabulary standard. We noted that these vocabulary
standards had been previously adopted or were proposed for adoption in
the Proposed Rule.
Comments. Many commenters expressed agreement with this
certification criterion and the use of the Consolidated CDA. Commenters
noted that the use of the Consolidated CDA would be beneficial for
interoperability purposes.
Response. We appreciate the support for this certification
criterion and the use of the Consolidated CDA for the clinical summary.
We are adopting this certification criterion as proposed with Release
2.0 (July 2012) of the Consolidated CDA standard as discussed earlier
in the preamble under the ``view, download, and transmit to a 3rd
party'' certification criterion, which fully supports the clinical
summary as defined by CMS in the Stage 2 final rule for the MU
objective and measure associated with this certification criterion. To
note, we have revised the certification criteria heading to the
singular form (``clinical summary'').
Comments. We received numerous comments regarding what should and
should not be included in a clinical summary, including requests for
clarification of data in the clinical summary and care plan. We also
received requests for alignment of the data in a clinical summary used
for this certification criterion and with the data included in the
clinical summary used for other certification criteria. We also
received requests for alignment with the use of the clinical summary by
CMS for MU.
Some commenters stated that the inclusion of names and contact
information of any additional care team members provides no clinical
benefit and will likely distract the patient and degrade the
effectiveness of the clinical summary. A few commenters stated that we
postpone the adoption of standards and certification criteria for care
plans and future scheduled tests as part of the clinical summaries.
Other commenters stated that EHR technology should offer EPs the
capability to customize the clinical summary, where omitting some
information is in the best interest of the patient.
Response. As noted in the Proposed Rule, this certification
criterion specifies the capabilities that EHR technology would need to
include in order for an EP to provide the information identified by CMS
to a patient after an office visit. A clinical summary and the data it
includes such as a care plan are defined or described by CMS. We direct
commenters to the Stage 2 final rule found elsewhere in this issue of
the Federal Register for a complete discussion of the ``clinical
summaries'' MU objective and measure, including the clinical summary
data that are required to be provided after an office visit. We have
adopted the Consolidated CDA standard, which supports all of the data
that CMS has included for the MU objective and measure to which this
certification criterion correlates.
Further to make this certification criterion easier to read and to
clearly express the capabilities that EHR technology must include in
order to support MU, we have broken the certification criterion into
three separate specific capabilities. The first echoes the requirement
that EHR technology must be able to create a clinical summary in both
human readable format and according to the Consolidated CDA. The second
would require EHR technology
[[Page 54246]]
to enable a user to customize (e.g., be able to edit) the data they
include in the clinical summary. This capability supports CMS's policy
for this MU objective and measure that permits EPs excluding certain
data from a clinical summary and clarifies as well as makes explicit
the customization capability other commenters mentioned should be
present. And, overall we believe this capability will assist EPs in
determining how to best structure the clinical summary they want to
provide their patients based on the data their CEHRT is able to
produce. The third specific capability identifies the minimum data EHR
technology must permit a user to select for inclusion in a clinical
summary.
Comments. A commenter stated that future appointments could be a
part of scheduling system and not readily available to the EHR to
include in the summary. The commenter noted that this could perhaps
require that another application be included in the ``process for
certification.''
Response. We interpret EHR technology broadly for the purposes of
certification in that any technology that meets a certification
criterion is defined as an EHR Module.
To meet this certification criterion, EHR technology must
demonstrate all the capabilities included in the certification
criterion. These capabilities support the associated MU objective and
measure, which includes providing any future appointments in a clinical
summary.
Comments. Commenters stated that it was unnecessary to adopt
separate certification criteria to explicitly require the capture of
unique data elements included in clinical summaries such as care plans
and future scheduled tests, while a few commenters suggested we pursue
such an approach.
Response. We agree with those commenters that stated it was
unnecessary to adopt separate certification criteria. We made this
similar response in the transitions of care certification criterion
where we also posed this question.
Comments. Commenters stated that they support the increased focus
on supporting patients' access to their information through various
means, but were concerned that the proposed certification criterion for
clinical summaries included requirements to share information with
unknown third parties. A commenter suggested that patients as well as
their designated agent(s) be registered on the EP's CEHRT to enable
transmission of their clinical data to them.
Response. We are unclear as to what language in the Proposed Rule
prompted commenters to raise this concern. This certification criterion
does not require the sharing of patient health information with third
parties. We encourage commenters to review our responses to comments on
the view, download, and transmit to a 3rd party certification
criterion.
Comments. A commenter noted that patients should be able to access,
download, and use clinical summaries which are a matter of patient
safety so errors and omissions can be detected.
Response. This certification criterion requires EHR technology to
be capable of enabling a user to electronically create a clinical
summary in human readable format and formatted according to the
Consolidated CDA.
Comment. A commenter stated that EHR technology should support
integration with HIEs to enable the export of clinical summaries,
making the information available to any authorized provider involved in
the patient's care.
Response. This certification criterion focuses on capabilities that
EHR technology would have to demonstrate for certification that would
support an EP's ability to provide a clinical summary to a patient,
including electronically. It is not focused on the exchange of a
patient's health information. Therefore, we decline to modify this
certification criterion in response to this recommendation. We note,
however, that the ``transitions of care-create and transmit transition
of care/referral summaries'' certification criterion (Sec.
170.314(b)(2)) requires EHR technology to be capable of formatting a
patient's transition of care/referral summary in accordance with the
Consolidated CDA and capable of using transport standards.
c. Inpatient Setting
We are adopting the following revised certification criterion for
the inpatient setting.
Transmission of Reportable Laboratory Tests and Values/
Results
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
Capability to submit electronic reportable laboratory results to public
health agencies, except where prohibited, and in accordance with
applicable law and practice.
------------------------------------------------------------------------
2014 Edition EHR Certification Criteria
Sec. 170.314(f)(4) (Inpatient setting only--transmission of reportable
laboratory tests and values/results).
------------------------------------------------------------------------
We proposed two certification criteria for reportable laboratory
tests and values/results that were essentially a split of the 2011
Edition EHR certification criterion for reportable lab results (Sec.
170.306(g)). We proposed one certification criterion that focused just
on the capabilities to electronically record, change, and access
laboratory rests and values/results (data capture) and another that
focused on the capability to electronically create reportable
laboratory tests and values/results for electronic transmission in
accordance with specified standards. We discussed these two proposed
certification criteria together in the Proposed Rule for simplicity and
to prevent confusion, but noted that we do not consider the
certification criterion we proposed to focus on data capture to be a
revised certification criterion. Rather, we stated that we believed
that the certification criterion would constitute an unchanged
certification criterion because all the capabilities included in the
criterion were the same as the capabilities included in the
corresponding 2011 Edition EHR certification criterion (Sec.
170.306(g)).
For the certification criterion focused on creating reportable
laboratory rests and values/results for transmission, we proposed the
use of only the HL7 2.5.1 standard and LOINC[supreg] version 2.38 as
the vocabulary standard. Following consultation with the Centers for
Disease Control and Prevention, we also proposed to adopt the HL7
Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to
Public Health, Release 1 (US Realm) with Errata and Clarifications and
SNOMED CT[supreg] International Release January 2012 version--which, we
noted, contains corrections and will require minor changes to
conformance testing and certification to account for newly assigned
OIDs (object identifiers) identifying the message profiles in the
implementation guide.
Comments. Commenters supported our proposed ``two certification
criteria approach.'' Commenter also stated that proposing the
certification criteria in the manner that we had would permit HIEs to
be certified to the certification criterion that includes the
capability to create reportable laboratory tests and values/results for
transmission in accordance with specified standards and then serve as
intermediaries for the transport of laboratory tests and values/results
to public health agencies.
Response. We appreciate the support expressed by commenters for our
approach. We are adopting as part of the 2014 Edition EHR certification
criteria the certification criterion focused on the capability to
electronically create reportable laboratory rests and values/
[[Page 54247]]
results for electronic transmission in accordance with the standards we
have specified (Sec. 170.314(f)(4)). We are not, however, adopting the
certification criterion we proposed that focused on data capture. For
similar reasons as expressed in the syndromic surveillance
certification criterion, we have dropped this requirement because we
believe it is not necessary to focus on for the purposes of EHR
technology certification.
We agree with commenters regarding HIEs and noted in the Proposed
Rule that our approach to the public health certification criteria
could enable additional EHR technologies (likely in the form of EHR
Modules) to be certified and provides additional pathways and
flexibility to EPs, EHs, and CAHs to have EHR technology that can be
used to satisfy the proposed revised definition of CEHRT.
Comments. Commenters supported maintaining the use of the HL7 2.5.1
standard and adopting the HL7 Version 2.5.1 Implementation Guide:
Electronic Laboratory Reporting to Public Health, Release 1 (US Realm)
with errata, as well as the latest versions of SNOMED CT[supreg] and
LOINC[supreg]. Commenters suggested that we simply state in regulation
that EHR technology can be certified to the most recent versions of the
vocabulary standards (SNOMED CT[supreg] and LOINC[supreg]) and the
implementation guide for certification.
Response. We appreciate the commenters' support for the standards
and implementation guide we proposed. We have adopted the proposed
certification criterion, including the proposed standards and
implementation guide with errata and clarifications and a recently
published supplement to the implementation guide, titled ````ELR 2.5.1
Clarification Document for EHR Technology Certification.'' The
supplement was not available when the Proposed Rule was published. It
does not specify additional substantive requirements. Rather, it
clarifies conformance requirements and other aspects of Release 1 with
errata and clarifications that will improve testing and certification
to the implementation guide. Accordingly, we are adopting the
supplement and the proposed Release 1 with errata and clarifications.
We have established a process for adopting certain vocabulary
standards, including SNOMED CT[supreg] and LOINC[supreg], which permits
the use of newer versions of those standards than the one adopted in
regulation. We refer readers to section IV.B for a discussion of
``minimum standards'' code sets and our new more flexible approach for
their use in certification and upgrading certified Complete EHRs and
certified EHR Modules. Readers should also review Sec. 170.555, which
specifies the certification processes for ``minimum standards'' code
sets. In response to the commenters' suggestion that we permit the use
of the ``most recent version'' of the implementation guide for
certification, we refer the commenters to section III.A.5 found earlier
in this preamble. This section explains why we cannot take such an
approach.
Comments. A commenter expressed concern about the ongoing
volatility of the LOINC[supreg] and SNOMED CT[supreg] code sets and the
burden that will be placed on laboratory staff. The commenter further
stated that the failure to adopt national standards for that coding may
result in less than optimal interstate sharing of laboratory results.
Another commenter noted that the mapping of local codes to our standard
codes is needed but little guidance is provided.
Response. We are not familiar with the ``volatility'' that the
commenter references and believe that LOINC[supreg] and SNOMED
CT[supreg] constitute consensus-based national standards. The CDC has
published the Reportable Condition Mapping Table (RCMT) that provides a
subset of LOINC[supreg] and SNOMED CT[supreg] codes associated with
reportable conditions. RCMT can be obtained from CDC vocabulary server
PHIN VADS (http://phinvads.cdc.gov). The CDC vocabulary team provides
guidance to implementers regarding the implementation of RCMT and
mapping of LOINC[supreg] and SNOMED CT[supreg] codes to local lab
tests. CDC vocabulary team can be reached directly via email at
[email protected] or through the CDC Meaningful Use technical assistance
team ([email protected]). In addition, the LOINC[supreg] SDO has
created a tool known as ``RELMA,'' which helps to map the local tests
to standard LOINC[supreg] laboratory tests. LOINC[supreg] SDO provides
RELMA training twice a year and, through a partnership with
LOINC[supreg] SDO, the CDC provides RELMA training to the public health
community at least twice a year with a special focus on microbiology
lab tests.
Comments. Commenters pointed to what they believed to be an
inconsistency between the Proposed Rule and the Stage 2 proposed rule.
Commenters stated that the Stage 2 proposed rule stated that ``Public
Health Agencies may specify the means of transport as long as it does
not go above and beyond what is required in ONC's certification
criteria.'' These commenters further stated that we only required the
Direct Protocol for transport.
One commenter strongly recommended the inclusion of PHIN-MS as a
required transport mechanism for hospital EHR systems and further noted
that leaving ``other transport mechanisms'' undefined or defined by
state will likely result in EHR vendor implementation variance. Another
commenter suggested the use of the NwHIN query-and-response protocol to
share reportable laboratory tests and values/results. Conversely, other
commenters strongly supported the requirement that transport method or
methods supported by the public health agency should be used for MU.
Response. We want to make clear that we do not require EHR
technology to be certified to any transport standard, including Direct,
to meet this certification criterion. There is no consensus transport
standard that states and public health agencies use for the reporting
of laboratory test and values/results. Therefore, we believe that it is
appropriate for EHR technology developers to have the flexibility to
include in their EHR technology and implement the transport standards
that permit EPs, EHs, and CAHs to report in their states and to local
public health agencies.
Comments. Some commenters stated that the MU objective related to
these certification criteria describes a function of a laboratory
information system rather than EHRs. A commenter stated that if
standards we propose for this certification criterion are mandated,
then state-level programs must also be amended to support the
standards. Other commenters stated that early adopters that support
only HL7 2.3.1, common among public health systems, should not be
penalized in MU Stage 2. One commenter requested clarification that
ongoing submission means that all relevant data is transmitted in a
timely fashion as required by the agency. Another commenter suggested
that we clarify that ``reportable laboratory tests'' means only those
whose transmission is required under state and local law.
Response. We appreciate the submission of these comments, but they
are outside the scope of this rulemaking. We direct commenters to the
Stage 2 final rule found elsewhere in this issue of the Federal
Register for a discussion of the MU objective and measure and responses
to these comments.
Comments. A commenter stated that is important that public health
authorities have the prerogative to prioritize which submitters are
moved in to production first.
Response. This certification criterion and certification in general
does not
[[Page 54248]]
address or regulate these decisions made by public health agencies.
11. Unchanged Certification Criteria
In the Proposed Rule, we described the certification criteria that
we considered ``unchanged.'' We noted the following factors in
determining whether a certification criterion would be ``unchanged:''
The certification criterion includes only the same
capabilities that were specified in previously adopted certification
criteria;
The certification criterion's capabilities apply to the
same setting as they did in previously adopted certification criteria;
and
The certification criterion remains designated as
``mandatory,'' or it is re-designated as ``optional,'' for the same
setting for which it was previously adopted certification criterion.
For clarity, we explained that an unchanged certification criterion
could be a certification criterion that includes capabilities that were
merged from multiple previously adopted certification criteria as long
as the capabilities specified by the merged certification criterion
remain the same. The ``authentication, access control, and
authorization'' certification criterion discussed below and adopted at
Sec. 170.314(d)(1) meets this description. Additionally, as we
specified in the Proposed Rule, an unchanged certification criterion
could be a certification criterion that has fewer capabilities than a
previously adopted certification criterion as long as the capabilities
that remain stay the same. The ``integrity'' certification criterion
discussed below and adopted at Sec. 170.314(d)(8) meets this
description. We discussed in the Proposed Rule and in the description
of revised certification criteria in this final rule that a
certification criterion could be characterized differently based on the
setting to which it applies or the designation it is given
(``mandatory'' or ``optional''). For example, a certification criterion
that includes the same capabilities that were specified in a previously
adopted certification criterion would be considered unchanged for the
ambulatory setting if the previously adopted certification criterion
only applied to the ambulatory setting and certification to the
criterion was ``mandatory.'' However, this same certification criterion
would be considered new for the inpatient setting if it were
subsequently adopted for both settings.
Comments. We did not receive comments questioning our description
of unchanged certification criteria.
Response. Therefore, we continue to use this description of
unchanged certification criteria to categorize the following
certification criteria we have adopted as part of the 2014 Edition EHR
certification criteria. For clarity, we have adopted these unchanged
certification criteria in addition to the unchanged certification
criteria previously discussed in this preamble (``immunization
information'' Sec. 170.314(f)(1) and ``receive laboratory test and
values/results'' Sec. 170.314(b)(5)--inpatient setting only).
a. Refinements to Unchanged Certification Criteria
In the Proposed Rule, we proposed refinements to the following
unchanged certification criteria. We received public comments on all of
the certification criteria. We discuss the public comments received and
the adoption of these unchanged certification criteria as part of the
2014 Edition EHR certification criteria below.
Computerized provider order entry
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
Use computerized provider order entry (CPOE) for medication, laboratory,
and radiology orders directly entered by any licensed healthcare
professional who can enter orders into the medical record per state,
local and professional guidelines to create the first record of the
order.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(a)(1) (Computerized provider order entry).
------------------------------------------------------------------------
We proposed a CPOE certification criterion that merged the separate
ambulatory and inpatient CPOE certification criteria in the 2011
Edition EHR certification criteria into one criterion because they
those certification criteria are identical. We proposed to replace the
terms ``modify'' and ``retrieve'' with ``change'' and ``access,''
respectively. We also proposed to remove the term ``store'' from the
criterion because it is redundant with our interpretation of the term
``record.'' Finally, we proposed to move the phrase ``at a minimum'' in
the certification criterion to eliminate any possible ambiguity as to
what the phrase modifies. As proposed, the certification criterion made
clear that the phrase modifies the order types and not the terms
``record,'' ``change,'' and ``access.''
Comments. Many commenters expressed general support for this
certification criterion as proposed. We also received many comments
requesting further clarification of the CPOE denominator, including
clarifying what orders count, what providers may enter the orders, and
how current MU EHR users should report measures when transitioning to
EHR technology certified to the 2014 Edition EHR certification criteria
during an EHR reporting period in 2013. One commenter requested
clarification as to whether the change in the CMS measure definition
would require ``re-certification'' to this certification criterion or
if it would only affect certification to the automated measure
calculation certification criterion.
A commenter recommended that this certification criterion include
the capability to send the order information in an electronic format
consistent with the content exchange standard identified in the
Proposed Rule at section 170.205(k) (HL7 2.5.1 and the HL7 Version
2.5.1 Implementation Guide: Standards and Interoperability Framework
Lab Results Interface, Release 1 (US Realm)). Another commenter
recommended that this certification criterion should be amended to
require some notation about a patient's predominant race when multiple
races are identified.
One commenter recommended that CPOE of radiology be separated into
its own certification criterion. The commenter stated that the new
``radiology'' certification criterion should require that CPOE of
radiology have integrated CDS tied to national physician association-
developed appropriateness criteria guidelines. The commenter reasoned
that appropriateness criteria-guided CDS at the point-of-order will
inform referring physicians and their patients as to the most
clinically appropriate imaging examinations for the given indications.
Response. We appreciate the support for the certification criterion
as proposed and are adopting this certification criterion as an
unchanged certification criterion for the 2014 Edition EHR
certification criterion at Sec. 170.314(a)(1). The comments requesting
clarification related to the denominator and the reporting of the CPOE
measure during 2013 are outside the scope of this rulemaking. We direct
commenters to the Stage 2 final rule for a discussion of these issues.
However, we do clarify that the change in the CPOE denominator affects
the ``automated measure calculation'' certification criterion (Sec.
170.314(g)(2)), which is a revised certification criterion for the 2014
Edition EHR certification criteria.
This certification criterion focuses on enabling a user to
electronically record, change, and access, at a minimum, medication,
laboratory and radiology/imaging orders. It does not focus on the
transmission of these orders.
[[Page 54249]]
Additionally, the standard recommended by the commenter is incorrect
because it focuses on the receipt of laboratory tests results, not the
outbound transmission of laboratory orders. Therefore, we decline, as
recommended by the commenter, to include the standard. We also do not
believe that the recording of race should be associated with this
certification criterion as recommended by a commenter because such an
action would dictate workflow and the recording of race is already
required by the ``demographics'' certification criterion (Sec.
170.313(a)(3)). Last, we decline to separate out radiology orders into
a separate certification criterion. While we appreciate the enhanced
clinical functionality presented in the commenter's recommendation,
this certification criterion is focused on the general CPOE capability
for various types of orders and supporting the associated MU objective
and measure. Additionally, as structured, this certification criterion
contemplates the general functionality applying to more than just
radiology or the other two types of orders specified.
Authentication, access control, and authorization
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
Protect electronic health information created or maintained by the
Certified EHR Technology through the implementation of appropriate
technical capabilities.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(d)(1) (Authentication, access control, and
authorization).
------------------------------------------------------------------------
We proposed to merge the ``access control'' certification criterion
at Sec. 170.302(o) and the ``authentication'' certification criterion
at Sec. 170.302(t) into one certification criterion for the 2014
Edition EHR certification criteria. We reasoned that since the two test
procedures developed for these certification criteria were similar and
that the capabilities included in the certification criteria go hand-
in-hand, it was best to merge the two certification criteria into one
certification criteria. We stated that this would allow for more
efficient testing and was consistent with EHR technology development.
In combination with this proposal, we proposed to adopt part of the
HITSC's recommendation related to person/user authentication, which was
reflected in the proposed certification criterion. We also expressed
the HITSC's authentication recommendation as additional guidance for
this certification criterion in that the capability to authenticate
human users would consist of the assertion of an identity and
presentation of at least one proof of that identity. We stated that it
is most appropriate for this certification criterion to focus on users
that would be able to access electronic health information in EHR
technology within an EP, EH, or CAH's organization and not to focus on
external users that may make requests for access to health information
contained in the EHR technology for the purpose of electronic health
information exchange. We further stated that the latter purpose would
likely require a different/additional security approach(es) and rely on
a health care provider's overall infrastructure beyond its EHR
technology.
We acknowledged in the Proposed Rule's preamble, as recommended by
the HITSC, example standards and implementation specifications which
could be followed in designing EHR technology to meet this
certification criterion. In particular, we specified that these example
standards and implementation specifications could include, but were not
limited to: NIST Special Publication 800-63, Level 2 (single-factor
authentication) and ASTM, E1986-09 (Information Access Privileges to
Health Information).
Comments. A majority of comments on the proposed certification
criterion supported it as proposed and without any changes for the
final rule. One commenter voiced its appreciation for the consolidation
of the two prior 2011 Edition EHR certification criteria. Another
commenter requested that we clarify whether the certification criterion
applies to: internal system and/or human users; external system and/or
human users that are recipients of ``push'' type health information
exchanges such as those required for in the Stage 2 proposed rule; or
excludes all external system and/or human users. The commenter went on
to note that this certification criterion does not include standards to
consistently specify electronic health information as distinguishable
security objects; specify whether the access is at a coarse or fine
grain level as would likely be required for data segmentation for
privacy; encode the ``actions'' in a consistent and meaningful manner
using standard data operations vocabulary; and specify an interoperable
value set of standard structural and functional roles. Further,
commenters noted that we should clarify the users to which the
certification criteria apply; and require adoption of the privacy and
security standard vocabularies such as those established by HL7 and
ASTM. Other commenters noted that the test procedure would need to be
updated for this certification criterion. Last, a commenter stated that
we should revise the requirement for single factor level of assurance
(LOA) 2 authentication and increase it to LOA 3, 2-factor
authentication. The commenter reasoned that by the time the final rule
goes into effect, additional LOA 3, 2-factor credential form factors
will be available to the general public and that these credentials will
be readily available from multiple commercial sources.
Response. We appreciate commenters support for this certification
criterion and have adopted it in this final rule as proposed. As we
stated in the Proposed Rule, we intend and believe that it is most
appropriate for this certification criterion to focus on users that
would be able to access electronic health information in EHR technology
within an EP, EH, or CAH's organization and not to focus on external
users that may make requests for access to health information contained
in the EHR technology for the purpose of electronic health information
exchange. The latter purpose would likely require a different/
additional security approach(es) and rely on a health care provider's
overall infrastructure beyond its EHR technology. With respect to the
other points raised in comments, we have purposefully left this
certification criterion flexible to accommodate for different
implementations, deployments, and organizational policy decisions.
Ultimately, this certification criterion sets a minimum requirement and
provides assurance that an EP, EH, and CAH's CEHRT includes
capabilities that can perform authentication, access control, and
authorization. Contrary to a commenter's suggestion, the certification
criterion does not specify an LOA, which in turn permits EHR technology
developers to satisfy it in a number of different ways. Practically
speaking, however, one-factor authentication would, at a minimum, be
needed to satisfy the certification criterion. Finally, we appreciate
the commenters' suggestions about specific security vocabulary
standards. We did not propose to include any of these standards and
believe that it would be prudent to first have the HITSC consider their
inclusion and whether it would be necessary to specify them in a
certification criterion or in guidance or some other type of
educational material.
Automatic log-off
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
[[Page 54250]]
Protect electronic health information created or maintained by the
Certified EHR Technology through the implementation of appropriate
technical capabilities.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(d)(5) (Automatic log-off).
------------------------------------------------------------------------
In the Proposed Rule, we proposed to adopt the automatic log-off
certification criterion from the 2011 Edition EHR certification
criteria (i.e., as unchanged). We did, however, seek to clarify what
``terminate'' in the certification criterion conveyed. We stated that
terminating a session should not be confused with locking a session,
where access to an active session is permitted after re-authentication.
We then indicated that EHR technology must have the capability to
terminate the session, including terminating the network connection.
Comments. Many commenters supported our proposal and agreed that
the certification criterion should remain unchanged for the 2014
Edition EHR certification criteria. Several commenters, though, took
issue with our clarification. One commenter noted that our proposal
does not describe what impact termination has on documentation in
progress at the time termination occurs. The commenter stated that this
would create the potential for information loss and give clinicians a
false sense that information entered into the patient's medical record
had been saved. Another commenter disagreed with our clarification
because it would draw a distinction between a session ``termination''
and a session ``lock.'' The commenter contended that any attempt to
draw such a distinction is purely subjective. The commenter stated
that, for example, an application's session state may persist in local
memory or in a centralized data store and that both of these could be
used to reconstitute a session which has been suspended by various
means. In the latter case, where a centralized data store is used for
the persistence of session state, the user may terminate the
application, reboot the workstation, restart the application and pick
up where they left off during their previous session. In the end, the
commenter proposed that any application state which: (a) Renders
application information completely inaccessible; (b) requires login
authentication to access the application; and (c) requires the same
credentials to access previous session state should qualify as a
termination. Further, they stated that this definition should apply
regardless of whether the application is physically terminated or not,
and regardless of whether the ability to reconstitute a previous
session is implemented through a centralized data store, or through in-
memory persistence of session state. Another comment sought
clarification that automatic log-off of an application does not lead to
automatically terminated network connections of other applications
active on, e.g., the desktop or server. Similarly, another commenter
stated that multiple applications may be running and concurrently using
the network connection on the same device. The commenter stated that
the proposed language implies that all network connections from the
end-user device are terminated automatically when the application shuts
down. They suggested that the termination of network connections be
limited to those used by the application being shut down. Once
commenter believed that we should clarify that it is the user's session
within the EHR that should be terminated.
Response. We appreciate the thoughtful and detailed responses
provided by commenters. In considering the prior response we issued in
the S&CC July 2010 Final Rule (75 FR 44617-618), our clarification in
the Proposed Rule, and the comments received on the Proposed Rule, we
believe that additional clarity is necessary regarding the capability
expressed by this certification criterion. Given the scenarios
identified by commenters, we believe that EHR technology developers
should interpret this certification criterion to require (as one
commenter described) that after a period of inactivity the EHR
technology must make a user's session inaccessible and subsequently
require the user to re-authenticate using the same credentials used to
begin or resume the session. To make the capability expressed by this
certification criterion clearer to EHR technology developers, we have
replaced ``Terminate'' with ``Prevent a user from gaining further
access to * * *.'' Although this may be longer phrasing toward the same
meaning, we believe it less ambiguous than ``terminate,'' is more plain
language, and that it is also consistent with the language used for the
``session lock'' security control specified in NIST 800-53 rev3.
Additionally, we clarify that this certification criterion is not meant
to result in the termination of network connections, especially network
connections that are not in use by the EHR technology, but by other
applications.
Emergency access
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
Protect electronic health information created or maintained by the
Certified EHR Technology through the implementation of appropriate
technical capabilities.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(d)(6) (Emergency access).
------------------------------------------------------------------------
In the Proposed Rule, we proposed to include in the 2014 Edition
EHR certification criteria a refined version of the 2011 Edition EHR
certification criterion for emergency access codified at Sec.
170.302(p). We proposed to remove the parenthetical ``who are
authorized for emergency situations'' from the certification criterion
and include the phrase ``identified set of users.'' We stated that
these refinements would more clearly convey the capabilities included
in this certification criterion and align with our consistent use of
the phrase ``identified set of users'' in every certification criterion
where we intend for the same capability to be available. We explained
that the purpose of this certification criterion is to provide certain
users (``identified set of users'') with the ability to override normal
access controls in the case of an emergency.
Comments. Almost all commenters that commented on this
certification criterion expressed their support for the certification
criterion as an unchanged certification criterion. One commenter
recommended that organizations be afforded the opportunity to define
their solution for emergency access based on their organizational
security policy, which may differ from the certification criterion and
testing procedures for emergency access. Another commenter suggested
that we create a more specific requirement because the current
requirements are ambiguous and do not provide enough guidance to EHR
technology developers.
Response. We appreciate the support expressed by many commenters
and are finalizing this certification criterion as proposed. With
respect to the two comments expressing alternative options for
certification, we believe these comments represent the opposite ends of
the continuum we seek to balance and manage when we adopt a
certification criterion. If the certification criterion was too
specific, the capability provided by a Complete EHR or EHR Module may
not be able to accommodate various organizational implementations. If
not specific enough, EHR technology developers could include
significantly different capabilities. The clarifying language provided
in the Proposed Rule and recited above as well as our prior responses
to comments included in the
[[Page 54251]]
S&CC July 2010 Final Rule (75 FR 44617) for the 2011 Edition version of
this certification criterion provide ample specificity for EHR
technology developers. They also include for the benefit of commenters
the citation to the HIPAA Security Rule requirement on which this
certification criterion is modeled (68 FR 8355).
Integrity
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
Protect electronic health information created or maintained by the
Certified EHR Technology through the implementation of appropriate
technical capabilities.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(d)(8) (Integrity).
------------------------------------------------------------------------
We proposed an ``integrity'' certification criterion at Sec.
170.314(d)(8) that was consistent with the HITSC's recommendation. We
also proposed to remove the capability to detect changes to an audit
log because we proposed to add that capability to the proposed
certification criterion for ``auditable events and tamper resistance''
at Sec. 170.314(d)(2). The 2011 Edition EHR certification criterion
adopted at Sec. 170.304(b) specifies that EHR technology must be able
to create a message digest in accordance with the standard specified at
Sec. 170.210(c). The adopted standard is: ``A hashing algorithm with a
security strength equal to or greater than SHA-1 (Secure Hash Algorithm
(SHA-1)) * * * must be used to verify that electronic health
information has not been altered.'' We stated in the Proposed Rule
that, after consultation with NIST, we understood that the strength of
a hash function in digital signature applications is limited by the
length of the message digest and that in a growing number of
circumstances the message digest for SHA-1 is too short for secure
digital signatures (SHA-2 produces a 256-bit message digest that is
expected to remain secure for a long period of time). We also stated
that certain operating systems and applications upon which EHR
technology may rely use SHA-1 and do not or cannot support SHA-2 at the
present time. Therefore, we requested public comment on whether we
should leave the standard as SHA-1 or replaces it with SHA-2.
Comments. Many commenters expressed support for the certification
criterion as proposed. These commenters also recommended retaining the
SHA-1 standard as a baseline because it is still relied upon in many
instances. One commenter noted that the use of SHA-1 and its security
strength is sufficient until digital signatures are broadly required in
the industry. Other commenters supported moving to SHA-2 as a better
long-term alternative.
One commenter did not support the use of ``message logs'' as the
only method of protecting health information during transmission. The
commenter contended that this certification criterion accounts for a
single-vendor system and does not address self-developed systems that
may use multiple platforms and internally-developed systems that are
interfaced together. The commenter further contended that there are
available methods to provide for secure and accurate exchange without
limiting the solution to message logs. As such, the commenter suggested
that this certification criterion should be modified to account for
internal versus external transmissions.
Response. We thank commenters for their support. We are finalizing
this certification criterion and its associated standard as proposed.
We agree with commenters that EHR technology developers should migrate
towards the use of SHA-2 because of its increased security strength,
but only where possible and voluntarily. The SHA-1 standard included in
this certification criterion serves as a floor and permits EHR
technology to be certified if it includes hashing algorithms with
security strengths equal to or greater than SHA-1. As expressed by many
commenters, the use of SHA-1 is still relied upon in many instances.
For example, the Applicability Statement for Secure Health Transport
standard that we have adopted in other certification criteria requires
that SHA-1 must be supported in addition to SAH-256. We decline to
accept the commenter's recommendation to have the certification
criterion differentiate between internal and external transmissions as
that distinction is not necessary for the purposes of certification and
determining whether EHR technology can perform this capability
according to the adopted standard. The capability's subsequent use for
internal and/or external transmissions, as the commenter advocates, is
up to the EP, EH, and CAH to determine in accordance with its
organizational policies. As a final note, we seek to call to readers'
attention that NIST has superseded FIPS 180-3 with FIPS 180-4. The
changes in FIPS 180-4 are limited in scope and do not affect the
approach we have expressed in the standard we adopted for this
certification. Therefore, in order keep the regulation current with
this recent publication we have modified the regulation text to refer
to FIPS 180-4 instead of 180-3.
b. Unchanged Certification Criteria Without Refinements
We proposed to include the following unchanged certification
criteria in the 2014 Edition EHR certification criteria without any
substantial refinements, except, where appropriate, replacing the terms
``generate,'' ``modify,'' and ``retrieve'' with ``create,'' ``change,''
and ``access,'' respectively. For the ``accounting of disclosures''
certification criterion, we specifically requested comments whether we
should revise the criterion. We received public comments on all of the
certification criteria. We discuss the public comments received and the
adoption of these certification criteria as part of the 2014 Edition
EHR certification criteria below.
Accounting of Disclosures
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
Protect electronic health information created or maintained by the
Certified EHR Technology through the implementation of appropriate
technical capabilities.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(d)(9) (optional--accounting of disclosures).
------------------------------------------------------------------------
We proposed to adopt the same optional ``accounting of
disclosures'' certification criterion included in the 2011 Edition EHR
certification criteria (Sec. 170.302(w)) as an optional certification
criterion for the 2014 Edition EHR certification criteria (Sec.
170.314(d)(9)). We did, however, specifically request public comment on
whether we should adopt a revised certification criterion. We noted
that since publication of the S&CC July 2010 final rule, the HHS Office
for Civil Rights (OCR) issued a proposed rule (76 FR 31426) addressing
the changes required by section 13405(c) of the HITECH Act, including
changes to the accounting of disclosure requirements under the HIPAA
Privacy Rule.\33\ We expressed interest in knowing whether commenters
believed that the 2014 Edition EHR certification criterion for
``accounting of disclosures'' should be revised to be a mandatory
certification criterion. We also expressed interest in knowing whether
commenters thought that the 2014 Edition EHR certification criterion
should be revised to include capabilities that would more fully support
an EP's, EH's, and CAH's ability to comply with the current HIPAA
Privacy Rule accounting for disclosure requirements at 45 CFR 164.528.
[[Page 54252]]
Additionally, we expressed interest in receiving input on whether, and
what additional, changes to the certification criterion would be needed
to support compliance with the proposed HIPAA Privacy Rule accounting
for disclosure provisions, if they were to be adopted by final rule in
substantially the same form as they were proposed. For those commenters
that believed revisions were appropriate, we asked that their comments
identify whether the certification criterion should be changed from
optional to mandatory and identify the specific capabilities that the
certification criterion should include and the rationale for including
those capabilities.
---------------------------------------------------------------------------
\33\ http://www.gpo.gov/fdsys/pkg/FR-2011-05-31/pdf/2011-13297.pdf.
---------------------------------------------------------------------------
Comments. Commenters overwhelmingly supported keeping this
certification criterion as optional and without revision. Many
commenters pointed to the significant amount of comments that were
submitted on the ``accounting of disclosures'' proposed rule (76 FR
31426) issued by OCR, particularly the comments they characterized as
expressing significant concern with the proposals in the proposed rule.
Most commenters stated that this certification criterion must be fully
aligned with the specifics of the ``accounting of disclosures'' final
rule and suggested that ONC and OCR work together in this regard. A few
commenters even suggested that we remove the certification criterion
until a ``accounting of disclosures'' final rule is issued. A few
commenters recommended that this certification criterion become
mandatory and generally stated that it should be revised to include
capabilities that would more fully support an EP's, EH's, and CAH's
ability to comply with the current HIPAA Privacy Rule accounting for
disclosure requirements. One commenter recommended that the specific
capabilities that the ``accounting of disclosures'' certification
criterion should be revised to include are: (1) The access report
capability set forth in the proposed rule proposing to modify the HIPAA
Privacy Rule's accounting for disclosures requirements; and (2) the
universal accessibility of accounting of disclosures. Another commenter
recommended that the certification criterion include a requirement to
account for disclosures of protected health information, including
release of information to third parties for care coordination, data-
sharing and research purposes. Along these lines, a commenter
recommended that EHR technology have the capability to document whether
a patient has accepted or denied a disclosure agreement (e.g., for
research purposes).
A commenter requested clarification regarding whether the data
elements required to be recorded for accounting of disclosures be in
structured format or free text. One commenter asked whether the part of
the ASTM E2147-01 standard that deals with disclosures has
applicability to this certification criterion and suggested that it
should be applicable to this certification criterion.
Response. We thank commenters for their feedback. We are adopting
this certification criterion as an unchanged certification criterion
for the 2014 Edition EHR certification criterion at Sec. 170.314(d)(9)
and have continued to designate it as ``optional.'' After consideration
of the comments received, we agree with those commenters that
recommended we wait and consider how best to align this certification
criterion with the provisions of an ``accounting of disclosures'' final
rule issued by OCR. We appreciate the suggested revisions offered by
commenters, but believe that alignment with an ``accounting of
disclosures'' final rule will provide the most certainty and useful
functionality for EPs, EHs, and CAHs, while also mitigating any EHR
technology development and implementation burdens that may accrue
through compliance with potential multiple adopted versions of this
certification criterion.
We clarify for commenters that each disclosure that has been
recorded must be done so in accordance with the standard at Sec.
170.210(d) and must include the date, time, patient identification,
user identification and the description of each disclosure. As to the
commenter's question about whether this information could be captured
in free text, we expect that date, time, patient identification, and
user identification would be automatically recorded only by EHR
technology. With respect to the description of each disclosure, we
reiterate what we stated in the S&CC July 2010 Final Rule in response
to this question (75 FR 44624). ``As we discussed in the Interim Final
Rule, we intended to leave Complete EHR and EHR Module developers with
the flexibility to innovate in this area and to develop new solutions
to address the needs of their customers. We anticipated that a
`description of the disclosure' would, at the present time, be a free
text field that would have included any information that could be
readily and electronically associated with the disclosure. For example,
we envisioned that some descriptive information could be included such
as the words `treatment,' `payment,' or `health care operations'
separately or together as a general category.''
The ASTM E2147-01 standard has not been adopted in whole or in part
for this certification criterion and we decline to adopt any part of
the ASTM E2147-01 standard for this certification criterion at this
time. Consistent with our rationale above, we believe it is most
appropriate to wait and consider the provisions of an ``accounting of
disclosures'' final rule to be issued by OCR before making any
revisions to this certification criterion.
Advance Directives
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
Record whether a patient 65 years old or older has an advance directive.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(a)(17) (Inpatient setting only--advance directives).
------------------------------------------------------------------------
Comments. The majority of commenters expressed support for this
certification criterion as an unchanged certification criterion. More
specifically, commenters stated that this certification criterion
should include the capability to record whether a patient has an
advance directive, but not require the EHR technology to demonstrate
that the actual advance directive document is recorded as an electronic
document in the EHR technology. A commenter recommended that this
requirement be included for the ambulatory setting as well so that this
data could be easily exchanged between EPs, EHs, and CAHs. One
commenter suggested that EHR technology be required to provide user
access to the advance directive. Another commenter suggested that EHR
technology should provide patients with access to their advance
directives and provide patients the capability to change the advance
directive.
Some commenters recommended that the certification criterion be
modified to accommodate scanned copies of advance directives as well as
reconciliation and version control capabilities. Other commenters
suggested that standard vocabulary was needed to describe and capture
an advance directive, including in the Consolidated CDA. A few
commenters suggested that we consider requiring EHR technology be
capable of recording the type of advance directive (e.g., Intubation,
Tube Feedings, Life Support) and the effective date/time periods for
the advance directive. The commenters reasoned that, while the
indication of an advance directive is not part of the summary of care
record for
[[Page 54253]]
MU, the Consolidated CDA that will be used for the 2014 Edition EHR
certification criteria calls for an indication of the type of advance
directive. Therefore, these commenters suggested this was an
opportunity to encourage EHR technology developers to implement such
functionality in conjunction with the Consolidated CDA functionality.
Conversely, some commenters stated that it is not necessary to require
specific codes for ``types'' of advance directives because they are not
often collected and may vary from state to state.
A few commenters requested clarification on whether ``yes'' and
``no'' data fields constituted ``structured'' data. Another commenter
requested clarification on whether structured data implied a Boolean
indicator.
Response. We appreciate the support for the certification criterion
as proposed and are adopting this certification criterion as an
unchanged certification criterion for the 2014 Edition EHR
certification criterion at Sec. 170.314(a)(17). This certification
criterion's scope focuses on the capabilities necessary to support MU,
which requires the recording of whether a patient 65 years old or older
has an advance directive. A patient's advance directive is not required
to be available or accessible with EHR technology. Under MU, advance
directive information is also not included in the summary care record,
required to be provided after a patient's office visit, or required to
be available for online viewing or downloading by a patient.
Accordingly, while we appreciate the commenters' suggested
modifications and inclusion of additional capabilities for this
certification criterion (i.e., requiring this capability for the
ambulatory setting, making the actual advance directive available in
scanned or structured format, noting the type of advance directive,
providing user or patient access to the advance directive and the
ability to change the advance directive), we decline to make any
revisions to this certification criterion at this time since such
additional capabilities would be beyond those needed to support MU.
We clarify that EHR technology would only need to demonstrate that
it can include an advance directive indicator and that the indicator is
stored in the patient's record. The use of ``yes'' and ``no'' data
fields may be one method for EHR technology to meet this certification
criterion. A Boolean search capability based on patients with advance
directives is not a requirement to meet this certification criterion.
Medication List
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
Maintain active medication list.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(a)(6) (Medication list).
------------------------------------------------------------------------
Comments. The majority of commenters recommended that this
certification criterion remain unchanged. Commenters reasoned that it
is appropriate to be non-prescriptive related to standards for internal
EHR functionality, while requiring the use of standards for health
information exchange. Conversely, a few commenters suggested that we
evaluate the applicability of standards for this certification
criterion with one commenter suggesting the use of the RxNorm standard.
These commenters suggested that this would lead to EPs, EHs, and CAHs
having the capability of providing this information as structured data
in an interoperable format. One commenter suggested that this
certification criterion be modified to require that EHR technology be
capable of providing a description of each medication's class and
intended purpose. One commenter stated that EHR technology should
support the import of medication lists from external sources, such as
an HIE, for true longitudinal care across providers.
Response. We appreciate the support for the certification criterion
as proposed and are adopting this certification criterion as an
unchanged certification criterion for the 2014 Edition EHR
certification criterion at Sec. 170.314(a)(6). We believe that this
certification criterion as adopted supports MU. Therefore, requiring
EHR technology to be capable of providing a description of each
medication's class and intended purpose is not necessary for
certification. However, as we state elsewhere, EHR technology
developers are free to include capabilities that go beyond
certification requirements.
As discussed in other certification criteria, we have required the
use of RxNorm in instances where EHR technology would be used to
perform external transmissions (e.g., for a transition of care (Sec.
170.314(b)(2)). Additionally, we require the capability to reconcile a
patient's medication list as part of the adopted ``clinical information
reconciliation'' certification criterion at Sec. 170.314(b)(4) and the
receipt of RxNorm codes in a transition of care/referral summary should
greatly facilitate this process. Thus, at this juncture, we do not
believe it is necessary to require as a condition of certification that
EHR technology natively record medications directly into RxNorm
although such an approach may be more efficient and expeditious for
some. We continue to remain cognizant of the potential burden that
requiring a standard for this certification criterion could cause and
continue to believe it is appropriate to provide EPs, EHs, and CAHs
with the flexibility to internally record such information in a manner
that includes the medication vocabularies with which they are familiar.
We note that in response to comments received on our use of the
term ``longitudinal care'' in this certification criterion and in other
certification criteria, we have replaced the term with the meaning we
gave the term for the ambulatory and inpatient settings in the Proposed
Rule. We refer readers to our discussion of the revised ``problem
list'' certification criterion earlier in this preamble.
Medication Allergy List
------------------------------------------------------------------------
-------------------------------------------------------------------------
MU Objective
Maintain active medication allergy list.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec. 170.314(a)(7) (Medication allergy list).
------------------------------------------------------------------------
Comments. The majority of commenters recommended that this
certification criterion remain unchanged. A couple of commenters
suggested expanding to include all allergies, including food and
substance allergies. The commenters reasoned that it was important to
maintain lists of these allergies to prevent adverse reactions and
other patient-safety events. These commenters also suggested
referencing a standard such as RxNorm or UNII as applicable for these
additional types of allergens. Another commenter specifically suggested
that we require the use of RxNorm for this certification criterion. One
commenter stated that EHR technology should support the import of
medication allergy lists from external sources, such as an HIE, for
true longitudinal care across providers.
Response. We appreciate the support for the certification criterion
as proposed and are adopting this certification criterion as an
unchanged certification criterion for the 2014 Edition EHR
certification criterion at Sec. 170.314(a)(7). While we appreciate the
commenters' suggestion to expand the capabilities included in this
certification criterion to cover additional types of allergens and
patient safety is one our utmost concerns, such additional capabilities
would be beyond those needed to support MU. Therefore, although we
decline to adopt this recommendation, we continue to encourage EHR
technology developers
[[Page 54254]]
to include capabilities that may go beyond certification requirements,
particularly where that may improve patient safety. Similar to the
rationale provided in our response above regarding the ``medication
list'' certification criterion, we decline to require as a condition of
certification that EHR technology natively record medication allergies
directly into RxNorm. We have however, in response to these comments
and other comments received on the other certification criteria that
reference medication allergies, adopted RxNorm for instances where this
data would be included in a CCDA formatted document.
We note that in response to comments received on our use of the
term ``longitudinal care'' in this certification criterion and in other
certification criteria, we have replaced the term with the meaning we
gave the term for the ambulatory and inpatient settings in the Proposed
Rule. We refer readers to our discussion of the revised ``problem
list'' certification criterion earlier in this preamble.
12. Gap Certification
``Gap certification'' is ``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).'' We stated in the Permanent Certification Program final
rule (76 FR 1307) and reiterated in the Proposed Rule that gap
certification will focus on the difference between certification
criteria that are adopted through rulemaking at different points in
time. We discuss in section III.A of this preamble, as we did in the
Proposed Rule, the factors we would consider in determining whether a
2014 Edition EHR certification criterion is ``new'' or ``revised.''
Examples of new certification criteria are the ``secure messaging''
certification criterion at Sec. 170.314(e)(3) and the ``electronic
medication administration record'' certification criterion at Sec.
170.314(a)(17). An example of a revised certification criterion is the
``CDS'' certification criterion at Sec. 170.314(a)(8). This
certification criterion is ``revised'' because it add capabilities to
the certification criteria for CDS that were previously adopted at
Sec. Sec. 170.304(e) and 170.306(c). An example of a certification
criterion that we would consider both new and revised is the ``e-
prescribing'' certification criterion at Sec. 170.314(b)(3). This
certification criterion is a revised certification criterion for the
ambulatory setting, but would be considered a new certification
criterion for the inpatient setting.
We stated in the Proposed Rule that for a Complete EHR or EHR
Module that was previously certified to the 2011 Edition EHR
certification criteria to be certified to the 2014 Edition EHR
certification criteria, test results from a NVLAP-accredited testing
laboratory would be required for all of the applicable new and revised
certification criteria that are adopted. For the certification criteria
that we identified as unchanged in the Proposed Rule, we stated that
test results that were used previously to certify a Complete EHR or EHR
Module to the 2011 Edition EHR certification criteria could be used to
certify the Complete EHR or EHR Module to the corresponding 2014
Edition EHR certification criteria that we identified. We provided an
illustration of how gap certification would work with our proposed 2014
Edition EHR certification criteria. An EHR Module that was previously
certified to the ``CPOE'' and ``drug-drug, drug-allergy interaction
checks'' certification criteria (i.e., previously tested and certified
to Sec. 170.304(a) or Sec. 170.306(a) and Sec. 170.302(a)) would not
need to be retested to the ``CPOE'' certification criterion at Sec.
170.314(a)(1) because this criterion has been identified as an
unchanged certification criterion. However, the previously certified
EHR Module would need to be retested for ``drug-drug, drug-allergy
interaction checks'' because the ``drug-drug, drug-allergy interaction
checks'' certification criterion at Sec. 170.314(a)(2) has been
identified as a revised certification criterion as part of the 2014
Edition of EHR certification criteria.
Comments. Multiple comments expressed support for our gap
certification policy and the identification of unchanged certification
criteria for the purposes of gap certification. Commenters noted that
gap certification would increase the efficiency of the certification
process and reduce costs for EHR technology developers and EPs, EHs and
CAHs. A commenter requested clarification about whether a Complete EHR
or EHR Module previously certified to the 2011 Edition EHR
certification criteria would need to maintain the same scope of
certification to be able to be ``gap-certified'' to the 2014 Edition
EHR certification criteria, and whether pursuing a different scope of
certification would require a ``new'' certification even if the same
criteria are part of the scope of the 2014 Edition certification. This
same commenter also noted that for some Complete EHRs and EHR Modules
certified to unchanged certification criteria, they would still need to
be tested to Sec. 170.314(g)(2). Another commenter requested that ONC
provide ONC-ACBs with gap certification guidance so that there is
consistency in the implementation of the policy.
Response. We appreciate commenters support for gap certification.
We agree with commenters that gap certification would be a less costly
and more efficient certification option for EHR technology developers.
We assume that by ``same scope of certification,'' the commenter meant
whether a Complete EHR or EHR Module previously certified to the 2011
Edition EHR certification criteria could only be certified to the
corresponding 2014 Edition EHR certification criteria. We clarify that
a previously certified Complete EHR or EHR Module would not need to
maintain the same scope of certification to be gap certified. For
example, it would be impossible for a Complete EHR designed for the
ambulatory setting presented for certification to the 2014 Edition EHR
certification criteria to be the same in scope as a Complete EHR
previously certified to the 2011 Edition EHR certification criteria
because the 2014 Edition EHR certification criteria applicable to the
ambulatory setting include new certification criteria adopted by the
Secretary. Similarly, an EHR Module presented for certification to the
2014 Edition EHR certification criteria may be certified to more
certification criteria than it was previously certified to the 2011
Edition EHR certification criteria and still be gap certified to the
unchanged certification criteria it includes. Along these lines, as
referenced by a commenter, EHR Modules certified to the 2014 Edition
EHR certification criteria that include a capability that supports a MU
percentage-based measure will need to be certified to either the new
certification criterion at Sec. 170.314(g)(1) or the revised
certification criterion at Sec. 170.314(g)(2) independent of the
designation (i.e., new, revised, or unchanged) of the certification
criterion that includes the capability that supports a MU percentage-
based measure (to note, Complete EHRs would need to be certified to
Sec. 170.314(g)(2)). As stated in the Permanent Certification Program
final rule (76 FR 1308), in all of these
[[Page 54255]]
examples, an ONC-ACB would issue a certification to the entire Complete
EHR or EHR Module it certifies to the 2014 Edition EHR certification
criteria. We also provided a detailed explanation of gap certification
and initial guidance in the Permanent Certification Program final rule
(76 FR 1307-08) and intend to provide additional guidance as necessary
to facilitate a consistent implementation of gap certification by ONC-
ACBs.
For the purposes of gap certification, table 3 below provides a
crosswalk of unchanged 2014 Edition EHR certification criteria to the
corresponding 2011 Edition EHR certification criteria. This table has
been revised compared to the table included in the Proposed Rule (77 FR
13860-61). We have removed from the table both the certification
criteria that have now been adopted as revised certification criteria
and those that were not adopted as part of the 2014 Edition EHR
certification criteria. The proposed unchanged certification criteria
that have been adopted as revised certification criteria are: ``drug-
formulary checks'' (Sec. 170.314(a)(10)); ``vital signs, body mass
index, and growth charts'' (Sec. 170.314(a)(4)); ``smoking status''
(Sec. 170.314(a)(11)); ``patient lists'' (Sec. 170.314(a)(14)); and
``patient reminders'' (Sec. 170.314(a)(15))[now combined and
collectively referred to as ``patient list creation'' (Sec.
170.314(a)(14)) in this final rule]. The certification criteria that
were proposed as part of the 2014 Edition EHR certification criteria,
but were not adopted are ``public health surveillance'' (Sec.
170.314(f)(3)) and ``reportable laboratory tests and values/results''
(Sec. 170.314(f)(5)). We also note, as identified in table 3, that for
the certification criterion at Sec. 170.314(b)(5) (Incorporate
laboratory tests and values/results), EHR technology designed for an
ambulatory setting would need to be tested by a NVLAP-accredited
testing laboratory because such EHR technology must meet new standards
and implementation specifications, while the capabilities required for
the inpatient setting are unchanged.
Table 3--Gap Certification: Crosswalk of Unchanged 2014 Edition EHR Certification Criteria to the Corresponding
2011 Edition EHR Certification Criteria
----------------------------------------------------------------------------------------------------------------
2014 Edition 2011 Edition
----------------------------------------------------------------------------------------------------------------
Title of regulation Title of regulation
Regulation section paragraph Regulation section paragraph
----------------------------------------------------------------------------------------------------------------
170.314(a)(6)................... Medication list...... 170.302(d)...................... Maintain active
medication list.
170.314(a)(7)................... Medication allergy 170.302(e)...................... Maintain active
list. medication allergy
list.
170.314(b)(5)................... Incorporate 170.302(h)...................... Incorporate
laboratory tests and laboratory test
values/results results.
(inpatient setting
only).
170.314(f)(1)................... Immunization 170.302(k)...................... Submission to
information. immunization
registries.
170.314(d)(1)................... Authentication, 170.302(o)...................... Access control.
access control, and
authorization.
170.314(d)(6)................... Emergency access..... 170.302(p)...................... Emergency access.
170.314(d)(5)................... Automatic log-off.... 170.302(q)...................... Automatic log-off.
170.314(d)(8)................... Integrity............ 170.302(s)...................... Integrity.
170.314(d)(1)................... Authentication, 170.302(t)...................... Authentication.
access control, and
authorization.
170.314(d)(9)................... Optional-accounting 170.302(w)...................... Accounting of
of disclosures. disclosures.
170.314(a)(1)................... Computerized provider 170. 304(a)..................... Computerized provider
order entry. 170. 306(a)..................... order entry.
170.314(a)(17).................. Inpatient setting 170.306(h)...................... Advance directives.
only-advance
directives.
----------------------------------------------------------------------------------------------------------------
13. Disability Status
In the Proposed Rule, we solicited comments on whether EHR
technology certified to the 2014 Edition EHR certification criteria
should be capable of recording the functional, behavioral, cognitive,
and/or disability status of patients (collectively referred to as
``disability status''). We stated that the recording of disability
status could have many benefits. It could facilitate provider
identification of patients with disabilities and the subsequent
provision of appropriate auxiliary aids and services for those patients
by providers. It could promote and facilitate the exchange of this type
of patient information between providers of care, which could lead to
better quality of care for those with disabilities. The recording of
disability status could also help monitor disparities between the
``disabled'' and ``nondisabled'' population.
We asked commenters whether there exists a standard(s) that would
be appropriate for recording disability status in EHR technology. We
pointed commenters to the standard for disability status approved by
the Secretary for use in population health surveys sponsored by HHS
\34\ and standards under development as part of the Standards and
Interoperability Framework and the Continuity Assessment Record and
Evaluation (CARE) assessment tool.\35\ We asked commenters whether
these standards or any other standards would be appropriate for
recording disability status in EHR technology.
---------------------------------------------------------------------------
\34\ http://www.minorityhealth.hhs.gov/templates/browse.aspx?lvl=2&lvlid=208.
\35\ http://wiki.siframework.org/file/detail/CARE+Tool+Functional%2C+Cognitive+and+Skin+Status.xls.
---------------------------------------------------------------------------
We requested that commenters consider whether the recording of
disability status should be a required or optional capability that EHR
technology would include for certification to the 2014 Edition EHR
certification criteria. We also requested that commenters consider
whether the recording of disability status should be part of a Base EHR
definition and included in a separate certification criterion or
possibly the ``demographics'' certification criterion (Sec.
170.314(a)(3)). Last, we requested that commenters consider whether
disability status recorded according to the standard should also be
included in other certification criteria such as ``transitions of
care--incorporate summary care record'' (Sec. 170.314(b)(1)),
``transitions of care--create and transmit summary care record'' (Sec.
170.314(b)(2)), ``view, download and transmit to 3rd party'' (Sec.
170.314(e)(1)), and ``clinical summaries'' (Sec. 170.314(e)(2)).
Comments. Commenters stated that there could be many benefits from
the recording of disability status, such as
[[Page 54256]]
the ones we described in the Proposed Rule. Commenters, however,
expressed a significant lack of consensus on how to define disability
status. Some commenters stated that ``functional status,'' is a more
precise, comprehensive, and objective measure for describing the
patient's clinical status. Other commenters stated that functional,
cognitive, and disability status were distinct. One commenter suggested
that we use the definition for ``disability'' identified in the
Americans with Disabilities Act Amendments Act. A couple of commenters
stated that there is no commonly accepted definition that could be used
for our purposes.
Commenters also expressed concern over disability status being
improperly defined, accurately recorded for a patient, and shared with
others. A few commenters stated that there may be legal ramifications
for patients or providers if the term ``disability'' is erroneously
applied to a patient record as benefit determinations, entitlement to
protected class status, and/or reimbursement could be affected. Another
commenter noted concerns that the accuracy of the data could differ if
the definition has subjective components and information is entered by
multiple providers. A couple of commenters noted that disability status
is not required for all patients or all specialties and should not be
required in any reports (they noted that when needed, it will be sent
as part of existing information). A couple of other commenters noted
privacy and security concerns with sharing and reporting patient
disabilities.
Commenters made a variety of recommendations regarding how
``disability status'' should be incorporated into the 2014 Edition EHR
certification criteria. Commenters suggested including it as its own
certification criterion, in and not in the ``demographics''
certification criterion, in all the certification criteria we mentioned
in the Proposed Rule, and in the Base EHR definition. A few commenters
also suggested that disability status could be captured in patient
problem lists. One commenter suggested that if the recording of
disability status is part of certification, then its recording should
be optional.
Commenters gave varying views on the availability of appropriate
standards and tools for capturing disability standards. Many commenters
also expressed views that standards were not mature enough. Commenters
suggested the Consolidated CDA be used for capturing cognitive and
functional status, but noted that it was not yet mature enough for
capturing other kinds of disabilities in a structured way. Some of
these commenters suggested that the Consolidate CDA could serve as a
``stepping stone.'' A commenter suggested the collection of disability
status data using the American Community Survey (ACS) questions on
disability (these constitute the 6-question data collection disability
standard used for population health surveys sponsored by HHS). Another
commenter noted that the World Health Organization created an entire
framework and vocabulary standard--the International Classification of
Functioning, Health and Disability (ICF)--to capture and record
functional and disability status. A commenter also suggested SNOMED
CT[supreg] (used in the SSA CCD) or ICD-10-CM/PCS could have potential
for use in recording disability status. Multiple commenters suggested
that the CARE assessment tool should be used. However, one commenter
stated that the CARE tool in its current form will not accurately
document medical severity, functional status, and other factors related
to outcomes as the questions lack sensitivity and, therefore, the type
of information about the patient needed to measure outcomes and
severity is not being collected by this instrument. A few other
commenters stated that there is no current standard(s) appropriate for
recording disability status in EHR technology at this time. These
comments suggested a new standard be developed using the CARE
assessment tool and ICF Core Sets to help guide the development of the
standard. Another commenter suggested that new standards could be
developed for including this as a separate section such as ``disability
history'' (alongside ``social history'').
Response. We appreciate the responses and various recommendations
from commenters. Although commenters did not express consensus around a
single definition or standard for recording or transmitting
``disability status,'' commenters generally provided a framework from
which forward progress on this topic can be made. Commenters noted that
benefits could be realized when such information is captured.
Commenters were also clear that we should not use a single term, such
as ``disability status,'' to capture both demographics (i.e.,
impairments that are generally permanent and do not change over time)
and clinical information (i.e., clinically assessed impairments that
may improve, worsen, or go away over time). Commenters did suggest that
functional and cognitive status be used for clinical information and
that standards were available to use for both capture and transmission.
We acknowledge that the Proposed Rule's use of a single term,
``disability status,'' was too imprecise to represent at least the two
different concepts expressed by commenters. As shown by the diversity
in commenters' views and considering that, in most cases, a standard
defines the information that must be recorded, we believe that further
stakeholder input is necessary before EHR technology is required as a
condition of certification to be capable of recording a patient's
disability(ies) in a specific standard. As a starting point, we ask
that stakeholders consider whether the recently developed 6-question
``data standard for disability status'' adopted for population health
surveys sponsored by HHS or any other standard would be appropriate for
requiring the recording of the types of impairments identified in the
6-question survey standard (e.g., ``are you deaf or do you have serious
difficulty hearing''). Unlike clinical cognitive or functional status
assessments, this information can be used by health care providers to
better accommodate and respond to individual patient needs. In turn, we
will ask the HITPC and HITSC to consider during their deliberations on
recommendations for MU Stage 3 that they review the 6-question ``data
standard for disability status'' and any other relevant standard for
the recording of disabilities.
As a current means of moving forward, we believe we can build on
commenters' recommendations for transmitting cognitive and functional
status. We agree with commenters that we should consider ``disability
status,'' at minimum, in terms of functional and cognitive status. We
also agree with commenters that the Consolidated CDA can serve as a
``stepping stone.'' The Consolidated CDA can capture functional and
cognitive status as well as other ``disability statuses.'' Therefore,
considering that the ``transitions of care'' certification criteria
already require that EHR technology be capable of using the
Consolidated CDA, we are also requiring that EHR technology be capable
of including patient data on functional and cognitive status in order
to align with inclusion of this information by CMS for transitions of
care/referrals in the Stage 2 final rule.
Overall, we believe these initial steps will put us on a path
forward using EHR technology to improve the quality of care for those
patients with disabilities.
[[Page 54257]]
B. Redefining Certified EHR Technology and Related Terms
1. Proposed Revisions to the Definition of Certified EHR Technology
Based on feedback ONC and CMS received on the CEHRT definition from
numerous stakeholders, including EPs, EHs, CAHs, EHR technology
developers, and multiple associations representing these and other
stakeholders and the recommendations \36\ of the HITSC, we proposed a
more flexible CEHRT definition. Overall, a majority of stakeholders and
the HITSC recommended a definition that would provide EPs, EHs, and
CAHs the flexibility to have or possess only the EHR technology
certified to adopted certification criteria that they would need/use to
demonstrate MU. Accordingly, consistent with the instruction of the
President's Executive Order (EO) 13563 to identify and consider
regulatory approaches that reduce burden and maintain flexibility for
the public, we proposed to revise the CEHRT definition at Sec.
170.102. The proposed revised CEHRT definition was broken into two
parts based on years of applicability.
---------------------------------------------------------------------------
\36\ HITSC recommendations dated November 16, 2011 and
transmitted to ONC on January 17, 2012. http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_0_6014_1818_17828_43/http%3B/wci-pubcontent/publish/onc/public_communities/_content/files/011712_iwg_transmittalmemo.pdf.
---------------------------------------------------------------------------
For FYs/CYs Up to and Including 2013
For the first part of the revised definition of CEHRT that would
apply for the FYs/CYs up to and including 2013, we proposed two
specific changes. The first was to include a reference to ``the 2011
Edition EHR certification criteria'' in order to make clear that these
are the certification criteria previously adopted by the Secretary at
Sec. Sec. 170.302, 170.304, and 170.306. We stated that this
clarification was necessary because with the adoption of the 2014
Edition EHR certification criteria in this final rule at Sec. 170.314,
there would be two ``editions'' of adopted certification criteria in
the CFR. Both the 2011 Edition and the 2014 Edition EHR certification
criteria must be effective at the same time for EHR technology to
continue to be tested and certified to the 2011 Edition EHR
certification criteria and so EHR technology developers may begin to
have their EHR technology tested and certified to the 2014 Edition EHR
certification criteria.
The second change we proposed would allow EPs, EHs, and CAHs to
satisfy the definition by having EHR technology certified to the 2014
Edition EHR certification criteria that are ``equivalent'' to the 2011
Edition EHR certification criteria. We stated that we would consider
''equivalent'' certification criteria to be those proposed 2014 Edition
EHR certification criteria that include capabilities that are at least
equal to the capabilities included in certification criteria that were
previously adopted as part of the 2011 Edition EHR certification
criteria. For further clarity, we provided a cross-walk between 2011
Edition EHR certification criteria and what we considered equivalent
proposed 2014 Edition EHR certification criteria (77 FR 13863). We
stated that this revision was necessary to permit EPs, EHs, and CAHs
with the flexibility to adopt or upgrade to EHR technology certified to
the 2014 Edition EHR certification criteria without adversely affecting
the certified status of previously adopted EHR technology or their
ability to meet the definition of CEHRT. With respect to CQMs, however,
we noted that EPs, EHs, and CAHs who adopt or upgrade to EHR technology
certified to the 2014 Edition EHR certification criteria during FY/CY
2012 or FY/CY 2013 must ensure that their CEHRT will enable them to
report on the CQMs required for the 2012 and 2013 EHR reporting
periods. More specifically, the EHR technology required to
electronically capture, calculate, and report CQMs during those years
will be different than the EHR technology needed to do the same in FY/
CY 2014 and subsequent years because CMS did not propose to change the
set of CQMs on which EPs, EHs, and CAHs would need to report until FY/
CY 2014. Therefore, we clarified that EPs, EHs, and CAHs will need to
have EHR technology certified to the CQM certification criteria
included in the 2011 Edition EHR certification criteria to be able to
report on the CQMs required for the 2012 and 2013 EHR reporting
periods. For further guidance, we encouraged EPs, EHs, and CAHs to read
CMS' Stage 2 proposed rule to understand the CQMs that would need to be
reported for a given EHR reporting period.
For FY and CY 2014 and Subsequent Years
We stated that the second part of the revised definition of CEHRT
that would apply beginning with FY/CY 2014 would accomplish four main
policy goals:
1. It defines CEHRT in plain language and makes the definition and
its requirements readily understandable to EPs, EHs, CAHs, EHR
technology developers, and other stakeholders.
2. It continues the progress towards increased interoperability
requirements for EHR technology by requiring all CEHRT to have, at a
minimum, the capabilities included the Base EHR definition.
3. It accounts for stakeholder feedback, which expressed that the
definition should align more closely with MU requirements under the EHR
Incentive Programs.
4. It follows the tenets expressed in EO 13563 by reducing
regulatory burden, providing more flexibility to the regulated
community, and making regulatory text more understandable.
We reminded stakeholders in the Proposed Rule that the definition
of CEHRT does not speak to just one audience. EPs, EHs, and CAHs may
view the definition of CEHRT in a way that informs them of the EHR
technology that they must possess to accomplish MU. Alternatively, EHR
technology developers may see the definition differently and in a way
that informs them of the potential market demand for certain EHR
technologies and, more specifically, the EHR technology that their
customers will need to achieve MU.
We affirmed in the Proposed Rule that only two types of EHR
technology, Complete EHRs and EHR Modules, can be certified under the
``ONC HIT Certification Program.'' However, we pointed out that under
the revised definition of CEHRT that we proposed for FY/CY 2014 and
subsequent years, an EP, EH, or CAH could meet the definition with a
certified Complete EHR, a single certified EHR Module, a combination of
separately certified EHR Modules, or any combination of the three. For
example, an EHR technology developer could get an EHR Module certified
that would subsequently enable an EP, EH, or CAH to have EHR technology
that would satisfy the proposed revised definition of CEHRT.
Alternatively, an EP, EH, or CAH could use a certified Complete EHR and
a certified EHR Module to meet the proposed revised definition of
CEHRT.
We provided the following scenarios in the Proposed Rule to
demonstrate the added flexibility the proposed revised CEHRT definition
could provide EPs, EHs, and CAHs. One scenario of added flexibility
would be where an EP, EH, or CAH qualifies for an exclusion for a MU
objective and associated measure. With respect to this scenario, we
expect that this new flexibility would apply in situations where the MU
objective and associated measure would not be applicable to the EP, EH,
or CAH. In most cases, we expect this would occur for EPs based on
their scope of practice
[[Page 54258]]
and would be significantly less likely to occur for most EHs and CAHs.
For example, a dentist will never give immunizations and, thus, would
not need EHR technology with the capability to submit immunization
information to immunization registries in order to satisfy the proposed
revised definition of CEHRT. As another example, and as noted earlier,
an EP may not have any office visits during an EHR reporting period and
thus may qualify for the exclusion for the MU objective and associated
measure requiring clinical summaries to be provided to patients for
each office visit. Under the proposed revised definition of CEHRT, the
EP would not need to have EHR technology that supports this capability.
The second scenario would be where an EP, EH, or CAH is able to and has
chosen to defer a MU ``menu set'' objective and associated measure for
a particular stage of MU. In such a case, the EP, EH, or CAH would not
necessarily need to have EHR technology with the capability to meet the
menu set objective and associated measure in order to have EHR
technology that satisfies the proposed revised definition of CEHRT.
Ultimately, under the proposed revised definition of CEHRT for FY/CY
2014 and subsequent years, the EP, EH, and CAH would be responsible for
ensuring that they have the necessary EHR technology to meet the Base
EHR definition and support the MU objectives and measures that they
seek to achieve under the EHR Incentive Programs. This means that EPs,
EHs, and CAHs could run the risk of not having sufficient CEHRT to
support their achievement of MU if, for example, they turn out not to
be able to exclude a MU objective and measure as anticipated or they
end up needing to satisfy a menu objective and measure that they
originally expected to defer.
Having offered these examples of the added flexibility the proposed
revised definition of CEHRT for FY/CY 2014 and subsequent years could
provide, we also emphasized that under the proposed revised definition,
all EPs, EHs, and CAHs must have EHR technology certified under the ONC
HIT Certification Program to the 2014 Edition EHR certification
criteria that meets the Base EHR definition as defined in the Proposed
Rule. For example, even if an EP could claim an exclusion from the MU
objective and associated measure for CPOE, he or she would still need
to have EHR technology that has been certified to the CPOE
certification criterion adopted by the Secretary because this
capability would be included in the Base EHR definition.
After consultation with CMS, we determined that it would be least
confusing and burdensome for EPs, EHs, CAHs, and EHR technology
developers if our revised definition would apply beginning with the EHR
reporting periods that will occur in FY/CY 2014. We stated that this
approach would account for the proposed start of MU Stage 2 in FY/CY
2014; the policy change we have made related to the Base EHR
definition; the time it would take EHR developers to update their EHR
technology to meet the proposed new and revised certification criteria
and have the EHR technology tested and certified to those criteria; and
the time it would take EPs, EHs, and CAHs to subsequently implement EHR
technology certified to the 2014 Edition EHR certification criteria. We
requested public comment on alternative approaches that would provide
equivalent simplicity and flexibility for EPs, EHs, and CAHs, as well
as EHR technology developers, but that would still meet our
programmatic goals and timelines.
We clarified and emphasized in the Proposed Rule that the revised
definition of CEHRT would apply for all EPs, EHs, and CAHs, regardless
of whether they are in Stage 1 or Stage 2 of MU. For example, EPs, EHs,
and CAHs that are in Stage 1 or Stage 2 of MU for the EHR reporting
periods in FY/CY 2014 would need to meet the revised definition of
CEHRT (which includes the Base EHR definition).
Comments. Commenters expressed appreciation and agreement with the
added flexibility the proposed revised CEHRT definition provided EPs,
EHs, and CAHs. The majority of commenters, however, expressed concern
that the time available between the publication of this final rule and
the proposed compliance dates (October 1, 2013 for EHs and CAHs and
January 1, 2014 for EPs) for the revised CEHRT definition that would
apply beginning with FY/CY 2014 would be insufficient. Commenters
stated that there would not be sufficient time for developing, testing,
and certifying EHR technologies to the 2014 Edition EHR certification
criteria and subsequently implementing these EHR technologies in the
healthcare environments of all EPs, EHs, and CAHs that intend to
participate in the EHR Incentive Programs in FY/CY 2014. EHR technology
developers suggested a minimum of 15 months is necessary from the
availability of testing and certification for EHR technology to the
2014 Edition EHR certification criteria if all EHs must have CEHRT that
meets the CEHRT definition for FY/CY 2014 on October 1, 2013.
Commenters suggested various alternatives to our proposed revised
CEHRT definition and the CMS proposed EHR reporting periods in FY/CY
2014. These alternative proposals suggested ways to provide additional
flexibility and reduce burden for EHR technology developers, EPs, EHs,
and CAHs in complying with the proposed revised CEHRT and meaningful
use requirements. Some commenters suggested permitting EPs, EHs, and
CAHs to meet the revised CEHRT definition for FY/CY 2014 at any time
during their Stage 2 EHR reporting period in 2014. This would
essentially give EHs and CAHs until September 30, 2014, and EPs until
December 31, 2014. Other commenters suggested a shorter EHR reporting
period for EPs, EHs, and CAHs in their first year of MU Stage 2, such
as a 90-day or 180-day EHR reporting period. Commenters stated this
would be similar to how MU Stage 1 was implemented. Some commenters
suggested permitting EPs, EHs, and CAHs to use EHR technology certified
to the 2011 Edition EHR certification criteria until at least FY/CY
2015. A few commenters suggested that we directly correlate the
definition of CEHRT with the MU stage. The commenters suggested that an
EP, EH, or CAH would only need to have EHR technology that could
support the MU stage they were attempting to achieve, such as EHR
technology certified to the 2011 Edition if they were attempting to
achieve MU Stage 1. The commenters also suggested that it should be
optional for EPs, EHs, and CAHs to use EHR technology certified to the
2014 Edition in Stage 1.
A few commenters suggested an approach within the framework of our
proposed revised CEHRT definition. These commenters suggested making
the flexibility provided by our proposed revised CEHRT definition for
FY/CY 2014 and subsequent years available during FY/CY 2012 and 2013.
In particular, one commenter suggested that we revise the first part of
the proposed CEHRT definition (applicable through FY/CY 2013) to
provide EPs, EHs, and CAHs with the option of meeting a CEHRT
definition similar to the definition for FY/CY 2014 and subsequent
years. The commenter suggested this could be achieved by revising the
CEHRT definition for FY/CY 2013 to include a Base EHR definition based
on the 2011 Edition EHR certification criteria or by permitting the use
of EHR technology in FY/CY 2013 that meets the CEHRT definition for FY/
CY 2014 and subsequent years. The commenter stated
[[Page 54259]]
that we could add flexibility by permitting an EP, EH, or CAH to use
either option in lieu of our proposal that would limit them to only
being able to use EHR technology certified to all of the applicable
2011 Edition EHR certification criteria or equivalent 2014 Edition EHR
certification criteria. The commenter identified, however, that if we
adopt an approach allowing EPs, EHs, and CAHs to meet the proposed
revised CEHRT definition for FY/CY 2014 and subsequent years in FY/CY
2013, it would create a potential inconsistency with respect to CQMs.
More specifically, the commenter stated that such an approach would
require an EP, EH, or CAH who wanted to adopt only 2014 Edition EHR
technology to still have 2011 Edition EHR technology that could
calculate the CQMs required for the EHR reporting periods in 2013. To
address this alignment issue, the commenter recommended that EPs, EHs,
and CAHs be permitted to use 2014 Edition EHR technology and attest in
FY/CY 2013 using the CQMs designated for the 2014 EHR reporting period
(and that would be part of their 2014 Edition EHR technology) in lieu
of the other CQM reporting requirements for FY/CY 2013.
Response. We appreciate commenters' support for our proposed
revised CEHRT definition. We understand the concerns expressed by
commenters regarding time constraints and the steps needed for EPs,
EHs, and CAHs to achieve compliance with the proposed revised CEHRT
definition for FY/CY 2014. We believe with the timely publication of
this final rule and the steps taken by CMS to add flexibility to the
EHR reporting periods in FY/CY 2014, there will be sufficient time for
all EPs, EHs, and CAHs that intend to participate in the EHR Incentive
Programs in FY/CY 2014 to adopt and implement EHR technology that meets
the CEHRT definition. The recommendations commenters made related to MU
Stage 2 timing fall within the purview of CMS and the EHR Incentive
Programs (i.e., length of EHR reporting periods and when EPs, EHs, and
CAHs must possess CEHRT in relation to the EHR reporting periods).
However, we have discussed the recommendations related to the length of
EHR reporting periods with CMS, and CMS has determined to adopt three-
month quarter EHR reporting periods in FY/CY 2014. This will provide
additional time for EHR technology developers as well as give EPs, EHs,
and CAHs up to an additional 9 months to adopt EHR technology that
meets the revised CEHRT definition for FY/CY 2014.
We decline to accept commenters' suggestions about correlating
``editions'' of certification criteria with MU stages (i.e., 2011
Edition with Stage 1 and 2014 Edition with Stage 2), permitting the use
of EHR technology certified to the 2011 Edition EHR technology through
FY/CY 2015, or making the use of EHR technology certified to the 2014
Edition EHR certification criteria optional for those EPs, EHs, or CAHs
participating in MU Stage 1. While these approaches could assuage
commenters' timing concerns, they do not account for the fact that such
a policy decision would have significant long-term consequences with
respect to accelerating electronic health information exchange and
interoperability. For example, as CMS illustrated in the Stage 2
proposed rule (77 FR 13703) and again in the Stage 2 final rule
published elsewhere in this issue of the Federal Register, its policy
remains that an EP, EH, and CAH will begin demonstrating meaningful use
according to the Stage 1 criteria. Thus, if we implemented an approach
of certifying EHR technology to MU stages (without a cutoff date), an
EP, EH, and CAH could participate in MU Stage 1 well into the future
with EHR technology certified to the 2011 Edition EHR certification
criteria. Similarly, in a scenario where all three anticipated MU
stages are in effect at the same time, EPs, EHs, and CAHs would all
have different EHR technologies certified to different functional and
interoperability capabilities. Such an outcome could potentially create
a disparity among meaningful EHR users just because of the EHR
technology they used to demonstrate MU and would serve as a limiting
step for the adoption of more advanced capabilities for patient care,
engagement, and safety. Moreover, this suggestion does not account for
how confusing or challenging it could potentially be in the scenario
where different EPs in a group practice are meeting different MU stages
during an EHR reporting period nor does it appear to account for how
feasible it would be for EHR technology developers to simultaneously
support EHR technologies certified to different functional and
interoperability capabilities for the time spans necessary.
Alternatively, we believe, as we have finalized, that it is simpler for
EPs, EHs, and CAHs, as well as their EHR technology developers, to have
a single EHR technology edition upon which to reference and rely that
can support any MU stage an EP, EH, or CAH seeks to achieve.
We agree with the commenter's detailed suggestion that we provide
EPs, EHs, and CAHs with the option of using EHR technology that meets
the proposed revised definition of CEHRT for FY/CY 2014 and subsequent
years as soon as practicable. We are therefore modifying the first part
of the proposed revised CEHRT definition to include this flexibility.
In other words, for the EHR reporting periods in CY/FY 2012 and 2013,
EPs, EHs, and CAHs may use technology that satisfies the CEHRT
definition that will apply in FY/CY 2014 and subsequent years. We
believe this is a better approach than retrospectively creating a CEHRT
definition for FY/CY 2012 and 2013 based on the 2011 Edition EHR
certification criteria, which would include a ``2011 Edition'' Base EHR
definition. A revised CEHRT definition based on 2011 Edition EHR
certification criteria for FY/CY 2012 and 2013 would only be effective
for about a year and during a period of time when most EHR technology
developers will be focused on designing and upgrading their EHR
technology to meet the 2014 Edition EHR certification criteria and not
on meeting a new ``2011 Edition'' Base EHR definition. More
importantly, providing such flexibility earlier will support continued
forward momentum towards increased electronic health information
exchange and interoperability, as well as avoid the potentially
unnecessary and duplicative adoption of 2011 Edition and 2014 Edition
CEHRT in the same year. To this last point and to emphasize, if an EP,
EH, or CAH does not take advantage of this new flexibility, then to
meet the CEHRT definition for FY/CY 2012 and 2013, the EP, EH, or CAH
will need to have EHR technology certified to all of the mandatory 2011
Edition EHR certification criteria (or equivalent 2014 Edition EHR
certification criteria) for either the ambulatory or inpatient setting,
as applicable. Last, with respect to the potential CQM misalignment the
commenter raised, we understand CMS is adopting a policy to accommodate
EPs, EHs, and CAHs that choose to use only 2014 Edition CEHRT in FY/CY
2013. For further explanation, we refer readers to CMS's final rule
published elsewhere in this issue of the Federal Register.
Consistent with EO 13563, this additional flexibility and the
original flexibility we proposed in the revised CEHRT definition should
create additional regulatory efficiencies for EPs, EHs, and CAHs.
Accordingly, the CEHRT definition will be revised at Sec. 170.102 to
reflect our proposal in the
[[Page 54260]]
Proposed Rule with the additional modification to the first part of the
definition discussed above. Table 4 below provides a crosswalk between
the 2011 Edition EHR certification criteria and the 2014 Edition EHR
certification criteria that we consider equivalent for the purposes of
revised CEHRT definition for any Federal FY or CY up to and including
2013. Table 5 below provides a general overview of the revised CEHRT
definition in relation to the stages of MU and the EHR reporting
periods in FY/CY 2011 through 2014.
[[Page 54261]]
[GRAPHIC] [TIFF OMITTED] TR04SE12.000
[[Page 54262]]
Table 5--Revised Definition of CEHRT
----------------------------------------------------------------------------------------------------------------
EHR Reporting Periods
-----------------------------------------------------------------------------------------------------------------
FY/CY 2011 FY/CY 2012 FY/CY 2013 FY/CY 2014
----------------------------------------------------------------------------------------------------------------
MU Stage 1 MU Stage 1 MU Stage 1 MU Stage 1 or MU Stage 2
----------------------------------------------------------------------------------------------------------------
All EPs, EHs, and CAHs must have: All EPs, EHs, and CAHs must
(1) EHR technology that has been certified to all applicable 2011 Edition EHR have EHR technology
certification criteria or equivalent 2014 Edition EHR certification criteria certified to the 2014
adopted by the Secretary; or Edition EHR certification
(2) EHR technology that has been certified to the 2014 Edition EHR certification criteria that meets the
criteria that meets the Base EHR definition and would support the objectives, Base EHR definition and
measures, and their ability to successfully report CQMs, for MU Stage 1. would support the
objectives, measures, and
their ability to
successfully report the
CQMs, for the MU stage
that they seek to achieve.
----------------------------------------------------------------------------------------------------------------
Comments. Some commenters expressed confusion about the impact of
our proposed revised CEHRT definition on our ``possession'' policy.
Response. In FAQs 9-10-017-2 \37\ and 12-10-021-1,\38\ we describe
our ``possession'' policy. We consider ``possessing'' (or ``having'')
Certified EHR Technology to include either the physical possession of
medium on which a certified Complete EHR or combination of certified
EHR Modules resides, or a legally enforceable right by an eligible
health care provider to access and use, at its discretion, the
capabilities a certified Complete EHR or combination of certified EHR
Modules includes. An eligible health care provider may determine the
extent to which it will implement or use these capabilities, which will
not affect the provider's ``possession'' of Certified EHR Technology.
In sum, prior to our revised CEHRT definition, an EP would need to
possess EHR technology certified to all mandatory certification
criteria for an ambulatory setting, and an EH or CAH would need to
possess EHR technology certified to all mandatory certification
criteria for an inpatient setting. As discussed above, this would still
hold true for FY/CY 2012 and 2013, unless an EP, EH, or CAH chooses to
use EHR technology that satisfies the FY/CY 2014 revised CEHRT
definition for those years. As also noted in our discussion above, our
revised CEHRT definition for FY/CY 2014 and subsequent years does limit
the potential quantity of EHR technology EPs, EHs, and CAHs would need
to ``possess'' to meet the CEHRT definition by requiring EPs, EHs, and
CAHs to have only EHR technology that meets the Base EHR definition and
would support the objectives and measures, and their ability to
successfully submit the CQMs, for the MU stage that they seek to
achieve.
---------------------------------------------------------------------------
\37\ http://healthit.hhs.gov/portal/server.pt/community/onc_regulations_faqs/3163/faq_17/20779.
\38\ http://healthit.hhs.gov/portal/server.pt/community/onc_regulations_faqs/3163/faq_21/21597.
---------------------------------------------------------------------------
We reiterate that an EP, EH, or CAH must continue to possess all of
a certified Complete EHR or certified EHR Module (i.e., the
capabilities for which certification is required) in order to receive
the benefit of such certification. An EP, EH, or CAH cannot purchase or
possess only ``components'' of a certified Complete EHR or certified
EHR Module for the purposes of meeting the CEHRT definition. That is,
unless independently certified, those ``components'' could not be used
to meet the CEHRT definition. We refer commenters to our discussion in
section III.B.4 of this preamble for further discussion related to
certifications issued to Complete EHRs and EHR Modules. Also, we seek
to make clear that the possession policy does not apply to those
capabilities that an EHR technology developer may include with those
that constitute a certified Complete EHR or certified EHR Module but
for which certification is not required. In those instances, because
these other included capabilities are not required for certification,
an EP, EH, or CAH, would not necessarily need to possess them if the
EHR technology developer would separately sell them. For more on this
point, we refer commenters to our ``EHR Technology Price Transparency''
discussion in section IV.F of this preamble.
2. Base EHR Definition
In the Proposed Rule, we proposed to add to Sec. 170.102 a new
defined term, ``Base EHR,'' which would essentially serve as a
substitute for the term ``Qualified EHR'' in the definition of CEHRT.
We stated that the Base EHR definition would reflect all of the
capabilities specified in the Qualified EHR statutory definition (that
is, in section 3000(13) of the PHSA) plus the additional capabilities
we proposed. We stated our intention to use the term ``Qualified EHR''
only as necessary and that its use would refer to the statutory
definition unless otherwise indicated. We stated that the term ``Base
EHR'' is more intuitive and conveys a plain language meaning. Moreover,
we noted that the term ``Qualified EHR'' does not inherently convey the
kinds of capabilities it includes. The term ``Base EHR,'' though,
conveys that EHR technology includes certain fundamental capabilities.
We also noted that the terms ``qualified EHR'' and ``qualified EHR
products'' have been used by CMS in other programs and with a different
meaning. Therefore, we concluded that the term ``Base EHR'' would be
more easily understood and readily accepted by stakeholders.
We proposed that the Base EHR definition would include all the
capabilities specified in the definition of a ``Qualified EHR'' under
section 3000(13) of the PHSA. We also proposed that it would include an
``extra'' privacy and security capacity beyond what the Qualified EHR
statutory definition required. Last, for clarity, we expressly listed
the certification criteria to which an EP, EH, or CAH would need to
make sure they had EHR technology certified in order to meet the Base
EHR definition.
With respect to CQMs, we proposed that the Base EHR definition
would include the certification criteria proposed at Sec.
170.314(c)(1) and (2). We stated that the inclusion of Sec.
170.314(c)(2) in a Base EHR ensures that EPs, EHs, and CAHs have the
capability to incorporate all the data elements of, and calculate, at
least one CQM. We stated that we anticipate that EHR technology
developers will design EHR technology to incorporate the data elements
for, and calculate, those CQMs
[[Page 54263]]
they believe their EHR technology would need to include in order to
support the providers to which they market their EHR technology. We
acknowledged, however, that this approach could leave a void in the
market for EHR technology that would support certain CQMs that EPs,
EHs, and CAHs would need to report beginning in 2014. Accordingly, we
sought comments on whether we should require certification to a set
number of CQMs as part of certification to Sec. 170.314(c)(2) and
provided potential options for such as an approach.
For one option, we stated that we could require EHR technology
designed for the ambulatory setting to be able to incorporate data
elements and calculate a specific number of CQMs for each of the CQM
``domains'' proposed by CMS for EPs in the Stage 2 proposed rule. For
EHR technology designed for the inpatient setting, we stated that we
could require that the EHR technology be able to incorporate data
elements and calculate a minimum threshold number of CQMs proposed by
CMS for EHs and CAHs (e.g., 24 or 36). Conversely, we noted a potential
challenge with this more explicit approach. In order for EPs, EHs, and
CAHs to have EHR technology that would meet the definition of a Base
EHR, their EHR technology developers could be required to demonstrate
that their EHR technology can incorporate and calculate data for
certain CQMs that may ultimately be irrelevant their customers, but
nonetheless are necessary for the EHR technology to be certified.
We also requested comment on whether a Base EHR should include, in
addition to Sec. 170.314(c)(1) and (2), the CQM reporting
certification criteria proposed at Sec. 170.314(c)(3), which would
enable a user to electronically create a data file for transmission of
clinical quality measurement results to CMS.
With respect to the ``privacy and security'' certification criteria
associated with the Base EHR definition's proposed capacity to protect
the confidentiality, integrity, and availability of health information
stored and exchanged, we proposed that the certification criteria
should apply equally to both the ambulatory and inpatient settings. We
specifically requested public comment on whether there should be a
distinction between the ambulatory and inpatient settings for EHR
technology certification to the privacy and security certification
criteria.
Comments. Commenters expressed support for the Base EHR definition
and how it serves as the foundation of the CEHRT definition. However,
it was also evident from comments that many commenters misunderstood
the proposed Base EHR concept. That is, they interpreted the Base EHR
as a singular, independent type of EHR technology that could or would
be separately certified.
One commenter suggested adding a capacity to the Base EHR
definition, including the ability to produce a health record for legal,
business, and disclosure purposes. Other commenters suggested including
additional certification criteria in the Base EHR definition, such as
new certification criteria addressing nutrition, diet, and allergies,
or proposed certification criteria such as family health history,
electronic notes, and automated measure calculation. Conversely, other
commenters suggested removing certification criteria from the Base EHR
definition. One of these commenters suggested limiting the
certification criteria included in the Base EHR definition to the
minimum number of certification criteria that would still be consistent
and compliant with the HITECH Act. Multiple commenters suggested not
including certification criteria with capabilities that would not be
needed by all EPs, EHs, and CAHs to attempt to achieve MU. These
commenters contended that this would increase flexibility for EPs, EHs,
and CAHs as well as prevent them from incurring unnecessary costs by
being required to purchase unwanted and unwarranted EHR technology.
More specifically, commenters suggested removing the ``vital signs''
certification criterion (Sec. 170.314(a)(4)), the ``drug-drug, drug-
allergy interaction check'' certification criterion (Sec.
170.314(a)(2)), and the ``view, download, and transmit to 3rd party''
certification criterion (Sec. 170.314(e)(1)). Commenters did, however,
express support for keeping the privacy and security certification
criteria in the Base EHR definition.
Commenters suggested that certification for privacy and security
should be consistent across both ambulatory and inpatient settings.
Commenters did, however, express confusion over how privacy and
security certification criteria correlated with other certification
criteria included in the Base EHR definition as well as other
certification criteria in general. In particular, commenters asked
whether the privacy and security capabilities needed to integrate with
the capabilities included in the other certification criteria that are
part of the Base EHR definition. If such integration is not required,
commenters suggested that we consider requiring integration
certification, particularly where the capabilities do not share a
common security architecture. One commenter asked for confirmation as
to whether EPs, EHs, and CAHs bear the responsibility for appropriately
implementing the privacy and security capabilities included in the Base
EHR definition, including with other capabilities of their CEHRT they
use to attempt to achieve MU.
Commenters expressed concern about the proposed CQM certification
criteria included, or considered for inclusion, in the Base EHR
definition. In response to our specific request for comment, many
commenters strongly recommended that, as part of the Base EHR
definition, we require certification to all CQMs by the setting the EHR
technology is designed to meet. As an alternative approach, commenters
suggested establishing a list of CQMs for certification by practice
setting (e.g., cardiology, pediatrics, etc.) and that the list(s) be
part of the Base EHR definition. One commenter suggested that the ``CQM
reporting'' certification criterion (Sec. 170.314(c)(3)) be included
in the Base EHR definition as a means of providing additional
flexibility for those wishing to contain the measures within their
local data warehouse infrastructure. Conversely, another commenter
stated that not all EPs, EHs, and CAHs will need the CQM reporting
capability and that it should not be a certification criterion that is
part of the Base EHR definition.
Response. We appreciate the support expressed for the Base EHR
definition. First, we would like to make clear that the Base EHR
definition must be satisfied in order to meet the CEHRT definition.
Stated another way, EPs, EHs, and CAHs should treat the Base EHR
definition like a checklist. In order to ultimately have EHR technology
that meets the CEHRT definition, an EP, EH, or CAH must ensure that the
EHR technology it has first meets the Base EHR definition. We also want
to make clear that the Base EHR definition is not meant to convey our
expectation that EHR technology must be separately certified as ``a
Base EHR.'' Nor should it be interpreted to mean that EHR technology
presented for certification must include all the certification criteria
included in the Base EHR definition. Rather, similar to the revised
CEHRT definition, the Base EHR definition can be satisfied through a
number of ways: (1) A certified Complete EHR; (2) a single certified
EHR Module; (3) a combination of separately certified EHR Modules; or
(4) a combination of 1 through 3.
As stated above and in the Proposed Rule, we believe that the Base
EHR
[[Page 54264]]
definition should include the fundamental capabilities that any EP, EH,
or CAH must have to demonstrate MU. Therefore, we are revising the
proposed Base EHR definition to be more consistent with this approach.
First, we agree with commenters that certain certification criteria
should be removed from the Base EHR definition. In particular, we have
removed the certification criteria for ``vital signs'' (Sec.
170.314(a)(4)), ``drug-drug, drug-allergy interaction check'' (Sec.
170.314(a)(2)), and ``view, download, and transmit to 3rd party''
(Sec. 170.314(e)(1)). The capabilities specified by these three
certification criteria are not necessarily needed by all EPs, EHs, and
CAHs to support their achievement of MU.
Second, based on public comments, we have added one new
certification criterion to the Base EHR definition. In response to our
request for comments in the Proposed Rule and as discussed in section
III.A.8 of this preamble, we received overwhelming feedback from EPs,
EHs, and CAHs recommending that steps be taken to improve data
portability. In response, we have adopted an initial data portability
certification criterion and have included it in the Base EHR
definition. We believe this initial data portability certification
criterion directly aligns with the statutory capacity specified in the
PHSA ``Qualified EHR'' definition ``to exchange electronic health
information with, and integrate such information from other sources.''
We believe that by including this certification criterion in the Base
EHR definition it will provide EPs, EHs, and CAHs with a mechanism to
potentially expedite and enhance the migration of data from one EHR
technology to another.
As noted above, the capabilities to capture (Sec. 170.314(c)(1))
and calculate (Sec. 170.314(c)(2)) CQMs remain part of the Base EHR
definition. The ability to capture information relevant to health care
quality aligns with statutory requirements for the Base EHR definition
and we believe the ability to calculate CQMs through EHR technology is
a fundamental capability all EPs, EHs, and CAHs should have to support
their achievement of MU and their own continuous quality improvement.
We have also amended our proposed Base EHR definition to require
certification to no fewer than the minimum number of CQMs that an EP,
EH, or CAH must report under the EHR Incentive Programs beginning in
FY/CY 2014. Additionally, in light of the fact that CMS identified for
EPs a subset of CQMs as a ``recommended core,'' we are separately
requiring that to meet the Base EHR definition EPs must have EHR
technology that has been certified to Sec. 170.314(c)(1) and Sec.
170.314(c)(2) for at least 6 CQMs from the ``recommended core.'' This
final rule provision is meant to complement CMS' reporting
requirements. We included this additional provision to support and
highlight the ``recommended core'' CQMs prioritized by CMS. Further, we
believe that by including this requirement in the Base EHR definition,
EHR technology developers will seek to be certified to those
``recommended core'' CQMs that are most relevant to their customer
base. As a result, EPs will then have the ability to report on some
portion of the ``recommended core'' CQMs in support of CMS' CQM policy
priorities.
In order for an EP to have EHR technology that meets the Base EHR
definition, he or she would need to have EHR technology certified to
Sec. 170.314(c)(1) and Sec. 170.314(c)(2) for no fewer than 9 CQMs
that in total cover at least 3 domains and include at least 6 CQMs from
the recommended ``core set'' for adult and pediatric populations as
identified in the Stage 2 final rule published elsewhere in this issue
of the Federal Register. In other words, of the minimum of 9 CQMs
necessary to meet the Base EHR definition, at least 6 CQMs must be from
the recommended core set identified by CMS, and altogether the 9 CQMs
must cover at least 3 domains. In support of the Million Hearts \39\
initiative, we strongly urge EHR technology developers that serve
customers for which NQF 0018 (Controlling High Blood Pressure) and NQF
0028 (Preventive Care and Screening: Tobacco Use: Screening and
Cessation Intervention) would be applicable to include these two CQMs
as part of the 6 recommended core set CQMs selected for certification.
These two CQMs support this HHS priority and will be broadly leveraged
through many Federal quality measurement programs.
---------------------------------------------------------------------------
\39\ http://millionhearts.hhs.gov/index.html.
---------------------------------------------------------------------------
Similarly, in order for an EH or CAH to have EHR technology that
meets the Base EHR definition, it would need to have EHR technology
certified to Sec. 170.314(c)(1) and Sec. 170.314(c)(2) for no fewer
than 16 CQMs that cover at least 3 domains as identified in the Stage 2
final rule published elsewhere in this issue of the Federal Register.
Additionally, by setting this minimum requirement, EHR technology
developers will now need to ensure that their EHR technology includes
the appropriate amount of CQMs if they seek to market their EHR
technology as meeting the Base EHR definition.
We decline to establish a list of CQMs by practice specialty for
certification. Considering the evolving nature of CQM specification and
development, the applicability and availability of CQMs for different
scopes of practice, and the varied customer bases of EHR technology
developers, we believe that this option would be both infeasible and
impractical at the present time. We also decline to include as part of
the Base EHR definition, even for the inpatient setting, a requirement
that EHR technology must be certified to all of the CQMs selected by
CMS for the EHR Incentive Programs because of instances where this type
of policy approach would require EPs (because of scope of practice) and
EHs and CAHs (e.g., children's hospitals and hospitals without an
emergency department) to have EHR technology certified for CQMs on
which they would have no information relevant to health quality to
report. We believe the policy we have established minimizes this type
of situation from occurring. It also seeks to balance the potential
burden faced by EHR technology developers to include and get their EHR
technology certified to CQMs on which their customers would not
necessarily have information relevant to health quality to report. We
acknowledge that EHR technology developers get to choose the CQMs to
which their EHR technology is certified and that those CQMs may not
necessarily meet the needs of every EP, EH or CAH. We continue to
believe, however, that EHR technology developers will be cognizant of
their customers' needs and will in most cases select CQMs for
certification that can broadly support their customer base. EPs, EHs,
and CAHs can also consult the CMS MU Stage 2 final rule to determine
whether the EHR technology they intend to purchase has the necessary
CQM capabilities. Last, we have included in the Base EHR definition the
capability to electronically submit CQMs as specified by the
certification criterion at Sec. 170.314(c)(3). As noted under the
discussion of CQM submission earlier in this preamble, EHR technology
certified to Sec. 170.314(c)(3) is required to enable the electronic
submission of CQM data to CMS according to adopted standards. We
believe that this capability will be useful to all EPs, EHs, and CAHs
because it is now structured to support the electronic submission of
CQMs for MU or as applicable under PQRS. Accordingly, we believe that
it is appropriate and beneficial to include
[[Page 54265]]
this capability and certification criterion in the Base EHR definition.
Last, we decline to expand the Base EHR definition beyond those
capabilities already proposed and the one addition we discuss above
because requiring the additional capabilities and certification
criteria suggested by some commenters would be inconsistent with our
stated approach of only requiring in the Base EHR definition
capabilities that are as universally applicable as possible.
With these revisions to the proposed Base EHR definition, we now
limit the definition to those certification criteria that most closely
align with the capacities specified in the definition of a ``Qualified
EHR'' under section 3000(13) of the PHSA and, as supported by
commenters, improve data portability and protect the confidentiality,
integrity and availability of patient health information. We see this
as the most appropriate starting point from which to potentially expand
(as necessary) the Base EHR definition in future rulemakings.
Furthermore, this modified Base EHR definition gives EPs, EHs, and CAHs
even more flexibility than we had proposed and could potentially
further reduce CEHRT adoption costs.
We agree with commenters that, as proposed, certification for
privacy and security should be consistent across both ambulatory and
inpatient settings. The privacy and security certification criteria
included in the Base EHR definition are designed to provide EPs, EHs,
and CAHs with basic technical capabilities that can support compliance
with parts of the HIPAA Privacy and Security Rules. As we stated in the
Proposed Rule, EPs, EHs, and CAHs are responsible for implementing
their CEHRT in ways that meet applicable privacy and security
requirements under Federal law (such as the HIPAA Privacy Rule and
Security Rule and 42 CFR Part 2) and applicable state law. The Base EHR
definition gives EPs, EHs, and CAHs the flexibility to implement and
combine EHR technology capabilities (particularly those capabilities
used for MU) in their healthcare environment in ways that they
determine are the most functional (e.g., with various different
certified EHR Modules), efficient, and cost effective.
``Integration certification'' is not currently part of the
temporary certification program nor is it included in the ONC HIT
Certification Program. We responded to similar comments in a prior
rulemaking (76 FR 1273) that integration certification was impractical
because of technical and logistical concerns (e.g., the integrated
healthcare environment of a hospital) as well as financial costs (e.g.,
bringing certified EHR Modules from different EHR technology developers
together for additional certification after being separately
certified). For these reasons, we continue to believe that such
certification should not be part of the ONC HIT Certification Program
at this time, even for only privacy and security. We reiterate,
however, our position stated in the Permanent Certification Program
final rule (76 FR 1273) that nothing precludes an ONC-ACB or other
entity from offering a service to certify EHR Module-to-EHR Module
integration. To be clear, although we do not require or specifically
preclude an ONC-ACB from certifying EHR Module-to-EHR Module
integration, any EHR Module-to-EHR Module certification performed by an
ONC-ACB or other entity will be done without specific authorization
from the National Coordinator and will not be considered part of the
ONC HIT Certification Program.
The Base EHR definition is included at Sec. 170.102 and has been
revised to remove the certification criteria referenced in the
discussion above, to add in a minimum number of CQMs for the ambulatory
and inpatient settings, and to add the certification criterion at Sec.
170.314(c)(3). Table 6 below specifies the 2014 Edition EHR
certification criteria included in the Base EHR definition and the Base
EHR capacities they support. To note, as mentioned under section
III.B.1 ``Revisions to the Definition of Certified EHR Technology,''
the Base EHR definition will now be one part of an optional means for
meeting the definition of CEHRT for any FY or CY up to and including
2013.
Table 6--Certification Criteria Required To Satisfy the Base EHR
Definition
------------------------------------------------------------------------
EHR technology that: Certification criteria
------------------------------------------------------------------------
Includes patient demographic and Demographics Sec.
clinical health information, such as 170.314(a)(3).
medical history and problem lists. Problem List Sec.
170.314(a)(5).
Medication List Sec.
170.314(a)(6).
Medication Allergy List Sec.
170.314(a)(7)
Has the capacity to provide clinical Clinical Decision Support Sec.
decision support. 170.314(a)(8).
Has the capacity to support physician Computerized Provider Order
order entry. Entry Sec. 170.314(a)(1).
Has the capacity to capture and query Clinical Quality Measures Sec.
information relevant to health care 170.314(c)(1) through (3).
quality.
Has the capacity to exchange electronic Transitions of Care Sec.
health information with, and integrate 170.314(b)(1) and (2) Data
such information from other sources. Portability Sec.
170.314(b)(7).
Has the capacity to protect the Privacy and Security Sec.
confidentiality, integrity, and 170.314(d)(1) through (8).
availability of health information
stored and exchanged.
------------------------------------------------------------------------
3. Complete EHR Definition
We stated in the Proposed Rule that we intended to maintain the
concept of a Complete EHR and permit EHR technology developers to seek
Complete EHR certifications for their EHR technology. We proposed,
however, to revise the Complete EHR definition for clarity to mean
``EHR technology that has been developed to meet, at a minimum, all
mandatory certification criteria of an edition of certification
criteria adopted by the Secretary for either an ambulatory setting or
inpatient setting.''
Comments. We received a few comments expressing support for our
proposed revised Complete EHR definition.
Response. We are revising our approach to the Complete EHR
definition based on modifications we have made to the Base EHR
definition and to clarify the applicability of the revised CEHRT
definition for any FY or CY up to and including 2013 to a Complete EHR.
In our proposal, a Complete EHR would have inherently met the Base EHR
definition because it would have required certification to all the
certification criteria included in the proposed Base EHR definition. We
have, however, modified the Base EHR definition to require that EHR
technology be certified to a minimum
[[Page 54266]]
number of CQMs per the ambulatory or inpatient setting in order to meet
the Base EHR definition, which will require certification to Sec.
170.314(c)(1) and (2) for more than one CQM. To ensure that a Complete
EHR encompasses the Base EHR definition, we are establishing two
separate Complete EHR definitions, one for the 2011 Edition EHR
certification criteria and one for the 2014 Edition EHR certification
criteria. As stated in the Proposed Rule, for certification to the 2011
Edition EHR certification criteria, a Complete EHR designed for an
ambulatory setting must meet the mandatory certification criteria
adopted at Sec. Sec. 170.302 and 170.304, while a Complete EHR
designed for an inpatient setting must meet the mandatory certification
criteria adopted under Sec. Sec. 170.302 and 170.306. For
certification of a Complete EHR to the 2014 Edition EHR certification
criteria, EHR technology must meet the Base EHR definition and all
mandatory certification criteria for either the ambulatory or inpatient
setting. Our addition of paragraph (d) to Sec. 170.300 and the use of
``ambulatory setting only'' and ``inpatient setting only'' headings
within Sec. 170.314 clarifies which certification criteria have
general applicability (apply to both ambulatory and inpatient settings)
or apply only to an inpatient setting or an ambulatory setting.
Additionally, we have made a guidance document available on our Web
site that clearly specifies the 2014 Edition EHR certification criteria
that apply to a Complete EHR designed for the ambulatory setting and a
Complete EHR designed for an inpatient setting.
Our revised CEHRT definition for any FY or CY up to and including
2013 states that a Complete EHR meets the definition if it ``meets the
requirements included in the definition of a Qualified EHR and has been
tested and certified in accordance with the certification program
established by the National Coordinator as having met all applicable
certification criteria adopted by the Secretary for the 2011 Edition
EHR certification criteria or the equivalent 2014 Edition EHR
certification criteria.'' We want to make clear that, although the
``equivalency option'' permits EPs, EHs, and CAHs to use a combination
of EHR technology certified to the 2011 Edition and 2014 Edition EHR
certification criteria to meet the revised CEHRT definition, a
certification cannot be issued for a Complete EHR based on a
combination of 2011 Edition and 2014 Edition EHR certification
criteria. This would be inconsistent with how we described a Complete
EHR in the Proposed Rule and with our ``representation requirement''
for Complete EHRs and EHR Modules certified under the ONC HIT
Certification Program at Sec. 170.523(k)(1)(i) (i.e., 2011 Edition or
2014 Edition compliant). Further, we believe a Complete EHR certified
to a combination of 2011 Edition and 2014 Edition EHR certification
criteria would cause confusion for EPs, EHs, and CAHs, particularly
when transitioning to meet the CEHRT definition for FY/CY 2014 and
subsequent years, which only permits EPs, EHs, and CAHs to use of EHR
technology certified to the 2014 Edition EHR certification criteria to
meet the definition. Accordingly, we are replacing the Complete EHR
definition at Sec. 170.102 with the 2011 Edition Complete EHR
definition described above and adding the 2014 Edition Complete EHR
definition also as described above.
4. Certifications Issued for Complete EHRs and EHR Modules
We restated frequently asked question (FAQ) 9-10-005-1 \40\ and its
supporting policy rationale in the Proposed Rule. FAQ 9-10-005-1
clarifies that a stand-alone, separate component of a certified
Complete EHR cannot derive ``certified'' status based solely on it
having been included as part of the Complete EHR when the Complete EHR
was certified. We noted that this same principle applies to certified
EHR Modules with multiple capabilities in that the components of the
EHR Modules cannot be separately sold or purchased as certified EHR
technology unless they have been separately certified.
---------------------------------------------------------------------------
\40\ http://healthit.hhs.gov/portal/server.pt/community/onc_regulations_faqs/3163/faq_5/20767.
---------------------------------------------------------------------------
Comments. We received two comments that supported our policy and a
comment that criticized it. The commenter that offered criticism stated
that EHR technology developers have been inclined to only get their EHR
technology certified as Complete EHRs and have not obtained
certification for their EHR technologies in the form of EHR Modules
that would best benefit EPs, EHs, and CAHs. The commenter stated that
as a consequence, EPs, EHs, and CAHs must possess more EHR technology
than they need or want from a particular EHR technology developer. The
commenter further stated that the option of EHR technology self-
developer certification to address such situations was not a viable
option because of the costs and complexity to pursue such an approach
was too daunting for most EPs, EHs, and CAHs. The commenter suggested
that as an alternative that we require that every Complete EHR
presented for certification also be certified as individual EHR
Modules.
Response. After consideration of the comments received, we reaffirm
our policy incorporated in FAQ 9-10-005-1. We believe that allowing
separate components of a certified Complete EHR or certified EHR Module
to derive ``certified'' status from the certification of the entire
certified Complete EHR or certified EHR Module would undermine the
purpose of the ONC HIT Certification Program. As stated in the Proposed
Rule, it would permit EHR technology developers to ``self-declare''
certifications for components of a certified Complete EHR or certified
EHR Module that have never been independently reviewed by an ONC-ACB as
actually being able to work as separate, independent technologies. This
approach could result in inaccurate, deceptive, or false
representations about an EHR technology's capabilities. Furthermore, it
is important for all stakeholders to recognize that a certification is
assigned to a Complete EHR or EHR Module, not to a capability. And, as
we look forward towards the development and introduction of combined
and/or workflow-based test procedures, one would be unable to infer
that a specific component of a certified Complete EHR or certified EHR
Module was compliant with a particular certification criterion unless
the component had been separately certified as performing the required
capability.
In regard to the commenter's specific suggestion that we require
Complete EHR technology developers to have their Complete EHR also
certified as EHR Modules, we reiterate that, in accordance with PHSA
section 3001(c)(5), the act of seeking certification is voluntary. More
importantly, in some cases it may not be practicable (from an EHR
technology design and functionality perspective or financially or
otherwise) for an EHR technology developer to seek separate
certifications for its EHR technology (Complete EHR or EHR Module) as a
more limited EHR Module or even in a manner that meets the needs of a
particular EP, EH, or CAH. Further, we question whether such an
approach could be equitably operationalized. There does not readily
appear to be an objective, non-arbitrary and practical way to identify
the make-up of each potentially smaller EHR Module that would need to
be certified from a Complete EHR or large EHR Module. With these
considerations in mind, we strongly encourage EHR technology developers
to seek, where possible,
[[Page 54267]]
certification for separate components of a certified Complete EHR or
certified EHR Module that would provide the solutions that EPs, EHs,
and CAHs seek to adopt. Additionally, from a practical perspective, we
believe our more flexible CEHRT definition will spur EHR technology
developers to move in this direction at a much more rapid pace.
5. Adaptations of Certified Complete EHRs or Certified EHR Modules
We stated in the Proposed Rule that it would be possible for an EHR
technology developer of a certified Complete EHR or certified EHR
Module (and only that EHR technology developer) to create an adaptation
of a certified Complete EHR or certified EHR Module without the need
for additional certification of the adaptation. We went on to say that
we consider an ``adaptation'' of a certified Complete EHR or certified
EHR Module to be a software application designed to run on a different
medium, which includes the exact same capability or capabilities
included in the certified Complete EHR or certified EHR Module. As an
example, we indicated that an adaptation of a certified Complete EHR
that is capable of running on a tablet device or smart phone could
include the capabilities of a certified Complete EHR to e-prescribe,
take electronic notes, and manage a patient's active medication list.
In this example, we specified that the adaptation would be covered by
the Complete EHR's certification so long as the adaptation included the
full and exact same capabilities required for the particular
certification criteria to which the Complete EHR was certified (i.e.,
in this case, the capabilities required by the certification criteria
proposed at Sec. 170.314(b)(3), (a)(9), and (a)(6), respectively)). We
noted that the user of the adaptation would need to ensure, perhaps
through contractual assurances from the EHR technology developer that
provides such adaptation, that the adaptation does not introduce
privacy and security vulnerabilities into the certified Complete EHR or
certified EHR Module. We further noted that, while an EHR technology
developer may create an adaptation without needing to obtain an
additional certification, the adaptation would be subject to the
provisions of the certification issued for the Complete EHR or EHR
Module. ONC-ATCBs and ONC-ACBs maintain authority over the
certifications that they issue and can take appropriate action when
there is evidence of non-conformance with those certifications.
Comments. Many commenters supported our approach to adaptations.
Some commenters did not, however, support extending a Complete EHR's or
EHR Module's certification to adaptations without further evaluation by
ONC-ACBs. These commenters expressed concern about an adaptation's
privacy and security capabilities, noting that such capabilities will
be fundamentally different from device to device. Commenters also
requested that we further clarify the term ``full and exact same
capabilities.'' Some commenters suggested a strict interpretation of
the term so that EPs, EHs, and CAHs could be confident that their
adapted EHR technology performs and interoperates as seamlessly as the
certified Complete EHR or certified EHR Module. Last, commenters
inquired about how this process would be monitored. For example,
commenters asked whether EHR technology developers needed to seek
formal inclusion of adaptations in their original certification and/or
attest that the adaptation has the ``exact same capabilities'' as the
certified Complete EHR or certified EHR Module.
Response. We are implementing our adaptation policy as explained in
the Proposed Rule and supplemented by the additional guidance provided
here in this final rule. As noted in the Proposed Rule, we believe
adaptations can serve as innovative ways to facilitate efficient
workflows and user interactions. While we believe our example recited
above and in the Proposed Rule specifies what constitutes ``full and
exact same capabilities,'' we provide the following as additional
clarification. In order for a software application to be treated as an
adaptation (and not as a unique, stand-alone EHR Module or Complete EHR
for which a separate certification would be required) it must include
the full and exact same capabilities required by the certification
criteria to which the EHR technology it is serving as an adaptation of
was certified. Stated another way, an adaptation cannot partially
address the capabilities required by a certification criterion. To
illustrate this simply, an adaptation of a certified Complete EHR would
need to enable a user to record all of the demographics specified at
Sec. 170.314(a)(3) and would not be in compliance with this policy if
it only provided a user the ability to record a patient's race and
ethnicity. Further, we acknowledge that adaptations will naturally
require the certified Complete EHR or certified EHR Module's user
interface and other design features to be changed in order to perform
efficiently on mobile platforms. Again, our concern is that the
capabilities included in the adaptation and available to a user are a
one-for-one match with the capabilities that have been adapted from the
certified Complete EHR or certified EHR Module. In other words, an
adaptation may include less overall capabilities than the certified
Complete EHR or certified EHR Module, but for those capabilities it
does include they must be the full and exact same capabilities for
which certification is required. For example, it would be acceptable
for an adaptation to include the full and exact same capabilities
specified by 3 of the 10 certification criteria to which an EHR Module
was certified.
We appreciate the concerns expressed by commenters related to
privacy and security, but remind commenters of certification's
limitations. Certification is not a substitute for, or guarantee of,
compliance with the HIPAA Privacy and Security Rules. Certification is
designed to provide EPs, EHs, and CAHs with basic technical
capabilities that can support compliance with parts of the HIPAA
Privacy and Security Rules. EPs, EHs, and CAHs remain responsible for
implementing their CEHRT in ways that meet applicable privacy and
security requirements under Federal law (such as the HIPAA Privacy Rule
and Security Rule and 42 CFR Part 2) and applicable state law. We would
expect that EHR technology developers would include the relevant
privacy and security capabilities in their adaptations where
appropriate. For example, we would expect that an adaptation designed
to run on a mobile device would employ authentication, access control,
and authorization capabilities consistent with those specified in the
certification criterion adopted at Sec. 170.314(d)(1). Similarly, we
could see scenarios where electronic health information used or
processed by an adaptation could be protected in accordance with the
``end-user device encryption'' certification criterion adopted at Sec.
170.314(d)(7)(i). As noted above and in the Proposed Rule, an EP, EH,
or CAH should take steps to ensure, perhaps through contractual
assurances from the EHR technology developer that provides such
adaptation, that privacy and security capabilities are implemented
appropriately and that the adaptation does not introduce privacy and
security vulnerabilities into the certified Complete EHR or certified
EHR Module. An EP, EH, and CAH should also take independent steps, or
again through contractual assurances from the EHR technology developer
that provides such adaptation, to address any privacy and security
vulnerabilities that may be introduced by the different medium(s) on
which the adaptation runs.
[[Page 54268]]
An adaptation would need to be based on an already certified
Complete EHR or certified EHR Module in order to be treated as being
part of the certification issued to these EHR technologies. In this
regard, an EHR technology developer would not need to obtain an
additional certification for an adaptation nor have to attest to the
functionality, capabilities, or otherwise for an adaptation. We believe
that contractual relationships with customers and compliance with
certifications issued by ONC-ATCBs and ONC-ACBs should be sufficient
measures to ensure the integrity of adaptations, while eliminating the
burden and costs of certification and attestation on EHR technology
vendors and their customers (EPs, EHs, and CAHs). EPs, EHs, and CAHs
should take note that absent an EHR technology developer actively
seeking a separate certification for an adaptation (which would not be
required under our policy), the adaptation itself would not be
independently listed on the CHPL because it is considered part of the
certification of a previously certified Complete EHR or certified EHR
Module. Thus, an EP, EH, and CAH would need to select as part of its
attestation process the certified Complete EHR or certified EHR Module
from which the adaptation was created. Last, we seek to make clear that
an EHR technology developer can always seek certification for its
adaptation. Certification of the adaptation would lead to its listing
on the CHPL and would permit the EHR technology developer to openly
sell the adaptation to all potential purchasers since it would be
separately certified.
IV. Provisions of the Proposed Rule Affecting the Permanent
Certification Program for HIT (``ONC HIT Certification Program'')
A. Program Name Change
As explained in the Proposed Rule, we have established two
certification programs, the ``temporary certification program for HIT''
and the ``permanent certification program for HIT'' (see 75 FR 36158
and 76 FR 1262, respectively). We noted in the Proposed Rule that we
expected that the permanent certification program would replace the
temporary certification program upon the effective date of this final
rule. As we discussed, at that time, there would no longer be a need to
continue to differentiate between the certification programs based on
their expected duration. Therefore, we proposed to replace all
references in Part 170 of the Code of Federal Regulations to the
permanent certification program with ``ONC HIT Certification Program.''
Comments. A few comments expressed agreement with our proposal to
change the program name. A commenter noted that having two names was
somewhat confusing and that shifting to one name would be desirable.
Response. We thank these commenters for their support and have
finalized our proposal. We are revising subpart E of Part 170, Title
45, Subtitle A, Subchapter D of the Code of Federal Regulations to
replace all references to the ``permanent certification program'' with
``ONC HIT Certification Program.'' We believe this new program name
provides clear attribution to the agency responsible for the program
and an appropriate description of the program's scope, covering both
current and future HIT certification activities. We also note that, as
we indicated in the Proposed Rule and in our notice published in the
Federal Register on November 3, 2011 (76 FR 68192), the temporary
certification program will officially sunset upon the effective date of
this final rule and will be replaced with the ONC HIT Certification
Program. When the temporary certification program sunsets, ONC-
Authorized Testing and Certification Bodies (ONC-ATCBs) will be
prohibited from accepting new requests to test and certify EHR
technology and will be permitted up to six months after the sunset date
to complete all testing and certification activities associated with
requests received prior to the sunset date. If these activities are not
completed within the 6-month period, the EHR technology would have to
be resubmitted for testing and certification under the ONC HIT
Certification Program.
B. ``Minimum Standards'' Code Sets
In the Proposed Rule, we described the current process for the
Secretary to identify and accept newer versions of ``minimum
standards'' code sets. Section 170.555 allows ONC-ACBs to certify
Complete EHRs and/or EHR Modules to newer versions of certain code sets
identified as ``minimum standards'' in Subpart B of part 170 if the
Secretary has accepted a newer version for certification and
implementation of EHR technology. We explained that, 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 also stated, based on the ``minimum
standards'' code sets we have previously adopted and the ones proposed,
that permitting EHR technology to be upgraded and certified to newer
versions of these code sets would not normally pose an interoperability
risk, cause unintended consequences, or place an undue burden on the
HIT industry. Therefore, we proposed to revise Sec. 170.555 such that,
unless the Secretary prohibits the use of a newer version of a
``minimum standards'' code set identified in subpart B of part 170, the
newer version could be used voluntarily for certification and
implemented as an upgrade to a previously certified Complete EHR or EHR
Module without adversely affecting the EHR technology's certified
status. In consideration of this proposed new approach, we clarified
that when we refer to a ``newer'' version of a ``minimum standard''
code set, we mean a final version or release as opposed to a draft
version or release of a code set.
We outlined a process for determining when to prohibit the use of a
newer version of a ``minimum standards'' code set that was similar to
the process we used for accepting newer versions of ``minimum
standards'' code sets. The public could inform ONC or the Secretary
could proactively identify a newer version of a ``minimum standard''
code set that may not be appropriate for use. We indicated our
expectation that we would still seek a recommendation from the HITSC,
based on their assessment of the newer version and on any public
comments that they receive, as to whether the Secretary should prohibit
the use of the newer version of the ``minimum standard'' code set.
After considering the HITSC's recommendation, the National Coordinator
would make a recommendation to the Secretary as to whether or not to
allow the continued use of the newer version. Finally, if the Secretary
decides to prohibit the use of a newer version of a minimum standard
code set, we stated that we would issue guidance indicating that the
newer version of the adopted ``minimum standards'' code set cannot be
used for certification under the ONC HIT Certification Program, and
thus upgrading previously certified Complete EHRs and EHR Modules to
the newer version would adversely affect their certified status.
As an exception to the process outlined above, we specified that,
in limited circumstances, it may be necessary for the Secretary to act
more quickly to prohibit the use of a newer version of a ``minimum
standards'' code set. Instances could arise where the use of a newer
version of a ``minimum standards'' code set may have an immediate
negative effect on
[[Page 54269]]
interoperability, cause an obvious unintended consequence, or pose an
undue burden on the HIT industry. Therefore, under such circumstances,
we specified that the Secretary may choose to prohibit the use of a
newer version of a ``minimum standards'' code set for purposes of
certification and upgrading certified EHR technology without seeking a
recommendation from the HITSC in advance.
To provide additional clarity and consistency, we proposed to also
make minor revisions to the text of Sec. 170.555, including removing
the terms ``adopted'' and ``accepted'' and replacing the term
``Certified EHR Technology'' in Sec. 170.555(b)(2) with ``A certified
Complete EHR or certified EHR Module.''
Comments. Most commenters supported our proposal to revise the
process for permitting the use of new versions of ``minimum standards''
code sets. Several commenters commended our proposed approach and
indicated it would reduce regulatory complexity and burden by providing
the industry with the flexibility to quickly utilize newer versions of
adopted ``minimum standards'' code sets. A few of the commenters that
agreed also expressed concern that it may be difficult for EPs, EHs,
and CAHs to reconcile different code set releases if one EHR technology
developer rolls them out faster than another. A few other commenters
recommended that we should require backward compatibility as a
condition for Secretary acceptance of newer versions of code sets.
These commenters stated this would serve as a means of mitigating the
challenges associated with different code set releases. A couple of
commenters also recommended that providing technical support for
previous versions should be a condition of certification of EHR
technology to newer versions of ``minimum standards'' code sets. One
commenter specifically suggested that support for the previous version
be offered for at least 12 to 18 months unless otherwise abandoned due
to extenuating circumstances (e.g., security or patient safety
concerns). One commenter suggested that when a newer version release is
available and accepted by the Secretary (with or without a
recommendation from the HITSC) that there be a period of 180 days when
vendors may test to either the previous or newer versions of the
standard. Another commenter recommended that a regular and rational
strategy be established to refresh the ``minimum standards'' called for
in MU.
Response. We appreciate the comments submitted in support of our
proposal and are revising Sec. 170.555 such that, unless the Secretary
prohibits the use of a newer version of a ``minimum standards'' code
set identified in subpart B of part 170, the newer version could be
used voluntarily for certification and implemented as an upgrade to a
previously certified Complete EHR or certified EHR Module without
adversely affecting the EHR technology's certified status. We believe
this approach reduces regulatory complexity and provides the industry
with the flexibility to utilize newer versions of adopted ``minimum
standards'' code sets without regulatory interference. We are also
finalizing our proposal to make the minor text changes to Sec.
170.555, as well as the process we outlined in the Proposed Rule for
determining when to prohibit the use of a newer version of a ``minimum
standards'' code set and the exception to that process.
With respect to the comments regarding the additional condition of
certification for technical support, timing for when new versions of
the code sets are released, and a schedule to refresh the ``minimum
standards'' that would be required as part of MU, we believe that these
commenters may have misinterpreted the flexibility and approach offered
by our proposal and the way in which newer versions of ``minimum
standards'' code sets would be treated by the final rule. Therefore, we
offer this additional explanation. In general, we understand that the
code sets we have identified as ``minimum standards'' code sets are
frequently updated to keep pace with industry needs. For example, when
a new medication becomes available, a new code for that medication
would be added to the next release of RxNorm. As finalized, our
revision to Sec. 170.555 permits an EHR technology developer to, for
example, immediately include that newer version of RxNorm when
presenting its Complete EHR or EHR Module for certification rather than
having to use the older version adopted in the Code of Federal
Regulations in order to get certified. As we explained, inclusion of
the newer version would be voluntary, and the developer would still
have the option for its EHR technology to be certified to the version
specified in regulation. It also permits certified Complete EHRs and
certified EHR Modules to be voluntarily upgraded to these newer
versions without adversely affecting the EHR technology's certified
status. With respect to comments about EPs, EHs, and CAHs reconciling
different releases and requiring backwards compatibility, we do not
believe that these are acute concerns with respect to the code sets we
have designated as ``minimum standards'' code sets because newer
releases should subsume or include the codes that were in a prior
version (subject to the natural retirement/deprecation of no longer
useful codes). As stated in the Proposed Rule, based on the ``minimum
standards'' code sets we have previously adopted and proposed, we
believe that permitting EHR technology to be upgraded and certified to
newer versions of these code sets would not normally pose an
interoperability risk, cause unintended consequences, or place an undue
burden on the HIT industry. In limited circumstances where the use of
newer versions of a ``minimum standards'' code set may have an
immediate negative effect, we can use the process we described above
for the Secretary to prohibit the use of a newer version of a ``minimum
standards'' code set for purposes of certification and upgrading
certified Complete EHRs and certified EHR Modules. Accordingly, we do
not believe that it is necessary to establish a backwards compatibility
condition for ``minimum standards'' code sets as suggested. Further, we
believe that the process we have in place for prohibiting the use of
newer versions will mitigate any potential adverse affect for EPs, EHs,
or CAHs should a major change to an adopted minimum standard occur.
With respect to the comment about the refresh cycles for ``minimum
standards'' code sets, we intend to make such updates as part of the
normal rulemaking cycle that we engage in to adopt new certification
criteria editions. Thus, we expect that regulatory updates to newer
versions of ``minimum standards'' code sets will be on predictable
schedule.
C. Revisions to EHR Module Certification Requirements
1. Privacy and Security Certification
In the Proposed Rule, we proposed that EPs, EHs, and CAHs must have
EHR technology that meets the proposed Base EHR definition. The
proposed Base EHR definition referenced all of the proposed privacy and
security certification criteria at Sec. 170.314(d) except the optional
``accounting of disclosure'' certification criterion at Sec.
170.314(d)(9). Based on the policy expressed by the proposed Base EHR
definition and stakeholder feedback received since the S&CC July 2010
final rule, we proposed to eliminate the current privacy and security
certification requirements in Sec. 170.550(e) for EHR Modules starting
[[Page 54270]]
with the 2014 Edition EHR certification criteria.
Comments. Several commenters supported our proposed revisions to
EHR Module certification and expressed agreement that it would reduce
regulatory burden and enable greater flexibility. A few commenters
disagreed with our position and contended that we should continue our
existing approach to the privacy and security certification of EHR
Modules as specified in Sec. 170.550(e) with the 2014 Edition EHR
certification criteria. A couple of commenters expressed concern that
our approach could lead to certain negative effects if, as a result of
this proposed change, the EHR technology certified and used by an EP,
EH, or CAH to satisfy the Base EHR definition could not be configured
to also apply those privacy and security capabilities to other
separately certified EHR Modules an EP, EH, or CAH may choose to
implement. Along those lines, some commenters requested greater clarity
regarding our proposed EHR Module certification change and how it
interacts with the Base EHR definition. One commenter suggested that if
ONC finalizes this proposal that we should evaluate its effect to
determine if additional requirements would subsequently be necessary.
Another commenter recommended that remote components providing services
to a Complete EHR or EHR Module should be secured with Transport Layer
Security (TLS) and should not be required to be separately certified to
the privacy and security requirements.
Response. In consideration of comments received, we are revising
Sec. 170.550(e) as proposed. Upon this final rule's effective date,
EHR Modules presented for certification to the 2014 Edition EHR
certification criteria will not be required to be certified to the
privacy and security certification criteria adopted at Sec.
170.314(d). We continue to believe, as echoed by many commenters, that
our proposed change would reduce regulatory burden on EHR technology
developers and the potential for EPs, EHs, and CAHs to purchase EHR
Modules that have redundant or conflicting privacy and security
capabilities.
With respect to the concern identified by some commenters, we
reiterate what we stated in the Proposed Rule. EPs, EHs, and CAHs
ultimately remain responsible for implementing their EHR technology in
ways that meet applicable privacy and security requirements under
Federal and applicable state law (e.g., the HIPAA Privacy Rule and
Security Rule and 42 CFR Part 2). Certification is in no way a
substitute or proxy for compliance with these legal requirements. Per
the commenters' scenario and the other request for greater
clarification on the Base EHR definition, we acknowledge it could be
possible for an EP, EH, or CAH to adopt, for example, a certified EHR
Module (certified EHR Module 1) that satisfies the Base EHR
definition as well as other certified EHR Modules, and that those other
certified EHR Modules might not be able to utilize or leverage the
privacy and security capabilities included in certified EHR Module
1. Therefore, we strongly encourage EPs, EHs, and CAHs
(presumably as they would with any other EHR technology necessary to
meet MU or not) to carefully evaluate as part of their ongoing risk
analysis processes whether the implementation of an additional separate
certified EHR Module could pose new risks to privacy and security. As
suggested by these commenters, we intend to monitor the effects of
these changes to determine whether alternative requirements would be
necessary as part of future rulemaking. For a more detailed discussion
of the Base EHR definition, its requirements and relationship to CEHRT
and certified EHR Modules, and our response to comments, we refer
readers to section III.B.2 of this final rule. Finally, with respect to
the commenter's two-part recommendation related to remote components
providing services to a certified Complete EHR or certified EHR Module,
we find the commenter's scenario and limited description of a ``remote
component'' too ambiguous to issue a definitive response. In the
Proposed Rule, we proposed that EHR technology presented for
certification as an EHR Module would no longer need to be separately
certified to the adopted privacy and security criteria--a proposal we
have finalized. In general, we agree that TLS could be an appropriate
standard in this situation, but, again, do not believe that the
commenter provided sufficient detail on which to respond.
2. Certification to Certain New Certification Criteria
We proposed to revise Sec. 170.550 to ensure certification of EHR
Modules to the following 2014 Edition EHR certification criteria, as
applicable: (1) Electronic recording of the numerator for each MU
objective with a percentage-based measure (Sec. 170.314(g)(1)
``automated numerator recording''); (2) electronic recording of
activities related to non-percentage-based measures (Sec.
170.314(g)(3) ``non-percentage-based measure use report''); and (3)
user-centered design processes to be applied to EHR technology that
includes certain capabilities (Sec. 170.314(g)(4) ``safety-enhanced
design''). More specifically, we proposed to revise Sec. 170.550 to
ensure that EHR Modules that are presented for certification to
certification criteria that include capabilities for supporting a MU
objective with a percentage-based measure are certified to Sec.
170.314(g)(1). However, we also proposed that this requirement would
not apply if the EHR Module was certified to Sec. 170.314(g)(2)
``automated measure calculation'' in lieu of certification to Sec.
170.314(g)(1). We proposed to revise Sec. 170.550 to ensure that EHR
Modules that are presented for certification to certification criteria
that include capabilities for supporting an MU objective with a non-
percentage-based measure are certified to Sec. 170.314(g)(3). Last, we
proposed to revise Sec. 170.550 to ensure that EHR Modules that are
presented for certification to any of the certification criteria listed
in proposed Sec. 170.314(g)(4) are also certified to Sec.
170.314(g)(4). We proposed to include these revisions at Sec.
170.550(f).
Comments. We received a few comments expressing support for
requiring certification to these certification criteria.
Response. We appreciate the support expressed by commenters and are
finalizing our proposals to have ONC-ACBs ensure EHR Modules are
certified to these certification criteria, except for our proposal
concerning the ``non-percentage-based measure use report''
certification criterion at Sec. 170.314(g)(3). As discussed earlier in
this preamble, we are not finalizing the proposed ``non-percentage-
based measure use report'' certification criterion as part of the 2014
Edition EHR certification criteria. Therefore, ONC-ACBs would not need
to ensure that EHR Modules were certified to the certification
criterion. We also note that, because we are not finalizing the
proposed ``non-percentage-based measure use report'' certification
criterion, we have re-designated the ``safety-enhanced design''
certification criterion to Sec. 170.314(g)(3).
After consideration of comments received on our proposal to adopt a
certification criterion related to quality management processes for EHR
technology, we have adopted a ``quality management system''
certification criterion at Sec. 170.314(g)(4). This certification
criterion applies to all EHR technology certified to the 2014 Edition
EHR certification criteria. Therefore, to ensure ONC-ACBs certify all
EHR Modules presented for certification to the 2014 Edition EHR
certification
[[Page 54271]]
criteria to this new certification criterion, we have revised Sec.
170.550(f) to require that EHR Modules are certified to Sec.
170.314(g)(4).
D. ONC-ACB Reporting Requirements
We proposed to revise Sec. 170.523(f) to require ONC-ACBs to
include an additional data element in the data set they must provide to
ONC for the Complete EHRs and/or EHR Modules they certify.
Specifically, we proposed that an ONC-ACB would need to provide ONC a
hyperlink for each Complete EHR and EHR Module it certifies that would
enable the public to access the test results that the ONC-ACB used to
certify the EHR technology. As with all of the other data ONC-ACBs are
required to report to ONC about certified Complete EHRs and certified
EHR Modules, we proposed to make the hyperlink available on the CHPL
with the respective certified Complete EHR or certified EHR Module. As
noted in the Proposed Rule, we expect that ONC-ACBs would ensure the
functionality of the hyperlink for a minimum of five years consistent
with Sec. 170.523(g), unless a certified Complete EHR or certified EHR
Module is removed from the CHPL. Under such circumstances, we stated
that the ONC-ACB would no longer need to ensure the functionality of
the hyperlink, although retention of the test results would be
required.
Comments. Many commenters supported our proposal. Some commenters,
however, opposed publicly posting test results. Commenters that
supported our proposal stated that publicly posting the test results
would improve transparency. Some of these same commenters also
indicated that the public availability of test results would empower
customers. Specifically, they stated that customers could review and
compare the test results against expected performance as a way to
troubleshoot any implementation challenges posed by a certified
Complete EHR or certified EHR Module. Conversely, commenters that
expressed opposition to publicly posting test results stated that doing
so could compromise EHR technology developers' intellectual property
rights. These commenters expressed concern about the publication of
source code as well as the publication of copyrighted materials that
may be present in testing screenshots. A few commenters also argued
that there was little value in publicly posting test results because
the true value for consumers was in knowing whether the EHR technology
was certified. As alternatives to, or rationale against, publicly
posting test results, commenters suggested that test results could be
obtained by consumers (e.g., EPs, EHs, and CAHs) during purchase
negotiations and that ONC could post information about the testing and
certification processes in lieu of posting test results. Commenters
also noted that a standardized format for test results does not
currently exist under the temporary certification program and suggested
that such a format was necessary for testing results to be equitably
treated and for any analysis or comparison of test results.
Response. We have considered the comments received on this
proposal. We strongly believe that transparency should be an integral
component of the ONC HIT Certification Program. Transparency can
provide for additional access to and scrutiny of the ONC HIT
Certification Program as well as improve program performance and
increase public confidence in the EHR technology certified under the
program.
We believe that an appropriate balance can be struck that supports
transparency, protects EHR technology developers' potential
intellectual property rights, and provides testing results in a
consistent and identifiable manner. We have finalized our proposal and
will require that ONC-ACBs submit a hyperlink of the test results used
to issue a certification to a Complete EHR or EHR Module, which can be
accessed by the public. In light of the concern expressed by some
commenters, we intend to provide guidance to ONC-ACBs regarding the
test results information that should be excluded from the publicly
accessible hyperlink they submit to ONC. As an example, we expect ONC-
ACBs would exclude from the publicly available hyperlink any
screenshots produced as part of the testing process. Although we do not
anticipate that source code would be visible in a test result report,
if it is visible, we expect ONC-ACBs would exclude it from the
information made available through the hyperlink. We would also expect
any negative test results to be excluded from publicly posted test
results because only passed test results would be necessary for
obtaining certification of a Complete EHR or EHR Module from an ONC-
ACB. We believe this should mitigate the concerns identified by
commenters, and we will provide additional guidance to ONC-ACBs in the
future if other unique circumstances not discussed here arise. We also
intend, as suggested by commenters, to work closely with NVLAP to
develop a standardized format for test results that can be used by all
accredited testing laboratories and submitted to any ONC-ACB to be used
for certification.
E. Continuation and Representation of Certified Status
1. 2011 or 2014 Edition EHR Certification Criteria Compliant
To align with our proposal to designate the certification criteria
adopted in Sec. Sec. 170.302, 170.304, and 170.306 collectively as the
``2011 Edition EHR certification criteria'' and to designate the
certification criteria proposed in the Proposed Rule at Sec. 170.314
as the ``2014 Edition EHR certification criteria,'' we proposed to
revise Sec. 170.523(k). The proposed revision to Sec. 170.523(k)
would require ONC-ACBs to ensure as part of certification that a
developer of a Complete EHR or EHR Module would indicate in all
marketing materials, communications, statements, and other assertions
the certification criteria edition to which it had been certified
rather than the compliance years the certification issued to the
Complete EHR or EHR Module represented. We proposed that this revision
would apply to all certifications issued after the effective date of
this final rule.
As noted in the Proposed Rule, we considered multiple options to
address certified Complete EHRs and certified EHR Modules already
designated as ``2011/2012'' compliant and concluded that the best
approach was to not require any changes to the ``2011/2012''
designation. Rather, we stated that we would simply make clear that
certified Complete EHRs and certified EHR Modules that are designated
as ``2011/2012 compliant'' would remain valid for purposes of the EHR
reporting periods in FY/CY 2013. We requested public comment on this
approach and any other approach that would present the least burden for
EHR technology developers and the least confusion for the market.
We also proposed to revise Sec. 170.523(k)(1)(i) by removing the
following statement: ``* * * or guarantee the receipt of incentive
payments'' because although incentives will be available under the
Medicaid EHR Incentive Program until 2021, they will no longer be
available under the Medicare EHR Incentive Program after 2016.
Comments. Commenters supported the concept of ``editions'' of
certification criteria and stated that identifying EHR technology's
compliance with editions of certification criteria would be less
confusing than using multiple years as a means of identifying an EHR
technology's certified status and validity.
Response. We thank the commenters for their support and are
revising
[[Page 54272]]
Sec. 170.523(k) as proposed. When an ONC-ACB issues a certification it
must require that the EHR technology developer include on its Web
site(s) and in all marketing materials, communications, statements, and
other assertions, the certification criteria edition to which the
Complete EHR or EHR Module was certified. This revision applies to all
certifications issued after the effective date of this final rule and
means that EHR technology certified to the 2011 Edition EHR
certification criteria will be designated as ``2011 Edition EHR
certification criteria compliant'' and EHR technology certified to the
2014 Edition EHR certification criteria will be designated as ``2014
Edition EHR certification criteria compliant.'' We believe this
revision will assist in eliminating confusion about the ``expiration''
of certifications, align with our revised definition of CEHRT, and
provide the market with greater clarity regarding the capabilities
certified Complete EHRs and certified EHR Modules include. As stated
above and in the Proposed Rule, EHR technology that has already been
designated as ``2011/2012 compliant'' does not need to be re-designated
as ``2011 Edition EHR certification criteria complaint.'' Finally,
consistent with our proposal, we are removing the statement: ``* * * or
guarantee the receipt of incentive payments'' from Sec.
170.523(k)(1)(i) to prevent confusion about the parameters of the EHR
Incentive Programs.
2. Updating a Certification
To ensure that the information required by Sec. 170.523(k)(1)(i)
remains accurate and reflects the correct EHR certification criteria
edition, ONC-ACBs, under Sec. 170.550(d), are permitted to provide
updated certifications to previously certified EHR Modules under
certain circumstances. In the Permanent Certification Program final
rule (76 FR 1306) and at Sec. 170.502, we defined ``providing or
provide an updated certification'' to an EHR Module as ``the action
taken by an ONC-ACB to ensure that the developer of a previously
certified EHR Module(s) shall update the information required by Sec.
170.523(k)(1)(i), after the ONC-ACB has verified that the certification
criterion or criteria to which the EHR Module(s) was previously
certified have not been revised and that no new certification criteria
adopted for privacy and security are applicable to the EHR Module(s).''
Based on our proposal in the Proposed Rule to no longer apply the
privacy and security certification requirements at Sec. 170.550(e) to
EHR Modules certified to the proposed 2014 Edition EHR certification
criteria, we proposed to revise the definition of ``providing or
provide an updated certification'' at Sec. 170.502. The proposed
revised definition would eliminate the requirement that ONC-ACBs must
verify whether any new privacy and security certification criteria
apply when they issue an updated certification to an EHR Module.
We also noted in the Proposed Rule that the certification criteria
and certification requirements that apply to previously certified EHR
Modules may change with each new edition of certification criteria that
is adopted by the Secretary. Therefore, we stated that we can provide
the best guidance to stakeholders on when ``updating'' a certification
would be permitted with each rulemaking for a certification criteria
edition. For the 2014 Edition EHR certification criteria, we stated
that if we were to adopt in a final rule the proposed certification
criteria at Sec. 170.314(g)(1) (automated numerator recording) and
Sec. 170.314(g)(3) (non-percentage-based measure use report), then no
previously certified EHR Module could have its certification
``updated'' to the 2014 Edition EHR certification criteria because it
would need to be certified to one of the above certification criteria
(with the option of an EHR Module being certified to Sec.
170.314(g)(2) in lieu of being certified to Sec. 170.314(g)(1)).
Comments. We received no comments on this proposal.
Response. We are finalizing the proposed revisions to the
definition ``providing or provide an updated certification'' at Sec.
170.502. We also specify that ``updating'' an EHR Module's
certification to the 2014 Edition EHR certification criteria will not
be available. As noted previously in this preamble, we have adopted a
``quality management system'' certification criterion (Sec.
170.314(g)(4)) that applies to all EHR technology certified to the 2014
Edition EHR certification criteria. Therefore, when certifying EHR
Modules to the 2014 Edition EHR certification criteria, ONC-ACBs must
certify EHR Modules to this new certification criterion. Additionally,
we have finalized the proposed new certification criteria ``automated
numerator recording'' (Sec. 170.314(g)(1)) and ``safety-enhanced
design'' (now designated as Sec. 170.314(g)(3)). ONC-ACBs must also
ensure that EHR Modules presented for certification to the 2014 Edition
EHR certification criteria are, as applicable, certified to these new
certification criteria. Consequently, an ONC-ACB may not issue
``updated'' certifications to previously certified EHR Modules for the
2014 Edition EHR certification criteria. As we noted in the Proposed
Rule, ``updating'' a certification may still be a viable option under
certain conditions when the Secretary adopts another edition of
certification criteria in the future.
3. Representation of Meeting the Base EHR Definition
With respect to the Base EHR definition, we explained in the
Proposed Rule that EPs, EHs, and CAHs would benefit from knowing which
certified EHR technologies on the market meet the Base EHR definition
because they would need to have EHR technology that meets the Base EHR
definition to satisfy the proposed revised definition of CEHRT
beginning with FY/CY 2014. We stated that it was unnecessary to
expressly propose a requirement for ONC-ACBs to identify EHR technology
that meets the Base EHR definition because EHR technology developers,
in order to gain a competitive advantage in the market, would likely
identify on their Web sites and in marketing materials, communications,
statements, and other assertions whether their certified Complete EHR
or certified EHR Module(s) also met the Base EHR definition (designed
for either the ambulatory or inpatient setting). We did, however,
consider (as a potential alternative and complementary approach)
permitting ONC-ACBs when issuing certifications to Complete EHRs and
EHR Modules that meet the Base EHR definition to formally indicate such
fact to the EHR technology developer and permit the EHR technology
developer in association with its EHR technology's certification to
represent that the EHR technology meets the Base EHR definition. We
requested public comment our approach and whether there was any other
potential approach that we had not identified.
Comments. Many commenters supported the Base EHR concept and
suggested that EHR technologies meeting the Base EHR definition should
be listed as such, and searchable, on the Certified HIT Products List
(CHPL). Commenters stated that specifically listing EHR technologies
that meet the Base EHR definition on the CHPL would provide the most
purchasing clarity for EPs, EHs, and CAHs. Some commenters also stated
that leaving it up to the EHR technology developers to identify whether
their EHR technologies met the Base EHR definition could be misleading
to purchasers.
Response. We believe, as indicated in the Proposed Rule, that EHR
technology
[[Page 54273]]
developers will be able to identify on their Web sites and in marketing
materials, communications, statements, and other assertions whether
their certified Complete EHR or certified EHR Module(s) meet the Base
EHR definition (designed for either the ambulatory or inpatient
setting). This will enable EHR technology developers to market the
post-certification combination of multiple certified EHR Modules as
meeting the Base EHR definition. We believe this is the best way to
address situations where an EHR technology developer has EHR Modules
certified at different times, but those EHR Modules together meet the
Base EHR definition. This approach will also permit multiple affiliated
EHR technology developers to market the post-certification combination
of their certified EHR Modules if together they meet the Base EHR
definition.
We do not believe that purchasers should be concerned about
misleading practices related to the identification of certified
Complete EHRs and certified EHR Modules as meeting the Base EHR
definition. First, a certified Complete EHR by definition meets the
Base EHR definition. Second, ONC-ACBs oversee the certifications they
issue to Complete EHRs and EHR Modules. When ONC-ACBs are accredited,
their conformance to ISO/IEC Guide 65:1996 (Guide 65) is verified.
Section 14.3 of Guide 65 states that ``incorrect references to the
certification system or misleading use of licenses, certificates or
marks, found in advertisement, catalogues, etc., shall be dealt with by
suitable action.'' Based on this provision, we are confident that any
misleading practices by EHR technology developers as they relate to
their certified EHR Modules will be dealt with appropriately by ONC-
ACBs.
We understand the commenters' desire to have EHR technology listed
on the CHPL designated as whether it meets the Base EHR definition. We
believe, however, that it would be impractical and administratively
burdensome to prospectively list or designate all EHR technologies that
could be combined post-certification to meet the Base EHR definition.
Rather, a more efficient and less burdensome approach will be to enable
the CHPL Web site to identify whether EHR technologies selected from
the CHPL meet the Base EHR definition. For example, if an EP, EH, or
CAH selected on the CHPL EHR technology developer A's certified EHR
Module and EHR technology developer B's certified EHR Module, we expect
that the CHPL would be able to identify whether the certified EHR
Modules together meet the Base EHR definition (i.e., have been
certified to all of the certification criteria specified in the Base
EHR definition and the requisite number of CQMs). This approach would
permit EPs, EHs, and CAHs to determine whether they have EHR technology
that meets the Base EHR definition and also limits inefficiencies and
burdens associated with EHR technology developers having ONC-ACBs
verify that their EHR technologies meet the Base EHR definition
(potentially post certification), reporting this information to the
CHPL, and/or having the CHPL attempt to prospectively identify all EHR
technologies (and combinations) that meet the Base EHR definition.
F. EHR Technology Price Transparency
In response to stakeholder feedback, the Proposed Rule described
our belief that the EHR technology marketplace could benefit from price
transparency associated with certified Complete EHRs and certified EHR
Modules. We further stated that price transparency could be achieved by
requiring ONC-ACBs to ensure that EHR technology developers include
clear pricing of the full cost to purchasers of their certified
Complete EHR and/or certified EHR Module on their Web sites and in all
marketing materials, communications, statements, and other assertions
related to a Complete EHR's or EHR Module's certification. In other
words, ONC-ACBs could require EHR technology developers to disclose a
purchaser's full cost (a single price) for all of the capabilities for
which certification was required and that were included in a certified
Complete EHR or certified EHR Module. We noted in the Proposed Rule,
however, that in no way would this requirement dictate the price an EHR
technology developer could assign to its EHR technology. We requested
comment on the feasibility and value of price transparency for
certified Complete EHRs and certified EHR Modules in the manner
described.
Comments. EHR technology developers and organizations representing
EHR technology developers opposed this proposal. Providers and provider
organizations supported the concept of price transparency, but not
necessarily as proposed. Commenters questioned our proposed form of
price transparency and stated that its anticipated value to purchasers
was unclear because of the complexity and multiple costs associated
with purchasing EHR technology. Alternatively, commenters stated that
knowing a certified Complete EHR or certified EHR Module's ``total cost
of ownership'' would be more valuable than just the price associated
with the capabilities that the certification assigned to a Complete EHR
or EHR Module represented. For commenters, total ownership costs
included: Implementation costs (e.g., local implementation,
subscription to an ASP, or web-based service); customization/
configuration (e.g., configurations of interfaces); training; and
maintenance. Commenters also suggested that price transparency should
mean that, in a multiple EHR technology developer scenario, the amount
paid to each EHR technology developer would be identified. Other
commenters noted that our proposed price transparency approach added
little benefit because EHR technology developers could offer a low
initial cost for the acquisition of a certified Complete EHR or
certified EHR Module and then charge additional costs for other
essential components of total ownership, such as implementation.
Commenters also pointed out that a single price could give a false
impression of equality. They cited, for example, that two certified
Complete EHRs may have the same price, but offer substantially
different capabilities and services in addition to those capabilities
for which certification is required.
Commenters stated that our proposal could hinder innovation and
flexibility in product development, pricing, and market strategies.
Some commenters stated, for example, that many products are not sold or
licensed with only the capabilities for which certification is required
and that our proposal could negatively alter current practices by
confusing customers familiar with customary pricing and purchasing
practices. A few commenters were also concerned about the proposal's
impact on confidential, competitive and, some thought, proprietary
marketing strategies. These commenters also noted that they were
unaware of any other industry with the type of pricing dimensions and
complexities as the HIT market and in which the Federal government
required prices to be publicly available.
Commenters stated that it would be burdensome to include prices on
all materials as proposed, particularly if prices change. A few EHR
technology self-developers requested that we exempt them from the price
transparency proposal because they would not be selling their certified
Complete EHR or certified EHR Module on the open market. Commenters
noted that Regional Extension Centers have taken extensive steps to
identify the true cost of EHR technologies inclusive of software (in-
house vs. hosted), services, training, maintenance, and other factors
[[Page 54274]]
in an effort to help their constituents properly compare certified
Complete EHRs and certified EHR Modules. Last, commenters sought
clarification regarding how EHR technology developers would be held
accountable to this requirement (i.e., what would be the consequences
for EHR technology developers).
Response. We appreciate the variety and specificity of comments
issued in response to this proposal. For the reasons stated in the
Proposed Rule as well as those raised by commenters in favor of this
proposal, we continue to believe that there is value in requiring ONC-
ACBs to ensure that EHR technology developers are transparent about the
costs associated with certified Complete EHRs and certified EHR
Modules. Further, we believe that such transparency can provide greater
purchasing clarity for EPs, EHs, and CAHs. In considering that almost
all commenters found fault with our proposal to list a purchaser's full
cost or single price for a certified Complete EHR or certified EHR
Module (for the various reasons identified in the comments above), we
have finalized a modified approach based on those same comments and
their suggestions for what would be helpful. This modified approach
focuses on an EHR technology developer's responsibility to notify EPs,
EHs, and CAHs about additional types of costs (i.e., one-time, ongoing,
or both) that may affect a certified Complete EHR or certified EHR
Module's total cost of ownership for the purposes of achieving MU.
We noted in the Proposed Rule that stakeholder feedback on unclear
pricing prompted us to offer the proposal to require ONC-ACBs to ensure
that EHR technology developers to specify the purchaser's full cost of
a certified Complete EHR or certified EHR Module. We identified that
stakeholders had conveyed to us that EHR technology developers were
specifying prices for multiple groupings of capabilities even though
the groupings did not correlate to the entire certified Complete EHR or
certified EHR Module. Further, as commenters reinforced, EHR
technologies that may be certified under the ONC HIT Certification
Program could be sold or licensed with capabilities that are in
addition to those that fall under the scope of certification.
We acknowledge that many factors, such as those mentioned by
commenters (e.g., costs from purchasing EHR technology from multiple
EHR technology developers, maintenance of the EHR technology, and
training of staff on the EHR technology), go into a purchaser's total
ownership cost for a certified Complete EHR or certified EHR Module(s).
Our proposal sought, however, to clearly identify for purchasers the
cost associated with the capabilities that the certification assigned
to a Complete EHR or EHR Module represented, separate and apart from
those capabilities and services that are not required for certification
but are sold by EHR technology developers with the purchase of a
certified Complete EHR or certified EHR Module. On balance, we believe
that the best approach to address the concerns that prompted our
proposal, as well as those received in response, is to amend Sec.
170.523(k)(1) to add a third provision related to price transparency.
Section Sec. 170.523(k)(1) requires an ONC-ACB to ensure that a
Complete EHR or EHR Module developer conspicuously includes on its Web
site and in all marketing materials, communications statements, and
other assertions related to the Complete EHR or EHR Module's
certification the information specified in paragraphs (k)(1)(i) and
(k)(1)(ii). This new provision, finalized at Sec. 170.523(k)(1)(iii),
requires an ONC-ACB to ensure that a Complete EHR or EHR Module
developer discloses any additional types of costs that an EP, EH, or
CAH would pay to implement the capabilities a certified Complete EHR or
certified EHR Module includes in order to attempt to meet MU objectives
and measures. We clarify that these types of costs are in addition to
those costs that an EP, EH, or CAH would pay to purchase (or upgrade
to) the EHR technology capabilities for which certification is
required. These may be one-time or recurring costs, or both. We also
clarify that ONC-ACBs would only be required to ensure that EHR
technology developers disclose the types of additional costs, and not
the actual dollar amounts of such costs.
For example, if EHR technology is certified to the ``view,
download, and transmit to a 3rd party'' certification criterion, and an
EP would be expected to pay an ``ongoing'' monthly service fee to the
EHR technology developer for it to host/administer this capability in
order for the EP to meet the correlated MU objective and measure, the
existence of this potential ``ongoing'' cost would need to be disclosed
by the EHR technology developer. As another example, an EHR Module
certified to the public health electronic lab reporting certification
criterion (Sec. 170.314(f)(4)) would be able to create a valid HL7
message for electronic submission. However, for the purposes of
achieving MU, a hospital may be expected to pay their EHR technology
developer a separate ``one-time'' and/or ``ongoing'' interface
development and configuration fee to establish connectivity between
their certified EHR Module and a public health authority. In such a
situation, the potential costs of the interface development and
configuration fee would need to be disclosed. A final example would be
where an EHR technology developer charges a ``one-time'' fee to
integrate its certified EHR technology with a hospital's other
certified EHR Modules or a health information exchange organization.
Again, just like the other examples, the potential for this fee would
need to be disclosed by the EHR technology developer. Building off
these examples, we would expect that an EHR technology developer could
satisfy Sec. 170.523(k)(1)(iii) by disclosing: 1) the type(s) of
additional cost; and 2) to what the cost is attributed. In reference to
the first example above, an EHR technology might state that ``an
additional ongoing fee may apply to implement XYZ online patient
service.'' In situations where the same types of cost apply to
different services, listing each as part of one sentence would be
acceptable, such as ``a one-time fee is required to establish
interfaces for reporting to immunization registries, cancer registries,
and public health agencies.''
We believe that the limited scope required by this new disclosure
will not hinder innovation and flexibility in product development
pricing, and marketing strategies, nor is it likely to implicate
confidential or proprietary information. We remind commenters that
certification already requires certain transparency provisions. Under
the ONC HIT Certification Program, ONC-ACBs must ensure that EHR
technology developers specify certain information about their certified
Complete EHR or certified EHR Module on their Web sites, in all
marketing materials, communication statements, and other assertions
(see Sec. 170.523(k)(1)(i) and (ii)). This information conveys all of
the capabilities that the certification issued to the Complete EHR or
EHR Module represents and what must be provided to an EP, EH, or CAH in
order for the EHR technology developer to properly convey the benefit
(i.e., certification) assigned to the certified Complete EHR or
certified EHR Module. Further, this information also notifies the
customer of any additional software that the EHR technology developer
relied on to meet certain certification criteria. In cases where
additional software is relied on, it is also encompassed by the
[[Page 54275]]
certification issued to the certified Complete EHR or certified EHR
Module. From a transparency perspective, this new requirement will
provide clarity to purchasers regarding the potential additional types
of costs they may face when implementing a certified Complete EHR or
certified EHR Module. It may also help prevent purchasers from being
surprised by additional costs beyond those associated with the adoption
and implementation of the capabilities that comprise their CEHRT.
We described ``self-developed'' EHR technology in the Permanent
Certification Program final rule (76 FR 1300-1301). We described self-
developed EHR technology to mean a Complete EHR or EHR Module that has
been designed, modified, or created by, or under contract for, a person
or entity that will assume the total costs for its testing and
certification and will be a primary user of the Complete EHR or EHR
Module. We further noted that this distinction served to distinguish
between those Complete EHRs and EHR Modules that would be created once
and most likely sold to many EPs, EHs, and CAHs from those that would
be certified once and used primarily by the person or entity who paid
for testing and certification. On the developer level, we used the
terms ``self-developer'' and commercial vendor to distinguish between
the two types of developers. As requested by commenters, EHR technology
self-developers would be exempt from the new requirement because they
will not be marketing or making their certified Complete EHRs or
certified EHR Modules commercially available for sale. To obtain this
exemption, EHR technology self-developers will need to provide written
notification to the ONC-ACB when presenting their EHR technology for
certification that they are an EHR technology self-developer and their
EHR technology will not be marketed or made commercially available for
sale to health care providers.
ONC-ACBs are responsible for ensuring compliance with Sec.
170.523(k)(1) and will determine appropriate consequences if EHR
technology developers fail to disclose the information specified in
Sec. 170.523(k)(1).
G. Certification and Certification Criteria for Other Health Care
Settings
The HITECH Act did not authorize the availability of incentives
under the EHR Incentive Programs for all health care providers.
Consequently, in the Proposed Rule, we noted that the certification
criteria proposed for adoption focused primarily on enabling EHR
technology to be certified and subsequently adopted and used by EPs,
EHs, and CAHs who seek to demonstrate MU under the EHR Incentive
Programs. We discussed, however, the National Coordinator's statutory
authority to establish a voluntary certification program or programs
for other types of HIT besides the EHR technology that could be used to
demonstrate meaningful use. We explained that any steps towards
certifying other types of HIT, including EHR technology such as
``Complete EHRs'' or ``EHR Modules'' for settings other than inpatient
or ambulatory, would first require the Secretary to adopt certification
criteria for other types of HIT and/or other types of health care
settings. With this consideration, we sought public comment on whether
we should focus any certification efforts towards the HIT used by
health care providers that are ineligible to receive incentives under
the EHR Incentive Programs.
In particular, we requested comments on whether we should consider
adopting certification criteria for other health care settings, such as
the long-term care, post-acute care, and mental and behavioral health
settings. We asked that commenters specify the certification criteria
that would be appropriate as well as the benefits they believe a
regulatory approach would provide. Last, we asked that the public
consider whether the private sector could alternatively address any
perceived need or demand for such certification and specifically
mentioned that the Certification Commission for Health Information
Technology (CCHIT) has certification programs for long-term and post-
acute care as well as behavioral health EHR technology.\41\
---------------------------------------------------------------------------
\41\ http://www.cchit.org/get_certified/cchit-certified-2011.
---------------------------------------------------------------------------
Comments. Commenters strongly supported certification for other
health care settings. A few commenters suggested that we develop
certification criteria for other health care settings. However, the
majority of commenters also noted that the lack of financial incentives
for other health care settings (e.g., long term, post acute, home
health, hospice, and behavioral settings) was a significant barrier and
would render attempts to adopt certification or certification criteria
for other health care settings infeasible. Multiple commenters noted
that voluntary certification programs for other health care settings
have been developed by the private sector with industry-wide
stakeholder input. Commenters specifically pointed to the certification
programs run by the CCHIT, which cover long-term and post-acute care,
skilled nursing facilities, and home health. Comments stated that
private sector certification programs provide for greater flexibility,
such as being able to revise and develop standards more in line with
the pace of technology development. Commenters also noted that these
programs are synchronized with applicable standards adopted to support
MU, such as standards for transitions of care and privacy and security.
Commenters recommended that we focus on interoperability and health
information exchange among all health care settings. Specifically,
commenters suggested that we identify a subset of MU certification
criteria and standards that support standards-based exchange of health
information that protect the privacy and security of the health
information being exchanged. Some commenters also suggested that we
identify certification criteria that would support the ability of
providers practicing in other health care settings to comply with
federal reporting requirements. Commenters also recommended that we
encourage EHR technology developers to obtain certification for EHR
Modules that would specifically support these types of capabilities,
like the exchange of a transition of care/referral summary.
Response. We appreciate the interest in other health care settings
expressed by commenters. We agree that it makes good policy sense to
support interoperability and the secure electronic exchange of health
information between all health care settings. We believe the adoption
of EHR technology certified to a minimal amount of certification
criteria adopted by the Secretary can support this goal. To this end,
we encourage EHR technology developers to certify EHR Modules to the
transitions of care certification criteria (Sec. 170.314(b)(1) and
(2)) as well as any other certification criteria that may make it more
effective and efficient for EPs, EHs, and CAHs to electronically
exchange health information with health care providers in other health
care settings. The adoption of EHR technology certified to these
certification criteria can facilitate the secure electronic exchange of
health information. We concur with commenters that there are currently
private sector organizations that are addressing requests for
certification programs for other health care settings.
VII. Collection of Information Requirements
Under the Paperwork Reduction Act of 1995 (PRA), agencies are
required to
[[Page 54276]]
provide 60-day notice in the Federal Register and solicit public
comment on a proposed collection of information before it is submitted
to the Office of Management and Budget for review and approval. In
order to fairly evaluate whether an information collection should be
approved by the Office of Management and Budget, section 3506(c)(2)(A)
of the PRA requires that we solicit comment on the following issues:
1. Whether the information collection is necessary and useful to
carry out the proper functions of the agency;
2. The accuracy of the agency's estimate of the information
collection burden;
3. The quality, utility, and clarity of the information to be
collected; and
4. Recommendations to minimize the information collection burden on
the affected public, including automated collection techniques.
In the Proposed Rule, published March 7, 2012 (77 FR 13832), we
solicited public comment on each of these issues for revisions to OMB
control number 0990-0378. We did not receive any comments on this
collection of information. We have finalized at Sec. 170.523(f)(8) the
requirement, as proposed, for ONC-ACBs to additionally report to ONC a
hyperlink with each EHR technology they certify that provides the
public with the ability to access the test results used to certify
Complete EHRs and EHR Modules. Having not obtained any information that
would suggest we reconsider our original burden estimates, we have
maintained those same estimates.
Abstract
Under the ONC HIT Certification Program, accreditation
organizations that wish to become the ONC-Approved Accreditor (ONC-AA)
must submit certain information, organizations that wish to become an
ONC-Authorized Certification Bodies (ONC-ACBs) must submit the
information specified by the application requirements, and ONC-ACBs
must comply with collection and reporting requirements, records
retention requirements, and submit annual surveillance plans and
annually report surveillance results. These collections of information
were approved under OMB control number 0990-0378. In the Proposed Rule,
we proposed to revise Sec. 170.523(f) and, correspondingly, proposed
to revise OMB control number 0990-0378 by requiring ONC-ACBs to include
one additional data element in the list of information about Complete
EHRs and EHR Modules they report to ONC.
Section 170.523(f) requires an ONC-ACB to provide ONC, no less
frequently than weekly, a current list of Complete EHRs and/or EHR
Modules that have been certified as well as certain minimum information
about each certified Complete EHR and/or EHR Module. We proposed to
require ONC-ACBs to additionally report to ONC a hyperlink with each
EHR technology they certify that provides the public with the ability
to access the test results used to certify the EHR technology. We
proposed to add this requirement at Sec. 170.523(f)(8).
For the purposes of estimating this additional potential burden, we
used the following assumptions. We assumed that all of the estimated
applicants will apply and become ONC-ACBs (i.e., 6 applicants) and that
they will report weekly (i.e., respondents will respond 52 times per
year). We assumed an equal distribution among ONC-ACBs in certifying
EHR technology on a weekly basis. As such, based on the number of
Complete EHRs and EHR Modules listed on the CHPL at the end of
September of 2011 (approximately one year since the CHPL's inception),
we estimated that, on average, each ONC-ACB will report 4 test results
hyperlinks to ONC on a weekly basis.
We believe that it will take approximately 5 minutes to report each
hyperlink to ONC. Therefore, as reflected in the table below, we
estimated an additional 20 minutes of work per ONC-ACB each week. Under
the regulatory impact statement section, we discuss the estimated costs
associated with reporting the hyperlinks to ONC.
Estimated Annualized Burden Hours
----------------------------------------------------------------------------------------------------------------
Number of Average burden
Type of respondent Number of responses per hours per Total burden
respondents respondent response hours
----------------------------------------------------------------------------------------------------------------
45 CFR 170.523(f)(8)........................ 6 52 .33 103
----------------------------------------------------------------------------------------------------------------
With the additional collection of information at Sec.
170.523(f)(8), we added 103 burden hours to our burden estimate in OMB
control number 0990-0378. Our estimates for the total burden hours
under OMB control number 0990-0378 are expressed in the table below.
Estimated Annualized Total Burden Hours
----------------------------------------------------------------------------------------------------------------
Number of Average
Type of respondent Number of responses per burden hours Total burden
respondents respondent per response hours
----------------------------------------------------------------------------------------------------------------
45 CFR 170.503(b)............................... 2 1 1 2
45 CFR 170.520.................................. 6 1 1 6
45 CFR 170.523(f)............................... 6 52 1.33 415
45 CFR 170.523(g)............................... n/a n/a n/a n/a
45 CFR 170.523(i)............................... 6 2 1 12
----------------------------------------------------------------------------------------------------------------
Total burden hours for OMB control number 0990-0378............................................. 435
----------------------------------------------------------------------------------------------------------------
[[Page 54277]]
VII. Regulatory Impact Statement
A. Statement of Need
Section 3004(b)(1) of the PHSA requires the Secretary to adopt an
initial set of standards, implementation specifications, and
certification criteria. On January 13, 2010, the Department issued an
interim final rule with a request for comments to adopt an initial set
of standards, implementation specifications, and certification
criteria. On July 28, 2010, the Department published in the Federal
Register a final rule to complete the adoption of the initial set of
standards, implementation specifications, and certification criteria.
Collectively, the initial set is referred to as the 2011 Edition EHR
certification criteria. This final rule adopts another edition of
standards, implementation specifications, and certification criteria
that we refer to as the 2014 Edition EHR certification criteria. The
2014 Edition EHR certification criteria support the MU objectives and
measures under the EHR Incentive Programs and will be used to test and
certify EHR technology (Complete EHRs and EHR Modules). EPs, EHs, and
CAHs must adopt and implement certified Complete EHRs and/or certified
EHR Modules in order to have CEHRT. EPs, EHs, and CAHs who seek to
qualify for incentive payments under the EHR Incentive Programs are
required by statute to use CEHRT.
B. Overall Impact
We have examined the impact of this final rule as required by
Executive Order 12866 on Regulatory Planning and Review (September 30,
1993), Executive Order 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 Executive Order 13132 on Federalism (August 4, 1999).
1. Comment and Response
Comments. A few other commenters stated we did not account for the
costs that public health agencies will incur by having to meet the
standards we adopt for certification criteria that support reporting to
public health agencies. Some commenters stated that the regulatory
impact analysis does not account for costs that EPs, EHs, and CAHs will
incur in adopting and implementing CEHRT. One commenter suggested that
we should increase our average overall hours for development and
preparation of EHR technology for certification to the 2014 Edition EHR
certification criteria by a multiplier of four to account for
integration of these new features into current EHR workflows.
Response. The information technology public health agencies use or
would need to employ or modify in order to receive data according to
the standards we adopt for EHR technology certification is not within
the scope of this rulemaking. In promulgating this final rule, we have
considered the standards adopted by public health agencies before
including them in the relevant certification criteria.
The costs that EPs, EHs, and CAHs will incur in adopting and
implementing certified Complete EHRs and certified EHR Modules are not
within the scope of this final rule. Those costs would include the
costs of integrating new features into their EHR workflows. Those costs
are estimated in the Stage 2 final rule published elsewhere in this
issue of the Federal Register.
2. Executive Orders 12866 and 13563--Regulatory Planning and Review
Analysis
Executive Orders 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 because our primary estimate of the costs to prepare
Complete EHRs and EHR Modules to be tested and certified will be less
than $100 million in any given year. Nevertheless, because of the
public interest in this final rule, we have prepared an RIA that to the
best of our ability presents the costs and benefits of the final rule.
a. Costs
This rule adopts standards, implementation specifications, and
certification criteria that establish the capabilities that EHR
technology would need to demonstrate to be certified. 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
Complete EHRs and EHR Modules to be tested and certified in accordance
with the certification criteria adopted by the Secretary. That is, we
focus on the technological development and preparation costs necessary
for a Complete EHR or EHR Module already certified to the 2011 Edition
EHR certification criteria to be upgrade to the adopted 2014 Edition
EHR certification criteria and for developing a new Complete EHR or EHR
Module to meet the 2014 Edition EHR certification criteria. The
estimated costs for having EHR technology actually tested and certified
were discussed in the Permanent Certification Program final rule (76 FR
1318-23). Last, we estimate the costs for ONC-ACBs to report to ONC
hyperlinks to the test results used to certify EHR technology.
i. Development and Preparation Costs for 2014 Edition EHR Certification
Criteria
The development costs we estimate are categorized based on the type
of 2014 Edition EHR certification criteria discussed in this final rule
(i.e., new, revised, and unchanged). The numbers of Complete EHRs and
EHR Modules that we estimate will be developed to each 2014 Edition EHR
certification criterion are based on the statistics we obtained from
the CHPL on July 6, 2012. We attempted to identify the total number of
Complete EHRs and EHR Modules that were developed to the 2011 Edition
EHR certification criteria as of July 6, 2012. By this we mean that we
first attempted to discern how many Complete EHRs and EHR Modules were
certified that would not constitute a newer version of the same EHR
technology. Second, we attempted to determine how many certified
Complete EHRs and certified EHR Modules shared much of the same
development costs. For example, when a Complete EHR is certified first
and then an EHR technology developer subsequently seeks one or more EHR
Module certifications for portions of that Complete EHR in order to
provide its customers with more options. Using this number, we adjusted
it based on additional considerations unique to the 2014 Edition EHR
certification criteria such as the adoption of optional certification
criteria, certification criteria included in the Base EHR definition,
and the revised CEHRT definition. The revised CEHRT definition will
only require EPs, EHs, and CAHs to possess the CEHRT they need to
demonstrate MU for the stage they seek to accomplish, which could
conceivably directly affect the number of EHR technologies developed to
certain certification criteria that support MU menu objectives and
measures. Using the final estimate of Complete EHRs and EHR Modules
that we believe will be developed to meet each
[[Page 54278]]
certification criterion, we have established an estimated range of 10%
less and 10% more EHR technologies being developed to each 2014 Edition
EHR certification criterion. We believe this will account for potential
new entrants to the market as well as for those EHR technologies
developed to meet the 2011 Edition EHR certification criteria that may
not be upgraded to the 2014 Edition EHR certification criteria because
of such factors and company mergers or acquisitions and the loss of
market share for some Complete EHRs and EHR Modules. For unchanged
certification criteria, we have only calculated development and
preparation costs for a potential 10% increase in new EHR technologies
being developed and prepared to meet the certification criteria.
As noted in the Proposed Rule, we are not aware of an available
independent study (e.g., a study capturing the efforts and costs to
develop and prepare Complete EHRs and EHR Modules to meet the
requirements of the 2011 Edition EHR certification criteria) that we
could rely upon as a basis for estimating the efforts and costs
required to develop and prepare EHR technology to meet the 2014 Edition
EHR certification criteria. Therefore, we have relied upon our own
research to estimate the effort required to develop and prepare EHR
technology to meet the requirements of the 2014 Edition EHR
certification criteria. We have identified 3 levels of effort that we
believe can be associated with the development and preparation of EHR
technology to meet the requirements of the 2014 Edition EHR
certification criteria. These levels of effort are the average range of
hours we would expect to be necessary to develop EHR technology to meet
the requirements of the 2014 Edition EHR certification criteria. This
means that a few EHR technology developers' costs may be less than this
range and a few may exceed the range. Level 1 is for certification
criteria that we believe will require the least amount of effort to
develop and prepare EHR technology for testing and certification to the
criteria, with a range of 40-100 hours. Level 2 is for certification
criteria that we believe will require a moderate amount of effort to
develop and prepare EHR technology for testing and certification to the
criteria, with a range of 100-300 hours. Level 3 is for certification
criteria that we believe will require the most amount of effort to
develop and prepare EHR technology for testing and certification to the
criteria, with a range of 300-400 hours.
We have based the effort levels on the hours necessary for a
software developer to develop and prepare the EHR technology for
testing and certification. The U.S. Department of Labor, Bureau of
Labor Statistics estimates that the mean hourly wage for a software
developer is $44.27.\42\ We have also calculated the costs of an
employee's benefits. We have calculated these costs by assuming that an
employer expends thirty-six percent (36%) of an employee's hourly wage
on benefits for the employee. We have concluded that a 36% expenditure
on benefits is an appropriate estimate because it is the routine
percentage used by HHS for contract cost estimates. We have rounded the
average software developer's wage with benefits to $60 per hour.
---------------------------------------------------------------------------
\42\ http://www.bls.gov/oes/current/oes151132.htm.
---------------------------------------------------------------------------
To calculate our low cost estimates for each certification
criterion in the tables below, we have multiplied the low number of the
estimated range of EHR technologies expected to be developed and
prepared by the low number of estimated hours (``level of effort''
described above) for a software developer to develop and prepare the
EHR technologies for testing and certification. To calculate our high
cost estimates for each certification criterion in the tables below, we
have multiplied the high number of the estimated range of EHR
technologies expected to be developed and prepared to the criterion by
the high number of estimated hours (``level of effort'' described
above) for a software developer to develop and prepare the EHR
technologies for testing and certification. For the following tables
(Tables 7 through Table 13), dollar amounts are expressed in 2012
dollars.
In comparison to the listed certification criteria in the
regulatory impact analysis for the Proposed Rule, we note the following
changes based on the certification criteria we adopted. We have
included the two new adopted certification criteria: data portability
(Sec. 170.314(b)(7); and quality management systems (Sec.
170.414(g)(4)). We have moved the proposed unchanged certification
criteria that have been adopted as revised certification criteria into
the revised certification criteria section. These include: ``drug-
formulary checks'' (Sec. 170.314(a)(10)); ``vital signs, body mass
index, and growth charts'' (Sec. 170.314(a)(4)); ``smoking status''
(Sec. 170.314(a)(11)); ``patient lists'' (Sec. 170.314(a)(14)); and
``patient reminders'' (Sec. 170.314(a)(15)) [now combined and
collectively referred to as ``patient list creation'']. Last, we have
moved the new ``view, download, and transmit to 3rd party''
certification criterion (Sec. 170.314(e)(1)) from a level 3 effort
down to a level 2 effort. We changed the level of effort because we did
not adopt our proposals regarding images and WCAG 2.0 level AA for this
certification criterion and because many of the EHR technologies that
will be designed to meet this certification criterion have already met
the 2011 Edition ``timely access'' certification criterion (Sec.
170.304(g)).
New Certification Criteria
Table 7--2014 Edition New EHR Certification Criteria: Level 1 Effort
----------------------------------------------------------------------------------------------------------------
Estimated
number of EHR Average Average
technologies development development
Regulation section Certification to be and and
criterion developed with preparation preparation
this costs--low costs--high
capability ($M) ($M)
----------------------------------------------------------------------------------------------------------------
170.314(a)(9)................................... Electronic 420-514 1.01 3.08
notes
170.314(a)(13).................................. Family health 420-514 1.01 3.08
history
170.314(b)(3)................................... Electronic 101-123 .24 .74
prescribing
(inpatient)
170.314(b)(7)................................... Data 670-818 1.61 4.91
portability
[[Page 54279]]
170.314(f)(5)................................... Cancer case 320-392 .77 2.35
information
170.314(g)(4)................................... Quality 670-818 1.61 4.91
management
systems
---------------------------------------------------------------
Total....................................... .............. .............. 6.25 19.07
----------------------------------------------------------------------------------------------------------------
Table 8--2014 Edition New EHR Certification Criteria: Level 2 Effort
----------------------------------------------------------------------------------------------------------------
Estimated
number of EHR Average Average
technologies development development
Regulation section Certification criterion to be and and
developed with preparation Preparation
this costs--low costs--high
capability ($M) ($M)
----------------------------------------------------------------------------------------------------------------
170.314(a)(12)........................ Image results........... 420-514 2.52 9.25
170.314(b)(6)......................... Transmission of 146-178 .88 3.20
electronic laboratory
tests and values/
results to ambulatory
providers.
170.314(d)(4)......................... Amendments.............. 566-691 3.40 12.44
170.314(e)(1)......................... View, download, and 567-693 3.40 12.47
transmit to 3rd party.
170.314(e)(3)......................... Secure messaging........ 320-392 1.92 7.06
170.314(f)(6)......................... Transmission to cancer 320-392 1.92 7.06
registries.
170.314(g)(1)......................... Automated numerator 398-486 2.39 8.75
recording.
-------------------------------------------------------------------------
Total............................. ........................ .............. 16.43 60.23
----------------------------------------------------------------------------------------------------------------
Table 9--2014 Edition New EHR Certification Criteria: Level 3 Effort
----------------------------------------------------------------------------------------------------------------
Estimated
of Average Average
EHR development development
technologies and and
Regulation section Certification criterion to be preparation preparation
developed with costs--low costs--high
this ($M) ($M)
capability
----------------------------------------------------------------------------------------------------------------
170.314(a)(16)........................ Electronic medication 101-123 1.82 2.95
administration record.
170.314(g)(3)......................... Safety-enhanced design.. 567-693 10.21 16.63
-------------------------------------------------------------------------
Total................................. ........................ .............. 12.03 19.58
----------------------------------------------------------------------------------------------------------------
Revised Certification Criteria
Table 10--2014 Edition Revised EHR Certification Criteria: Level 1 Effort
----------------------------------------------------------------------------------------------------------------
Estimated
number of EHR Average Average
technologies development development
Regulation section Certification criterion to be and and
developed with preparation preparation
this costs--low costs--high
capability ($M) ($M)
----------------------------------------------------------------------------------------------------------------
170.314(a)(2)......................... Drug-drug, drug-allergy 484-591 1.16 3.55
interaction checks.
170.314(a)(3)......................... Demographics............ 530-648 1.27 3.89
170.314(a)(4)......................... Vital signs, body mass 502-613 1.20 3.68
index, and growth
charts.
170.314(a)(5)......................... Problem list............ 504-616 1.21 3.70
170.314(a)(10)........................ Drug-formulary checks... 484-591 1.16 3.55
170.314(a)(11)........................ Smoking status.......... 536-655 1.29 3.93
170.314(a)(14)........................ Patient list creation... 473-578 1.14 3.47
170.314(a)(15)........................ Patient-specific 480-587 1.15 3.52
education resources.
170.314(b)(3)......................... Electronic prescribing 445-544 1.07 3.26
(ambulatory).
170.314(b)(5)......................... Incorporate laboratory 167-205 .40 1.23
tests and values/
results (ambulatory
setting).
[[Page 54280]]
170.314(c)(2)......................... Clinical quality 497-608 1.19 3.65
measures--incorporate
and calculate.
170.314(d)(3)......................... Audit report(s)......... 670-818 1.61 4.91
170.314(e)(2)......................... Clinical summaries...... 432-528 1.04 3.17
170.314(f)(2)......................... Transmission to 456-557 1.09 3.34
immunization registries.
170.314(f)(3)......................... Transmission to public 447-546 1.07 3.28
health agencies--
syndromic surveillance.
170.314(f)(4)......................... Transmission of 60-74 .14 .44
reportable laboratory
tests and values/
results.
-------------------------------------------------------------------------
Total............................. ........................ .............. 17.19 52.57
----------------------------------------------------------------------------------------------------------------
Table 11--2014 Edition Revised EHR Certification Criteria: Level 2 Effort
----------------------------------------------------------------------------------------------------------------
Estimated
number of EHR Average Average
technologies development development
Regulation Section Certification criterion to be and and
developed with preparation preparation
this costs--low costs--high
capability ($M) ($M)
----------------------------------------------------------------------------------------------------------------
170.314(b)(1)......................... Transitions of care-- 514-628 3.08 11.30
receive, display, and
incorporate transition
of care/referral
summaries.
170.314(b)(4)......................... Clinical information 498-609 2.99 10.96
reconciliation.
170.314(c)(3)......................... Clinical quality 497-608 2.98 10.94
measures--submission.
170.314(d)(2)......................... Auditable events and 670-818 4.02 14.72
tamper resistance.
170.314(d)(7)......................... End-user device 667-816 4.00 14.69
encryption.
170.314(g)(2)......................... Automated measure 460-562 2.76 10.12
calculation.
-------------------------------------------------------------------------
Total............................. ........................ .............. 19.83 72.73
----------------------------------------------------------------------------------------------------------------
Table 12--2014 Edition Revised EHR Certification Criteria: Level 3 Effort
----------------------------------------------------------------------------------------------------------------
Estimated
number of EHR Average Average
technologies development development
Regulation Section Certification criterion to be and and
developed with preparation preparation
this costs--low costs--high
capability ($M) ($M)
----------------------------------------------------------------------------------------------------------------
170.314(a)(8)......................... Clinical decision 474-580 8.53 17.40
support.
170.314(b)(2)......................... Transitions of care-- 514-628 9.25 18.84
create and transmit
transition of care/
referral summaries.
170.314(c)(1)......................... Clinical quality 497-608 8.95 18.24
measures--capture and
export.
-------------------------------------------------------------------------
Total............................. ........................ .............. 26.73 54.48
----------------------------------------------------------------------------------------------------------------
Unchanged Certification Criteria
Table 13--2014 Edition Unchanged EHR Certification Criteria: Level 2 Effort
----------------------------------------------------------------------------------------------------------------
Estimated
number of EHR Average Average
technologies development development
Regulation Section Certification criterion to be and and
developed with preparation preparation
this costs--low costs--high
capability ($M) ($M)
----------------------------------------------------------------------------------------------------------------
170.314(a)(1)......................... CPOE.................... 62 .37 1.12
170.314(a)(6)......................... Medication list......... 57 .34 1.03
170.314(a)(7)......................... Medication allergy list. 58 .35 1.04
170.314(a)(17)........................ Advance directives...... 11 .07 .20
[[Page 54281]]
170.314(b)(5)......................... Incorporate laboratory 19 .11 .34
tests and values/
results (inpatient
setting).
170.314(d)(1)......................... Authentication, access 76 .46 1.37
control, and
authorization.
170.314(d)(5)......................... Automatic log-off....... 76 .46 1.37
170.314(d)(6)......................... Emergency access........ 73 .44 1.31
170.314(d)(8)......................... Integrity............... 75 .45 1.35
170.314(d)(9)......................... Accounting of 13 .08 .23
disclosures.
170.314(f)(1)......................... Immunization information 51 .31 .92
���������������������������������������
Total............................. ........................ .............. 3.44 10.28
----------------------------------------------------------------------------------------------------------------
ii. Overall Development and Preparation Estimated Costs Over a 3-Year
Period
In total, we estimate the overall costs for a 3-year period to be
$101.90 million to $288.94 million, with a cost mid-point of
approximately $195.42 million. If we were to evenly distribute the
overall estimated costs to develop and prepare Complete EHRs and EHR
Modules between calendar years 2012 and 2014, we believe they would
likely be in the range of $33.97 million to $96.31 million per year
with an annual cost mid-point of approximately $65.14 million. We have
used the mid-point cost as our primary annual cost estimate for this
regulatory impact analysis.
We do not believe that the estimated costs will be spread evenly
over these three years due to market pressures, primarily consisting of
EPs, EHs, and CAHs needing to adopt and implement EHR technology
certified to the 2014 Edition EHR certification criteria in order to
have CEHRT in FY/CY 2014. Based on this market pressure, in the
Proposed Rule, we distributed the majority of the estimated costs in
2012 (40%) and 2013 (50%), while only distributing 10% of the estimated
costs in 2014. With the additional flexibility that we have adopted in
the CEHRT definition for FY/CY 2013, namely permitting EPs, EHs, and
CAHs to meet the CEHRT definition for FY/CY 2014 in FY/CY 2013, we
believe that the market pressure for EHR technology certified to the
2014 Edition EHR certification criteria to be available sooner will
further increase. Given this consideration and the fact that we have
issued this final rule sooner than we anticipated when publishing the
Proposed Rule, we have revised our distribution of estimated costs to
place more of the total estimated costs in 2012. As such, the estimated
costs attributable to this final rule are distributed as follows: 45%
for 2012, 45% for 2013, and 10% for 2014. This distribution of
estimated costs for the year in which this final rule is published is
also consistent with the distribution we used in the S&CC July 2010
final rule (75 FR 44648) for the year in which it was published. Table
14 below expresses the distribution of estimated costs for 2012 through
2014 in 2012 dollars.
Table 14--Distributed Total Development and Preparation Costs for Complete EHR and EHR Module Developers (3-Year
Period)--Totals Rounded
----------------------------------------------------------------------------------------------------------------
Primary mid-
Total low cost Total high point total
Year Ratio (%) estimate ($M) cost estimate cost estimate
($M) ($M)
----------------------------------------------------------------------------------------------------------------
2012............................................ 45 45.85 130.02 87.93
2013............................................ 45 45.85 130.02 87.93
2014............................................ 10 10.20 28.90 19.56
�������������������������������������������������
3-Year Totals............................... .............. 101.90 288.94 195.42
----------------------------------------------------------------------------------------------------------------
iii. Costs for Reporting Test Results Hyperlinks
Costs to ONC-ACBs
Under Sec. 170.523(f)(8), ONC-ACBs are required to provide ONC, no
less frequently than weekly, a hyperlink with each EHR technology it
certifies that provides the public with the ability to access the test
results used to certify the EHR technology. As stated in the collection
of information section, the reporting of this information will be
required on a weekly basis and it will take each ONC-ACB about 20
minutes to prepare and electronically transmit an estimated four test
results hyperlinks with the other required information to ONC each
week.
We believe that an employee equivalent to the Federal
Classification of GS-9 Step 1 could report the hyperlink to ONC. We
have utilized the corresponding employee hourly rate for the locality
pay area of Washington, DC, as published by OPM, to calculate our cost
estimates. We have also calculated the costs of the employee's benefits
while completing the specified tasks. We have calculated these costs by
assuming that an ONC-ACB expends thirty-six percent (36%) of an
employee's hourly wage on benefits for the employee. We have concluded
that a 36% expenditure on benefits is an appropriate estimate because
it is the routine percentage used by HHS for contract cost estimates.
Our cost estimates are expressed in Table 15 below and are expressed in
2012 dollars.
[[Page 54282]]
Table 15--Annual Costs for an ONC-ACB To Report Test Results Hyperlinks to ONC
--------------------------------------------------------------------------------------------------------------------------------------------------------
Annual burden Employee
Program requirement Employee equivalent hours per ONC- Employee hourly benefits hourly Total cost per
ACB wage rate cost ONC-ACB
--------------------------------------------------------------------------------------------------------------------------------------------------------
45 CFR 170.523(f)(8)............................ GS-9 Step 1....................... 17.16 $22.39 $8.06 $522.52
--------------------------------------------------------------------------------------------------------------------------------------------------------
To estimate the highest possible cost, we assume that all of the
applicants we estimated for the purposes of the collection of
information (i.e., six) will apply and become ONC-ACBs under the ONC
HIT Certification Program. Therefore, we estimate the total annual
development and reporting cost under the ONC HIT Certification Program
to be $3,136 (rounded using a total of 103 hours).
Costs to the Federal Government
We do not believe that the collection of information requirement of
Sec. 170.523(f)(8), through our posting of test results hyperlinks on
the CHPL, will require us to incur any additional costs than the costs
we estimated for having personnel post a list of all certified Complete
EHRs and certified EHR Modules on our Web site (i.e., the CHPL), which
was $10,784 on an annualized basis (76 FR 1323).
b. Benefits
We believe that there will be several benefits that may arise from
this final rule. Foremost, EHR technology certified to the 2014 Edition
EHR certification criteria will be capable of supporting EPs, EHs, and
CAHs' attempts to demonstrate MU under the EHR Incentive Programs. The
2014 Edition EHR certification criteria also promote enhanced
interoperability, functionality, utility, and security of EHR
technology through the capabilities they include and the standards they
require EHR technology to meet for certification. The capabilities
specified in the 2014 Edition EHR certification criteria will help
ensure that health care providers have the necessary information
technology tools to improve patient care, and reduce medical errors and
unnecessary tests. The standards adopted will aid in fostering greater
interoperability.
The provisions in this final rule will increase the competition and
innovation in the HIT marketplace that was spurred by the Secretary's
adoption of the 2011 Edition EHR certification criteria. The revised
CEHRT definition, the process for approving newer versions of minimum
standards, and the revised privacy and security certification of EHR
Modules will reduce the regulatory burden and add flexibility for EHR
technology developers, EPs, EHs, and CAHs. Further, the ``splitting''
of certain certification criteria into multiple certification criteria
should increase the opportunity and flexibility for EHR technology
developers to have more EHR technology eligible for certification.
Last, the provisions of this final rule are supportive of other
initiatives, such as the Partnership for Patients, Medicare Shared
Savings Program, and other quality measure programs administered by
CMS.
3. Regulatory Flexibility Act
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 Complete
EHRs and EHR Module developers represent a small segment of the overall
information technology industry, we believe that the entities impacted
by this final rule most likely fall under the North American Industry
Classification System (NAICS) code 541511 ``Custom Computer 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.5 million in annual
receipts \43\ which ``indicates the maximum allowed for a concern and
its affiliates to be considered small entities.''
---------------------------------------------------------------------------
\43\ 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 Complete EHR or EHR Module. We also note
that with the exception of aggregate business information available
through the U.S. Census Bureau and the SBA related to NAICS code
541511, it appears that many Complete EHR and EHR Module developers are
privately held or owned and do not regularly, if at all, make their
specific annual receipts publicly available. As a result, it is
difficult to locate empirical data related to many of the Complete EHR
and EHR Module developers to correlate to the SBA size standard.
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 will have effects on Complete EHR
and EHR Module developers, some of which may be small entities.
However, we believe that we have established the minimum amount of
requirements necessary to accomplish our policy goals, 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. In order for a Complete EHR or EHR
Module to provide the capabilities that an EP, EH, or CAH would be
required to use under the Stage 2 final rule, it will need to comply
with the applicable 2014 Edition EHR certification criteria adopted by
the Secretary. Moreover, we note that this final rule does not impose
the costs cited in the regulatory impact analysis as compliance costs,
but rather as investments which Complete EHR and EHR Module developers
voluntarily take on and expect to recover with an appropriate rate of
return. Accordingly, we do not believe that this final rule will create
a significant impact on a substantial number of small entities. The
Secretary certifies that this final rule will not have a significant
impact on a substantial number of small entities.
4. Executive Order 13132--Federalism
Executive Order 13132 establishes certain requirements that an
agency must meet when it promulgates a final
[[Page 54283]]
rule that imposes substantial direct requirement costs on state and
local governments, preempts state law, or otherwise has federalism
implications. Nothing in this final rule imposes substantial direct
compliance costs on state and local governments, preempts state law or
otherwise has federalism implications. We are not aware of any state
laws or regulations that are contradicted or impeded by any of the
standards, implementation specifications, or certification criteria
that the Secretary has adopted.
5. 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 1 year of $100 million in
1995 dollars, updated annually for inflation. The current inflation-
adjusted statutory threshold is approximately $139 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.
The Office of Management and Budget reviewed this final rule.
List of Subjects in 45 CFR Part 170
Computer technology, Electronic health record, Electronic
information system, Electronic transactions, Health, Health care,
Health information technology, Health insurance, Health records,
Hospitals, Incorporation by reference, Laboratories, Medicaid,
Medicare, Privacy, Reporting and recordkeeping requirements, Public
health, Security.
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. In Sec. 170.102, remove the ``Complete EHR'' definition, add in
alphanumeric order the definitions ``2011 Edition EHR certification
criteria,'' ``2014 Edition EHR certification criteria,'' ``Base EHR,''
``Common MU Data Set,'' ``Complete EHR, 2011 Edition,'' and ``Complete
EHR, 2014 Edition,'' and revise the definition of ``Certified EHR
Technology'' to read as follows:
Sec. 170.102 Definitions.
2011 Edition EHR certification criteria means the certification
criteria at Sec. Sec. 170.302, 170.304, and 170.306.
2014 Edition EHR certification criteria means the certification
criteria at Sec. 170.314.
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;
(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 at: Sec. 170.314(a)(1), (3), and (5) through (8); (b)(1),
(2), and (7); (c)(1) through (3); (d)(1) through (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.
* * * * *
Certified EHR Technology means:
(1) For any Federal fiscal year (FY) or calendar year (CY) up to
and including 2013:
(i) A Complete EHR that meets the requirements included in the
definition of a Qualified EHR and has been tested and certified in
accordance with the certification program established by the National
Coordinator as having met all applicable certification criteria adopted
by the Secretary for the 2011 Edition EHR certification criteria or the
equivalent 2014 Edition EHR certification criteria; or
(ii) A combination of EHR Modules in which each constituent EHR
Module of the combination has been tested and certified in accordance
with the certification program established by the National Coordinator
as having met all applicable certification criteria adopted by the
Secretary for the 2011 Edition EHR certification criteria or the
equivalent 2014 Edition EHR certification criteria, and the resultant
combination also meets the requirements included in the definition of a
Qualified EHR; or
(iii) EHR technology that satisfies the definition for FY and CY
2014 and subsequent years specified in paragraph (2);
(2) For FY and CY 2014 and subsequent years, the following: EHR
technology certified under the ONC HIT Certification Program to the
2014 Edition EHR certification criteria that has:
(i) The capabilities required to meet the Base EHR definition; and
(ii) All other capabilities that are necessary to meet the
objectives and associated measures under 42 CFR 495.6 and successfully
report the clinical quality measures selected by CMS in the form and
manner specified by CMS (or the States, as applicable) for the stage of
meaningful use that an eligible professional, eligible hospital, or
critical access hospital seeks to achieve.
Common MU Data Set means the following data expressed, where
indicated, according to the specified standard(s):
(1) Patient name.
(2) Sex.
(3) Date of birth.
(4) Race--the standard specified in Sec. 170.207(f).
(5) Ethnicity--the standard specified in Sec. 170.207(f).
(6) Preferred language--the standard specified in Sec. 170.207(g).
(7) Smoking status--the standard specified in Sec. 170.207(h).
(8) Problems--at a minimum, the version of the standard specified
in Sec. 170.207(a)(3).
(9) Medications--at a minimum, the version of the standard
specified in Sec. 170.207(d)(2).
(10) Medication allergies--at a minimum, the version of the
standard specified in Sec. 170.207(d)(2).
(11) Laboratory test(s)--at a minimum, the version of the standard
specified in Sec. 170.207(c)(2).
(12) Laboratory value(s)/result(s).
(13) Vital signs--height, weight, blood pressure, BMI.
(14) Care plan field(s), including goals and instructions.
(15) Procedures--
(i) At a minimum, the version of the standard specified in Sec.
170.207(a)(3) or Sec. 170.207(b)(2).
(ii) Optional. The standard specified at Sec. 170.207(b)(3).
[[Page 54284]]
(iii) Optional. The standard specified at Sec. 170.207(b)(4).
(16) Care team member(s).
Complete EHR, 2011 Edition means EHR technology that has been
developed to meet, at a minimum, all mandatory 2011 Edition EHR
certification criteria for either an ambulatory setting or inpatient
setting.
Complete EHR, 2014 Edition means EHR technology that meets the Base
EHR definition and has been developed to meet, at a minimum, all
mandatory 2014 Edition EHR certification criteria for either an
ambulatory setting or inpatient setting.
* * * * *
0
3. Add Sec. 170.202 to read as follows:
Sec. 170.202 Transport standards.
The Secretary adopts the following transport standards:
(a) Standard. ONC Applicability Statement for Secure Health
Transport (incorporated by reference in Sec. 170.299).
(b) Standard. ONC XDR and XDM for Direct Messaging Specification
(incorporated by reference in Sec. 170.299).
(c) Standard. ONC Transport and Security Specification
(incorporated by reference in Sec. 170.299).
0
4. Add Sec. 170.204 to read as follows:
Sec. 170.204 Functional standards.
The Secretary adopts the following functional standards:
(a) Accessibility. Standard. Web Content Accessibility Guidelines
(WCAG) 2.0, Level A Conformance (incorporated by reference in Sec.
170.299).
(b) Reference source. Standard. HL7 Version 3 Standard: Context-
Aware Retrieval Application (Infobutton) (incorporated by reference in
Sec. 170.299). (1) Implementation specifications. HL7 Version 3
Implementation Guide: URL-Based Implementations of the Context-Aware
Information Retrieval (Infobutton) Domain, (incorporated by reference
in Sec. 170.299).
(2) Implementation specifications. HL7 Version 3 Implementation
Guide: Context-Aware Knowledge Retrieval (Infobutton) Service-Oriented
Architecture Implementation Guide, (incorporated by reference in Sec.
170.299).
(c) Clinical quality measure-by-measure data. Data Element Catalog,
(incorporated by reference in Sec. 170.299).
0
5. In Sec. 170.205, republish the introductory text and add paragraphs
(a)(3), (d)(3), (e)(3), and (g) through (k) to read as follows:
Sec. 170.205 Content exchange standards and implementation
specifications for exchanging electronic health information.
The Secretary adopts the following content exchange standards and
associated implementation specifications:
(a) * * *
(3) Standard. HL7 Implementation Guide for CDA[supreg] Release 2:
IHE Health Story Consolidation, (incorporated by reference in Sec.
170.299). The use of the ``unstructured document'' document-level
template is prohibited.
* * * * *
(d) * * *
(3) Standard. HL7 2.5.1 (incorporated by reference in Sec.
170.299). Implementation specifications. PHIN Messaging Guide for
Syndromic Surveillance (incorporated by reference in Sec. 170.299) and
Conformance Clarification for EHR Certification of Electronic Syndromic
Surveillance, Addendum to PHIN Messaging Guide for Syndromic
Surveillance (incorporated by reference in Sec. 170.299).
(e) * * *
(3) Standard. HL7 2.5.1 (incorporated by reference in Sec.
170.299). Implementation specifications. HL7 2.5.1 Implementation Guide
for Immunization Messaging, Release 1.4, (incorporated by reference in
Sec. 170.299).
* * * * *
(g) Electronic transmission of lab results to public health
agencies. Standard. HL7 2.5.1 (incorporated by reference in Sec.
170.299). Implementation specifications. HL7 Version 2.5.1
Implementation Guide: Electronic Laboratory Reporting to Public Health,
Release 1 (US Realm) (incorporated by reference in Sec. 170.299) with
Errata and Clarifications, (incorporated by reference in Sec. 170.299)
and ELR 2.5.1 Clarification Document for EHR Technology Certification,
(incorporated by reference in Sec. 170.299).
(h) Clinical quality measure data import, export, and electronic
submission. Standard. HL7 Implementation Guide for CDA[supreg] Release
2: Quality Reporting Document Architecture, (incorporated by reference
in Sec. 170.299).
(i) Cancer information. 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),
(incorporated by reference in Sec. 170.299).
(j) Electronic incorporation and transmission of lab results.
Standard. HL7 Version 2.5.1 Implementation Guide: S&I Framework Lab
Results Interface, (incorporated by reference in Sec. 170.299).
(k) Clinical quality measure aggregate electronic submission.
Standard. Quality Reporting Document Architecture Category III,
Implementation Guide for CDA Release 2 (incorporated by reference in
Sec. 170.299).
0
6. In Sec. 170.207, republish the introductory text and add paragraphs
(a)(3), (b)(3), (b)(4), revise paragraphs (c), (d), (e), and (f) and
add paragraphs (g) through (j) to read as follows:
Sec. 170.207 Vocabulary standards for representing electronic health
information.
The Secretary adopts the following code sets, terminology, and
nomenclature as the vocabulary standards for the purpose of
representing electronic health information:
(a) * * *
(3) Standard. IHTSDO SNOMED CT[supreg] International Release July
2012 (incorporated by reference in Sec. 170.299) and US Extension to
SNOMED CT[supreg] March 2012 Release (incorporated by reference in
Sec. 170.299).
(b) * * *
(3) Standard. The code set specified at 45 CFR 162.1002(a)(4).
(4) Standard. The code set specified at 45 CFR 162.1002(c)(3) for
the indicated procedures or other actions taken.
(c) Laboratory tests. (1) Standard. Logical Observation Identifiers
Names and Codes (LOINC[supreg]) version 2.27, when such codes were
received within an electronic transaction from a laboratory
(incorporated by reference in Sec. 170.299).
(2) Standard. Logical Observation Identifiers Names and Codes
(LOINC[supreg]) Database version 2.40, a universal code system for
identifying laboratory and clinical observations produced by the
Regenstrief Institute, Inc. (incorporated by reference in Sec.
170.299).
(d) Medications. (1) Standard. Any source vocabulary that is
included in RxNorm, a standardized nomenclature for clinical drugs
produced by the United States National Library of Medicine.
(2) Standard. RxNorm, a standardized nomenclature for clinical
drugs produced by the United States National Library of Medicine,
August 6, 2012 Release (incorporated by reference in Sec. 170.299).
(e) Immunizations. (1) Standard. HL7 Standard Code Set CVX--
Vaccines Administered, July 30, 2009 version (incorporated by reference
in Sec. 170.299).
(2) Standard. HL7 Standard Code Set CVX--Vaccines Administered,
updates through July 11, 2012 (incorporated by reference in Sec.
170.299).
(f) Race and Ethnicity. Standard. The Office of Management and
Budget Standards for Maintaining, Collecting, and Presenting Federal
Data on Race
[[Page 54285]]
and Ethnicity, Statistical Policy Directive No. 15, as revised, October
30, 1997 (see ``Revisions to the Standards for the Classification of
Federal Data on Race and Ethnicity,'' available at http://www.whitehouse.gov/omb/fedreg_1997standards).
(g) Preferred language. Standard. As specified by the Library of
Congress, ISO 639-2 alpha-3 codes limited to those that also have a
corresponding alpha-2 code in ISO 639-1. (incorporated by reference in
Sec. 170.299).
(h) Smoking status. Standard. Smoking status must be coded in one
of the following SNOMED CT[supreg] codes:
(1) Current every day smoker. 449868002
(2) Current some day smoker. 428041000124106
(3) Former smoker. 8517006
(4) Never smoker. 266919005
(5) Smoker, current status unknown. 77176002
(6) Unknown if ever smoked. 266927001
(7) Heavy tobacco smoker. 428071000124103
(8) Light tobacco smoker. 428061000124105
(i) Encounter diagnoses. Standard. The code set specified at 45 CFR
162.1002(c)(2) for the indicated conditions.
(j) Family health history. HL7 Version 3 Standard: Clinical
Genomics; Pedigree, (incorporated by reference in Sec. 170.299).
0
7. In Sec. 170.210:
0
a. Republish the introductory text;
0
b. In paragraph (a)(1), add the phrase ``, (January 27, 2010)'' after
``140-2'';
0
c. In paragraph (c), remove ``180-3 (October, 2008))'' and add in its
place ``180-4 (March 2012))''; and
0
d. Add paragraphs (e) through (h) to read as follows:
Sec. 170.210 Standards for health information technology to protect
electronic health information created, maintained, and exchanged.
The Secretary adopts the following standards to protect electronic
health information created, maintained, and exchanged:
* * * * *
(e) Record actions related to electronic health information, audit
log status, and encryption of end-user devices. (1)(i) The audit log
must record the information specified in sections 7.2 through 7.4, 7.6,
and 7.7 of the standard specified at Sec. 170.210(h) when EHR
technology is in use.
(ii) The date and time must be recorded in accordance with the
standard specified at Sec. 170.210(g).
(2)(i) The audit log must record the information specified in
sections 7.2 and 7.4 of the standard specified at Sec. 170.210(h) when
the audit log status is changed.
(ii) The date and time each action occurs in accordance with the
standard specified at Sec. 170.210(g).
(3) The audit log must record the information specified in sections
7.2 and 7.4 of the standard specified at Sec. 170.210(h) when the
encryption status of electronic health information locally stored by
EHR technology on end-user devices is changed. The date and time each
action occurs in accordance with the standard specified at Sec.
170.210(g).
(f) Encryption and hashing of electronic health information. Any
encryption and hashing algorithm identified by the National Institute
of Standards and Technology (NIST) as an approved security function in
Annex A of the FIPS Publication 140-2 (incorporated by reference in
Sec. 170.299).
(g) Synchronized clocks. The date and time recorded utilize a
system clock that has been synchronized following (RFC 1305) Network
Time Protocol, (incorporated by reference in Sec. 170.299) or (RFC
5905) Network Time Protocol Version 4, (incorporated by reference in
Sec. 170.299).
(h) Audit log content. ASTM E2147-01(Reapproved 2009),
(incorporated by reference in Sec. 170.299)
0
8. Amend Sec. 170.299 by revising paragraphs (b) through (j) and
adding paragraphs (k) through (n) to read as follows:
Sec. 170.299 Incorporation by reference.
* * * * *
(b) American National Standards Institute, Health Information
Technology Standards Panel (HITSP) Secretariat, 25 West 43rd Street--
Fourth Floor, New York, NY 10036, http://www.hitsp.org.
(1) HITSP Summary Documents Using HL7 Continuity of Care Document
(CCD) Component, HITSP/C32, July 8, 2009, Version 2.5, IBR approved for
Sec. 170.205.
(2) [Reserved]
(c) ASTM International, 100 Barr Harbor Drive, PO Box C700, West
Conshohocken, PA, 19428-2959 USA; Telephone (610) 832-9585 or http://www.astm.org/.
(1) ASTM E2147-01 (Reapproved 2009) Standard Specification for
Audit and Disclosure Logs for Use in Health Information Systems,
approved September 1, 2009, IBR approved for Sec. 170.210.
(2) ASTM E2369-05: Standard Specification for Continuity of Care
Record (CCR), year of adoption 2005, ASTM approved July 17, 2006, IBR
approved for Sec. 170.205.
(3) ASTM E2369-05 (Adjunct to E2369): Standard Specification
Continuity of Care Record,--Final Version 1.0 (V1.0), November 7, 2005,
IBR approved for Sec. 170.205.
(d) Centers for Disease Control and Prevention, 2500 Century
Parkway, Mailstop E-78, Atlanta, GA 30333, USA (800-232-4636); http://www.cdc.gov/ehrmeaningfuluse/.
(1) HL7 Standard Code Set CVX--Vaccines Administered, July 30,
2009, IBR approved for Sec. 170.207.
(2) IIS: HL7 Standard Code Set CVX--Vaccines Administered, updates
through July 11, 2012, IBR approved for Sec. 170.207.
(3) Implementation Guide for Immunization Data Transactions using
Version 2.3.1 of the Health Level Seven (HL7)Standard Protocol
Implementation Guide Version 2.2, June 2006, IBR approved for Sec.
170.205.
(4) HL7 2.5.1 Implementation Guide for Immunization Messaging
Release 1.0, May 1, 2010, IBR approved for Sec. 170.205.
(5) PHIN Messaging Guide for Syndromic Surveillance: Emergency
Department and Urgent Care Data, ADT Messages A01, A03, A04, and A08,
HL7 Version 2.5.1 (Version 2.3.1 Compatible), Release 1.1, August 2012,
IBR approved for Sec. 170.205.
(6) Conformance Clarification for EHR Certification of Electronic
Syndromic Surveillance, ADT MESSAGES A01, A03, A04, and A08, HL7
Version 2.5.1, Addendum to PHIN Messaging Guide for Syndromic
Surveillance: Emergency Department and Urgent Care Data (Release 1.1),
August 2012, IBR approved for Sec. 170.205.
(7) HL7 2.5.1 Implementation Guide for Immunization Messaging,
Release 1.4, August 1, 2012, IBR approved for Sec. 170.205.
(8) Implementation Guide for Ambulatory Healthcare Provider
Reporting to Central Cancer Registries, HL7 Clinical Document
Architecture (CDA), Release 1.0, August 2012, IBR approved for Sec.
170.205.
(9) ELR 2.5.1 Clarification Document for EHR Technology
Certification, July 16, 2012, IBR approved for Sec. 170.205.
(e) Centers for Medicare & Medicaid Services, Office of Clinical
Standards and Quality, 7500 Security Boulevard, Baltimore, Maryland
21244; Telephone (410) 786-3000
(1) CMS PQRI 2009 Registry XML Specifications, IBR approved for
Sec. 170.205.
(2) 2009 Physician Quality Reporting Initiative Measure
Specifications Manual for Claims and Registry, Version 3.0, December 8,
2008 IBR approved for Sec. 170.205.
[[Page 54286]]
(f) Health Level Seven, 3300 Washtenaw Avenue, Suite 227, Ann
Arbor, MI 48104; Telephone (734) 677-7777 or http://www.hl7.org/
(1) Health Level Seven Standard Version 2.3.1 (HL7 2.3.1), An
Application Protocol for Electronic Data Exchange in Healthcare
Environments, April 14, 1999, IBR approved for Sec. 170.205.
(2) Health Level Seven Messaging Standard Version 2.5.1 (HL7
2.5.1), An Application Protocol for Electronic Data Exchange in
Healthcare Environments, February 21, 2007, IBR approved for Sec.
170.205.
(3) Health Level Seven Implementation Guide: Clinical Document
Architecture (CDA) Release 2--Continuity of Care Document (CCD), April
01, 2007, IBR approved for Sec. 170.205.
(4) HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory
Reporting to Public Health, Release 1 (US Realm) HL7 Version 2.5.1:
ORU[supcaret]R01, HL7 Informative Document, February, 2010, IBR
approved for Sec. 170.205.
(5) HL7 Version 3 Standard: Context-Aware Retrieval Application
(Infobutton); Release 1, July 2010, IBR approved for Sec. 170.204.
(6) HL7 Version 3 Implementation Guide: URL-Based Implementations
of the Context-Aware Information Retrieval (Infobutton) Domain, Release
3, December 2010, IBR approved for Sec. 170.204.
(7) HL7 Version 3 Implementation Guide: Context-Aware Knowledge
Retrieval (Infobutton) Service-Oriented Architecture Implementation
Guide, Release 1, HL7 Draft Standard for Trial Use, March 2011, IBR
approved for Sec. 170.204.
(8) HL7 Implementation Guide for CDA[supreg] Release 2: IHE Health
Story Consolidation, DSTU Release 1.1 (US Realm) Draft Standard for
Trial Use July 2012, IBR approved for Sec. 170.205.
(9) HL7 Clinical Document Architecture, Release 2.0, Normative
Edition, May 2005, IBR approved for Sec. 170.205.
(10) HL7 Version 2.5.1 Implementation Guide: S&I Framework Lab
Results Interface, Release 1--US Realm [HL7 Version 2.5.1: ORU-R01]
Draft Standard for Trial Use, July 2012, IBR approved for Sec.
170.205.
(11) HL7 Version 3 Standard: Clinical Genomics; Pedigree, Release
1, Edition 2011, March 2012, IBR approved for Sec. 170.207.
(12) HL7 Implementation Guide for CDA[supreg] Release 2: Quality
Reporting Document Architecture, DTSU Release 2 (Universal Realm),
Draft Standard for Trial Use, July 2012, IBR approved for Sec.
170.205.
(13) HL7 v2.5.1 IG: Electronic Laboratory Reporting to Public
Health (US Realm), Release 1 Errata and Clarifications, September, 29,
2011, IBR approved for Sec. 170.205.
(14) Quality Reporting Document Architecture Category III, Release
1, Implementation Guide for CDA Release 2 (US Realm) Based on HL7 CDA
Release 2.0, August 2012, IBR approved for Sec. 170.205.
(g) Internet Engineering Task Force (IETF), University of Delaware,
Newark, DE 19716, Telephone (302) 831-8247, http://www.ietf.org/rfc.html.
(1) Network Time Protocol (Version 3) Specification, Implementation
and Analysis, March 1992, IBR approved for Sec. 170.210.
(2) Network Time Protocol Version 4: Protocol and Algorithms
Specification, June 2010, IBR approved for Sec. 170.210.
(h) Library of Congress, Network Development and MARC Standards
Office, Washington, DC 20540-4402, Tel: (202) 707-6237 or http://www.loc.gov/standards/iso639-2/.
(1) ISO 639-2. Codes for the Representation of Names of Languages
Part 2: Alpha-3 Code, April 8, 2011, IBR approved for Sec. 170.207.
(2) [Reserved]
(i) National Council for Prescription Drug Programs, Incorporated,
9240 E. Raintree Drive, Scottsdale, AZ 85260- 7518; Telephone (480)
477-1000; and Facsimile (480) 767-1042 or http://www.ncpdp.org.
(1) National Council for Prescription Drug Programs Prescriber/
Pharmacist Interface SCRIPT Standard, Implementation Guide, Version 8,
Release 1, October 2005, IBR approved for Sec. 170.205.
(2) SCRIPT Standard, Implementation Guide, Version 10.6, October,
2008, (Approval date for ANSI: November 12, 2008), IBR approved for
Sec. 170.205.
(j) National Institute of Standards and Technology, Information
Technology Laboratory, National Institute of Standards and Technology,
100 Bureau Drive, Gaithersburg, MD 20899-8930, http://csrc.nist.gov/groups/STM/cmvp/standards.html.
(1) Annex A: Approved Security Functions for FIPS PUB 140-2,
Security Requirements for Cryptographic Modules, Draft, January 27,
2010, IBR approved for Sec. 170.210.
(2) Annex A: Approved Security Functions for FIPS PUB 140-2,
Security Requirements for Cryptographic Modules, Draft, May 30, 2012,
IBR approved for Sec. 170.210.
(k) Office of the National Coordinator for Health Information
Technology (ONC), 200 Independence Avenue SW., Suite 729-D, Washington,
DC 20201, http://healthit.hhs.gov.
(1) Applicability Statement for Secure Health Transport, Version
1.1, July 10, 2012, IBR approved for Sec. 170.202; available at http://healthit.hhs.gov/portal/server.pt/community/healthit_hhs_gov__direct_project/3338.
(2) XDR and XDM for Direct Messaging Specification, Version 1,
March 9, 2011, IBR approved for Sec. 170.202; available at http://healthit.hhs.gov/portal/server.pt/community/healthit_hhs_gov__direct_project/3338.
(3) Transport and Security Specification, Version 1.0, June 19,
2012, IBR approved for Sec. 170.202.
(l) Regenstrief Institute, Inc., LOINC[supreg] c/o Medical
Informatics The Regenstrief Institute, Inc 410 West 10th Street, Suite
2000 Indianapolis, IN 46202-3012; Telephone (317) 423-5983 or http://loinc.org/.
(1) Logical Observation Identifiers Names and Codes (LOINC[supreg])
version 2.27, June 15, 2009, IBR approved for Sec. 170.207.
(2) Logical Observation Identifiers Names and Codes (LOINC[supreg])
Database version 2.40, Released June 2012, IBR approved for Sec.
170.207.
(m) U.S. National Library of Medicine, 8600 Rockville Pike,
Bethesda, MD 20894; Telephone (301) 594-5983 or http://www.nlm.nih.gov/.
(1) International Health Terminology Standards Development
Organization Systematized Nomenclature of Medicine Clinical Terms
(SNOMED CT[supreg]), International Release, July 2009, IBR approved for
Sec. 170.207.
(2) International Health Terminology Standards Development
Organisation (IHTSDO) Systematized Nomenclature of Medicine Clinical
Terms (SNOMED CT[supreg]) International Release July 31, 2012, IBR
approved for Sec. 170.207.
(3) US Extension to SNOMED CT[supreg] March 2012 Release, IBR
approved for Sec. 170.207.
(4) RxNorm, August 6, 2012 Full Release Update, IBR approved for
Sec. 170.207.
(5) Data Element Catalog, Version: August 2012, IBR approved for
Sec. 170.204.
(n) World Wide Web Consortium (W3C)/MIT, 32 Vassar Street, Room 32-
G515, Cambridge, MA 02139 USA, http://www.w3.org/standards/
(1) Web Content Accessibility Guidelines (WCAG) 2.0, December 11,
2008, IBR approved for Sec. 170.204.
(2) [Reserved]
0
9. In Sec. 170.300, republish paragraphs (a) and (b), revise paragraph
(c) and add paragraph (d) to read as follows:
[[Page 54287]]
Sec. 170.300 Applicability.
(a) The certification criteria adopted in this subpart apply to the
testing and certification of Complete EHRs and EHR Modules.
(b) When a certification criterion refers to two or more standards
as alternatives, the use of at least one of the alternative standards
will be considered compliant.
(c) Complete EHRs and EHR Modules are not required to be compliant
with certification criteria or capabilities specified within a
certification criterion that are designated as optional.
(d) In Sec. 170.314, all certification criteria and all
capabilities specified within a certification criterion have general
applicability (i.e., apply to both ambulatory and inpatient settings)
unless designated as ``inpatient setting only'' or ``ambulatory setting
only.''
(1) ``Inpatient setting only'' means that the criterion or
capability within the criterion is only required for certification of
EHR technology designed for use in an inpatient setting.
(2) ``Ambulatory setting only'' means that the criterion or
capability within the criterion is only required for certification of
EHR technology designed for use in an ambulatory setting.
0
10. Add Sec. 170.314 as follows:
Sec. 170.314 2014 Edition electronic health record certification
criteria.
The Secretary adopts the following certification criteria for
Complete EHRs or EHR Modules. Complete EHRs or EHR Modules must include
the capability to perform the following functions electronically,
unless designated as optional, and in accordance with all applicable
standards and implementation specifications adopted in this part:
(a) Clinical. (1) Computerized provider order entry. Enable a user
to electronically record, change, and access the following order types,
at a minimum:
(i) Medications;
(ii) Laboratory; and
(iii) Radiology/imaging.
(2) Drug-drug, drug-allergy interaction checks. (i) Interventions.
Before a medication order is completed and acted upon during
computerized provider order entry (CPOE), interventions must
automatically and electronically indicate to a user drug-drug and drug-
allergy contraindications based on a patient's medication list and
medication allergy list.
(ii) Adjustments. (A) Enable the severity level of interventions
provided for drug-drug interaction checks to be adjusted.
(B) Limit the ability to adjust severity levels to an identified
set of users or available as a system administrative function.
(3) Demographics. (i) Enable a user to electronically record,
change, and access patient demographic data including preferred
language, sex, race, ethnicity, and date of birth.
(A) Enable race and ethnicity to be recorded in accordance with the
standard specified in Sec. 170.207(f) and whether a patient declines
to specify race and/or ethnicity.
(B) Enable preferred language to be recorded in accordance with the
standard specified in Sec. 170.207(g) and whether a patient declines
to specify a preferred language.
(ii) Inpatient setting only. Enable a user to electronically
record, change, and access preliminary cause of death in the event of a
mortality.
(4) Vital signs, body mass index, and growth charts. (i) Vital
signs. Enable a user to electronically record, change, and access, at a
minimum, a patient's height/length, weight, and blood pressure. Height/
length, weight, and blood pressure must be recorded in numerical values
only.
(ii) Calculate body mass index. Automatically calculate and
electronically display body mass index based on a patient's height and
weight.
(iii) Optional--Plot and display growth charts. Plot and
electronically display, upon request, growth charts for patients.
(5) Problem list. Enable a user to electronically record, change,
and access a patient's active problem list:
(i) Ambulatory setting. Over multiple encounters in accordance
with, at a minimum, the version of the standard specified in Sec.
170.207(a)(3); or
(ii) Inpatient setting. For the duration of an entire
hospitalization in accordance with, at a minimum, the version of the
standard specified in Sec. 170.207(a)(3).
(6) Medication list. Enable a user to electronically record,
change, and access a patient's active medication list as well as
medication history:
(i) Ambulatory setting. Over multiple encounters; or
(ii) Inpatient setting. For the duration of an entire
hospitalization.
(7) Medication allergy list. Enable a user to electronically
record, change, and access a patient's active medication allergy list
as well as medication allergy history:
(i) Ambulatory setting. Over multiple encounters; or
(ii) Inpatient setting. For the duration of an entire
hospitalization.
(8) Clinical decision support. (i) Evidence-based decision support
interventions. Enable a limited set of identified users to select
(i.e., activate) one or more electronic clinical decision support
interventions (in addition to drug-drug and drug-allergy
contraindication checking) based on each one and at least one
combination of the following data:
(A) Problem list;
(B) Medication list;
(C) Medication allergy list;
(D) Demographics;
(E) Laboratory tests and values/results; and
(F) Vital signs.
(ii) Linked referential clinical decision support. (A) EHR
technology must be able to:
(1) Electronically identify for a user diagnostic and therapeutic
reference information; or
(2) Electronically identify for a user diagnostic and therapeutic
reference information in accordance with the standard specified at
Sec. 170.204(b) and the implementation specifications at Sec. 170.204
(b)(1) or (2).
(B) For paragraph (a)(8)(ii)(A) of this section, EHR technology
must be able to electronically identify for a user diagnostic or
therapeutic reference information based on each one and at least one
combination of the data referenced in paragraphs (a)(8)(i)(A) through
(F) of this section.
(iii) Clinical decision support configuration. (A) Enable
interventions and reference resources specified in paragraphs (a)(8)(i)
and (ii) of this section to be configured by a limited set of
identified users (e.g., system administrator) based on a user's role.
(B) EHR technology must enable interventions to be electronically
triggered:
(1) Based on the data referenced in paragraphs (a)(8)(i)(A) through
(F) of this section.
(2) When a patient's medications, medication allergies, and
problems are incorporated from a transition of care/referral summary
received pursuant to paragraph (b)(1)(iii) of this section.
(3) Ambulatory setting only. When a patient's laboratory tests and
values/results are incorporated pursuant to paragraph (b)(5)(i)(A)(1)
of this section.
(iv) Automatically and electronically interact. Interventions
triggered in accordance with paragraphs (a)(8)(i) through (iii) of this
section must automatically and electronically occur when a user is
interacting with EHR technology.
(v) Source attributes. Enable a user to review the attributes as
indicated for all clinical decision support resources:
(A) For evidence-based decision support interventions under
paragraph (a)(8)(i) of this section:
[[Page 54288]]
(1) Bibliographic citation of the intervention (clinical research/
guideline);
(2) Developer of the intervention (translation from clinical
research/guideline);
(3) Funding source of the intervention development technical
implementation; and
(4) Release and, if applicable, revision date(s) of the
intervention or reference source.
(B) For linked referential clinical decision support in paragraph
(a)(8)(ii) of this section and drug-drug, drug-allergy interaction
checks in paragraph(a)(2) of this section, the developer of the
intervention, and where clinically indicated, the bibliographic
citation of the intervention (clinical research/guideline).
(9) Electronic notes. Enable a user to electronically record,
change, access, and search electronic notes.
(10) Drug-formulary checks. EHR technology must automatically and
electronically check whether a drug formulary (or preferred drug list)
exists for a given patient and medication.
(11) Smoking status. Enable a user to electronically record,
change, and access the smoking status of a patient in accordance with
the standard specified at Sec. 170.207(h).
(12) Image results. Electronically indicate to a user the
availability of a patient's images and narrative interpretations
(relating to the radiographic or other diagnostic test(s)) and enable
electronic access to such images and narrative interpretations.
(13) Family health history. Enable a user to electronically record,
change, and access a patient's family health history according to:
(i) At a minimum, the version of the standard specified in Sec.
170.207(a)(3); or
(ii) The standard specified in Sec. 170.207(j).
(14) Patient list creation. Enable a user to electronically and
dynamically select, sort, access, and create patient lists by: date and
time; and based on each one and at least one combination of the
following data:
(i) Problems;
(ii) Medications;
(iii) Medication allergies;
(iv) Demographics;
(v) Laboratory tests and values/results; and
(vi) Ambulatory setting only. Patient communication preferences.
(15) Patient-specific education resources. EHR technology must be
able to electronically identify for a user patient-specific education
resources based on data included in the patient's problem list,
medication list, and laboratory tests and values/results:
(i) In accordance with the standard specified at Sec. 170.204(b)
and the implementation specifications at Sec. 170.204(b)(1) or (2);
and
(ii) By any means other than the method specified in paragraph
(a)(15)(i) of this section.
(16) Inpatient setting only--electronic medication administration
record. (i) In combination with an assistive technology that provides
automated information on the ``rights'' specified in paragraphs
(a)(16)(i)(A) through (E) of this section, enable a user to
electronically verify the following before administering medication(s):
(A) Right patient. The patient to whom the medication is to be
administered matches the medication to be administered.
(B) Right medication. The medication to be administered matches the
medication ordered for the patient.
(C) Right dose. The dose of the medication to be administered
matches the dose of the medication ordered for the patient.
(D) Right route. The route of medication delivery matches the route
specified in the medication order.
(E) Right time. The time that the medication was ordered to be
administered compared to the current time.
(ii) Right documentation. Electronically record the time and date
in accordance with the standard specified in Sec. 170.210(g), and user
identification when a medication is administered.
(17) Inpatient setting only--advance directives. Enable a user to
electronically record whether a patient has an advance directive.
(b) Care coordination. (1) Transitions of care--receive, display,
and incorporate transition of care/referral summaries. (i) Receive. EHR
technology must be able to electronically receive transition of care/
referral summaries in accordance with:
(A) The standard specified in Sec. 170.202(a).
(B) Optional. The standards specified in Sec. 170.202(a) and (b).
(C) Optional. The standards specified in Sec. 170.202(b) and (c).
(ii) 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), Sec. 170.205(a)(2), and Sec.
170.205(a)(3).
(iii) Incorporate. 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:
(A) Correct patient. Demonstrate that the transition of care/
referral summary received is or can be properly matched to the correct
patient.
(B) Data incorporation. 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).
(C) 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).
(2) Transitions of care--create and transmit transition of care/
referral summaries. (i) 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; and
(E) Ambulatory setting only. The reason for referral; and referring
or transitioning provider's name and office contact information.
(F) Inpatient setting only. Discharge instructions.
(ii) Transmit. Enable a user to electronically transmit the
transition of care/referral summary created in paragraph (b)(2)(i) of
this section in accordance with:
(A) The standard specified in Sec. 170.202(a).
(B) Optional. The standards specified in Sec. 170.202(a) and (b).
(C) Optional. The standards specified in Sec. 170.202(b) and (c).
(3) Electronic prescribing. Enable a user to electronically create
prescriptions and prescription-related
[[Page 54289]]
information for electronic transmission in accordance with:
(i) The standard specified in Sec. 170.205(b)(2); and
(ii) At a minimum, the version of the standard specified in Sec.
170.207(d)(2).
(4) Clinical information 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:
(i) 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.
(ii) Enable a user to create a single reconciled list of
medications, medication allergies, or problems.
(iii) Enable a user to review and validate the accuracy of a final
set of data and, upon a user's confirmation, automatically update the
list.
(5) Incorporate laboratory tests and values/results. (i) Receive
results. (A) Ambulatory setting only. (1) Electronically receive and
incorporate clinical laboratory tests and values/results in accordance
with the standard specified in Sec. 170.205(j) and, at a minimum, the
version of the standard specified in Sec. 170.207(c)(2).
(2) Electronically display the tests and values/results received in
human readable format.
(B) Inpatient setting only. Electronically receive clinical
laboratory tests and values/results in a structured format and
electronically display such tests and values/results in human readable
format.
(ii) Electronically display all the information for a test report
specified at 42 CFR 493.1291(c)(1) through (7).
(iii) Electronically attribute, associate, or link a laboratory
test and value/result with a laboratory order or patient record.
(6) Inpatient setting only--transmission of electronic laboratory
tests and values/results to ambulatory providers. EHR technology must
be able to electronically create laboratory test reports for electronic
transmission in accordance with the standard specified in Sec.
170.205(j) and with laboratory tests expressed in accordance with, at a
minimum, the version of the standard specified in Sec. 170.207(c)(2).
(7) Data portability. Enable a user to electronically create a set
of export summaries for all patients in EHR technology formatted
according to the standard adopted at Sec. 170.205(a)(3) that
represents the most current clinical information about each patient and
includes, at a minimum, the Common MU Data Set and the following data
expressed, where applicable, according to the specified standard(s):
(i) Encounter diagnoses. The standard specified in Sec. 170.207(i)
or, at a minimum, the version of the standard at Sec. 170.207(a)(3);
(ii) Immunizations. The standard specified in Sec. 170.207(e)(2);
(iii) Cognitive status;
(iv) Functional status; and
(v) Ambulatory setting only. The reason for referral; and referring
or transitioning provider's name and office contact information.
(vi) Inpatient setting only. Discharge instructions.
(c) Clinical quality measures. (1) Clinical Quality Measures--
capture and export. (i) Capture. For each and every CQM for which the
EHR technology is presented for certification, EHR technology must be
able to electronically record all of the data identified in the
standard specified at Sec. 170.204(c) that would be necessary to
calculate each CQM. Data required for CQM exclusions or exceptions must
be codified entries, which may include specific terms as defined by
each CQM, or may include codified expressions of ``patient reason,''
``system reason,'' or ``medical reason.''
(ii) Export. EHR technology must be able to electronically export a
data file formatted in accordance with the standards specified at Sec.
170.205(h) that includes all of the data captured for each and every
CQM to which EHR technology was certified under paragraph (c)(1)(i) of
this section.
(2) Clinical quality measures--import and calculate. (i) Import.
EHR technology must be able to electronically import a data file
formatted in accordance with the standard specified at Sec. 170.205(h)
and use such data to perform the capability specified in paragraph
(c)(2)(ii) of this section. EHR technology presented for certification
to all three of the certification criteria adopted in paragraphs (c)(1)
through (3) of this section is not required to meet paragraph
(c)(2)(i).
(ii) Calculate. EHR technology must be able to electronically
calculate each and every clinical quality measure for which it is
presented for certification.
(3) Clinical quality measures--electronic submission. Enable a user
to electronically create a data file for transmission of clinical
quality measurement data:
(i) In accordance with the standards specified at Sec. 170.205(h)
and (k); and
(ii) That can be electronically accepted by CMS.
(d) Privacy and security. (1) Authentication, access control, and
authorization. (i) Verify against a unique identifier(s) (e.g.,
username or number) that a person seeking access to electronic health
information is the one claimed; and
(ii) Establish the type of access to electronic health information
a user is permitted based on the unique identifier(s) provided in
paragraph (d)(1)(i) of this section, and the actions the user is
permitted to perform with the EHR technology.
(2) Auditable events and tamper-resistance. (i) Record actions. EHR
technology must be able to:
(A) Record actions related to electronic health information in
accordance with the standard specified in Sec. 170.210(e)(1);
(B) Record the audit log status (enabled or disabled) in accordance
with the standard specified in Sec. 170.210(e)(2) unless it cannot be
disabled by any user; and
(C) Record the encryption status (enabled or disabled) of
electronic health information locally stored on end-user devices by EHR
technology in accordance with the standard specified in Sec.
170.210(e)(3) unless the EHR technology prevents electronic health
information from being locally stored on end-user devices (see
170.314(d)(7) of this section).
(ii) Default setting. EHR technology must be set by default to
perform the capabilities specified in paragraph (d)(2)(i)(A) of this
section and, where applicable, paragraphs (d)(2)(i)(B) or (C), or both
paragraphs (d)(2)(i)(B) and (C).
(iii) When disabling the audit log is permitted. For each
capability specified in paragraphs (d)(2)(i)(A) through (C) of this
section that EHR technology permits to be disabled, the ability to do
so must be restricted to a limited set of identified users.
(iv) Audit log protection. Actions and statuses recorded in
accordance with paragraph (d)(2)(i) of this section must not be capable
of being changed, overwritten, or deleted by the EHR technology.
(v) Detection. EHR technology must be able to detect whether the
audit log has been altered.
(3) Audit report(s). Enable a user to create an audit report for a
specific time period and to sort entries in the audit log according to
each of the data specified in the standards at Sec. 170.210(e).
(4) Amendments. Enable a user to electronically select the record
affected by a patient's request for amendment and perform the
capabilities specified in paragraphs (d)(4)(i) or (ii) of this section.
[[Page 54290]]
(i) Accepted amendment. For an accepted amendment, append the
amendment to the affected record or include a link that indicates the
amendment's location.
(ii) Denied amendment. For a denied amendment, at a minimum, append
the request and denial of the request to the affected record or include
a link that indicates this information's location.
(5) Automatic log-off. Prevent a user from gaining further access
to an electronic session after a predetermined time of inactivity.
(6) Emergency access. Permit an identified set of users to access
electronic health information during an emergency.
(7) End-user device encryption. Paragraph (d)(7)(i) or (ii) of this
section must be met to satisfy this certification criterion.
(i) EHR technology that is designed to locally store electronic
health information on end-user devices must encrypt the electronic
health information stored on such devices after use of EHR technology
on those devices stops.
(A) Electronic health information that is stored must be encrypted
in accordance with the standard specified in Sec. 170.210(a)(1).
(B) Default setting. EHR technology must be set by default to
perform this capability and, unless this configuration cannot be
disabled by any user, the ability to change the configuration must be
restricted to a limited set of identified users.
(ii) EHR technology is designed to prevent electronic health
information from being locally stored on end-user devices after use of
EHR technology on those devices stops.
(8) Integrity. (i) Create a message digest in accordance with the
standard specified in Sec. 170.210(c).
(ii) Verify in accordance with the standard specified in Sec.
170.210(c) upon receipt of electronically exchanged health information
that such information has not been altered.
(9) Optional--accounting of disclosures. Record disclosures made
for treatment, payment, and health care operations in accordance with
the standard specified in Sec. 170.210(d).
(e) Patient engagement. (1) View, download, and transmit to 3rd
party. (i) EHR technology must provide patients (and their authorized
representatives) with an online means to view, download, and transmit
to a 3rd party the data specified below. Access to these capabilities
must be through a secure channel that ensures all content is encrypted
and integrity-protected in accordance with the standard for encryption
and hashing algorithms specified at Sec. 170.210(f).
(A) View. Electronically view in accordance with the standard
adopted at Sec. 170.204(a), at a minimum, the following data:
(1) The Common MU Data Set (which should be in their English (i.e.,
non-coded) representation if they associate with a vocabulary/code
set).
(2) Ambulatory setting only. Provider's name and office contact
information.
(3) Inpatient setting only. Admission and discharge dates and
locations; discharge instructions; and reason(s) for hospitalization.
(B) Download. (1) Electronically download an ambulatory summary or
inpatient summary (as applicable to the EHR technology setting for
which certification is requested) in human readable format or formatted
according to the standard adopted at Sec. 170.205(a)(3) that includes,
at a minimum, the following data (which, for the human readable
version, should be in their English representation if they associate
with a vocabulary/code set):
(i) Ambulatory setting only. All of the data specified in paragraph
(e)(1)(i)(A)(1) and (2) of this section.
(ii) Inpatient setting only. All of the data specified in
paragraphs (e)(1)(i)(A)(1) and (3) of this section.
(2) Inpatient setting only. Electronically download transition of
care/referral summaries that were created as a result of a transition
of care (pursuant to the capability expressed in the certification
criterion adopted at paragraph (b)(2) of this section).
(C) Transmit to third party. (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 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 the standard specified in Sec. 170.202(a).
(ii) Activity history log. (A) When electronic health information
is viewed, downloaded, or transmitted to a third-party using the
capabilities included in paragraphs (e)(1)(i)(A) through (C) of this
section, the following information must be recorded and made accessible
to the patient:
(1) The action(s) (i.e., view, download, transmission) that
occurred;
(2) The date and time each action occurred in accordance with the
standard specified at Sec. 170.210(g); and
(3) The user who took the action.
(B) EHR technology presented for certification may demonstrate
compliance with paragraph (e)(1)(ii)(A) of this section if it is also
certified to the certification criterion adopted at Sec. 170.314(d)(2)
and the information required to be recorded in paragraph (e)(1)(ii)(A)
is accessible by the patient.
(2) Ambulatory setting only--clinical summary. (i) Create. Enable a
user to create a clinical summary for a patient in human readable
format and formatted according to the standards adopted at Sec.
170.205(a)(3).
(ii) Customization. Enable a user to customize the data included in
the clinical summary.
(iii) Minimum data from which to select. EHR technology must permit
a user to select, at a minimum, the following data when creating a
clinical summary:
(A) Common MU Data Set (which, for the human readable version,
should be in their English representation if they associate with a
vocabulary/code set)
(B) The provider's name and office contact information; date and
location of visit; reason for visit; immunizations and/or medications
administered during the visit; diagnostic tests pending; clinical
instructions; future appointments; referrals to other providers; future
scheduled tests; and recommended patient decision aids.
(3) Ambulatory setting only--secure messaging. Enable a user to
electronically send messages to, and receive messages from, a patient
in a manner that ensures:
(i) Both the patient (or authorized representative) and EHR
technology user are authenticated; and
(ii) The message content is encrypted and integrity-protected in
accordance with the standard for encryption and hashing algorithms
specified at Sec. 170.210(f).
(f) Public health. (1) Immunization information. Enable a user to
electronically record, change, and access immunization information.
(2) Transmission to immunization registries. EHR technology must be
able to electronically create immunization information for electronic
transmission in accordance with:
(i) The standard and applicable implementation specifications
specified in Sec. 170.205(e)(3); and
(ii) At a minimum, the version of the standard specified in Sec.
170.207(e)(2).
(3) Transmission to public health agencies--syndromic surveillance.
EHR technology must be able to
[[Page 54291]]
electronically create syndrome-based public health surveillance
information for electronic transmission in accordance with:
(i) Ambulatory setting only. (A) The standard specified in Sec.
170.205(d)(2). (B) Optional. The standard (and applicable
implementation specifications) specified in Sec. 170.205(d)(3).
(ii) Inpatient setting only. The standard (and applicable
implementation specifications) specified in Sec. 170.205(d)(3).
(4) Inpatient setting only--transmission of reportable laboratory
tests and values/results. EHR technology must be able to electronically
create reportable laboratory tests and values/results for electronic
transmission in accordance with:
(i) The standard (and applicable implementation specifications)
specified in Sec. 170.205(g); and
(ii) At a minimum, the versions of the standards specified in Sec.
170.207(a)(3) and (c)(2).
(5) Optional--ambulatory setting only--cancer case information.
Enable a user to electronically record, change, and access cancer case
information.
(6) Optional--ambulatory setting only--transmission to cancer
registries. EHR technology must be able to electronically create cancer
case information for electronic transmission in accordance with:
(i) The standard (and applicable implementation specifications)
specified in Sec. 170.205(i); and
(ii) At a minimum, the versions of the standards specified in Sec.
170.207(a)(3) and (c)(2).
(g) Utilization. (1) 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.
(2) Automated measure calculation. For each meaningful use
objective with a percentage-based measure that is supported by a
capability included in an EHR technology, electronically record the
numerator and denominator and create a report including the numerator,
denominator, and resulting percentage associated with each applicable
meaningful use measure.
(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), and (16) and (b)(3) and (4).
(4) Quality management system. For each capability that an EHR
technology includes and for which that capability's certification is
sought, the use of a Quality Management System (QMS) in the
development, testing, implementation and maintenance of that capability
must be identified.
(i) If a single QMS was used for applicable capabilities, it would
only need to be identified once.
(ii) If different QMS were applied to specific capabilities, each
QMS applied would need to be identified. This would include the
application of a QMS to some capabilities and none to others.
(iii) If no QMS was applied to all applicable capabilities such a
response is acceptable to satisfy this certification criterion.
Sec. Sec. 170.500 through 170.599 [Amended]
0
11. In subpart E, consisting of Sec. Sec. 170.500 through 170.599,
remove the phrases ``permanent certification program for HIT'' and
``permanent certification program'' and add in their place ``ONC HIT
Certification Program'' wherever they may occur.
0
12. Amend Sec. 170.502 by revising the definition of ``providing or
provide an updated certification'' to read as follows:
Sec. 170.502 Definitions.
* * * * *
Providing or provide an updated certification means the action
taken by an ONC-ACB to ensure that the developer of a previously
certified EHR Module(s) shall update the information required by Sec.
170.523(k)(1)(i), after the ONC-ACB has verified that the certification
criterion or criteria to which the EHR Module(s) was previously
certified have not been revised and that no new certification criteria
are applicable to the EHR Module(s).
* * * * *
0
13. In Sec. 170.523, republish the introductory text, add paragraph
(f)(8), revise paragraphs (k)(1)(i) and (ii), and add paragraph
(k)(1)(iii) to read as follows:
Sec. 170.523 Principles of proper conduct for ONC-ACBs.
An ONC-ACB shall:
* * * * *
(f) * * *
(8) A hyperlink to the test results used to certify the Complete
EHRs and/or EHR Modules that can be accessed by the public.
* * * * *
(k) * * *
(1) * * *
(i) ``This [Complete EHR or EHR Module] is [specify Edition of EHR
certification criteria] compliant and has been certified by an ONC-ACB
in accordance with the applicable certification criteria adopted by the
Secretary of Health and Human Services. This certification does not
represent an endorsement by the U.S. Department of Health and Human
Services'';
(ii) The information an ONC-ACB is required to report to the
National Coordinator under paragraph (f) of this section for the
specific Complete EHR or EHR Module at issue; and
(iii) Any additional types of costs that an EP, EH, or CAH would
pay to implement the Complete EHR's or EHR Module's capabilities in
order to attempt to meet meaningful use objectives and measures. EHR
technology self-developers are excluded from this requirement.
* * * * *
0
14. In Sec. 170.550, revise paragraph (e), redesignate paragraph (f)
as paragraph (g), and add a new paragraph (f) to read as follows:
Sec. 170.550 EHR Module certification.
* * * * *
(e) Privacy and security certification. For certification to the
2011 Edition EHR certification criteria, EHR Module(s) shall be
certified to all privacy and security certification criteria adopted by
the Secretary, unless the EHR Module(s) is presented for certification
in one of the following manners:
(1) The EHR Modules are presented for certification as a pre-
coordinated, integrated bundle of EHR Modules, which would otherwise
meet the definition of and constitute a Complete EHR, and one or more
of the constituent EHR Modules is demonstrably responsible for
providing all of the privacy and security capabilities for the entire
bundle of EHR Modules; or
(2) An EHR Module is presented for certification, and the presenter
can demonstrate and provide documentation to the ONC-ACB that a privacy
and security certification criterion is inapplicable or that it would
be technically infeasible for the EHR Module to be certified in
accordance with such certification criterion.
(f) When certifying an EHR Module to the 2014 Edition EHR
certification
[[Page 54292]]
criteria, an ONC-ACB must certify the EHR Module in accordance with the
certification criteria at:
(1) Section 170.314(g)(1) if the EHR Module has capabilities
presented for certification that would support a meaningful use
objective with a percentage-based measure;
(2) Section 170.314(g)(3) if the EHR Module is presented for
certification to one or more listed certification criteria in Sec.
170.314(g)(3); and
(3) Section 170.314(g)(4).
* * * * *
0
15. Revise Sec. 170.555 to read as follows:
Sec. 170.555 Certification to newer versions of certain standards.
(a) ONC-ACBs may certify Complete EHRs and/or EHR Module(s) to a
newer version of certain identified minimum standards specified at
subpart B of this part, unless the Secretary prohibits the use of a
newer version for certification.
(b) Applicability of a newer version of a minimum standard. (1)
ONC-ACBs are not required to certify Complete EHRs and/or EHR Module(s)
according to newer versions of standards identified as minimum
standards in subpart B of this part, unless and until the incorporation
by reference of a standard is updated in the Federal Register with a
newer version.
(2) A certified Complete EHR or certified EHR Module may be
upgraded to comply with newer versions of standards identified as
minimum standards in subpart B of this part without adversely affecting
its certification status, unless the Secretary prohibits the use of a
newer version for certification.
Dated: August 21, 2012.
Kathleen Sebelius,
Secretary.
[FR Doc. 2012-20982 Filed 8-23-12; 2:30 pm]
BILLING CODE 4150-45-P