2015 25597 2 Federal Register

Vol.
80 Friday,
No. 200 October 16, 2015
Part II
Department of Health and Human Services

Office of the Secretary
45 CFR Part 170
2015 Edition Health Information Technology (Health IT) Certification
Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, and
ONC Health IT Certification Program Modifications; Final Rule
mstockstill on DSK4VPTVN1PROD with RULES2
VerDate Sep<11>2014 19:11 Oct 15, 2015 Jkt 238001 PO 00000 Frm 00001 Fmt 4717 Sfmt 4717 E:\FR\FM\16OCR2.SGM 16OCR2
62602 Federal Register / Vol. 80, No. 200 / Friday, October 16, 2015 / Rules and Regulations
DEPARTMENT OF HEALTH AND CFR Code of Federal Regulations 3. Types of Care and Practice Settings
HUMAN SERVICES CHPL Certified Health IT Product List 4. Referencing the ONC Health IT
CLIA Clinical Laboratory Improvement Certification Program
Office of the Secretary Amendments C. Health IT Module Certification
CMS Centers for Medicare & Medicaid Requirements
Services 1. Privacy and Security
45 CFR Part 170 CQM Clinical Quality Measure 2. Design and Performance (§ 170.315(g))
RIN 0991–AB93 EHR Electronic Health Record D. Principles of Proper Conduct for ONC–
FDA Food and Drug Administration ACBs
2015 Edition Health Information HHS Department of Health and Human 1. ‘‘In-the-Field’’ Surveillance and
Services Maintenance of Certification
Technology (Health IT) Certification HISP Health Information Service Providers
Criteria, 2015 Edition Base Electronic 2. Transparency and Disclosure
HIT Health Information Technology Requirements
Health Record (EHR) Definition, and HITPC HIT Policy Committee 3. Open Data Certified Health IT Product
ONC Health IT Certification Program HITSC HIT Standards Committee List (CHPL)
Modifications HL7 Health Level Seven 4. Records Retention
IG Implementation Guide 5. Complaints Reporting
AGENCY: Office of the National LOINC® Logical Observation Identifiers 6. Adaptations and Updates of Certified
Coordinator for Health Information Names and Codes Health IT
Technology (ONC), Department of NIST National Institute of Standards and E. ‘‘Decertification’’ of Health IT—Request
Health and Human Services (HHS). Technology for Comments
ONC Office of the National Coordinator for
ACTION: Final rule. V. Incorporation by Reference
Health Information Technology
VI. Collection of Information Requirements
SDO Standards Developing Organization
SUMMARY: This final rule finalizes a new VII. Regulatory Impact Statement
SNOMED CT® Systematized Nomenclature of
edition of certification criteria (the 2015 Medicine Clinical Terms
A. Statement of Need
Edition health IT certification criteria or B. Overall Impact
‘‘2015 Edition’’) and a new 2015 Edition Table of Contents 1. Executive Orders 12866 and 13563—
Base Electronic Health Record (EHR) Regulatory Planning and Review
I. Executive Summary Analysis
definition, while also modifying the A. Purpose of Regulatory Action 2. Regulatory Flexibility Act
ONC Health IT Certification Program to B. Summary of Major Provisions 3. Executive Order 13132—Federalism
make it open and accessible to more 1. Overview of the 2015 Edition Health IT 4. Unfunded Mandates Reform Act of 1995
types of health IT and health IT that Certification Criteria
Regulation Text
supports various care and practice 2. Health IT Definitions
3. The ONC Health IT Certification I. Executive Summary
settings. The 2015 Edition establishes Program and Health IT Module
the capabilities and specifies the related C. Costs and Benefits A. Purpose of Regulatory Action
standards and implementation II. Background
specifications that Certified Electronic A. Statutory Basis
Building on past rulemakings, we
Health Record Technology (CEHRT) 1. Standards, Implementation issued a proposed rule (‘‘Proposed
would need to include to, at a Specifications, and Certification Criteria Rule’’) (80 FR 16804) that identified
minimum, support the achievement of 2. HIT Certification Programs how health IT certification to the
meaningful use by eligible professionals
B. Regulatory History proposed 2015 Edition health IT
1. Standards, Implementation certification criteria could support the
(EPs), eligible hospitals, and critical Specifications, and Certification Criteria
access hospitals (CAHs) under the establishment of an interoperable
Rules
Medicare and Medicaid EHR Incentive nationwide health information
2. Medicare and Medicaid EHR Incentive
Programs (EHR Incentive Programs) Programs Rules infrastructure. The Proposed Rule
when such edition is required for use 3. ONC Health IT Certification Programs reflected stakeholder feedback received
under these programs. Rules through various outreach initiatives,
III. Provisions of the Proposed Rule Affecting including the regulatory process, and
DATES: These regulations are effective Standards, Implementation was designed to broadly support the
January 14, 2016, except for Specifications, Certification Criteria, and health care continuum through the use
§ 170.523(m) and (n), which are Definitions of certified health IT. This final rule,
effective on April 1, 2016. A. 2015 Edition Health IT Certification
taking into account public comments
The incorporation by reference of Criteria
1. Applicability received on the Proposed Rule,
certain publications listed in the rule is
2. Standards and Implementation continues to focus on the establishment
approved by the Director of the Federal
Specifications of an interoperable nationwide health
Register as of January 14, 2016. 3. Adopted Certification Criteria information infrastructure, through the
FOR FURTHER INFORMATION CONTACT: 4. 2015 Edition Gap Certification Eligibility same means identified in the Proposed
Michael Lipinski, Office of Policy, Table Rule and recited below, but with an
Office of the National Coordinator for 5. Not Adopted Certification Criteria
additional focus on reducing health IT
Health Information Technology, 202– B. Health IT Definitions
1. Base EHR Definitions developer and provider burden as
690–7151. compared to the Proposed Rule. To this
2. Certified EHR Technology Definition
SUPPLEMENTARY INFORMATION: 3. Common Clinical Data Set Definition end, this final rule will:
Commonly Used Acronyms 4. Cross-Referenced FDA Definitions • Improve interoperability for specific
IV. Provisions of the Proposed Rule Affecting purposes by adopting new and updated
API Application Programming Interface the ONC Health IT Certification Program vocabulary and content standards for
CAH Critical Access Hospital A. Subpart E—ONC Health IT Certification the structured recording and exchange
CDA Clinical Document Architecture Program
CDC Centers for Disease Control and B. Modifications to the ONC Health IT
of health information, including a
Prevention Certification Program Common Clinical Data Set composed
CDS Clinical Decision Support 1. Health IT Modules primarily of data expressed using
CEHRT Certified Electronic Health Record 2. ‘‘Removal’’ of Meaningful Use adopted standards; and rigorously
Technology Measurement Certification Requirements testing an identified content exchange
Federal Register / Vol. 80, No. 200 / Friday, October 16, 2015 / Rules and Regulations 62603
standard (Consolidated Clinical standards, and implementation and not other CQM capabilities such as
Document Architecture (C–CDA)); specifications. It incorporates changes import, calculate, and ‘‘report to CMS.’’
• Facilitate the accessibility and that are designed to spur innovation, • It includes the 2015 Edition
exchange of data by including enhanced open new market opportunities, and ‘‘smoking status’’ certification criterion
data export, transitions of care, and provide more choices to providers when as patient demographic and clinical
application programming interface (API) it comes to electronic health health information data consistent with
capabilities in the 2015 Edition Base information exchange. To achieve these statutory requirements.1
Electronic Health Record (EHR) goals, new ‘‘application access’’ (also • It includes the 2015 Edition
definition; known as ‘‘API’’) certification criteria ‘‘implantable device list’’ certification
• Establish a framework that makes have been adopted that will require the criterion as patient demographic and
the Office of the National Coordinator demonstration of an API that responds clinical health information data
for Health Information Technology to data requests for any one category of consistent with statutory requirements.2
(ONC) Health IT Certification Program the data referenced in the Common • It includes the 2015 Edition ‘‘API’’
open and accessible to more types of Clinical Data Set as well as for all of the certification criteria as capabilities that
health IT, health IT that supports a data referenced in the Common Clinical support both the capture and query of
variety of care and practice settings, Data Set. We note that in response to information relevant to health care
various HHS programs, and public and comments, we have separated this quality and exchange electronic health
private interests; criterion into 3 criteria to provide health information with, and integrate such
• Support the Centers for Medicare & IT developers and providers more information from other sources.3
Medicaid Services (CMS) Medicare and • It includes the proposed 2015
flexibility. To further validate the
Medicaid EHR Incentive Programs (EHR Edition certification criteria that
continued interoperability of certified
Incentive Programs) through the correspond to the remaining 2014
health IT and the ability to exchange
adoption of a set of certification criteria Edition certification criteria referenced
electronic health information with
that align with proposals for Stage 3; in the ‘‘2014 Edition’’ Base EHR
health IT certified to the 2014 Edition,
• Address health disparities by definition (i.e., CPOE, demographics,
2015 Edition, and potentially future
providing certification: to standards for problem list, medication list,
editions, a new ‘‘transitions of care’’
more granular capture of race and medication allergy list, CDS, transitions
certification criterion will rigorously
ethnicity; the collection of sexual of care, data portability, and relevant
assess a product’s ability to create and transport certification criteria). For the
orientation, gender identity, social, receive an interoperable C–CDA. We transport certification criteria, we
psychological, and behavioral data; for have also adopted certification criteria include the ‘‘Direct Project’’ criterion
the exchange of sensitive health that both support interoperability and (§ 170.315(h)(1)) as well as the ‘‘Direct
information (Data Segmentation for other settings and use cases, such as the Project, Edge Protocol and XDR/XDM’’
Privacy); and for the accessibility of ‘‘Common Clinical Data Set summary criterion (§ 170.315(h)(2)) as equivalent
health IT; record,’’ ‘‘data segmentation for alternative means for meeting the 2015
• Ensure all health IT presented for privacy,’’ and ‘‘care plan’’ certification Edition Base EHR definition.
certification possess the relevant criteria. We refer readers to section III.B.1 of
privacy and security capabilities; We refer readers to section III.A for an this preamble for a more detailed
• Improve patient safety by: applying overview table (Table 2) of certification discussion of the 2015 Edition Base EHR
enhanced user-centered design criteria adopted in this final rule as definition and to section III.A.3 of this
principles to health IT, enhancing compared to the certification criteria preamble for a full discussion of the
patient matching, requiring health IT to proposed in the Proposed Rule and the criteria that have been included in the
be capable of exchanging relevant adopted 2014 Edition. We also refer Base EHR definition. Of note, the
patient information (e.g., Unique Device readers to sections III.A.3 and III.A.5 of ‘‘demographics’’ certification criterion
Identifiers), improving the surveillance this preamble for full discussions of (§ 170.315(a)(5)) now includes sexual
of certified health IT, and making more certification criteria adopted as part of orientation and gender identity as data
information about certified products the 2015 Edition in this final rule elements, the ‘‘smoking status’’
publicly available and accessible; (III.A.3) and the proposed certification certification criterion (§ 170.315(a)(11))
• Increase the reliability and criteria not adopted in this final rule is now only a functional requirement,
transparency of certified health IT (III.A.5). the ‘‘API’’ criterion has been separated
through surveillance and disclosure
2. Health IT Definitions into 3 distinct criteria as mentioned
requirements; and
above, and the Direct-related criteria
• Provide health IT developers with a. Base EHR Definitions have been updated from ‘‘unchanged’’
more flexibility, opportunities, and time
This final rule adopts a Base EHR to ‘‘revised’’ to incorporate updated and
for development and certification of
definition specific to the 2015 Edition necessary interoperability standards.
health IT that supports interoperability, As discussed in more detail under the
usability, and innovation. (i.e., a 2015 Edition Base EHR
‘‘privacy and security’’ heading in
definition) at § 170.102 and renames the
B. Summary of Major Provisions section IV.C.1 of this preamble, Health
current Base EHR definition at § 170.102
1. Overview of the 2015 Edition Health as the 2014 Edition Base EHR definition. 1 A Base EHR is the regulatory term we have given
IT Certification Criteria The 2015 Edition Base EHR definition to what the HITECH Act defines as a ‘‘qualified
The 2015 Edition health IT differs from the 2014 Edition Base EHR EHR.’’ Our Base EHR definition(s) include all
definition in the following ways: capabilities found in the ‘‘qualified EHR.’’ Please
certification criteria (‘‘2015 Edition’’ or see the 2014 Edition final rule (77 FR 54262) for
‘‘2015 Edition certification criteria’’) • It does not include privacy and further explanation.
facilitates greater interoperability for security capabilities and certification 2 A capability included in the Base EHR
several clinical health information criteria. definition, which originates from the ‘‘qualified
EHR’’ definition found in the HITECH Act.
purposes and enables health • It only includes capabilities to 3 These are capabilities included in the Base EHR
information exchange through new and record and export clinical quality definition, which originate from the ‘‘qualified
enhanced certification criteria, measure (CQM) data (§ 170.315(c)(1)) EHR’’ definition found in the HITECH Act.
IT Modules presented for certification to regardless of the setting or program the settings. These modifications will also
criteria listed in the 2015 Base EHR Health IT Module is designed to serve to support other public and
definition and other 2015 Edition support. private programs that may reference the
certification criteria will be subject to For the full requirements to meet the use of health IT certified under the ONC
the applicable privacy and security CEHRT definition under the EHR Health IT Certification Program. When
criteria for the purposes of certification. Incentive Programs, including for years we established the certification program
The CQM capabilities noted above as before 2018 and for 2018 and (76 FR 1262),4 we stated our initial
not included in the 2015 Edition Base subsequent years, we refer readers to the focus would be on EHR technology and
EHR definition have, however, been EHR Incentive Programs Stage 3 and supporting the EHR Incentive Programs,
included the Certified EHR Technology Modifications final rule published which at the time, focused on the
(CEHRT) definition under the EHR elsewhere in this issue of the Federal ambulatory setting and inpatient setting
Incentive Programs. We refer readers to Register. (76 FR 1294).
the next section (‘‘b. CEHRT definition’’) This final rule permits other types of
c. Common Clinical Data Set
for further information and guidance on health IT, such as technology
the relationship of the 2015 Edition We revised the ‘‘Common MU Data implemented by health information
Base EHR definition and the 2015 Set’’ definition in § 170.102. We service providers (HISPs) and health
Edition certification criteria with the changed the name to ‘‘Common Clinical information exchanges (HIEs), to receive
CEHRT definition. We also refer readers Data Set,’’ which aligns with our appropriate attribution and not be
to the CEHRT definition finalized in the approach throughout this final rule to referenced by a certificate with ‘‘EHR’’
EHR Incentive Programs Stage 3 and make the ONC Health IT Certification included in it. This final rule also
Modifications final rule published Program more open and accessible to supports health IT certification for other
elsewhere in this issue of the Federal other types of health IT beyond EHR care and practice settings, such as long-
Register as the authoritative source for technology and for health IT that term post-acute care (LTPAC),
the requirements to meet the CEHRT supports care and practice settings behavioral health, and pediatrics.
definition. beyond those included in the EHR Further, this final rule will make it
Incentive Programs. We also changed simpler for certification criteria and
b. CEHRT Definition references to the ‘‘Common MU Data certified health IT to be referenced by
This final rule removes the CEHRT Set’’ in the 2014 Edition (§ 170.314) to other HHS programs (e.g., Medicare and
definition from § 170.102 for the ‘‘Common Clinical Data Set.’’ Medicaid payment programs and
following reasons. The CEHRT We revised the definition to account various grant programs), other public
definition has always been defined in a for the new and updated standards and programs, and private entities and
manner that supports the EHR Incentive code sets we have adopted in this final associations.
Programs. As such, the CEHRT rule for the 2015 Edition that will
definition more appropriately resides improve and advance interoperability a. Program Alignment Changes
solely within the EHR Incentive through the exchange of the Common As part of our approach to evolve the
Programs regulations. This is also Clinical Data Set. We also revised the ONC Health IT Certification Program,
consistent with our approach in this definition to support patient safety and we have replaced prior rulemaking use
final rule to make the ONC Health IT improve care through clearly referenced of ‘‘EHR’’ and ‘‘EHR technology’’ with
Certification Program more open and data elements (‘‘care plan data’’) and the ‘‘health IT.’’ The term health IT is
accessible to other types of health IT inclusion of new patient data (e.g., reflective of the scope of ONC’s
beyond EHR technology and for health Unique Device Identifiers (UDIs) and authority under the Public Health
IT that supports care and practice immunizations (with standards)). These Service Act (§ 3000(5) as ‘‘health
settings beyond those included in the revisions will not change the standards, information technology’’ is so defined),
EHR Incentive Programs. Further, this codes sets, and data requirements and represents a broad range of
adds administrative simplicity in that specified in the Common Clinical Data technology, including EHR technology.
regulatory provisions, which EHR Set for 2014 Edition certification, which It also more properly represents some of
Incentive Programs participants must remain unchanged. They only apply to the technology, as noted above, that has
meet (e.g., the CEHRT definition), are health IT certified to the 2015 Edition been previously certified to editions of
defined within the context of certification criteria that reference the certification criteria under the ONC
rulemakings for those programs. Common Clinical Data Set. Health IT Certification Program and may
We note that the CEHRT definition We refer readers to section III.B.3 of be certified to the 2015 Edition.
finalized by CMS continues to include this preamble for a detailed discussion Similarly, to make the ONC Health IT
the Base EHR definition(s) defined by of the Common Clinical Data Set and a Certification Program more open and
ONC, including the 2015 Edition Base table listing the data and standards accessible, we have renamed the EHR
EHR definition adopted in this final included in the Common Clinical Data Module as ‘‘Health IT Module.’’
rule. We also refer readers to Table 4 Set for both the 2014 and 2015 Editions. b. ‘‘Meaningful Use Measurement’’
(‘‘2015 Edition Health IT Certification
Criteria Associated with the EHR 3. The ONC Health IT Certification We have adopted our proposed
Incentive Programs Stage 3’’) found in Program and Health IT Module approach in that we will not require
section III.A.3 of this preamble. Table 4 We have changed the name of the ONC-Authorized Certification Bodies
crosswalks 2015 Edition certification ONC HIT Certification Program to the (ONC–ACBs) to certify Health IT
criteria with the finalized CEHRT ‘‘ONC Health IT Certification Program.’’ Modules to the 2015 Edition
definition and EHR Incentive Programs We have also modified the ONC Health ‘‘meaningful use measurement’’
Stage 3 objectives. It also identifies IT Certification Program in ways that certification criteria. We note, however,
mandatory and conditional certification will make it more accessible to other that CMS has included the 2015 Edition
requirements (i.e., the application of types of health IT beyond EHR
4 Please see section II.B.3 of this preamble for a
certain certification criteria to Health IT technology and for health IT that regulatory history of the ONC Health IT
Modules) that Health IT Modules supports care and practice settings Certification Program, including changes to the
presented for certification must meet beyond the ambulatory and inpatient program’s name.
‘‘meaningful use measurement’’ know exactly what privacy and security these new and revised PoPC promote
certification criteria in the CEHRT functionality against which the Health greater transparency and accountability
definition as a program requirement for IT Module had to be tested in order to for the ONC Health IT Certification
the EHR Incentive Programs. be certified. Program.
Accordingly, we encourage health IT
d. Principles of Proper Conduct (PoPC) C. Costs and Benefits
developers supporting providers
for ONC–ACBs Our estimates indicate that this final
participating in the EHR Incentive
Programs or providers’ quality We have adopted new and revised rule is an economically significant rule
improvement needs to seek certification PoPC for ONC–ACBs. ONC–ACBs are as its overall costs for health IT
to these criteria as appropriate for their now required to report an expanded set developers may be greater than $100
Health IT Modules (e.g., a Health IT of information to ONC for inclusion in million in at least one year. We have,
Module is presented for certification to the open data file that would make up therefore, projected the costs and
a criterion that supports a Stage 3 the Certified Health IT Product List benefits of the final rule. The estimated
objective with a percentage-based (CHPL). ONC–ACBs must ensure that costs expected to be incurred by health
measure and the Health IT Module can health IT developers provide more IT developers to develop and prepare
meet the ‘‘automated numerator meaningful disclosure of certain types health IT to be tested and certified in
recording’’ criterion or ‘‘automated of costs and limitations that could accordance with the 2015 Edition
measure calculation’’ criterion). interfere with the ability of users to certification criteria (and the standards
implement certified health IT in a and implementation specifications they
c. Privacy and Security Certification manner consistent with its certification. include) are represented in monetary
Framework ONC–ACBs must retain records for a terms in Table 1 below. We note that
We have adopted a new, simpler, period of time that will support HHS this final rule does not impose the costs
straight-forward approach to privacy program needs. ONC–ACBs must also cited as compliance costs, but rather as
and security certification requirements obtain a record of all adaptations and investments which health IT developers
for Health IT Modules certified to the updates affecting ‘‘safety-enhanced voluntarily take on and may expect to
2015 Edition. In sum, the privacy and design’’ criteria on a quarterly basis recover with an appropriate rate of
security certification criteria applicable each calendar year. ONC–ACBs must return. We further note that, based on
to a Health IT Module presented for also report to the National Coordinator the estimates provided by a health IT
certification is based on the other complaints received on certified health developer association in response to the
capabilities included in the Health IT IT. We have also adopted new Proposed Rule, we have reduced the
Module and for which certification is requirements for ‘‘in-the-field’’ estimated burden of the 2015 Edition by
sought. Under the 2015 Edition privacy surveillance under the ONC Health IT over 40,000 burden hours per health IT
and security certification framework, a Certification Program that clarify and developer by not adopting certain
health IT developer will know exactly expand ONC–ACBs’ existing proposed certification criteria,
what it needs to do in order to get its surveillance responsibilities by functionality and standards.
Health IT Module certified and a specifying requirements and procedures The dollar amounts expressed in
purchaser of a Health IT Module will for in-the-field surveillance. We believe Table 1 are expressed in 2014 dollars.
TABLE 1—DISTRIBUTED TOTAL 2015 EDITION DEVELOPMENT AND PREPARATION COSTS FOR HEALTH IT DEVELOPERS (4-
YEAR PERIOD)—TOTALS ROUNDED
Total low cost Total high cost Total average

Ratio
Year estimate estimate cost estimate
(%) ($M) ($M) ($M)
2015 ................................................................................................................. 15 39.07 60.48 49.77

2016 ................................................................................................................. 35 91.15 141.12 116.14
2017 ................................................................................................................. 35 91.15 141.12 116.14
2018 ................................................................................................................. 15 39.07 60.48 49.77
4-Year Totals ............................................................................................ ........................ 260.44 403.19 331.82
As noted above, we expect that health The 2015 Edition continues to improve patient data that could be used to
IT developers will recover an health IT interoperability through the address health disparities would not
appropriate rate of return for their adoption of new and updated standards only benefit patients, but the entire
investments in developing and and implementation specifications. For health care delivery system through
preparing their health IT for example, many proposed certification improved quality of care. The 2015
certification to the 2015 Edition criteria include standards and Edition also supports usability and
certification criteria adopted in this implementation specifications for patient safety through new and
final rule. However, we do not have data interoperability that directly support the enhanced certification requirements for
available to quantify these benefits or EHR Incentive Programs, which include health IT.
other benefits that will likely arise from objectives and measures for the This final rule also makes the ONC
health IT developers certifying their interoperable exchange of health Health IT Certification Program open
health IT to the 2015 Edition. information and for providing patients and accessible to more types of health
We believe that there will be several electronic access to their health IT and for health IT that supports a
significant benefits that may arise from information in structured formats. In variety of care and practice settings.
this final rule for patients, health care addition, the adopted certification This should benefit health IT
providers, and health IT developers. criteria that support the collection of developers, providers practicing in
other care/practice settings, and adoption of any grouping of such Set of Standards, Implementation
consumers through the availability and standards, implementation Specifications, and Certification Criteria
use of certified health IT that includes specifications, or certification criteria. for Electronic Health Record
capabilities that promote The Secretary is required to publish all Technology’’ (75 FR 2014, Jan. 13, 2010)
interoperability and enhanced determinations in the Federal Register. (the ‘‘S&CC January 2010 interim final
functionality. Section 3004(b)(3) of the PHSA titled, rule’’), which adopted an initial set of
Subsequent Standards Activity, standards, implementation
II. Background specifications, and certification criteria.
provides that the Secretary shall adopt
A. Statutory Basis additional standards, implementation After consideration of the comments
specifications, and certification criteria received on the S&CC January 2010
The Health Information Technology
as necessary and consistent with the interim final rule, a final rule was
for Economic and Clinical Health
schedule published by the HITSC. We issued to complete the adoption of the
(HITECH) Act, Title XIII of Division A
consider this provision in the broader initial set of standards, implementation
and Title IV of Division B of the
context of the HITECH Act to grant the specifications, and certification criteria
American Recovery and Reinvestment
Secretary the authority and discretion to and realign them with the final
Act of 2009 (the Recovery Act) (Pub. L.
adopt standards, implementation objectives and measures established for
111–5), was enacted on February 17,
specifications, and certification criteria the EHR Incentive Programs Stage 1
2009. The HITECH Act amended the
that have been recommended by the (formally titled: Health Information
Public Health Service Act (PHSA) and Technology: Initial Set of Standards,
created ‘‘Title XXX—Health Information HITSC and endorsed by the National
Coordinator, as well as other Implementation Specifications, and
Technology and Quality’’ (Title XXX) to Certification Criteria for Electronic
improve health care quality, safety, and appropriate and necessary health IT
standards, implementation Health Record Technology; Final Rule,
efficiency through the promotion of HIT (75 FR 44590, July 28, 2010) and
and electronic health information specifications, and certification criteria.
referred to as the ‘‘2011 Edition final
exchange. 2. Health IT Certification Programs rule’’). The 2011 Edition final rule also
1. Standards, Implementation Section 3001(c)(5) of the PHSA established the first version of the
Specifications, and Certification Criteria provides the National Coordinator with CEHRT definition. Subsequent to the
the authority to establish a certification 2011 Edition final rule (October 13,
The HITECH Act established two new
program or programs for the voluntary 2010), we issued an interim final rule
federal advisory committees, the Health
certification of health IT. Specifically, with a request for comment to remove
IT Policy Committee (HITPC) and the
section 3001(c)(5)(A) specifies that the certain implementation specifications
Health IT Standards Committee (HITSC)
National Coordinator, in consultation related to public health surveillance that
(sections 3002 and 3003 of the PHSA, had been previously adopted in the
respectively). Each is responsible for with the Director of the National
Institute of Standards and Technology 2011 Edition final rule (75 FR 62686).
advising the National Coordinator for The standards, implementation
Health Information Technology (NIST), shall keep or recognize a
program or programs for the voluntary specifications, and certification criteria
(National Coordinator) on different adopted by the Secretary in the 2011
aspects of standards, implementation certification of health information
technology as being in compliance with Edition final rule established the
specifications, and certification criteria. capabilities that CEHRT must include in
The HITPC is responsible for, among applicable certification criteria adopted
under this subtitle (i.e., certification order to, at a minimum, support the
other duties, recommending priorities achievement of EHR Incentive Programs
for the development, harmonization, criteria adopted by the Secretary under
section 3004 of the PHSA). Stage 1 by eligible professionals (EPs),
and recognition of standards, eligible hospitals, and critical access
implementation specifications, and The certification program(s) must also
include, as appropriate, testing of the hospitals (CAHs) under the Medicare
certification criteria. Main and Medicaid Programs; Electronic
responsibilities of the HITSC include technology in accordance with section
13201(b) of the [HITECH] Act. Overall, Health Record Incentive Program; Final
recommending standards, Rule (75 FR 44314) (the ‘‘EHR Incentive
implementation specifications, and section 13201(b) of the HITECH Act
requires that with respect to the Programs Stage 1 final rule’’).
certification criteria for adoption by the The Secretary issued a proposed rule
Secretary under section 3004 of the development of standards and
with request for comments titled
PHSA, consistent with the ONC- implementation specifications, the
‘‘Health Information Technology:
coordinated Federal Health IT Strategic Director of the NIST, in coordination
Standards, Implementation
Plan. with the HITSC, shall support the
Specifications, and Certification Criteria
Section 3004 of the PHSA identifies a establishment of a conformance testing
for Electronic Health Record
process for the adoption of health IT infrastructure, including the
Technology, 2014 Edition; Revisions to
standards, implementation development of technical test beds. The
the Permanent Certification Program for
specifications, and certification criteria HITECH Act also indicates that the
Health Information Technology’’ (77 FR
and authorizes the Secretary to adopt development of this conformance
13832, March 7, 2012) (the ‘‘2014
such standards, implementation testing infrastructure may include a
Edition proposed rule’’), which
specifications, and certification criteria. program to accredit independent, non- proposed new and revised standards,
As specified in section 3004(a)(1), the Federal laboratories to perform testing. implementation specifications, and
Secretary is required, in consultation B. Regulatory History certification criteria. After consideration
with representatives of other relevant of the comments received on the 2014

federal agencies, to jointly review 1. Standards, Implementation Edition proposed rule, a final rule was
standards, implementation Specifications, and Certification Criteria issued to adopt the 2014 Edition set of
specifications, and certification criteria Rules standards, implementation
endorsed by the National Coordinator The Secretary issued an interim final specifications, and certification criteria
under section 3001(c) and subsequently rule with request for comments titled, and realign them with the final
determine whether to propose the ‘‘Health Information Technology: Initial objectives and measures established for
the EHR Incentive Programs Stage 2, as definition. This revision was intended technology certified to the 2014 Edition
well as Stage 1 revisions (Health to allow more flexibility with respect to for an EHR reporting period in 2014 due
Information Technology: Standards, the representation of dental procedures to delays in the availability of such
Implementation Specifications, and data for EHR technology testing and technology to continue to use EHR
Certification Criteria for Electronic certification. technology certified to the 2011 Edition
Health Record Technology, 2014 On February 26, 2014, the Secretary or a combination of EHR technology
Edition; Revisions to the Permanent published a proposed rule titled certified to the 2011 Edition and 2014
Certification Program for Health ‘‘Voluntary 2015 Edition Electronic Edition for the EHR reporting periods in
Information Technology (77 FR 54163, Health Record (EHR) Certification CY 2014 and FY 2014. On September 4,
Sept. 4, 2012) (the ‘‘2014 Edition final Criteria; Interoperability Updates and 2014, a final rule (‘‘CEHRT Flexibility
rule’’). The standards, implementation Regulatory Improvements’’ (79 FR final rule’’) was published (79 FR
specifications, and certification criteria 10880) (‘‘Voluntary Edition proposed 52910) adopting these proposals.
adopted by the Secretary in the 2014 rule’’). The proposed rule proposed a On March 30, 2015, the Secretary
Edition final rule established the voluntary edition of certification criteria published a proposed rule titled ‘‘2015
capabilities that CEHRT must include in that was designed to enhance Edition Health Information Technology
order to, at a minimum, support the interoperability, promote innovation, (Health IT) Certification Criteria; 2015
achievement of the EHR Incentive and incorporate ‘‘bug fixes’’ to improve Edition Base Electronic Health Record
Programs Stage 2 by EPs, eligible upon the 2014 Edition. A correction (EHR) Definition, and ONC Health IT
hospitals, and CAHs under the Medicare notice was published for the Voluntary Certification Program Modifications’’
and Medicaid Programs; Electronic Edition proposed rule on March 19, (80 FR 16804) (‘‘2015 Edition Proposed
Health Record Incentive Program—Stage 2014, entitled ‘‘Voluntary 2015 Edition Rule’’ or ‘‘Proposed Rule’’). The
2 final rule ( 77 FR 53968) (the ‘‘EHR Electronic Health Record (EHR) Proposed Rule proposed an edition of
Incentive Programs Stage 2 final rule’’). Certification Criteria; Interoperability certification criteria that was designed
On December 7, 2012, an interim final Updates and Regulatory Improvements; to enhance interoperability and is the
rule with a request for comment was Correction’’ (79 FR 15282). This subject of this final rule.
jointly issued and published by ONC correction notice corrected the preamble
2. Medicare and Medicaid EHR
and CMS to update certain standards text and gap certification table for four
Incentive Programs Rules
that had been previously adopted in the certification criteria that were omitted
2014 Edition final rule. The interim from the list of certification criteria On January 13, 2010, CMS published
final rule also revised the EHR Incentive eligible for gap certification for the 2015 the Medicare and Medicaid Programs;
Programs by adding an alternative Edition EHR certification criteria. On Electronic Health Record Incentive
measure for the Stage 2 objective for September 11, 2014, a final rule was Program; Proposed Rule (75 FR 1844).
hospitals to provide structured published titled ‘‘2014 Edition Release 2 The rule proposed the criteria for Stage
electronic laboratory results to Electronic Health Record (EHR) 1 of the EHR Incentive Programs and
ambulatory providers, corrected the Certification Criteria and the ONC HIT regulations associated with the
regulation text for the measures Certification Program; Regulatory incentive payments made available
associated with the objective for Flexibilities, Improvements, and under Division B, Title IV of the
hospitals to provide patients the ability Enhanced Health Information HITECH Act. Subsequently, CMS
to view online, download, and transmit Exchange’’ (79 FR 54430) (‘‘2014 Edition published a final rule (75 FR 44314) for
information about a hospital admission, Release 2 final rule’’). The final rule Stage 1 of the EHR Incentive Programs
and made the case number threshold adopted a small subset of the original on July 28, 2010, simultaneously with
exemption policy for clinical quality proposals in the Voluntary Edition the publication of the 2011 Edition final
measure (CQM) reporting applicable for proposed rule as optional and revised rule. The EHR Incentive Programs Stage
eligible hospitals and CAHs beginning 2014 Edition EHR certification criteria 1 final rule established the objectives,
with FY 2013. In addition, the interim that provide flexibility, clarity, and associated measures, and other
final rule provided notice of CMS’s enhance health information exchange. It requirements that EPs, eligible
intent to issue technical corrections to also finalized administrative proposals hospitals, and CAHs must satisfy to
the electronic specifications for CQMs (i.e., removal of regulatory text from the meet Stage 1.
released on October 25, 2012 (77 FR Code of Federal Regulations (CFR)) and On March 7, 2012, CMS published the
72985). On September 4, 2014, a final proposals for the ONC HIT Certification Medicare and Medicaid Programs;
rule (Medicare and Medicaid Programs; Program that provide improvements. Electronic Health Record Incentive
Modifications to the Medicare and On May 23, 2014, CMS and ONC Program—Stage 2; Proposed Rule (77 FR
Medicaid Electronic Health Record jointly published the ‘‘Medicare and 13698). Subsequently, CMS published a
(EHR) Incentive Program for 2014 and Medicaid Programs; Modifications to final rule (77 FR 53968) for the EHR
Other Changes to the EHR Incentive the Medicare and Medicaid Electronic Incentive Programs on September 4,
Program; and Health Information Health Record Incentive Programs for 2012, simultaneously with the
Technology: Revisions to the Certified 2014; and Health Information publication of the 2014 Edition final
EHR Technology Definition and EHR Technology: Revisions to the Certified rule. The EHR Incentive Programs Stage
Certification Changes Related to EHR Technology Definition’’ proposed 2 final rule established the objectives,
Standards; Final Rule) (79 FR 52910) rule (79 FR 29732). The rule proposed associated measures, and other
was published adopting these proposals. to update the EHR Incentive Programs requirements that EPs, eligible
On November 4, 2013, the Secretary Stage 2 and Stage 3 participation hospitals, and CAHs must satisfy to
published an interim final rule with a timeline. It proposed to revise the meet Stage 2. It also revised some Stage
request for comment, 2014 Edition CEHRT definition to permit the use of 1 requirements.
Electronic Health Record Certification EHR technology certified to the 2011 As described above in Section II.B.1,
Criteria: Revision to the Definition of Edition to meet the CEHRT definition ONC and CMS jointly issued an interim
‘‘Common Meaningful Use (MU) Data for FY/CY 2014. It also proposed to final rule with a request for comment
Set’’ (78 FR 65884), to make a minor allow EPs, eligible hospitals, and CAHs that was published on December 7, 2012
revision to the Common MU Data Set that could not fully implement EHR and a final rule that was published on
September 4, 2014. Also, as described All these proposals were finalized in a these criteria as the ‘‘2015 Edition’’ in
above in Section II.B.1, ONC and CMS final rule published on November 25, this preamble. We codified the 2015
jointly issued proposed and final rules 2011 (76 FR 72636). Edition in § 170.315 to set them apart
that were published on May 23, 2014 The 2014 Edition final rule made from other editions of certification
and September 4, 2014, respectively. changes to the permanent certification criteria and make it easier for
On March 30, 2015, CMS published program. The final rule adopted a stakeholders to quickly determine the
the Medicare and Medicaid Programs; proposal to change the Permanent certification criteria included in the
Electronic Health Record Incentive Certification Program’s name to the 2015 Edition.
Program—Stage 3; Proposed Rule (80 FR ‘‘ONC HIT Certification Program,’’ In the Proposed Rule, we identified
16732) (‘‘EHR Incentive Programs Stage revised the process for permitting the the 2015 Edition certification criteria as
3 proposed rule’’) outlining objectives, use of newer versions of ‘‘minimum new, revised, or unchanged in
associated measures, and other standard’’ code sets, modified the comparison to the 2014 Edition. In the
requirements that EPs, eligible certification processes ONC–ACBs need 2014 Edition final rule we gave meaning
hospitals, and CAHs would need to to follow for certifying EHR Modules in to the terms ‘‘new,’’ ‘‘revised,’’ and
meet to participate in Stage 3 of the EHR a manner that provides clear ‘‘unchanged’’ to both describe the
Incentives Programs. implementation direction and differences between the 2014 Edition
On April 15, 2015, CMS published the compliance with the new certification certification criteria and the 2011
Medicare and Medicaid Programs; criteria, and eliminated the certification Edition certification criteria, as well as
Electronic Health Record Incentive requirement that every EHR Module be establish what certification criteria in
Program—Modifications to Meaningful certified to the ‘‘privacy and security’’ the 2014 Edition were eligible for gap
Use in 2015 Through 2017; Proposed certification criteria. certification (see 77 FR 54171, 54202,
Rule (80 FR 20346) (‘‘EHR Incentive The Voluntary Edition proposed rule and 54248). Given that beginning with
Programs Modifications proposed rule’’) included proposals that focused on the 2015 Edition, ‘‘Complete EHR’’
proposing modifications to the EHR improving regulatory clarity, certifications will no longer be issued
Incentive Programs for the EHR simplifying the certification of EHR (see also 79 FR 54443–45) and that we
reporting periods and meaningful use Modules that are designed for purposes proposed to make the ONC Health IT
measures in 2015 through 2017. other than meeting requirements of the Certification Program more open and
3. ONC Health IT Certification Program EHR Incentive Programs, and accessible to other health care/practice
Rules discontinuing the use of the Complete settings, we also proposed to give new
EHR definition. As noted above, we meaning to these terms for the purpose
On March 10, 2010, ONC published a of a gap certification analysis as so
issued the 2014 Edition Release 2 final
proposed rule (75 FR 11328) titled, specified:
rule to complete the rulemaking for the
‘‘Proposed Establishment of
Voluntary Edition proposed rule. The • ‘‘New’’ certification criteria are
Certification Programs for Health those that as a whole only include
2014 Edition Release 2 final rule
Information Technology’’ (the capabilities never referenced in
‘‘Certification Programs proposed rule’’). discontinued the ‘‘Complete EHR’’
certification concept beginning with the previously adopted certification criteria
The rule proposed both a temporary and editions and to which a Health IT
permanent certification program for the proposed 2015 Edition, adopted an
updated standard (ISO/IEC 17065) for Module presented for certification to the
purposes of testing and certifying HIT. 2015 Edition could have never
It also specified the processes the the accreditation of ONC–ACBs, and
adopted the ‘‘ONC Certified HIT’’ previously been certified. As a counter
National Coordinator would follow to example, the splitting of a 2014 Edition
authorize organizations to perform the certification and design mark for
certification criterion into two criteria as
certification of HIT. A final rule required use by ONC–ACBs under the
part of the 2015 Edition would not make
establishing the temporary certification ONC Health IT Certification Program.
As noted above, on March 30, 2015, those certification criteria ‘‘new’’ for the
program was published on June 24, purposes of a gap certification eligibility
2010 (75 FR 36158) (‘‘Temporary the Secretary published the Proposed
Rule which, in addition to proposing analysis.
Certification Program final rule’’) and a • ‘‘Revised’’ certification criteria are
final rule establishing the permanent the 2015 Edition, proposed revisions to
those that include within them
certification program was published on the ONC Health IT Certification
capabilities referenced in a previously
January 7, 2011 (76 FR 1262) (‘‘the Program.
adopted edition of certification criteria
Permanent Certification Program final III. Provisions of the Proposed Rule as well as changed or additional new
rule’’). Affecting Standards, Implementation capabilities; and to which a Health IT
On May 31, 2011, ONC published a Specifications, and Certification Module presented for certification to the
proposed rule (76 FR 31272) titled Criteria 2015 Edition could not have been
‘‘Permanent Certification Program for previously certified to all of the
Health Information Technology; A. 2015 Edition Health IT Certification
included capabilities.
Revisions to ONC-Approved Accreditor Criteria • ‘‘Unchanged’’ certification criteria
Processes.’’ The rule proposed a process This rule finalizes new, revised, and are those that include the same
for addressing instances where the unchanged certification criteria that capabilities as compared to prior
ONC–Approved Accreditor (ONC–AA) establish the capabilities and related certification criteria of adopted editions;
engaged in improper conduct or did not standards and implementation and to which a Health IT Module
perform its responsibilities under the specifications for the certification of presented for certification to the 2015
permanent certification program, health IT, including EHR technology. Edition could have been previously
addressed the status of ONC– We refer to these new, revised, and certified to all of the included
Authorized Certification Bodies in unchanged certification criteria as the capabilities.
instances where there may be a change ‘‘2015 Edition health IT certification Comments. While we received no
in the accreditation organization serving criteria’’ and have added this term and specific comments on these terms, we
as the ONC–AA, and clarified the its definition to § 170.102. As noted in received comments both supporting and
responsibilities of the new ONC–AA. the Executive Summary, we also refer to opposing the adoption of certification
criteria that go beyond specifically Eligibility Table’’) of this preamble for a rule as well as discussed in more detail
supporting an objective and measure complete description of gap certification in section IV.B of this preamble, we
under the EHR Incentive Programs. and the identification of 2015 Edition believe the availability and use of
Response. We continue to maintain certification criteria eligible for gap certified health IT for other use cases
the same meanings for the terms ‘‘new,’’ certification. In sum, ‘‘unchanged’’ and health care settings beyond the EHR
‘‘revised,’’ and ‘‘unchanged’’ as criteria are eligible for gap certification. Incentive Programs has significant
described in the Proposed Rule with a For health IT previously certified to the value. Therefore, we have adopted
slight modification to the meaning of 2011 or 2014 Edition certification certification criteria that support those
‘‘unchanged’’ to state that ‘‘unchanged’’ criteria, this permits, where applicable, purposes. Table 2 below provides an
certification criteria are certification the use of prior test results for
overview of certification criteria
criteria that include the same or less of certification to the 2015 certification
the same capabilities as compared to adopted in this final rule as compared
criteria. This creates efficiencies and
prior certification criteria of adopted to the certification criteria proposed in
substantially reduces burden.
editions. We refer readers to section As described in the Proposed Rule the Proposed Rule and the adopted 2014
III.A.4 (‘‘2015 Edition Gap Certification and Executive Summary of this final Edition.
TABLE 2—2015 EDITION HEALTH IT CERTIFICATION CRITERIA

Not Adopted Proposed Criteria (14)
Vital Signs
Image Results
Family Health History—Pedigree
Patient List Creation
Electronic Medication Administration Record
Decision Support—Knowledge Artifact
Decision Support—Service
Incorporate Laboratory Tests and Values/Results
Transmission of Laboratory Test Reports
Accessibility Technology
SOAP Transport and Security Specification and XDR/XDM for Direct Messaging
Healthcare Provider Directory—Query Request
Healthcare Provider Directory—Query Response
Electronic Submission of Medical Documentation
Unchanged Criteria as Compared to the 2014 Edition (Gap Certification Eligible) (16)
Computerized Provider Order Entry (CPOE)—Medications

CPOE—Laboratory
CPOE—Diagnostic Imaging
Drug-Drug, Drug-Allergy Interaction Checks for CPOE
Medication List
Medication Allergy List
Drug-Formulary and Preferred Drug List Checks
Smoking Status
Authentication, Access Control, Authorization
Audit Report(s)
Amendments
Automatic Access Time-Out
Emergency Access
End-User Device Encryption
Accounting of Disclosures
Transmission to Public Health Agencies—Reportable Laboratory Tests and Values/
Results
Revised Criteria as Compared to the 2014 Edition (25)
Demographics
Problem List
Clinical Decision Support
Family Health History
Patient-Specific Education Resources
Transitions of Care
Clinical Information Reconciliation and Incorporation
Electronic Prescribing
Data Export
Clinical Quality Measures—Record and Export
Clinical Quality Measures—Import and Calculate

Clinical Quality Measures—Report
View, Download, and Transmit to 3rd Party
Transmission to Immunization Registries
Transmission to Public Health Agencies—Syndromic Surveillance
Transmission to Cancer Registries
Automated Numerator Recording
Automated Measure Calculation
TABLE 2—2015 EDITION HEALTH IT CERTIFICATION CRITERIA—Continued

Safety-enhanced Design
Quality Management System
Auditable Events and Tamper-Resistance*
Integrity*
Secure Messaging*
Direct Project*
Direct Project, Edge Protocol, and XDR/XDM*
New Criteria as Compared to the 2014 Edition (19)
Implantable Device List

Social, Psychological, and Behavioral Data
Data Segmentation for Privacy—Send
Data Segmentation for Privacy—Receive
Care Plan
Common Clinical Data Set Summary Record—Create ................................................... New criteria based on request for comment in the Pro-
posed Rule.
Common Clinical Data Set Summary Record—Receive
Clinical Quality Measures—Filter
Trusted Connection .......................................................................................................... New for privacy and security certification framework and
API approach.
Auditing Actions on Health Information ........................................................................... New for privacy and security certification framework and
API approach.
Patient Health Information Capture.
Transmission to Public Health Agencies—Electronic Case Reporting.
Transmission to Public Health Agencies—Antimicrobial Use and Resistance Report-
ing.
Transmission to Public Health Agencies—Health Care Surveys.
Consolidated CDA Creation Performance.
Application Access—Patient Selection ............................................................................ Split the proposed API criterion into three criteria based
on public comments.
Application Access—Data Category Request.
Application Access—All Data Request
Accessibility—centered Design.
* The criterion was proposed as unchanged, but has been adopted as revised in this final rule.
We proposed that readers should criteria (i.e., ‘‘export summary,’’ CAH’s CEHRT and used to demonstrate
interpret the following terms used in the ‘‘transition of care/referral summary,’’ meaningful use (as identified in Table 4
2015 Edition with the same meanings ‘‘ambulatory summary,’’ and ‘‘inpatient of section III.A.3 below). We note that
we adopted in the 2014 Edition final summary.’’) Table 4 also identifies certification
rule (77 FR 54168–54169), in response We received no specific comments on criteria that are mandatory and
to comment: ‘‘User,’’ ‘‘record,’’ these proposals and have adopted these conditional certification requirements
‘‘change,’’ ‘‘access,’’ ‘‘incorporate,’’ meanings and approaches for for Health IT Modules, such as safety-
‘‘create,’’ and ‘‘transmit,’’ but apply to certification to the 2015 Edition. enhanced design (conditional), and
all health IT, not just ‘‘EHR technology.’’ As with the adoption of the 2011 and
quality management system
For the term ‘‘incorporate,’’ we also 2014 editions of certification criteria
(mandatory), accessibility-centered
proposed that readers should interpret (see the introductory text to §§ 170.302,
design (mandatory), and privacy and
the term as we further explained it 170.304, 170.306, and 170.314), all
security certification criteria
under the ‘‘transitions of care’’ capabilities mentioned in certification
(conditional). To note, we use the term
certification criterion (77 FR 54218) in criteria are expected to be performed
electronically, unless otherwise noted. mandatory to mean that all Health IT
the 2014 Edition final rule and in the
Therefore, we no longer include Modules must be certified to the
Voluntary Edition proposed rule (79 FR
‘‘electronically’’ in conjunction with certification criterion (see also
10898). We proposed that the scope of
a 2015 Edition certification criterion each capability included in a § 170.550(g)(2) and (3)). Conditional
was the same as the scope previously certification criterion under § 170.315 means that certification to the
assigned to a 2014 Edition certification because the introductory text to certification criterion (e.g., the
criterion (for further explanation, see § 170.315 (which covers all the ‘‘Consolidated CDA creation
the discussion at 77 FR 54168). That is, certification criteria included in the performance,’’ ‘‘safety-enhanced
certification to the 2015 Edition section) clearly states that health IT design,’’ ‘‘automatic access timeout,’’ or
certification criteria at § 170.315 would must be able to electronically perform ‘‘integrity’’ certification criterion)
occur at the second paragraph level of the following capabilities in accordance depends on what other certification
the regulatory section and encompass with all applicable standards and criteria a Health IT Module is presented
all paragraph levels below the second implementation specifications adopted for certification to (see § 170.550(g)(1)
paragraph level. We also proposed to in the part. and (4) and § 170.550(f)). For more
continue to use the same specific Health IT certified to the 2015 Edition information on ‘‘conditional’’
descriptions for the different types of certification criteria and associated certification related to privacy and
‘‘data summaries’’ established in the standards and implementation security, we also refer readers to section
2014 Edition final rule (77 FR 54170– specifications can be implemented as IV.C.1 (‘‘Privacy and Security’’) of this
54171) for the 2015 Edition certification part of an EP’s, eligible hospital’s, or preamble.
Health IT certified to the 2015 Edition entire certification criterion in this similar to those used by voluntary
certification criteria and associated manner. Again, this approach also consensus standards bodies.);
standards and implementation supports our goal to make the ONC • The standards adopted at
specifications can also be used to meet Health IT Certification Program more § 170.205(d)(4) and (e)(4) for reporting
other HHS program requirements (e.g., agnostic to health care settings and of syndromic surveillance and
Medicare chronic care management accessible to health IT that supports immunization information to public
services) or private sector requirements care and practice settings beyond the health agencies, respectively (These
(e.g., The Joint Commission ambulatory and inpatient settings. We standards go through a process similar
performance measurement initiative note that we still use ‘‘optional,’’ within the public health community to
(‘‘ORYX’’ vendor)). We refer readers to ‘‘inpatient setting only,’’ and those used by other industry
section IV.B.4 of this preamble for ‘‘ambulatory setting only’’ designations stakeholders and voluntary consensus
further programs that reference the use within certification criteria to provide standards bodies.);
of certified health IT. flexibility and reduce burden where • The standard adopted at
feasible and appropriate. § 170.207(f)(2) for race and ethnicity;
1. Applicability and
We proposed to replace the term
Section 170.300 establishes the ‘‘EHR technology’’ in paragraphs (d)(1) • Certain standards related to the
applicability of subpart C—Certification and (d)(2) of § 170.300 with ‘‘health IT’’ protection of electronic health
Criteria for Health Information to align with our approach to make the information adopted in § 170.210.
Technology. We proposed to revise ONC Health IT Certification Program We are aware of no voluntary
paragraph (d) of § 170.300 to add in a more clearly open to the certification of consensus standard that would serve as
reference to § 170.315 and revise the all types of health IT. We received no an alternative to these standards for the
parenthetical in the paragraph to say comments on this specific proposal and purposes that we have identified in this
‘‘i.e., apply to any health care setting’’ have replaced ‘‘EHR technology’’ with final rule.
instead of ‘‘i.e., apply to both ‘‘health IT’’ in the referenced b. Compliance With Adopted Standards
ambulatory and inpatient settings.’’ paragraphs. Again, we refer readers to
We received no comments on these and Implementation Specifications
section IV.B of this preamble for a
specific proposed revisions and have In accordance with Office of the
detailed discussion of modifications to
adopted the proposed revisions. As Federal Register regulations related to
the ONC Health IT Certification Program
noted in the Proposed Rule, these ‘‘incorporation by reference,’’ 1 CFR
and responses to public comments
revisions clarify which specific part 51, which we follow when we
received on the proposed modifications.
capabilities within a certification adopt proposed standards and/or
criterion included in § 170.315 have 2. Standards and Implementation implementation specifications in a final
general applicability (i.e., apply to any Specifications rule, the entire standard or
health care setting) or apply only to an a. National Technology Transfer and implementation specification document
inpatient setting or an ambulatory Advancement Act is deemed published in the Federal
setting. The revision to change the Register when incorporated by reference
language of the parenthetical aligns with The National Technology Transfer therein with the approval of the Director
our approach to make the ONC Health and Advancement Act (NTTAA) of 1995 of the Federal Register. Once published,
IT Certification Program more agnostic (15 U.S.C. 3701 et. seq.) and the Office compliance with the standard and
to health care settings and accessible to of Management and Budget (OMB) implementation specification includes
health IT that supports care and practice Circular A–119 5 require the use of, the entire document unless we specify
settings beyond the ambulatory and wherever practical, technical standards otherwise. For example, for the Health
inpatient settings. We refer readers to that are developed or adopted by Level Seven (HL7) Implementation
section IV.B of this preamble for a voluntary consensus standards bodies to Guide (IG) for CDA Release 2: National
detailed discussion of modifications to carry out policy objectives or activities, Health Care Surveys (NHCS), Release 1
the ONC Health IT Certification Program with certain exceptions. The NTTAA adopted in this final rule, health IT
responses to public comments received and OMB Circular A–119 provide certified to the certification criterion
on the proposed modifications. exceptions to selecting only standards referencing this IG will need to
We note that, with the 2015 Edition, developed or adopted by voluntary demonstrate compliance with all
we no longer label an entire certification consensus standards bodies, namely mandatory elements and requirements
criterion as either optional or when doing so would be inconsistent of the IG. If an element of the IG is
ambulatory/inpatient (at the second with applicable law or otherwise optional or permissive in any way, it
paragraph level of § 170.315). For impractical. In this final rule, we refer will remain that way for testing and
example, the 2015 Edition certification to voluntary consensus standards, certification unless we specified
criterion for transmission to cancer except for: otherwise in regulation. In such cases,
registries is simply ‘‘transmission to • The standards adopted in § 170.202. the regulatory text preempts the
cancer registries’’ instead of ‘‘optional— (These industry standards were permissiveness of the IG.
ambulatory setting only—transmission developed by groups of industry
to cancer registries.’’ Similarly, the 2015 stakeholders committed to advancing c. ‘‘Reasonably Available’’ to Interested
Edition certification criterion for the Direct Project,6 which included Parties
‘‘accounting of disclosures’’ is simply initiatives under the Standards and The Office of the Federal Register has
‘‘accounting of disclosures’’ instead of Interoperability (S&I) Framework.7 established new requirements for
‘‘optional—accounting of disclosures.’’ These groups used consensus processes materials (e.g., standards and
These simplifications are possible given implementation specifications) that
5 http://www.whitehouse.gov/omb/circulars_a119.
that, beginning with the 2015 Edition agencies incorporate by reference in the
6 http://www.healthit.gov/policy-researchers-
certification criteria, ‘‘Complete EHR’’ Federal Register (79 FR 66267; 1 CFR
implementers/direct-project.
certifications will no longer be issued 7 http://www.healthit.gov/policy-researchers- 51.5(b)). To comply with these
(see 79 FR 54443–45). Therefore, there implementers/standards-interoperability-si- requirements, in section V
is no longer a need to designate an framework. (‘‘Incorporation by Reference’’) of this
preamble, we provide summaries of, Release 2: National Health Care Surveys These code sets are the National Drug
and uniform resource locators (URLs) to, (NHCS) where ‘‘x’’ could be any Codes (NDC)—Vaccine NDC Linker,
the standards and implementation version/release within the version/ updates through August 17, 2015; the
specifications we have adopted and release 1 family). Another commenter CDC Race and Ethnicity Code Set
incorporated by reference in the Federal suggested that we consider adopting a Version 1.0 (March 2000); 8 and the
Register. To note, we also provide ‘‘rolling’’ upgrade cycle for all Crosswalk: Medicare Provider/Supplier
relevant information about these standardized code systems and value to Healthcare Provider Taxonomy, April
standards and implementation sets. Specifically, the commenter 2, 2015.
specifications throughout this section of recommended that a certified Health IT
We have not adopted MVX codes for
the preamble (section III), including Module should not be more than two
vaccine manufacturers as detailed
URLs. versions behind the most currently
further in the discussion on the
released version of the code system or
‘‘Minimum Standards’’ Code Sets ‘‘transmission to immunization
value set. Commenters also suggested
In the Proposed Rule, we proposed to that the vocabulary code set versions in registries’’ certification criterion in
adopt newer versions of four previously the Proposed Rule are now outdated and section III.A.3 of the preamble.
adopted minimum standards code sets have since been updated per a regular Therefore, we do not see a need to
for the 2015 Edition. The code sets update cycle. Commenters suggested we include MVX codes in this list of code
proposed were: The September 2014 adopt these more recent versions of sets.
Release of the U.S. Edition of SNOMED these vocabulary code sets as they We confirm that CDC continues to
CT®, LOINC® version 2.50, the February provide the most up-to-date clinical steward the CDC Race and Ethnicity
2, 2015 monthly version of RxNorm, information for clinical relevance and Code Set, Version 1.0 (March 2000). We
and the February 2, 2015 version of the interoperability. also confirm that we have reviewed this
CVX code set. We also proposed to Response. As many of the proposed version and believe it is appropriate to
adopt two new minimum standards minimum standards code sets are adopt it as the minimum standard code
code sets (the National Drug Codes updated frequently throughout the year, set for race and ethnicity. Any updates
(NDC)—Vaccine Codes, updates through we considered whether it was more to the code set, including the issuance
January 15, 2015 and the ‘‘Race & appropriate to adopt versions of of newer versions, are within the
Ethnicity—CDC’’ code system in the minimum standards code sets that were oversight of the CDC.
PHIN Vocabulary Access and issued after the Proposed Rule and
before we published this final rule. In As we stated in the 2014 Edition final
Distribution System (VADS) Release
making such determination, as we have rule (77 FR 54169–54170), the Office of
3.3.9 (June 17, 2011)). We reiterated, as
done with prior finalized versions of the Federal Register regulations related
we have previously articulated (77 FR
minimum standards code sets, we gave to ‘‘incorporation by reference’’ are
54170), the adoption of newer versions
consideration to whether these newer limited to a specific version that is
improve interoperability and health IT
implementation, while creating little versions included any new substantive approved rather than future versions or
additional burden through the inclusion requirements and their effects on revisions of a given publication. Thus,
of new codes. We further stated that, as interoperability. We have found no we do not include regulation language
many of these minimum standards code negative effects on interoperability with that refers to a version/release as, for
sets are updated frequently throughout the newer versions we have adopted as example ‘‘Version/Release 1.X’’ when
the year, we would consider whether it compared to the proposed versions. ‘‘X’’ remains variable. Further, to remain
may be more appropriate to adopt a Rather, these newer versions will in compliance with the Administrative
version of a minimum standards code further support and improve the Procedure Act and address any potential
set that is issued before we publish a structured recording of data. To note, interoperability concerns, we would
final rule for the Proposed Rule. the adopted newer version of a need to issue regulations to adopt a
Comments. A number of commenters minimum standards code set will serve newer version minimum standards code
were supportive of the proposal to adopt as the baseline for certification. As with set as a ‘‘baseline’’ standard and cannot
more recent versions of the U.S. Edition all adopted minimum standards code require health IT developers to upgrade
of SNOMED CT®, LOINC®, RxNorm, sets, health IT can be certified to newer on a rolling basis.
and the CVX code set. Commenters versions of the adopted baseline version e. Object Identifiers (OIDs) for Certain
supported adoption of NDC codes for minimum standards code sets for Code Systems
vaccines, but also recommended we purposes of certification, unless the
adopt the MVX codes for vaccine Secretary specifically prohibits the use We are providing the following table
manufacturer as part of this list. One of a newer version (see § 170.555 and 77 (Table 3) of OIDs for certain code
commenter requested identification of FR 54268). systems to assist health IT developers in
the steward for the PHIN VADS ‘‘Race We have adopted newer versions of the proper identification and exchange
& Ethnicity—CDC’’ code system, noting four 2014 Edition minimum standards of health information coded to the
that it did not appear to have been code sets in this final rule for the 2015 vocabulary standards referenced in this
updated since 2007. This commenter Edition. These code sets are the final rule.
also requested verification that the code September 2015 Release of the U.S.
set has been reviewed on a regular basis. Edition of SNOMED CT®, LOINC® 8 We have more specifically identified the CDC
A few commenters suggested that we version 2.52, the September 8, 2015 Race and Ethnicity code set as compared to the
do not specify an exact version and monthly version of RxNorm, and the identification in the Proposed Rule. We note this
code set remains part of the PHIN Vocabulary
release of a standard (e.g., allow for August 17, 2015 version of the CVX Access and Distribution System (VADS) Release
adoption of version/release 1.x of the code set. We have also adopted three 3.3.9. http://www.cdc.gov/phin/resources/
HL7 Implementation Guide for CDA new minimum standards code sets. vocabulary/index.html.
TABLE 3—CODE SYSTEM OBJECT IDENTIFIERS (OIDS)

Code system OID Code system name
2.16.840.1.113883.6.96 .............................. IHTSDO SNOMED CT®.

2.16.840.1.113883.6.1 ................................ LOINC®.
2.16.840.1.113883.6.88 .............................. RxNorm.
2.16.840.1.113883.12.292 .......................... HL7 Standard Code Set CVX-Vaccines Administered.
2.16.840.1.113883.6.69 .............................. National Drug Code Directory.
2.16.840.1.113883.6.8 ................................ Unified Code of Units of Measure (UCUM 9).
2.16.840.1.113883.6.13 .............................. Code on Dental Procedures and Nomenclature (CDT).
2.16.840.1.113883.6.4 ................................ International Classification of Diseases, 10th Revision, Procedure Coding System (ICD–10–PCS).
2.16.840.1.113883.6.238 ............................ CDC Race and Ethnicity Code Set Version 1.0 (March 2000).
2.16.840.1.113883.6.316 ............................ Tags for Identifying Languages—Request for Comment (RFC) 5646 (preferred language).
2.16.840.1.113883.6.101 ............................ Healthcare Provider Taxonomy.
f. Subpart B—Standards and certification criterion in the regulatory text will provide further
Implementation Specifications for chronological order in which it would clarity regarding when a health IT
Health Information Technology appear in the CFR. In other words, the developer has flexibility to select one of
preamble that follows discusses the two or more options for certifying its
We proposed to remove the term adopted certification criteria in Health IT Module as compared to when
‘‘EHR Modules’’ from § 170.200 and add § 170.315(a) first, then § 170.315(b), and it is expected that the Health IT Module
in its place ‘‘Health IT Modules’’ We so on through section (h). Due to certain demonstrate all listed methods for
proposed to remove the term ‘‘EHR proposed certification criteria not being
technology’’ from § 170.210 and add in certification. This restructuring, by
adopted as well as further consideration itself, did not alter any of the proposed
its place ‘‘health IT.’’ We noted that of proper categorization of criteria, the
these proposals were consistent with certification criteria requirements.
designation of some criteria within
our overall approach to this rulemaking § 170.315 has changed in comparison to Table 4 below identifies the 2015
as discussed in the Proposed Rule the Proposed Rule (e.g., the 2015 Edition certification criteria associated
Executive Summary and recited in this Edition ‘‘smoking status’’ criterion has with the EHR Incentive Programs Stage
final rule’s Executive Summary. We been codified in § 170.315(a)(11) instead 3 as finalized in EHR Incentive
received no comments on these specific of proposed (a)(12) and the 2015 Edition Programs Stage 3 and Modifications
proposals and have adopted these ‘‘patient health information capture’’ final rule published elsewhere in this
proposals. We refer readers to section criterion has been codified in issue of the Federal Register. While
IV.B of this preamble for a detailed § 170.315(e)(3) instead of proposed these certification criteria can be used to
discussion of modifications to the ONC (a)(19)). support other use cases and health care
Health IT Certification Program and We note that we have restructured the settings beyond the EHR Incentive
responses to public comments received regulatory text of certification criteria to Programs, we have also adopted
on the proposed modifications. remove the use of ‘‘or’’ in many places additional 2015 health IT certification
where it was proposed to indicate criteria that support other specific use
3. Adopted Certification Criteria
certification optionality. We have cases and health care settings. These
We discuss the certification criteria replaced it with language that we criteria were listed in Table 2 and are
that we have adopted as part of the 2015 believe will better convey that same discussed in this section of the
Edition in this section. We discuss each optionality. This restructuring of the preamble.
9 Copyright© 1998–2013, Regenstrief Institute,
Inc. and the UCUM Organization. All rights

reserved.
Table 4. 2015 Edition Health IT Certification Criteria Associated with the EHR Incentive
3
CFR Relationship to the Health IT

Section Certification Criterion CEHRT 10 Definition and Module
170.315 Stage 3 Objectives 11 Certification
Specifically included in the

Computerized Provider Order Entry
(a)(l) CEHRT definition
(CPOE)- Medications 12
(a)(2) CPOE- Laboratory 13
(a)(3) CPOE- Diagnostic Imaging 14

Associated with
Drug-Drug, Drug-Allergy Interaction
(a)(4)
Checks for CPOE
(a)(5) Demographics
CEHRT definition
(a)(6) Problem List
CEHRT definition
(a)(7) Medication List
CEHRT definition
(a)(8) Medication Allergy List
CEHRT definition
(a)(9) Clinical Decision Support CEHRT definition
Associated with
Drug-Formulary and Preferred Drug
(a)(lO)
List Checks
(a)(ll) Smoking Status
CEHRT definition
(a)(l2) Family Health History
CEHRT definition
10 The EHR Incentive Programs CEHRT defmition includes the criteria adopted in the 2015 Edition Base EHR
defmition. These criteria are identified in this table as specifically included in CEHRT defmition, as are other
criteria specifically included in the CEHRT defmition but are not part of the 2015 Edition Base EHR defmition. For
more information on the 2015 Edition Base EHR defmition, please see section III.B.lofthis fmal rule's preamble.
For more details on the CEHRT defmition, please see the EHR Incentive Programs Stage 3 and Modifications fmal
rule published elsewhere in this issue of the Federal Register.
11 Criteria "associated with objectives" support requirements of the EHR Incentive Programs to use certified EHR
technology to meet objectives. For further information on these requirements, please see the EHR Incentive
Programs Stage 3 and Modifications fmal rule published elsewhere in this issue of the Federal Register.
12 Technology needs to be certified to§ 170.315(a)(1), (a)(2), or (a)(3).
ER16OC15.000</GPH>
(b)(l) Transitions of Care

Associated with
Clinical Information Reconciliation
and

(b)(6) Data Export
CEHRT definition
Clinical Quality Measures -Record Specifically included in the
( c)(1)
and CEHRT Defmition
Clinical Quality Measures -Import Specifically included in the
( c)(2)
and Calculate CEHRT Defmition
(c)(3) Clinical Quality Measures -Report
CEHRT Defmition
View, Download, and Transmit to 3
(e)(3)
(f)( I)
(f)(2) Associated with Objective 8

Transmission to Public Health
(f)(3) Agencies -Reportable Laboratory Associated with Objective 8
Tests and Values/Results
Transmission to Cancer Registries
Transmission to Public Health
(f)(S) Associated with Objective 8
· - Electronic Case

(g)(l) Automated Numerator Recording
CEHRT definition
(g)(2) Automated Measure Calculation
CEHRT definition
(g)(7) Application Access -Patient Selection
CEHRT definition
15 For the public health certification criteria in§ 170.315(f), health IT will only need to be certified to those criteria
that are required to meet the measures the provider intends to report on to meet Objective 8: Public Health and
Clinical Data Registry Reporting.
ER16OC15.001</GPH>
• Computerized Provider Order Entry We requested comment on whether Comments. Most commenters
We proposed to adopt three separate we should specify, for the purposes of opposed the inclusion of specific data
2015 computerized provider order entry testing and certification to the 2015 elements for certification. These
(CPOE) certification criteria based on Edition CPOE criteria, certain data commenters most often cited burden on
the clinical purpose (i.e., medications, elements that a Health IT Module must health IT developers and concern that
laboratory, and diagnostic imaging), be able to include in a transmitted new data elements might lead to
which was consistent with the 2014 order. In particular, we requested inefficient workflow for the order entry
Edition CPOE certification criteria we comment on whether a Health IT process as reasons for not including
Module should be able to include any additional data elements. Some
adopted in the 2014 Edition Release 2
or all of the following data elements: commenters expressed support for the
final rule (79 FR 54435–36).
secondary diagnosis codes; reason for inclusion of additional data elements
Comments. We received only a few order; and comment fields entered by mentioned in the Proposed Rule, but
comments on this proposed approach, the ordering provider, if they are varied in their support for the specific
all which expressed support for provided to the ordering provider in data elements that should we included.
separating the functionality based on their order entry screen. We also These commenters did, however, agree
clinical purpose. requested comment on whether there that the ‘‘reason for order’’ data element
Response. We have adopted separate are any other data elements that a was a data element that should be
CPOE certification criteria based on Health IT Module should be able to included with an order.
clinical purposes that are described in include as part of an order for the Response. We acknowledge the lack
ER16OC15.002</GPH>
more detail below. purposes of testing and certification. of agreement as to what data elements
should be required for certification, but We proposed to adopt a 2015 Edition Edition CPOE—diagnostic imaging
also the support for the ‘‘reason for CPOE certification criterion specific to criterion adopted at § 170.314(a)(20) as
order’’ data elements. With laboratory ordering that was revised in well as § 170.314(a)(1)(iii). The
consideration of commenters concerns comparison to the CPOE—laboratory proposed criterion does not reference
about burden and workflow criterion adopted at § 170.314(a)(19) as any standards or implementation
inefficiencies, we have adopted the well as § 170.314(a)(1)(ii). For the specifications. We also proposed to
‘‘reason for order’’ data element as an ambulatory setting, we proposed that adopt the title of ‘‘diagnostic imaging,’’
optional certification provision in each this criterion would include the HL7 which is the title we gave to the 2014
of the three CPOE certification criteria. Version 2.5.1 Implementation Guide: Edition version of this certification
We agree with commenters that the S&I Framework Laboratory Orders (LOI) criterion in the 2014 Edition Release 2
reason for an order data element has from EHR, Draft Standard for Trial Use, final rule (79 FR 54436).
value. The designation of this provision Release 2—US Realm (‘‘Release 2’’). We Comments. Commenters
as optional in all three criteria gives proposed to adopt the most recent overwhelmingly recommended that this
flexibility to health IT developers as version of the HL7 Version 2.5.1 criterion remain unchanged. A few
they consider certification of their Implementation Guide: S&I Framework commenters recommended we add
health IT and providers as they consider Laboratory Test Compendium functionality to this criterion, including
what certified health IT to purchase. Framework, Release 2, (also referred to the required use of a standard such as
• Computerized Provider Order as the ‘‘electronic Directory of Services Digital Imaging and Communications in
Entry—Medications (eDOS) IG’’) for certification to all health Medicine (DICOM) to support radiology.
care settings. We also proposed to Response. We thank commenters for
require that a Health IT Module use, at their support and have adopted this
2015 Edition Health IT Certification Cri-
terion a minimum, version 2.50 of Logical criterion as unchanged. As noted above,
§ 170.315(a)(1) (Computerized provider Observation Identifiers Names and we have, however, adopted the ‘‘reason
order entry—medications) Codes (LOINC®) as the vocabulary for order’’ data element as an optional
standard for laboratory orders. provision within this criterion. While
We proposed to adopt a 2015 Edition Comments. Commenters stated that we appreciate comments suggesting the
CPOE certification criterion specific to the LOIs and eDOS IGs were not ready inclusion of additional functionality,
medication ordering that was for implementations, but acknowledged the recommended functionality is
unchanged in comparison to the 2014 the significant progress being made in outside the scope of the proposed
Edition CPOE—medications criterion developing standards for laboratory criterion. Therefore, we have not
adopted at § 170.314(a)(18) as well as ordering and the harmonizing of adopted the recommended functionality
§ 170.314(a)(1)(i). The proposed laboratory-related IGs. in this criterion. We also refer readers to
criterion does not reference any Response. With consideration of our previous discussion of DICOM (77
standards or implementation comments, we have determined not to FR 54173).
adopt any standards for this certification • Drug-Drug, Drug-Allergy Interaction
specifications.
criterion. We have, however, adopted Checks for CPOE
Comments. Commenters the ‘‘reason for order’’ data element as
overwhelmingly recommended that this an optional provision within this 2015 Edition Health IT Certification Cri-
criterion remain unchanged. A few criterion. We have made the terion
commenters requested clarifications determination to keep this criterion § 170.315(a)(4) (Drug-drug, drug-allergy
regarding the designation of authorized interaction checks for CPOE)
‘‘functional’’ at this time based on a
CPOE users and the proper counting of number of factors, including (among
CPOE orders for the purposes of meeting We proposed to adopt a revised 2014
other aspects) that the best versions of Edition ‘‘drug-drug, drug-allergy
the associated meaningful use objective the IGs that could be associated with
and measure. interaction checks’’ criterion
this criterion were not sufficiently (§ 170.314(a)(2)) to clarify that the
Response. We thank commenters for ready. That being said, we believe that capabilities included in this criterion
their support and have adopted this the LOI and eDOS IGs show great are focused on CPOE. We proposed that
criterion as unchanged. As noted above, promise in improving laboratory a Health IT Module must record at least
we have, however, adopted the ‘‘reason interoperability and could potentially one action taken and by whom, and
for order’’ data element as an optional result in significant cost savings to the must generate either a human readable
provision within this criterion. For industry at large. Accordingly, we display or human readable report of
questions related to the EHR Incentive remain committed to continued actions taken and by whom in response
Programs (i.e., the designation of collaboration with stakeholders to to drug-drug or drug-allergy interaction
authorized CPOE users and the proper support the widespread adoption of checks (DD/DAI). We explained that the
counting of CPOE order for the purposes these IGs, including the development of benefits of recording user actions for
of meeting the associated meaningful testing tools and pilots where necessary DD/DAI interventions that assist with
use objective and measure), we refer and feasible. quality improvement and patient safety
readers to CMS and the EHR Incentive • Computerized Provider Order
outweigh the development burden
Programs Stage 3 and Modifications Entry—Diagnostic Imaging
associated with this functionality.
final rule published elsewhere in this
However, to address development
issue of the Federal Register. 2015 Edition Health IT Certification Cri-
concerns, we proposed that a Health IT
• Computerized Provider Order terion

§ 170.315(a)(3) (Computerized provider Module must only record, at a
Entry—Laboratory order entry—diagnostic imaging) minimum, one user action for DD/DAI
checks; and asked for comment on
2015 Edition Health IT Certification Cri- We proposed to adopt a 2015 Edition focusing the requirement to record at
terion CPOE certification criterion specific to least one user action taken for DD/DAI
§ 170.315(a)(2) (Computerized provider
order entry—laboratory)
diagnostic imaging ordering that was interventions on a subset of DD/DAI
unchanged in comparison to the 2014 interventions and what sources we
should consider for defining this subset. that focused on each of the specific data Ethnicity—CDC’’ code system in PHIN
We further noted that the proposed elements in the certification criterion. VADS as a minimum standards code set
criterion does not establish the uses for We have categorized and responded to and Release 3.3.9, or potentially a newer
the ‘‘user action’’ information, who these comments in a similar manner. version if released before this final rule,
should be able to view the information, as the baseline for certification to the
Sex
or who could adjust the capability. We 2015 Edition. To note, the Proposed
also sought comment on requiring We proposed the requirement to Rule section III.B.3 ‘‘Common Clinical
functionality that would inform a user record sex in accordance with HL7 Data Set’’ also discussed adopting the
of new or updated DD/DAI when the Version 3 (‘‘AdministrativeGender’’) Race & Ethnicity—CDC’’ code system in
medication or medication allergy lists and a nullFlavor value attributed as PHIN VADS (at a minimum, Release
are updated. follows: male (M); female (F); and 3.3.9) and the OMB standard as the race
Comments. We received a few unknown (UNK), and noted that HL7 and ethnicity standards under the
comments supporting our proposed Version 3 for recording sex would be ‘‘Common Clinical Data Set’’ definition
clarification that this criterion focused required under the ‘‘Common Clinical for certification to the 2015 Edition.
on CPOE, but also suggestions that this Data Set’’ definition for certification to Comments. A majority of commenters
functionality could support other use the 2015 Edition. In the Proposed Rule’s supported our proposal to require a
cases, such as when medications are section III.B.3 (‘‘Common Clinical Data Health IT Module to be able to capture
reviewed or medication or medication Set’’), we stated that this approach granular patient race and ethnicity data.
allergy lists are updated. We received would become the method for capturing Some commenters questioned the
mixed comments in response to the sex under the ‘‘Common Clinical Data necessity for such granular race and
proposed additional ‘‘recording user Set’’ definition for certification to the ethnicity capture because it was not
response’’ functionality for this 2015 Edition. required for the EHR Incentive Programs
criterion. While many commenters Comments. Commenters were or another identified purpose, with one
supported the overall goal of interaction generally supportive of recording sex in commenter recommending that this be a
checking for quality improvement and a structured manner. A few commenters future certification requirement.
patient safety, including functionality suggested that we used other values, Commenters expressed concerns about
that would inform a user of new or such as U or UN for undifferentiated. A user interfaces in relation to the over
updated DD/DAI, many commenters few commenters also requested 900 concepts for race and ethnicity in
stated that current systems already clarification on the proposed use of two PHIN VADS, including concern over
provide a wide range of functionality to different value sets (HL7 how many concepts should be
enable providers to document decisions AdministrativeGender and NullFlavor). displayed for users. Similarly,
concerning interaction warnings. These Response. We appreciate the support commenters suggested that testing and
commenters stated that the proposed for our proposal. We have adopted the certification should not be to all 900
‘‘recording user response’’ is not requirement for recording sex as concepts. A few commenters requested
necessary for certification or for proposed. We clarify that this coding is clarification on whether a health IT
providers to satisfy objectives of the intended to present birth sex. Therefore, Module must be able to capture
EHR Incentive Programs. Commenters we believe the use of the specified multiple races or ethnicities for a
requested the criterion remain eligible values and value sets is the most patient and the appropriate method for
for gap certification. A few expressed appropriate approach. It is also an capturing when a patient declines to
overall agreement with the other approach that we believe poses the least provide race or ethnicity information.
functionality specified in this criterion, burden and most health IT developers Response. We thank commenters for
including the ability to adjust the are using these values and value sets. their support. We have adopted the race
severity level of interventions (e.g., and ethnicity requirements as proposed,
Race and Ethnicity including the use of both the OMB and
alerts) for drug-drug interaction checks.
Response. We have determined, based We proposed the requirement to the CDC Race and Ethnicity standards.
on public comments, to focus this record each one of a patient’s races and We believe that the structured granular
certification criterion on CPOE and to ethnicities in accordance with, at a recording of race and ethnicity can both
not adopt the ‘‘recording user response’’ minimum, the ‘‘Race & Ethnicity—CDC’’ improve patient care and support the
functionality. This approach is code system in the PHIN Vocabulary elimination of health disparities
responsive to comments and will permit Access and Distribution System (VADS), whether or not currently required by the
health IT developers to focus their Release 3.3.9 18 and aggregate each one EHR Incentives Programs or another
efforts on functionality and of a patient’s races and ethnicities to the HHS program. By adopting these
requirements that support the goals categories in the OMB standard for race requirements, we ensure certified health
outlined in the Executive Summary, and ethnicity. We explained that a IT has these capabilities and can make
including supporting the Health IT Module must be able to record them available to providers. We clarify
interoperability of health IT. To note, each one of a patient’s races and four points in response to comments.
this criterion is eligible for gap ethnicities using any of the 900 plus First, as mentioned in the Proposed
certification. concepts in the ‘‘Race & Ethnicity— Rule, a health IT developer and provider
• Demographics CDC’’ code system, and noted that can best determine how the user
health IT developers and health care interface is designed, including how
2015 Edition Health IT Certification Cri- providers could determine the many race and ethnicity values are
displayed. Second, as mentioned above
terion appropriate user interface

§ 170.315(a)(5) (Demographics) implementation in a given setting. The and in the Proposed Rule, a Health IT
Proposed Rule section III.A.2.d Module must be able to record each one
We proposed to adopt a revised 2015 (‘‘Minimum Standards’’ Code Sets) of a patient’s races and ethnicities using
Edition ‘‘demographics’’ certification discussed the adoption of the ‘‘Race & any of the 900 plus concepts. For testing
criterion in comparison to the 2014 and certification, a Health IT Module
Edition certification criterion 18 https://phinvads.cdc.gov/vads/ViewCode would be tested to any of the 900 plus
(§ 170.314(a)(3)). We received comments System.action?id=2.16.840.1.113883.6.238#. concepts at the discretion of the testing
body. Third, a Health IT Module would designed, including how many Response. We thank commenters for
need to be capable of recording multiple preferred languages are displayed. their feedback. Given this feedback, the
races and/or ethnicities for a patient. clinical relevance of capturing SO/GI,
Preliminary Cause of Death and Date of
This approach is consistent with the and the readiness of the values and
Death
OMB standard. Fourth, a Health IT vocabulary codes for representing this
Module must be able to demonstrate In the Proposed Rule, we proposed information in a structured way, we
that it can record whether a patient that, for the inpatient setting, a Health require that Health IT Modules enable a
declined to provide information for all IT Module must include the user to record, change, and access SO/
data specified in this certification functionality to record, change, and GI to be certified to the 2015 Edition
criterion. We do not, however, specify access the ‘‘date of death.’’ We stated ‘‘demographics’’ certification criterion.
for the purposes of certification how that this functionality would be in By doing so, SO/GI is now included in
that data is specifically captured. addition to the requirement to enable a the 2015 Edition Base EHR definition.
user to electronically record, change, The 2015 Edition Base EHR definition is
Preferred Language and access ‘‘preliminary cause of death’’ part of the CEHRT definition under the
In the Proposed Rule, we proposed to in case of mortality, as is included in EHR Incentive Programs. Therefore,
require the use of the Internet the 2014 Edition ‘‘demographics’’ providers participating in the EHR
Engineering Task Force (IETF) Request certification criterion. Incentive Programs will need to have
for Comments (RFC) 5646 19 standard Comments. The majority of certified health IT with the capability to
for preferred language. We stated that commenters supported this capture SO/GI to meet the CEHRT
RFC 5646 entitled ‘‘Tags for Identifying requirement. A few commenters definition in 2018 and subsequent years.
Languages, September 2009’’ is the requested clarification as to whether the We note that like all information in
coding system that is commonly used to preliminary cause of death was to be the ‘‘demographics’’ criterion,
encode languages on the web. We also recorded consistent with either the certification does not require that a
noted that this standard is compatible SNOMED CT® or ICD–10–CM provider collect this information, only
with the C–CDA Release 2.0 (and C– standards. that certified Health IT Modules enable
CDA Release 2.1) and that other Response. We thank commenters for a user to do so. We believe including
preferred language standards in use their support and have adopted this SO/GI in the ‘‘demographics’’ criterion
today can be efficiently mapped to it, requirement as proposed. We clarify represents a crucial first step forward to
such as ISO 639–1, 639–2, and 639–3. that the preliminary cause of death is improving care for LGBT communities.
The Proposed Rule explained that the not required to be recorded in We have not included it in the
standard does not determine the way in accordance with a standard for the Common Clinical Data Set at this time.
which health care providers use the purposes of certification to this criterion We refer readers to section III.B.3 of this
capability to record preferred language as we did not propose such a preamble for further discussion of the
or the preferred language values they are requirement nor have we adopted one. Common Clinical Data Set.
presented with to select a patient’s Comments. We received comments
Sexual Orientation and Gender Identity
preferred language. In the Proposed from a health care coalition that has
(SO/GI)
Rule’s section III.B.3 (‘‘Common Clinical partnered with and coordinated
Data Set’’), we stated that RFC 5646 We did not propose to include a industry-development of the
would also become the preferred requirement to capture a patient’s appropriate terminology to capture SO/
language standard under the ‘‘Common sexual orientation or gender identity as GI for health care settings. The
Clinical Data Set’’ definition for part of this criterion. Rather, we commenters suggested that we revise
certification to the 2015 Edition. proposed the capture of SO/GI data as the proposed terminology for collecting
Comments. Commenters were part of the proposed ‘‘social, SO/GI to use more appropriate language
generally supportive of the adoption of psychological, and behavioral data’’ that reflects up-to-date, non-offensive
the RFC 5646 standard. Some certification criterion. terminology that will facilitate the goal
commenters (health IT developers) Comments. We received a significant of providing welcoming and affirming
expressed opposition to the recording of number of comments from providers, health care to LGBT individuals. As
preferred language in RFC 5646 due to consumers/individuals, and health care such, the commenters recommended
the new burden it would create versus coalitions strongly recommending that that we retain the proposed SNOMED
the perceived minimal value. One we consider including sexual CT® and HL7 V3 codes but revise the
commenter suggested adopting ISO orientation and gender identify as a description of some codes to use
639–3 instead of RFC 5646. component of the Base EHR definition synonyms which reflect more
Response. We have adopted RFC 5646 (e.g., in the demographics certification appropriate language. The commenters
as the preferred language standard for criterion) or Common Clinical Data Set noted that they have already submitted
this criterion. As extensively discussed definition. These commenters suggested revisions to SNOMED CT® to include
in the Proposed Rule (80 FR 16817), we that there are mature vocabulary the synonyms for these terms. The
believe this is the most appropriate standards for representing SO/GI and commenters also noted that the core
standard for capturing a patient’s there is strong clinical value in having concepts of the codes remain the same.
preferred language. It is compatible with this data to inform decisions about Response. We thank the commenters
the C–CDA Release 2.1 and other health care and treatment. Commenters for the suggestion and are proceeding
preferred language standards can be indicated that by including SO/GI in the with the recommendation to include use
efficiently mapped to it, including IS0 Base EHR or Common Clinical Data Set the revised terminology for collecting
639–1, 639–2, and 639–3. As mentioned definitions, providers would be required SO/GI. We refer readers to
in the Proposed Rule and clarified for to possess this functionality for § 170.207(o)(1) and § 170.207(o)(2) for a
other demographics data, a health IT participation in the EHR Incentive full list of the code descriptors and
developer and provider can best Programs, which could have a large codes for SO/GI, respectively.
determine how the user interface is impact for evaluating the quality of care Comments. One commenter
provided to lesbian, gay, bisexual, and recommended we consider including
19 http://www.rfc-editor.org/info/rfc5646. transgender (LGBT) communities. structured and coded questions for
soliciting SO/GI information as part of baseline for certification to the 2015 This will enable a provider to choose
certification. Edition. any available and appropriate code in
Response. While we thank the Comments. The majority of SNOMED CT® for a patient’s problems.
commenter for providing this commenters supported the proposed We did not propose as part of this
recommendation, we do not believe that certification criterion. A commenter criterion to test and certify a Health IT
the suggested questions have not yet suggested that instead of the full Module’s ability to enable a user to
been scientifically validated for use in SNOMED CT® code system, the record, change, and access a patient’s
health care settings and, thus, have not reference should be explicit to a concept active problem list and problem history
adopted them. We do, however, believe and its value set relevant to this across health care settings as this
that these questions are being used criterion, such as the ‘‘core’’ problem criterion is focused on the ambulatory
today in health care settings as ‘‘best list. A commenter recommended and inpatient settings in support of the
practices,’’ and would suggest that requiring certification to the most EHR Incentive Programs. We believe the
health care providers and institutions current version of SNOMED CT®. Some use of ‘‘for the duration of an entire
decide whether to include these commenters recommended that we hospitalization’’ is appropriate for this
questions in the collection of SO/GI require the use of the ICD–10–CM code criterion and refer readers to our
information. These ‘‘best practice’’ set. These commenters noted that the detailed discussed of this determination
questions and the answers we have code set is used for billing purposes and in the 2014 Edition final rule (77 FR
adopted are: the required use of SNOMED CT® adds 54211–54212).
• Do you think of yourself as: burden on providers and their staff due We agree with commenters that
Æ Straight or heterosexual; to the required use of two different efficient testing and certification
Æ Lesbian, gay, or homosexual; systems. processes should be available to Health
Æ Bisexual; A couple of commenters stated that IT Modules previously certified to the
Æ Something else, please describe. the problem list should not be limited 2014 Edition ‘‘problem list’’ criterion for
Æ Don’t know. to the duration of a hospitalization certification to this criterion.
• What is your current gender because it may be needed when the Accordingly, we will consider such
identity? (Check all that apply.) patient is out of the hospital, suggesting options, such as attestation, in
Æ Male; ‘‘for the duration of an entire developing the test procedure for this
Æ Female; hospitalization’’ be struck from the criterion and in issuing guidance to the
Æ Transgender male/Trans man/ criterion. Another commenter suggested ONC–AA and ONC–ACBs.
Female-to-male; that the distinction between inpatient • Medication List
Æ Transgender female/Trans woman/ and ambulatory records should be
Male-to-female; dropped in favor of a ‘‘patient’’ record 2015 Edition Health IT Certification Cri-
Æ Genderqueer, neither exclusively stating that several major healthcare terion
male nor female; systems have dropped the distinction § 170.315(a)(7) (Medication list)
Æ Additional gender category/(or and are focusing on a patient problem
other), please specify. list where one or more problems on the We proposed to adopt a 2015 Edition
Æ Decline to answer. problem list are addressed in a ‘‘medication list’’ certification criterion
Comments. One commenter particular encounter (outpatient visit or that was unchanged as compared to the
recommended that we add another inpatient stay). 2014 Edition ‘‘medication list’’
question and set of answers to collect Commenters suggested that if this certification criterion (§ 170.314(a)(6)).
assigned birth sex. criterion was adopted as proposed that To note, the proposed criterion does not
Response. We have not adopted this health IT developers should have the reference any standards or
recommendation to collect assigned ability to attest that their health IT implementation specifications.
birth sex as suggested because we previously certified to the 2014 Edition Comments. The majority of
already require the capturing of birth ‘‘problem list’’ criterion meets the newer commenters expressed support for this
sex as described under the ‘‘sex’’ section baseline version of SNOMED CT® for certification criterion as proposed. A
above. the purposes of testing and certification few commenters suggested additional
• Problem List to this criterion. functionalities for this criterion. These
Response. We have adopted this suggestions included functionality to
2015 Edition Health IT Certification Cri- certification criterion as proposed, designate or mark medications as
terion except that we have adopted a newer confidential or sensitive and include
§ 170.315(a)(6) (Problem list) baseline version SNOMED CT® patient-generated data. One commenter
(September 2015 Release of the U.S. recommended requiring that
We proposed to adopt a 2015 Edition Edition) for the purposes of medications be recorded in accordance
‘‘problem list’’ certification criterion certification. We refer readers to section with RxNorm. A couple of commenters
that was revised as compared to the III.A.2.c (‘‘Minimum Standards’’ Code requested clarification and expansion of
2014 Edition ‘‘problem list’’ certification Sets) for a more detailed discussion of the medication list to include over-the-
criterion (§ 170.314(a)(5)) by requiring our adoption of the September 2015 counter medications, herbal
the September 2014 Release of the U.S. Release of the U.S. Edition of SNOMED supplements, medical cannabis, and
Edition of SNOMED CT® as the baseline CT® and for our reasons why we always oxygen. In general, a few commenters
version permitted for certification to adopt a baseline version of a vocabulary suggested that the medication list
this criterion. The Proposed Rule’s code set for certification instead of should be available across encounters
section III.A.2.d (‘‘Minimum Standards’’ specifying certification must be to the and there should not be a distinction
Code Sets) discussed our adoption of ‘‘most current’’ version. As with the between inpatient and ambulatory
SNOMED CT® as a minimum standards 2014 Edition, testing and certification records. One of these commenters noted
code set and the adoption of the will focus on a Health IT Module’s that healthcare systems have dropped
September 2014 Release (U.S. Edition), ability to enable a user to record, the distinction and are focusing on a
or potentially a newer version if change, and access a patient’s problem patient medication list. Another
released before this final rule, as the list in accordance with SNOMED CT®. commenter stated that the Food and
Drug Administration (FDA) is currently couple of commenters recommended in comparison to the 2014 Edition
working to implement requirements additional functionalities such as ‘‘CDS’’ criterion (§ 170.314(a)(8)). We
from the Drug Supply Chain Security including time and date for medication proposed to require a Health IT Module
Act (DSCSA) regarding standards for the allergies entered, edited, and deleted. In to follow the updated Infobutton
interoperable exchange of information general, a few commenters suggested standard (Release 2, June 2014) 20 and
for tracing human, finished and/or that the medication allergy list should one of two updated associated IGs: HL7
prescription drugs. The commenter be available across encounters and there Implementation Guide: Service-
recommended that we be aware of these should not be a distinction between Oriented Architecture Implementations
efforts and align current and future inpatient and ambulatory records. One of the Context-aware Knowledge
certification requirements with any of these commenters noted that Retrieval (Infobutton) Domain, Release
future FDA requirements for standards- healthcare systems have dropped the 1, August 2013 (‘‘SOA Release 1 IG’’),21
based identification of prescription distinction and are focusing on a patient the updated Infobutton URL-based IG
drugs. medication allergy list. Another (HL7 Version 3 Implementation Guide:
Response. We thank commenters for commenter stated that the FDA is Context-Aware Knowledge Retrieval
their support and have adopted this currently working to implement (Infobutton), Release 4, June 2014)
criterion as proposed. The other requirements from the Drug Supply (‘‘URL-based Release 4 IG’’). 22 We
comments summarized above are Chain Security Act (DSCSA) regarding proposed to require certification only to
outside the scope of the proposed standards for the interoperable exchange the Infobutton standard (and an
criterion. We did not propose additional of information for tracing human, associated IG) for identifying diagnostic
functionality for this criterion, finished and/or prescription drugs. The or therapeutic reference information, as
including structured capture in commenter recommended that we be we stated this is the best consensus-
accordance with RxNorm. We also did aware of these efforts and align current based standard available to support the
not propose as part of this criterion to and future certification requirements use case. We requested comment on
test and certify a Health IT Module’s with any future FDA requirements for requiring that a Health IT Module be
ability to enable a user to record, standards-based identification of able to request patient-specific
change, and access a patient’s active prescription drugs. education resources identified using
medication list and medication history Response. We thank commenters for Infobutton standards based on a
across health care settings as this their support and have adopted this patient’s preferred language. We
criterion is focused on the ambulatory criterion as proposed. The other proposed to require that a Health IT
and inpatient settings in support of the comments summarized above are Module presented for certification to
EHR Incentive Programs (please also see outside the scope of the proposed this criterion be able to record at least
our response to comments for the criterion. We did not propose additional one action taken and by whom when a
‘‘problem list’’ certification criterion functionality for this criterion, CDS intervention is provided to a user,
above). Further, we do not define including additional allergens and the and that a Health IT Module must
‘‘medications’’ for the purpose of testing structured capture of medication generate either a human readable
and certifying a Health IT Module’s allergies. As we noted in the Proposed display or human readable report of the
ability to enable a user to record, Rule (80 FR 16820), there are a number responses and actions taken and by
change, and access a patient’s active of vocabularies and code sets that could whom when a CDS intervention is
medication list and medication history. support food and environmental provided. We clarified that the 2015
We thank the commenter for the allergies as well as medications, but our Edition CDS certification criterion does
information related to FDA’s work and view is that there is no ready solution not use the terms ‘‘automatically’’ and
will take steps to ensure our work aligns for using multiple vocabularies to code ‘‘trigger’’ as related to CDS interventions
with the relevant work of the FDA. allergies that could be adopted for the so as to reiterate the intent to encompass
• Medication Allergy List purposes of certification at this time. We all types of CDS interventions without
also did not propose as part of this being prescriptive on how the
2015 Edition Health IT Certification Cri- criterion to test and certify a Health IT interventions are deployed. We
terion Module’s ability to enable a user to proposed cross-reference corrections to
§ 170.315(a)(8) (Medication allergy list) record, change, and access a patient’s the 2014 Edition CDS criterion.
active medication allergy list and Infobutton Standard and Related IGs
We proposed to adopt a 2015 Edition medication allergy history across health
‘‘medication allergy list’’ certification care settings as this criterion is focused Comments. A majority of commenters
criterion that was unchanged as on the ambulatory and inpatient settings supported the inclusion of the updated
compared to the 2014 Edition in support of the EHR Incentive Infobutton standard and related IGs.
‘‘medication allergy list’’ certification Programs (please also see our response Multiple commenters recommended
criterion (§ 170.314(a)(7)). to comments for the ‘‘problem list’’ that there should be more options
Comments. The majority of besides Infobutton for identifying
certification criterion above). As noted
commenters supported this criterion as diagnostic or therapeutic reference
in our response under the ‘‘medication
proposed. Multiple commenters information. A commenter
list’’ certification criterion, we will take
recommended adding functionality to recommended a requirement for
steps to ensure our work aligns with the
support food and environmental Infobutton to be connected to a
relevant work of the FDA.
allergies as well as other types of • Clinical Decision Support reference resource at the end user’s
allergens, noting that most providers are choice in cases of inability to use the
already recording this information and 2015 Edition Health IT Certification Cri- Infobutton functionality due to
that such functionality would support terion
patient safety. Some of these same § 170.315(a)(9) (Clinical decision support) 20 http://www.hl7.org/implement/standards/
commenters recommended the product_brief.cfm?product_id=208.

21 http://www.hl7.org/implement/standards/
structured capture of this information in We proposed to adopt a 2015 Edition product_brief.cfm?product_id=283.
various standards, including RxNorm, ‘‘clinical decision support’’ (CDS) 22 http://www.hl7.org/implement/standards/
UNII, SNOMED CT®, and LOINC®. A certification criterion that was revised product_brief.cfm?product_id=22.
contractual relationships to reference functionality, health IT developers will transition of care/referral summary
resources. Multiple commenters voiced be able to focus more of their efforts on because the proposed 2015 Edition
a need for materials to be tested and other adopted functionality and ‘‘clinical information reconciliation and
vetted to ensure the accuracy and requirements, including those that incorporation’’ criterion does not
appropriate literacy level of material, in support the interoperability of health IT. include reconciling laboratory tests and
addition to providers being able to values/results.
CDS Intervention Response
provide educational resources from Response. We have removed the
Documentation
other sources in case the most references to laboratory tests and
appropriate material deemed by the Comments. We received mixed values/results from the criterion. The
physician cannot be identified or is comments in response to the proposed commenter is correct in that the 2015
limited by the health IT. additional ‘‘recording user response’’ Edition ‘‘clinical information
Response. We thank commenters for functionality for this criterion. While reconciliation and incorporation’’
their support and have adopted the many commenters supported the overall criterion does not include reconciling
proposed Infobutton standard and goal of interaction checking for quality laboratory tests and values/results.
supporting IGs. We clarify for improvement and patient safety, many Therefore, this data would not
commenters that our certification commenters stated that current systems necessarily be available for CDS when a
approach only focuses on capabilities already provide a wide range of patient record is incorporated.
that must be certified to meet this functionality to enable providers to
criterion. A health IT developer’s document decisions concerning CDS Reordering of Provisions/Regulation
product could include other means for interventions. These commenters stated Text
identifying diagnostic or therapeutic that the proposed ‘‘recording user We have reordered the provisions of
reference information. Our approach response’’ is not necessary for the criterion/regulation text to better
actually reduces burden on health IT certification or for providers to satisfy align with testing procedures. We have
developers in that they do not have to objectives of the EHR Incentive moved the CDS intervention interaction
have any other means tested and Programs. provision to the beginning, followed by
certified. In regard to comments Response. We have not adopted the the CDS configuration, evidence-based
suggesting the certification of the ‘‘recording user response’’ functionality. decision support interventions, linked
connection to a reference resource and This approach is responsive to referential CDS, and source attributes.
diagnostic or therapeutic reference comments suggesting that this This reordering does not alter the
information obtained, these comments functionality is already included in requirements of the criterion in any
are beyond the scope of our proposal health IT and is unnecessary to support way.
and we have not adopted them. providers participating in the EHR
Incentive Programs. Further, by not 2014 Edition ‘‘Clinical Decision
Preferred Language Request for Support’’ Certification Criterion—
Comment adopting this functionality, health IT
developers will be able to focus more of Corrections
Comments. Commenters expressed their efforts on other adopted We received no comments on our
support for the capability to identify for functionality and requirements, proposal to revise the cross-reference in
a user diagnostic and therapeutic including those that support the § 170.314(a)(8)(iii)(B)(2) (CDS
reference information based on a interoperability of health IT. configuration) to more specifically
patient’s preferred language with the cross-reference the 2014 ‘‘transitions of
use of Infobutton. Commenters stated Clarifying ‘‘Automatically’’ and
care’’ (‘‘ToC’’) criterion
that this would support reducing racial ‘‘Triggered’’ Regulatory Text
(§ 170.314(b)(1)(iii)(B)). Accordingly, we
and ethnic health disparities by Comments. Commenters expressed have adopted this proposed revision.
improving literacy and addressing agreement with our proposal to not use • Drug-Formulary and Preferred Drug
language barriers. Some commenters the terms ‘‘automatically’’ and ‘‘trigger’’ List Checks
contended that including such as in the 2015 Edition CDS criterion and
requirement would increase burden for that CDS interventions should be 2015 Edition Health IT Certification Cri-
limited value because resources are limited by how they are deployed. terion
often not available in other languages Response. We thank commenters for § 170.315(a)(10) (Drug-formulary and pre-
with the exception of three or four of the their support. We have not included ferred drug list checks)
most commonly spoken languages. these terms in the certification criterion
Response. We appreciate the to clarify our intent to encompass all In the Proposed Rule, we proposed to
comments received in response to this types of CDS interventions without adopt a 2015 Edition ‘‘drug formulary
request for comment, including those being prescriptive on how the checks and preferred drug list’’
supporting the inclusion of preferred interventions are deployed. certification criterion that was split
language. We have, however, not based on drug formularies and preferred
included preferred language Clinical Decision Support drug lists. We proposed that a Health IT
functionality in this criterion. While Configuration—Laboratory Tests and Module must (1) automatically check
this functionality many support Values/Results whether a drug formulary exists for a
reducing health disparities, we believe Comments. We received a comment given patient and medication and (2)
that when weighing all proposed seeking clarification on the criterion’s receive and incorporate a formulary and
policies and the accumulated burden reference to laboratory tests and values/ benefit file according to the National
they present, this functionality would results for CDS configuration Council for Prescription Drug Programs
not provide as much impact in relation capabilities related to the incorporation (NCPDP) Formulary and Benefit
to other proposals such as the structured of a transition of care/referral summary. Standard v3.0 (‘‘v3.0’’). We proposed
recording of a patient’s preferred The commenter stated that we should that a Health IT Module must
language and specific race and ethnicity remove reference to laboratory tests and automatically check whether a preferred
information under the ‘‘demographics’’ values/results for CDS configuration in drug list exists for a given patient and
criterion. By not adopting this relation to the incorporation of a medication. For drug formularies and
preferred drug lists, we proposed that a time prescription benefit inquiry and is Health IT Module must record, change,
Health IT Module be capable of planning to make recommendations to and access smoking status to any of the
indicating the last update of a drug the NCPDP membership on the creation September 2014 Release of the U.S.
formulary or preferred drug list as part of a new transaction and/or standard or Edition of SNOMED CT® available
of certification to this criterion. We modification of existing transactions or codes for smoking status, at a minimum.
requested comment on more recent standards. We noted that a Health IT Module
versions of the NCPDP Formulary and Response. We appreciate the detailed certified to certification criteria that
Benefit Standard to support feedback commenters provided. We reference the Common Clinical Data Set
functionality for receiving and have determined that it is most (i.e., the ‘‘transitions of care’’ (‘‘ToC’’),
incorporating a formulary and benefit appropriate to not adopt a specific ‘‘data export’’ (previously ‘‘data
file and sought to understand associated standard for this criterion. We agree portability’’), ‘‘view, download, and
potential development burdens. In with commenters that the NCPDP transmit to 3rd party’’ (VDT),
addition, we sought comment on a Formulary and Benefit Standard v3.0 is ‘‘Consolidated CDA creation
standard for individual-level, real-time widely implemented today in support of performance,’’ and ‘‘application access
formulary benefit checking to address Medicare Part D requirements and that to the Common Clinical Data Set’’
the patient co-pay use case, whether we certification to this standard would add certification criteria) would need to be
should offer health IT certification to unnecessary burden to health IT able to code smoking status in only the
the standard for this use case, and if this developers and providers who are 8 smoking status codes,23 which may
functionality should be a separate already adhering to the standard. mean mapping other smoking status
criterion from the 2015 Edition ‘‘drug We believe that certification for codes to the 8 codes. We explained that
formulary and preferred drug list individual-level, real-time prescription we expect Health IT developers to work
checks’’ certification criterion. pricing information will provide the with health care providers to include
Comments. Commenters were most value to inform provider the appropriate implementation of
supportive of splitting the drug- prescribing decisions and discussions smoking status codes in a user interface.
formulary checks functionality from the between providers and patients on the Comments. Some commenters stated
preferred drug list functionality. A most appropriate medication options for that health IT should not be required to
number of commenters stated that the the patient. However, at this time, there support the full set of smoking status
NCPDP Formulary and Benefit Standard is no real-time patient-level standard codes within SNOMED CT® as it would
provides static, group-level formulary with consensus stakeholder support that cause unnecessary development burden
pricing information that does not would be appropriate for certification. and potential workflow issues for
indicate individual-level, real-time Based on the comments received, we providers. Multiple commenters also
prescription pricing information. A few strongly urge the industry to accelerate expressed concern with the proper
commenters stated that these static, its work on identifying the need to mapping all of the available smoking
group-level formularies are not useful create a new transaction and/or status codes within SNOMED CT® to
for informing discussions with patients standard or modify existing transactions the specified 8 SNOMED CT® smoking
about what medications to prescribe or standards for real-time prescription codes in the Common Clinical Data Set
because they do not provide information benefit inquiries. We intend to continue and used for exchange of patient health
about the patient’s co-pay for a our participation in this area and will information. We also received
particular drug. Many commenters also consider proposing certification comments requesting the inclusion of
suggested that it was not necessary for functionalities for real-time prescription other substances and routes of
ONC to offer certification to this benefit inquiries in future rulemaking. administration, including the use of
functionality because most health IT With consideration of comments chewing tobacco.
systems already support NCPDP’s supporting our proposed split of Response. We have adopted a
Formulary and Benefit Standard v3.0 functionality between drug formularies ‘‘smoking status’’ certification criterion
due to the Medicare Part D e-prescribing and preferred drug lists, we have that does not reference a standard. As
requirements under the Medicare adopted a 2015 Edition ‘‘drug-formulary stated in the Proposed Rule (80 FR
Prescription Drug, Improvement, and and preferred drug list checks’’ criterion 16870), the capture of a patient’s
Modernization Act of 2003 (MMA). that simply separates drug formulary smoking status has significant value in
Some of these commenters even and preferred drug list functionality, but assisting providers with addressing the
indicated that they test and certify does not require any standards or number one cause of preventable death
through Surescripts’ certification functionality beyond that included in and disease in the United States. We
program to the standard. In terms of a the 2014 Edition ‘‘drug-formulary have also included this criterion in the
version of the NCPDP Formulary and checks’’ criterion. As such, this Base EHR definition so that this
Benefit Standard, stakeholders preferred certification criterion is eligible for gap functionality is available to all providers
ONC adopt v3.0 rather than any certification. participating in the EHR Incentive
subsequent version to align with the • Smoking Status Programs. In consideration of the
Medicare Part D requirements. concerns expressed by commenters
Commenters also contended that the 2015 Edition Health IT Certification Cri- regarding development burden and the
industry has widely adopted v3.0 and terion proper mapping of all available smoking
that newer versions are less stable. § 170.315(a)(11) (Smoking status) status codes within SNOMED CT® to
Many commenters stated that there is the specified 8 SNOMED CT® for
not an industry-wide accepted standard We proposed to adopt a 2015 Edition
for real-time individual patient-level ‘‘smoking status’’ certification criterion 23 These 8 codes are: current every day smoker,
formulary checking, but recommended that was revised in comparison to the 449868002; current some day smoker,
ONC adopt certification to a standard 2014 Edition ‘‘smoking status’’ criterion 428041000124106; former smoker, 8517006; never
once the industry moves to an agreed- (§ 170.314(a)(11)) and to include the smoker, 266919005; smoker—current status
unknown, 77176002; unknown if ever smoked,
upon standard. A few commenters 2015 Edition certification criterion in 266927001; heavy tobacco smoker,
noted that an NCPDP task group is the 2015 Edition Base EHR definition. 428071000124103; and light tobacco smoker,
analyzing use cases to support a real- To be certified, we proposed that a 428061000124105.
exchange, we believe that the best path Entry. Another commenter suggested 2015 Edition Health IT Certification Cri-
forward is the adoption of a ‘‘smoking that the FHH be stored in a question/ terion
status’’ criterion that would simply answer format (LOINC® for ‘‘questions’’ § 170.315(a)(13) (Patient-specific education
require a Health IT Module to (observations) and SNOMED CT® for resources)
demonstrate that it can enable a user to ‘‘answers’’ (observation values)), which
record, change, and access a patient’s would also better support electronic In the Proposed Rule, we proposed to
smoking status. In regard to comments exchange of the information. Some adopt a 2015 Edition ‘‘patient-specific
suggesting the inclusion of other commenters suggested that if this education resources’’ certification
substances and routes of administration, criterion was adopted as proposed that criterion that was revised in comparison
these comments are beyond the scope of health IT developers should have the to the 2014 Edition ‘‘patient-specific
our proposal and we have not adopted ability to attest that their Health IT education resources’’ certification
them. In sum, this certification criterion previously certified to the 2014 Edition criterion (§ 170.314(a)(15)). We
is ‘‘unchanged’’ as compared to the 2014 FHH criterion meets the newer baseline proposed that certification would only
Edition ‘‘smoking status’’ criterion and version of SNOMED CT® for the focus on the use of Infobutton for this
is eligible for gap certification. purposes of testing and certification to certification criterion instead of
As discussed in more detail under this criterion. Infobutton and any means other than
section III.B.3 of this preamble, we have Response. We have adopted this Infobutton as required by the 2014
adopted the 8 specified SNOMED CT® certification criterion as proposed, Edition criterion. We stated that there is
smoking codes as part of the Common except that we have adopted a newer diminished value in continuing to frame
Clinical Data Set (and for purposes of baseline version SNOMED CT® the 2015 Edition certification criterion
exchange). This is a continuation of our (September 2015 Release of the U.S. similarly to the 2014 Edition criterion.
approach first adopted with the 2014 We proposed to adopt the updated
Edition) for the purposes of
Edition. Infobutton standard (Release 2 and the
certification. We refer readers to section
• Family Health History III.A.2.c (‘‘Minimum Standards’’ Code
associated updated IGs (SOA-based IG
and URL-based IG)). We also noted that
Sets) for a more detailed discussion of
2015 Edition Health IT Certification Cri- we would not include a requirement
our adoption of the September 2015
terion that health IT be capable of
§ 170.315(a)(12) (Family health history) Release of the U.S. Edition of SNOMED
electronically identifying patient-
CT®. While not supporting a specific
specific education resources based on
We proposed to adopt a 2015 Edition meaningful use objective of Stage 3 of
‘‘laboratory values/results’’ because the
‘‘family health history’’ (FHH) the EHR Incentive Programs, this
Infobutton standard cannot fully
certification criterion that was revised functionality is included in the CEHRT support this level of data specificity.
in comparison to the 2014 Edition FHH definition. Furthermore, we believe that We proposed that a Health IT Module
certification criterion adopted at the FHH functionality is a functionality be able to request patient-specific
§ 170.314(a)(13). In particular, we that should be available to providers for education resources based on a patient’s
proposed to require a Health IT Module more comprehensive patient care. preferred language as this would assist
to enable a user to record, change, and We note that our intent is not to limit providers in addressing and mitigating
access a patient’s FHH electronically the use of LOINC® for associated FHH certain health disparities. More
according to, at a minimum, the ‘‘questions’’ or the specific SNOMED specifically, we proposed that a Health
concepts or expressions for familial CT® code that is used to label FHH. IT Module must be able to request that
conditions included in the September Rather, the intent is to capture this patient-specific education resources be
2014 Release of the U.S. Edition of information in SNOMED CT® instead of identified (using Infobutton) in
SNOMED CT®, which would be a newer billing terminologies like ICD–10–CM. accordance with RFC 5646. We noted
baseline version of SNOMED CT® than We also do not intend to prohibit the that Infobutton only supports a value set
adopted for the 2014 Edition FHH exchange of this information using the of ISO 639–1 for preferred language and,
criterion. The proposed rule’s section C–CDA 2.1. As we have noted in this therefore, stated that testing and
III.A.2.d (‘‘Minimum Standards’’ Code and prior rulemakings, certification certification of preferred language for
Sets) discussed our adoption of serves as a baseline. This baseline can this certification criterion would not go
SNOMED CT® as a minimum standards be built upon through future regulation beyond the value set of ISO 639–1. We
code set and the adoption of the or simply through a decision by a health further noted testing and certification
September 2014 Release (U.S. Edition), IT developer and/or its customer to would focus only on the ability of a
or potentially a newer version if include functionality that goes beyond Health IT Module to make a request
released before a this final rule, as the the baseline. As present, we have set the using a preferred language and
baseline for certification to the 2015 certification baseline for FHH Infobutton because the language of
Edition. information at recording it in SNOMED patient education resources returned
Comments. Commenters generally CT®. through Infobutton is dependent on
supported this certification criterion. We agree with commenters that what the source can support.
Some commenters suggested not efficient testing and certification Comments. Multiple commenters
adopting this criterion because it does processes should be available to Health supported the inclusion of the updated
not support a specific meaningful use IT Modules previously certified to the Infobutton standard and supporting IGs.
objective of the proposed EHR Incentive 2014 Edition FHH criterion for A few commenters expressed concern
Programs Stage 3. A couple of certification to this criterion. about limiting certification to only
commenters suggested the recording of Accordingly, we will consider such Infobutton and suggested there are other
FHH is more valuable when it is options, such as attestation, in viable options for requesting patient-
actually exchanged, with one developing the test procedure for this specific education resources. A
commenter recommending that we criterion and in issuing guidance to the commenter requested clarification as to
require FFH data be sent using the C– ONC–AA and ONC–ACBs. whether providers must only use
CDA FHH Section with Entries or, • Patient-Specific Education certified health IT for requesting
minimally, the C–CDA FHH Organizer Resources patient-specific education resources for
the purposes of participating in the EHR 2015 Edition Health IT Certification Cri- acute for implantable devices, which by
Incentive Programs. terion their nature are difficult to detect and
Response. We thank commenters for § 170.315(a)(14) (Implantable device list) identify in the absence of reliable
their support and have adopted the clinical documentation.
proposed Infobutton standard and In the Proposed Rule, we proposed to We acknowledged in the Proposed
supporting IGs. We continue to believe adopt a new 2015 Edition certification Rule that fully implementing UDIs in
that the Infobutton capability is criterion focused on the ability of health health IT will take time and require
important to be available to providers to IT to exchange, record, and allow a user addressing a number of challenges.
have and use to identify patient-specific to access a list of Unique Device Nevertheless, we noted that substantial
education resources. We clarify for Identifiers (UDIs) 24 associated with a progress has been made. In particular,
commenters that our certification patient’s implantable devices. Health IT we summarized the FDA’s regulatory
approach only focuses on capabilities certified to the proposed criterion activities and timeline for implementing
that must be certified to meet this would be able to ‘‘parse’’ a UDI into its the Unique Device Identification System
criterion. A health IT developer’s constituent components (or and extensive work by public and
product could include other means for ‘‘identifiers’’) and make those accessible private sector stakeholders to advance
requesting patient-specific education to the user. Separately, the health IT standards and specifications in support
resources. Our approach actually would be able to retrieve and provide a of UDI use cases. On the basis of these
reduces burden on health IT developers user with access to, if available, the developments and our own ongoing
in that they do not have to have any optional ‘‘Device Description’’ attribute consideration of these and other
other means tested and certified. For associated with a UDI in the FDA’s issues,26 we recognized that while ‘‘the
questions related to the EHR Incentive Global Unique Device Identification path to full implementation is complex,
Programs, we refer readers to CMS and Database (GUDID). Further, to facilitate there are relatively straightforward
the EHR Incentive Programs Stage 3 and the exchange of UDIs and increase their steps’’ that we could take now to
Modifications final rule published availability and reliability in certified support the electronic exchange and use
elsewhere in this issue of the Federal health IT, we proposed to include the of UDIs, beginning with UDIs for
Register. proposed 2015 Edition implantable implantable devices. Our proposed
Comments. We received a few device list certification criterion in the certification criterion focused narrowly
comments supporting our approach for 2015 Edition Base EHR definition and to on implementing these first steps.
‘‘laboratory values/results.’’ include a patient’s UDIs as data within In light of the foregoing and with the
the CCDS definition for certification to revisions discussed below in our
Response. We have not included
the 2015 Edition. We also proposed to analysis of the comments on this
‘‘laboratory values/results’’ as patient
modify § 170.102 to include new proposal, we have finalized a 2015
data that must be used to identify
definitions for ‘‘Device Identifier,’’ Edition ‘‘implantable device list’’
patient-specific education resources.
‘‘Implantable Device,’’ ‘‘Global Unique certification criterion. We have also
Comments. Commenters expressed
Device Identification Database finalized our proposals to include this
strong support for the capability to
(GUDID),’’ ‘‘Production Identifier,’’ and certification criterion in the 2015 Base
request patient-specific education
‘‘Unique Device Identifier.’’ EHR definition and to include a
materials based on a patient’s preferred We explained that the purpose of the patient’s UDIs as data within the 2015
language with the use of Infobutton. proposed implantable device list Common Clinical Data Set definition.
Commenters stated that this would certification criterion was to enable the Discussion of those proposals can be
support reducing racial and ethnic baseline functionality necessary to found elsewhere in this final rule.
health disparities by improving literacy support the exchange and use of UDIs Comments. Most commenters agreed
and addressing language barriers. in certified health IT. The need to with the central premise of our
Commenters also expressed a need for exchange and have access to this proposal, that enabling the exchange
materials to be tested and vetted to information wherever patients seek care and use of UDIs in certified health IT is
ensure the accuracy and appropriate is broadly relevant to all clinical users a key initial step towards realizing the
literacy level of the materials. Some of health IT, regardless of setting or substantial patient safety, public health,
commenters contended that this specialty, so that they may know what and other benefits of UDIs and the
requirement would increase burden for devices their patients are using (or have Unique Device Identification System.
limited value because educational used) and thereby prevent device- Many commenters strongly supported
resources are often not available in other related adverse events and deliver safe the proposed criterion, including its
languages with the exception of three or and effective care.25 This need is most focus on implantable devices.
four of the most commonly spoken Commenters stated that the ability to
languages. 24 A UDI is a unique numeric or alphanumeric
exchange and access identifying
Response. We thank commenters for code that consists of two parts: (1) A device
information about patients’ implantable
their support and feedback. With identifier (DI), a mandatory, fixed portion of a UDI
that identifies the labeler and the specific version devices wherever patients seek care
consideration of the mixed feedback, we or model of a device, and (2) a production identifier would enable clinicians to prevent
have determined to designate the use of (PI), a conditional, variable portion of a UDI that
device-related medical errors and
preferred language as an optional identifies one or more of the following when
included on the label of a device: The lot or batch improve the quality of care provided to
provision within this criterion. As number within which a device was manufactured; patients. Commenters also stated that
optional, health IT developers have the serial number of a specific device; the the need to access accurate information
flexibility to pursue certification if they expiration date of a specific device; the date a
deem it advantages. With our new open specific device was manufactured; the distinct
identification code required by 21 CFR 1271.290(c) important benefits, including better surveillance
data CHPL (see section IV.D.3 of this for a human cell, tissue, or cellular and tissue-based and evaluation of device performance and more
preamble), information on whether a product (HCT/P) regulated as a device. 21 CFR effective preventative and corrective action in
Health IT Module was certified to this 801.3. See also http://www.fda.gov/MedicalDevices/ response to device recalls.
DeviceRegulationandGuidance/ 26 As further context for our proposal, we
functionality would be readily available UniqueDeviceIdentification/. described our previous consideration of these and
for consumers. 25 In addition, as UDIs become ubiquitous, UDI other issues related to UDI adoption in a previous
• Implantable Device List capabilities in health IT will support other rulemaking. 79 FR 10894.
about patients’ implantable devices is Some commenters also stated that if we systems used to capture UDIs for
broadly applicable to primary care did not require—or at least provide the implantable devices. Moreover,
physicians, specialists, and other option for—AIDC, users may be forced prescribing specific AIDC requirements
providers to support care coordination to manually enter UDIs. They stated that for certified health IT may also be
and ensure that providers have a this could discourage them from unnecessary. Given the obvious
complete medical history of their capturing UDIs, which could lead to convenience, accuracy, and other
patients. incomplete or inaccurate information advantages of AIDC, we anticipate that
Many commenters supported the about patients’ implantable devices. users of certified health IT designed for
proposed criterion in full and Separate from AIDC, several surgical settings will expect developers
recommended that we finalize it commenters suggested that we adopt to include AIDC capabilities as a
without any substantial revision. A other UDI-related capabilities, such as necessary complement to the baseline
significant number of commenters also the ability to generate lists of patients implantable device list functionality
urged to expand the scope of this with a particular device; to generate required by this criterion. Allowing
criterion to include additional UDI- notifications to patients in the event of developers and their customers to
related capabilities. In contrast, a a device recall; and to record and track design and implement the most
significant number of commenters information about non-implantable appropriate AIDC solutions for their
stated that we should not finalize this devices and medical and surgical individual needs is consistent with
criterion or should make all or part of supplies that are not regulated as a FDA’s policy of permitting flexibility in
it an optional certification criterion for device. the use of these technologies and avoids
the 2015 Edition. Commenters also Response. We have not adopted any imposing unnecessary requirements and
offered a variety of suggested revisions AIDC requirements for UDIs as part of costs on developers, providers, and our
and refinements with respect to the this final rule. While we unequivocally testing and certification bodies.
capabilities we proposed. agree with commenters that UDIs Contrary to the suggestions of some
Response. We have adopted this should be captured using AIDC and commenters, our decision not to adopt
certification criterion substantially as should rarely if ever be manually a particular AIDC requirement for
proposed, subject to certain revisions entered; and while for this reason we implantable devices does not mean that
and clarifications discussed further strongly urge health IT developers and users of certified health IT systems will
below in response to the comments we heath care organizations to implement be forced to manually record UDIs.
received. We thank commenters for AIDC capabilities in all settings and Again, for the reasons we have stated,
their detailed and thoughtful feedback systems in which UDIs may be this criterion has no bearing on how
on our proposal. We reiterate that this captured; yet for the reasons elaborated UDIs are entered or captured in
certification criterion represents a first below, we believe at this time that upstream IT systems during a procedure
step towards enabling the widespread certification is neither an effective nor or operation. It is tailored solely to
exchange and use of UDIs and related appropriate means to further these bringing and providing capabilities for
capabilities in certified health IT, policies. As we explained in the UDIs to downstream EHR and health IT
beginning with implantable devices. Proposed Rule, this criterion is not systems used in physicians’ offices,
Because we recognize that fully intended to provide the capability to hospitals, and other places where
implementing UDIs in health IT will enter or ‘‘capture’’ UDIs for implantable patients with implantable devices seek
take time and require addressing a device, such as during the course of a care.
number of challenges, the certification procedure. The reason for this is that the Similarly, at this time we believe that
criterion focuses narrowly on baseline capture of UDIs currently occurs in a it would be premature to include other
health IT capabilities that developers wide variety of ‘‘upstream’’ IT systems capabilities suggested by commenters.
can feasibly implement today. These and settings that are beyond the scope Some of those capabilities—such as the
capabilities will provide the foundation of the current ONC Health IT ability to record information about non-
for broader adoption and more Certification Program. Rather than implantable devices—are beyond the
advanced capabilities and use cases. We ineffectually trying to address these scope of the proposal. For other
believe that this approach minimizes ‘‘upstream’’ use cases, we have chosen capabilities, greater adoption and use of
the potential burden while maximizing to focus this certification criterion on UDIs in certified health IT is needed
the impact of this criterion for all the baseline functionality necessary to before the capabilities will be useful to
stakeholders. ensure that, once recorded in a patient’s most health IT users. For example, we
Comments. A significant number of electronic health record, UDIs can be recognize that being able to generate a
commenters who supported our exchanged among ‘‘downstream’’ health list of patients with a particular device
proposed implantable device list IT systems (the overwhelming majority will be necessary to respond to device
certification criterion also of which we do certify) and accessed by recalls and analyze device performance
recommended that we adopt additional clinicians wherever patients seek care. and other characteristics. But those
UDI-related capabilities, either as part of Some commenters understood our benefits cannot materialize until UDIs
this criterion (which we proposed to rationale for not requiring AIDC are more broadly and more readily
reference in the 2015 Edition Base EHR capabilities for all certified health IT accessible through interoperable health
definition) or as a separate, optional and instead recommended we adopt a IT and health information exchange.
certification criterion. Many separate optional AIDC certification Likewise, achieving these benefits will
commenters urged us to include criterion that could be leveraged by first require implementing other
requirements for Automatic certified health IT designed for baseline functionality included in this
Identification and Data Capture (AIDC) operating rooms and other surgical criterion, such as the ability to retrieve
of UDIs. Commenters stated that such a settings in which devices are implanted key device attributes from the GUDID.
requirement would facilitate the or removed. While we appreciate the We think that focusing the requirements
accurate and efficient capture of UDIs suggestion, such a certification criterion of this criterion—and thus the efforts of
and align this criterion with the UDI would be applicable to only a small developers and users of certified health
final rule, which requires UDIs to subset of certified health IT, which in IT—on these essential baseline
support one or more forms of AIDC. turn represents only a small subset of IT functionalities is the quickest path to
the adoption of UDIs in health IT and CFR 801.3. Because these identifiers are require health IT to be able to parse
thus to creating demand and part of the UDI, health IT should be able UDIs issued by FDA-accredited issuing
opportunities for the more advanced to parse these identifiers from the UDI agencies. There are currently three FDA-
capabilities commenters envision. using the issuing agency’s accredited issuing agencies (GS1,
Comments. Some commenters specifications. There is no need to query HIBCC, and ICCBBA) 27 and each
requested clarification as to what an external database or source, such as issuing agency has only one approved
constitutes an ‘‘implantable device’’ for the GUDID. UDI format. All three formats are unique
purposes of this certification criterion. Second, we also used the same term, and can thus be readily distinguished by
Response. We have adopted new ‘‘data element,’’ to refer to certain health IT and parsed according to the
definitions in § 172.102 for information not included in the UDI correct format. The formats themselves
‘‘Implantable Device’’ and several other itself but that is associated with the UDI are described in detail in a single five-
terms by cross-referencing the and can be retrieved using the GUDID. page reference document available on
definitions for those terms already Specifically, we proposed that health IT the FDA Web site.28 Each format has
provided at 21 CFR 801.3. We believe be able to retrieve and make accessible been approved by the FDA, and no
adopting these definitions in our final the optional ‘‘Device Description’’ changes can be made unless the FDA
rule will prevent any interpretative attribute associated with the Device similarly approves of the changes prior
ambiguity and ensure that each phrase’s Identifier portion of the UDI (assuming to implementation.
specific meaning reflects the same the attribute has been populated in the We disagree that the requirement to
meaning given to it in the Unique GUDID). parse a UDI should be postponed until
Device Identification System final rule. To distinguish these separate the emergence of a single canonical UDI
For further discussion of these new concepts and for consistency with the format. It is unclear at this time when
definitions, we refer readers to section UDI final rule, this preamble and the or if such a canonical format will be
III.B.4 of this preamble. corresponding regulation at developed and whether it would
Comment. A commenter § 170.315(a)(14) use the terms support the functionality we are
recommended that we use the term ‘‘identifier’’ and ‘‘attribute’’ to refer to requiring. It is also unclear whether
‘‘identifier’’ instead of the term ‘‘data the two distinct types of information implementing a canonical format would
element’’ to refer to the following described above. reduce or increase the overall technical
identifying information that composes Comments. Many commenters,
complexity and burden of implementing
the Production Identifier portion of a including some health IT developers,
these capabilities for multiple UDI
UDI: supported the requirement to parse a
formats. Meanwhile, postponing these
• The lot or batch within which a UDI and allow a user to access the
capabilities would frustrate the purpose
device was manufactured; identifiers that compose the UDI. Other
of this certification criterion. Without
• the serial number of a specific commenters stated that requiring this
the ability to parse a UDI, health IT
device; functionality would be burdensome
would be unable to provide users with
• the expiration date of a specific because UDIs may be issued by different
issuing agencies and in different useful information identifying and
device;
safety-related information about a
• the date a specific device was formats. Some commenters suggested
we withdraw this proposed requirement device, such as the device’s expiration
manufactured; and
• for an HCT/P regulated as a device, until a canonical format is established to date (which will be parsed from the
the distinct identification code required harmonize and streamline the process of Production Identifier) or a description of
by 21 CFR 1271.290(c). parsing UDIs issued by different FDA- the device (which will be retrieved by
To avoid confusion and align our accredited issuing agencies and in parsing and looking up the Device
terminology with the UDI final rule, the different formats. Identifier in the GUDID).
commenter recommended we refer to A number of commenters pointed out The omission of ‘‘Distinct
these ‘‘data elements’’ as ‘‘identifiers’’ or that we had omitted from this Identification Code required by 21 CFR
‘‘production identifiers.’’ requirement the Distinct Identification 1271.290(c)’’ among the identifiers that
Response. We agree that our use of the Code required by 21 CFR 1271.290(c), health IT must be able to parse was an
term ‘‘data elements’’ was imprecise and which is one of the five identifiers that oversight, and we thank commenters for
could lead to unnecessary confusion. make up the Production Identifier and bringing it to our attention. We agree
Accordingly, we have revised our applies to human cells, tissues, or that to avoid misalignment with the UDI
terminology as follows to align more cellular and tissue-based products final rule, health IT should be required
closely with the UDI final rule. (HCT/P) regulated as a device, including to parse this identifier and make it
In our proposal, we used the term certain kinds of implantable devices accessible in the same manner required
‘‘data elements’’ to describe two distinct (e.g., skin grafts and bone matrixes). To for the other identifiers that compose
types of information associated with ensure the exchange of UDIs for all the Production Identifier, as referenced
UDIs. First, we said that a Health IT implantable devices and to avoid in the Proposed Rule. We therefore
Module certified to our proposed misalignment with the UDI final rule, 27 http://www.fda.gov/MedicalDevices/Device
criterion would have to be able to parse we were urged to include the Distinct RegulationandGuidance/UniqueDevice
certain ‘‘data elements from a UDI’’ and Identification Code among the Identification/UDIIssuingAgencies/default.htm.
make these accessible to a user. 80 FR identifiers that technology must be able 28 FDA, UDI Formats by FDA-Accredited Issuing
16825. In that context, we were referring to parse and make accessible to a user Agency (May 7, 2014), http://www.fda.gov/
to what the UDI final rule describes as under this criterion. downloads/MedicalDevices/DeviceRegulationand
Guidance/UniqueDeviceIdentification/GlobalUDI
the ‘‘production identifiers that appear Response. The requirement to parse a DatabaseGUDID/UCM396595.doc. The reference
on the label of the device.’’ 21 CFR UDI is reasonable despite the existence document is one of two technical documents made
830.310(b)(1). These are the identifiers of multiple issuing agencies and available by the FDA to assist labelers and other
listed above that compose and are formats. We disagree that this persons to comply with the GUDID Guidance. See
http://www.fda.gov/MedicalDevices/Device
required to be included in the requirement is burdensome and note RegulationandGuidance/UniqueDevice
Production Identifier when required to that it was supported by several health Identification/GlobalUDIDatabaseGUDID/
be included on the label of a device. 21 IT developers. This criterion would ucm416106.htm.
include it with those identifiers at As commenters acknowledged, clinicians by displaying the familiar
§ 170.315(a)(14)(ii). For similar including many who objected to this name of each device in the list next to
alignment and consistency, we also requirement, the availability of the device’s UDI. Based on the
include the Production Identifier itself dedicated web services for retrieving the comments, we accept that the ‘‘GMDN
in the list of identifiers at attributes associated with a UDI from PT Name’’ attribute is more suitable for
§ 170.315(a)(14)(ii). the GUDID will significantly streamline our purposes because it is a recognized
Comments. Several commenters and reduce the costs of including this international standard for medical
objected to the proposed requirement functionality in certified health IT. We devices and, unlike the ‘‘Device
that health IT be able to query a UDI take the commenters at their word and Description’’ attribute, is required and
against the GUDID and retrieve the believe that the availability of these therefore much more likely to in fact be
associated ‘‘Device Description’’ dedicated web services—which will be populated in the GUDID. We are
attribute (when that attribute has been specifically designed for health IT therefore revising § 170.315(a)(14)(iii) to
populated and is available). Some developers and aligned with this require the ‘‘GMDN PT Name’’ attribute
commenters stated that it was certification criterion—will instead of ‘‘Device Description.’’
unreasonable to expect developers to substantially mitigate the concerns Relatedly, we have also revised
implement GUDID capabilities before all raised by developers and other § 170.315(a)(14)(iii) to permit health IT
of the planned GUDID functionality is commenters regarding the potential developers who meet this requirement
available. At the time of the Proposed burden or technical challenges of using the GUDID web services to do so
Rule, the GUDID was available as a implementing GUDID functionality. in either of two ways. They may either
downloadable file, which was and Comments. Several commenters were retrieve the ‘‘GMDN PT Name’’ attribute
continues to be updated daily. A web puzzled by our proposal to require or, alternatively, the ‘‘SNOMED CT®
interface and web services were also retrieval only of the ‘‘Device Description’’ associated with a UDI.
planned but had not yet been Description’’ attribute. They pointed out Pursuant to a cooperative agreement
implemented. Although we explained that submission of this attribute to the between the relevant standards
that the daily downloadable version of GUDID is optional and is not developing organizations, the SNOMED
GUDID could be used to satisfy the standardized. The proposed CT® code set is being mapped to GMDN
proposed criterion, some commenters requirement would therefore be unlikely PT and thus the description of a device
insisted that we should not require any to serve our goal of providing clinicians will be identical under both
GUDID retrieval capabilities until web and patients with accurate and terminologies. However, we expect that
services are in place to enable GUDID accessible information about many developers will prefer to use the
attributes to be easily retrieved ‘‘on implantable devices. Some commenters SNOMED CT® code set because they
demand.’’ Several commenters suggested that the ‘‘Global Medical already do so and because they can
requested that we clarify FDA’s timeline Device Nomenclature (GMDN) PT retrieve the computable ‘‘SNOMED CT®
for implementing web services. Name’’ attribute would better suit our Identifier,’’ which will also be available
Response. FDA has partnered with the purpose and noted that this attribute, via the web services and will enable
National Library of Medicine (NLM) to unlike ‘‘Device Description,’’ is a developers to more easily deploy CDS
implement the GUDID. The GUDID is required attribute and a recognized and other functionality for implantable
now available via a web interface called international standard for medical devices. Thus allowing developers the
AccessGUDID.29 In addition, FDA has device nomenclature. flexibility to retrieve the ‘‘SNOMED CT®
Several commenters also urged us to
confirmed that web services will be Description’’ in lieu of the identical
require retrieval of additional GUDID
available via the AccessGUDID website mapped ‘‘GMDN PT Name’’ attribute
attributes. Several commenters noted
by October 31, 2015. These web services will avoid requiring them to support
that certain safety-related attributes—
are being implemented to support multiple and duplicative code sets for
specifically ‘‘What MRI safety
health IT developers to meet this medical devices and may also encourage
information does the labeling contain?’’
implantable device list certification them to incorporate more advanced
and ‘‘Device required to be labeled as
criterion. For any valid UDI, the web capabilities for implantable devices,
containing natural rubber latex or dry
services will return the following consistent with the goals of this
natural rubber (21 CFR 801.437)’’—are
GUDID attributes: required to be submitted to the GUDID, criterion.
• ‘‘GMDN PT Name’’; As discussed above, the GUDID web
are already available, and would
• ‘‘Brand Name’’; interface is now available via the NLM
significantly further the patient safety
• ‘‘Version or Model’’; AccessGUDID website, which will soon
aims outlined in our proposal. Along
• ‘‘Company Name’’; be augmented with dedicated web
the same lines, other commenters
• ‘‘What MRI safety information does services designed to support health IT
identified additional GUDID attributes
the labeling contain?’’; and certified to this criterion. With this
that would enable identification of the
• ‘‘Device required to be labeled as increased readiness of the GUDID,
manufacturer or labeler (i.e., company
containing natural rubber latex or dry health IT should be able to retrieve
name), brand, and specific version or
natural rubber (21 CFR 801.437).’’ additional GUDID attributes with little
model of a device.
In addition to these GUDID attributes, Response. We believed that retrieving additional effort. Therefore, we are also
and for the convenience of health IT the ‘‘Device Description’’ attribute including the following attributes
developers, the web services will also would be a good starting point for among those that must be retrieved and
return the ‘‘SNOMED CT® Identifier’’ GUDID functionality under this made accessible to users of health IT
and the ‘‘SNOMED CT® Description’’ criterion and would make the certified to this criterion:
mapped to the GMDN code set.30 implantable device list more useful to • ‘‘Brand Name’’;
29 See http://accessgudid.nlm.nih.gov/. A list of • ‘‘Version or Model’’;
the International Health Terminology Standards
APIs currently in development is available at Development Organization (IHTSDO), GMDN will • ‘‘Company Name’’;
http://accessgudid.nlm.nih.gov/docs.
30 Under a Cooperative Agreement between the
be used as the basis for the medical device
component of SNOMED CT®. See http://
• ‘‘What MRI safety information does
Global Medical Device Nomenclature Agency and www.ihtsdo.org/resource/resource/84. the labeling contain?’’; and
• ‘‘Device required to be labeled as AccessGUDID web services, which as change the status of a UDI but would
containing natural rubber latex or dry discussed above are being designed require that UDI itself not be deleted
natural rubber (21 CFR 801.437).’’ 31 specifically to support health IT and still be accessible to a user.
For the reasons that commenters developers to meet this implantable Specifically, health IT certified to this
identified, these particular attributes device list certification criterion. criterion must enable a user to change
will further the core goals of this Comments. Commenters the status of a UDI recorded for a patient
criterion by significantly enhancing the overwhelmingly supported our proposal to indicate that the UDI is inactive. We
ability of clinicians to identify and to require that health IT enable a user also expect that developers will
access important safety-related to change a UDI in a patient’s implement this functionality in a
information about their patients’ implantable device list and, in manner that allows users to indicate the
implantable devices. appropriate circumstances, ‘‘delete’’ reason that the UDI’s status was
Comment. A commenter noted that erroneous, duplicative, or outdated changed to inactive. Consistent with the
this criterion would require health IT to information about a patient’s policy that UDIs should not be deleted
retrieve UDI attributes exclusively from implantable devices. However, several from the implantable device list or from
the GUDID. The commenter commenters took issue with our use of a patient’s electronic health record, a
recommended we consult with FDA to the term ‘‘delete,’’ which could imply UDI that has been designated inactive
ensure that the GUDID will be able to that a user should be able to completely must still be accessible to the user so
support the potentially large volume of remove a UDI and associated that users can access information about
requests that could result from this information from a patient’s implantable the device, even if it was explanted or
requirement. device list and from the patient’s recorded in error. We expect that both
Response. As discussed above, FDA electronic health record altogether. the status and other appropriate
and NLM are implementing web Commenters stated that information metadata will be recorded in a manner
services specifically to support health IT about a patient’s implantable devices consistent with the C–CDA, where
developers to meet this implantable should be retained for historical applicable, and will be exchanged with
device list certification criterion. FDA accuracy and context. One commenter the UDI according to that standard.
has signed an interagency agreement noted that allowing users to delete this As noted above, the comments on this
with NLM to provide public access to information could violate record aspect of our proposal suggest the need
AccessGUDID, including web services. retention laws. Several commenters for greater precision regarding the
NLM has experience with large volume suggested that we clarify that a user concept of an ‘‘implantable device list.’’
requests and will be able to meet any should be able to ‘‘flag’’ or otherwise In this final rule, we use the term
demands generated by developers and annotate a UDI as no longer active while ‘‘implantable device list’’ to refer to the
users as a result of this criterion. still retaining the UDI and associated visible list that is displayed to the user
Comments. Some commenters noted information. of health IT certified to this criterion
that UDI attributes are not exclusive to The comments on this aspect of our and that must show, at a minimum: (1)
the GUDID and are commonly stored in proposal suggest some confusion A patient’s active UDIs, meaning all
providers’ enterprise resource planning surrounding the concept of an UDIs recorded for the patient that have
systems (ERPS), materials management ‘‘implantable device list’’ contemplated not been designated inactive; (2) the
information systems (MMIS), and other in the Proposed Rule. Different corresponding description of each UDI
‘‘systems of record.’’ Thus, instead of commenters used the term ‘‘implantable in the list (which, as discussed above,
requiring health IT to always retrieve device list’’ to refer to at least three may be either the GUDID attribute
the UDI attributes from the GUDID, it distinct constructs: (1) The list of UDIs ‘‘GMDN PT Name’’ or the ‘‘SNOMED
was suggested that we permit attributes that would be recorded and exchanged CT® Description’’ mapped to that
to be retrieved from these and other as structured data; (2) the presumably attribute); and (3) if one or more inactive
appropriate sources, thereby giving more detailed list of information about UDIs are not included in the list, a
providers and developers (who may a patient’s implantable devices that method of accessing those UDIs and
have different database and technical would subsist separately and locally in their associated information from within
infrastructures) the flexibility to select EHR systems; and (3) the list of UDIs the list. The implantable device list may
the most appropriate source of this and other information that would be but need not also include the identifiers
information. formatted and presented to users of an and attributes associated with each UDI
Response. As we stated in the EHR system. Some commenters that the health IT must be able to
Proposed Rule, the requirement to recognized this ambiguity and asked us retrieve and make accessible to a user.
retrieve attributes from the GUDID can to be more precise. But several If the implantable device list does not
be accomplished using the GUDID’s web commenters oscillated between these contain these identifiers and attributes,
interface, web services, downloadable different constructs and imputed them then the health IT would need to enable
module, or any other method of retrieval to different parts of our proposal, a user to access them (for example, by
permitted under FDA’s GUDID depending on the context. As a result, presenting them when a user clicks on
guidance. Thus GUDID attributes could some of these commenters perceived in an item in the implantable device list).
be retrieved from a local system, our proposal elements that had not been Similarly, the implantable device list
provided the information in that system proposed, such as the ability to enable may but need not include inactive UDIs,
is up to date and is based upon the data a user to manually record a UDI or to so long as these UDIs are accessible
downloaded from the GUDID. That said, exchange certain kinds of information from within the list. For example, the
about implantable devices. implantable device list could display
we encourage the use of the

Response. We appreciate commenters’ only active UDIs so long as it also
31 Current GUDID attributes are derived from the feedback on this aspect of our proposal. contained a link or other obvious way
UDI final rule and are specified in the FDA GUDID We agree that a user should not be able for a user to access all other UDIs
Data Elements Reference Table (May 1, 2015), to permanently ‘‘delete’’ UDIs recorded recorded for the patient.
http://www.fda.gov/downloads/MedicalDevices/
DeviceRegulationandGuidance/
for a patient. Therefore, we are adopting The discussion above should make
UniqueDeviceIdentification/ the approach suggested by most clear that we are using the term
GlobalUDIDatabaseGUDID/UCM396592.xls. commenters that would allow a user to ‘‘implantable device list’’ to refer to the
UDIs and other information that must be also expected that appropriate devices their patients have and use that
presented and made accessible to a user associated metadata, such as the date information to deliver safer and more
in the manner described above. This and site of the implant, will be included effective care. We take seriously the
information is distinct from the with the UDI where available as concerns raised by some commenters
information not visible to a user that specified in the standard.32 regarding the potential costs and
must be recorded and exchanged by Beyond these basic parameters, we burdens of the proposed criterion. We
health IT certified to this criterion. That believe it is premature to prescribe the have addressed those concerns above in
information is not an ‘‘implantable exact content and form of contextual our responses to comments on the
device list’’ but rather a list of UDIs information associated with UDIs. The specific aspects of our proposal to
recorded for a patient and the associated comments confirm our observation in which those concerns pertain. We note
metadata that must be recorded and the Proposed Rule that additional that for many of these aspects, health IT
exchanged in accordance with the standards and use cases will be needed developers often contradicted one
requirements of the CCDS definition, to support this functionality. another as to the relative costs and
the 2015 Base EHR definition, and the Comments. Some commenters difficulty of implementing the UDI-
C–CDA standard. We discuss this data insisted that the proposed criterion related capabilities we proposed. As just
separately below in response to lacked relevance to the majority of one illustration, several EHR developers
comments regarding the exchange of providers who do not practice in stated that the requirement that health
contextual information about a patient’s surgical or certain kinds of inpatient IT be able to parse a UDI was infeasible
implantable devices. To avoid any settings. For this reason, they suggested or would be unduly burdensome. In
ambiguity or misinterpretation, we have that we remove some or all of the contradistinction, a different EHR
structured § 170.315(a)(14) to more criterion from the 2015 Base EHR developer objected to other aspects of
precisely codify the concepts explained definition or from the final rule. the proposal but specifically endorsed
above. Some commenters who otherwise the capability to parse UDIs; and yet
Comments. In the Proposed Rule, we supported our proposal felt that we another EHR developer supported all of
stated that this certification criterion should not include this certification the capabilities we proposed. In short,
would not require health IT to be able criterion in the Base EHR or should health IT developers’ comments
to exchange or use contextual make some of the proposed regarding cost and burden often pointed
information about a device (such as a requirements optional in the 2015 in different directions, which suggests
procedure note). We requested comment Edition. Similarly, some commenters that many of their concerns are
on whether we had overlooked the need objected to the inclusion of a patient’s idiosyncratic to particular developers,
for or feasibility of requiring this Unique Device Identifiers in the CCDS not generalizable to all developers or the
functionality. Many of the comments we definition. Some of these commenters health IT industry. We submit that
received emphasized the importance of objected in principle to including any competition in the marketplace is the
recording and exchanging contextual requirements that are not correlated more appropriate vehicle for mediating
information about implantable devices. with a meaningful use objective or such differences, not our regulations.33
Some commenters expressed concerns measure, while others objected on the Because all providers should have
that exchanging UDIs without their basis that this certification criterion access to information about their
proper context could lead to would be unduly costly and patients’ implantable devices, we are
interoperability, patient safety, or other burdensome for developers and could including a patient’s Unique Device
implementation challenges. Some place significant and unnecessary Identifiers in the CCDS definition. To
commenters also urged us to specify burdens on providers. ensure that all certified health IT has the
precisely how contextual information Several commenters claimed that this basic ability to exchange, record, and
associated with an implantable device criterion was not ripe and there were a make this information available, we are
should be recorded and exchanged lack of available standards for certain including this certification criterion in
among health IT certified to this aspects of our proposal. Commenters the 2015 Base EHR definition. These
criterion. These commenters did not also cited potential implementation definitions are not limited to the EHR
identify any specific standards or challenges, especially the fact that UDIs Incentive Programs and must support
implementation specifications. Several and other information about other programs as well as the broader
other commenters explained that implantable devices are often captured needs of health IT users throughout the
current standards and implementation in IT systems that are not part of health care system. We refer
guides do not specify a consistent certified health IT. Because bridging commenters to our discussion of these
approach to documenting this these systems will be challenging definitions elsewhere in this final rule.
information. without more mature standards or We decline to postpone this criterion
Response. We recognize the customized interfaces, the information until the Unique Device Identification
importance of contextual information in these systems may not be recorded in System is fully implemented for all
about patients’ implantable devices. As certified health IT. devices and across the entire medical
described elsewhere in this rule, we Response. Again, we reiterate that this
have included the Unique Device device industry, or until additional
criterion is not aimed at surgical standards are fully developed and
Identifier in the CCDS definition with specialties, settings, or systems. It is
the intent of capturing and sharing UDIs harmonized for additional use cases.
aimed at delivering information to all While this work is ongoing, UDIs are
associated with implantable devices in clinicians so that they can know what
both internal EHR records as well as required to be available for all
exchangeable documents. We clarify implantable devices by September 2015.

32 The UDI for implantable devices is encoded
that, where the UDI is present and Similarly, standards already exist for
and exchanged in the Procedure Activity Procedure
represents an Implantable Device, the (V2) section of C–CDA, which contains a Product recording and exchanging UDIs for
UDI should be sent in accordance with Instance template that can accommodate the UDI
the implantable device, the implant date, and the 33 In this connection we refer readers to the
the C–CDA, which specifies its target site. Although not required by the standard, discussion of the new transparency and disclosure
inclusion in the Procedure Activity this information should be sent if available, as with requirements for health IT developers finalized
section of exchangeable documents. We all of the CCDS content. elsewhere in this rule.
implantable devices as structured data coded in accordance with, at a more complete view of health, including
in patients’ electronic health records. minimum, the September 2014 Release social supports and community
These standards have been refined since of the U.S. Edition of SNOMED CT® and resources.35 We believe the collection of
the last time we proposed to adopt a HL7 Version 3, as enumerated in tables the information in certified Health IT
certification criterion for implantable in the Proposed Rule. We sought Modules through this criterion can
devices. And, as noted above, the comment on inclusion of the better inform links to social supports
GUDID is now available via the NLM’s appropriate social, psychological, and and community resources.
AccessGUDID website and will support behavioral data measures, on In regard to comments expressing
web services for this certification standardized questions for collection of privacy and security concerns, we first
criterion. While full implementation of sexual orientation and gender identity note that the functionality in this
the Unique Device Identification System data, on a minimum number of data criterion is focused on capture and not
will take several years, and while the measures for certification, on combining privacy and security. Second, we have
development of standards is an ongoing and separating the measures in established a privacy and security
process, UDIs for implantable devices certification criteria, and on inclusion of certification framework for all Health IT
can begin to be incorporated in health additional data and available standards. Modules that are certified to the 2015
IT and will support and help accelerate Comments. Many commenters were in Edition (please see section IV.C.1 of this
these other efforts. support of our proposal to include a preamble). Third, we recommend that
Commenters concerns regarding new certification criterion for the institutions develop and maintain
potential ‘‘upstream’’ implementation capture of social, psychological, and policies for the collection and
challenges are valid, but we have behavioral data. Commenters dissemination of this data that is
addressed those concerns by focusing recommended that we consider consistent with applicable federal and
this certification criterion only on the including security and privacy state laws.
baseline functionality necessary to safeguards for this information and We appreciate comments on
ensure that, once recorded in a patient’s additional measures relevant to other additional data to consider for inclusion
electronic health record, UDIs can be settings (e.g., oral health measures, in this criterion. We have, however,
exchanged among certified health IT behavioral health diagnosis history, determined that the proposed list
and accessed by users of certified health expansion of violence measures, and presents an appropriate first step for the
IT wherever the patient seeks care. expansion of measure applicability to standardized collection of social,
• Social, Psychological, and parents of pediatric patients). behavioral, and psychological data. We
Behavioral Data Commenters also recommended that we note, based on feedback from
verify proposed LOINC® codes that commenters, we have included the
2015 Edition Health IT Certification Cri- were listed as pending in the Proposed capture of sexual orientation and gender
terion Rule. identity (SO/GI) data in the 2015
§ 170.315(a)(15) (Social, psychological, and Some commenters were against Edition ‘‘demographics’’ certification
behavioral data) certification for this data. These criterion. We will continue to consider
commenters cited lack of uses cases for whether this list should be expanded
We proposed to adopt a new 2015 the data, overburdening providers with through future rulemaking.
Edition ‘‘social, psychological, and data collection, and lack of maturity of We have verified the LOINC® codes
behavioral data’’ certification criterion data standards. A few commenters were that were proposed and obtained the
that would require a Health IT Module not supportive of additional codes for those listed as pending in the
to be capable of enabling a user to certification for criteria that are not Proposed Rule, and have provided the
record, change, and access a patient’s proposed to specifically support Stage 3 proper codes and answer list IDs for all
social, psychological, and behavioral of the EHR Incentive Programs. eight domains we are adopting in this
data based on SNOMED CT® and Response. We thank commenters for criterion (please refer to § 170.207(p))
LOINC® codes, including sexual their feedback. We have adopted a 2015 for the full list of LOINC® codes).
orientation and gender identity and the Edition ‘‘social, psychological, and Comments. There were mixed
ability to record a patient’s decision not behavioral data’’ certification criterion comments on whether we should adopt
to provide information. As the Proposed that is described in more detail below. all proposed domains in one criterion or
Rule explained, the proposed As stated in Proposed Rule (80 FR adopt a separate criterion for each
certification criterion is designed to 16826), we continue to believe that proposed domain. We also received
advance the collection and use of such offering certification to enable a user to mixed feedback on whether certification
patient data, to transform health record, change, and access a patient’s would be to all domains, a select
delivery, to reduce health disparities, social, psychological, and behavioral number, or at least one. Commenters in
and to achieve the overarching goals of data will assist a wide array of favor of one criterion with all domains
the National Quality Strategy. We stakeholders in better understanding stated that the proposed domains are
proposed that social, psychological, and how this data may adversely affect interrelated and together provide a total
behavioral data be coded in accordance health and ultimately lead to better health system perspective that can
with, at a minimum, version 2.50 of outcomes for patients. We also believe facilitate care management and
LOINC®, and we explained that LOINC® that this data has use cases beyond the coordination.
codes will be established in a newer EHR Incentive Programs, including Response. We thank commenters and
version of LOINC® for the question- supporting the Precision Medicine agree that these eight domains can
answer sets that do not currently have Initiative 34 and delivery system reform.
together provide a more comprehensive

a LOINC® code in place, prior to the In addition, the Federal Health IT picture of the patient that can facilitate
publication of the final rule. We Strategic Plan aims to enhance routine care management and coordination. We
proposed that sexual orientation be medical care through the incorporation also believe that there will not be a
coded in accordance with, at a of more information into the health care significant increase in development
minimum, the September 2014 Release process for care coordination and a
of the U.S. Edition of SNOMED CT® and 35 http://www.healthit.gov/sites/default/files/9-5-
HL7 Version 3 that gender identity be 34 http://www.nih.gov/precisionmedicine/. federalhealthitstratplanfinal_0.pdf.
burden to meet all the proposed exchange of structured data between compatibility with Release 1.1 while
domains because there will be providers across disparate settings than maintaining many of the improvements
developmental synergies in meeting all previous versions. Commenters did not and new templates in Release 2.0. While
domains using the required LOINC® support requiring that Health IT we thank commenters for the alternate
code set. Accordingly, we have adopted Modules presented for certification suggested pathway regarding 2014
one criterion that requires certification would need to demonstrate its Edition certified health IT, this would
to all eight proposed domains (not conformance and capability to send, require a revision to the existing 2014
including SO/GI). receive, and parse both versions Release Edition ‘‘ToC’’ certification criteria
• Transitions of Care 1.1 and 2.0 of the C–CDA standards. (§ 170.314(b)(1), § 170.314(b)(2), and
Commenters stated that this proposed § 170.314(b)(8)) that would require
2015 Edition Health IT Certification Cri- requirement would be too resource technology to be able to display a
terion intensive, expressed concerns about the C–CDA document conformant with
§ 170.315(b)(1) (Transitions of care) C–CDA Release 2.0. We did not propose
storage needed to store two versions of
the C–CDA document, and would this approach for public comment.
We proposed to adopt a 2015 Edition Further, it would also be impractical
require systems to establish complex
certification criterion for ‘‘transitions of and burdensome to implement as it
rules about handling content that is
care’’ (‘‘ToC’’) that is a continuation and would require forcing all health IT
extension of the ‘‘ToC’’ certification present in one version but not in the
other. The majority of commenters developers to bring back health IT
criterion adopted as part of the 2014 certified to the 2014 Edition to update
Edition Release 2 final rule at instead recommended that we adopt a
single version of the C–CDA standard each product’s certification.
§ 170.314(b)(8). We proposed the We believe that adopting Release 2.1
following revisions and additions. that would ensure systems can correctly
process both Releases 1.1 and 2.0, with largely achieves the goal to ensure
Updated C–CDA Standard many commenters specifically systems can send, receive, and parse
recommending Release 2.1 of C–CDA both C–CDA documents formatted
We proposed to adopt C–CDA Release according to Release 1.1 or 2.0 and
2.0 at § 170.205(a)(4) and noted that (HL7 Implementation Guide for CDA®
Release 2: Consolidated CDA Templates minimizes the burden raised by
compliance with the C–CDA Release 2.0 commenters. However, we are aware
cannot include the use of the for Clinical Notes (US Realm), Draft
Standard for Trial Use Release 2.1, that a system developed strictly to
‘‘unstructured document’’ document- Release 2.1 might not automatically
level template for certification to this August 2015) 36 which the industry has
developed, balloted, and published. support receiving Release 1.1 C–CDAs
criterion. To address ‘‘bilateral without additional development (e.g.,
asynchronous cutover,’’ we proposed Release 2.1 provides compatibility
between Releases 2.0 and 1.1 by additional generation and import effort
that the 2015 Edition ‘‘ToC’’ since different vocabulary requirements
certification criterion reference both the applying industry agreed-upon
compatibility principles.37 Release 2.1 apply in several places when comparing
C–CDA Release 1.1 and Release 2.0 the two versions of the C–CDA).
standards and that a Health IT Module also contains all the new document
templates included in Release 2.0. Therefore, we have adopted C–CDA
presented for certification to this Release 2.1 (both Volumes 1 and 2) as
criterion would need to demonstrate its Commenters also recommended an
alternate pathway if we did not adopt a requirement for the 2015 Edition
conformance and capability to create ‘‘ToC’’ criterion at § 170.314(b)(1), and
and parse both versions (Release 1.1 and Release 2.1 that would require:
have also adopted the requirement that
2.0) of the C–CDA standards. While we • A 2015 Edition certified Health IT
a Health IT Module must demonstrate
recognized that this proposal was not Module to be able to send documents
its ability to receive, validate, parse,
ideal, we proposed this more conformant to C–CDA Release 2.0;
display, and identify errors to C–CDA
conservative approach as a way to • A 2015 Edition certified Health IT
Release 1.1 documents to ensure
mitigate the potential that there would Module to be able to parse both a C–
compatibility and interoperability. Note
be interoperability challenges for CDA Release 1.1 and 2.0 document;
that for consistency, all 2015 Edition
transitions of care as different health • A 2014 Edition certified Health IT
certification criteria that reference C–
care providers adopted Health IT Module to be able to parse a C–CDA
CDA creation (e.g., clinical information
Modules certified to the 2015 Edition Release 1.1 document, and display but reconciliation and incorporation; view,
criterion (including CCDA Release 2.0 not parse a document conformant to download, and transmit to 3rd party)
capabilities) at different times. We C–CDA Release 2.0. require conformance to Release 2.1.
requested comment on an alternative A few commenters requested 2015 Edition certification criteria that
approach related to the creation of clarification on the different kinds of include a ‘‘receipt’’ of C–CDA
C–CDA-formatted documents. We noted null values and guidance on what documents function (e.g., clinical
that the adoption of C–CDA Release 2.0 constitutes an ‘‘indication of none’’ information reconciliation and
would be applicable to all of the other since blank values will not meet the incorporation) will also require testing
certification criteria in which the requirements of the corresponding to correctly process C–CDA Release 1.1
C–CDA is referenced and that, unless measure for transitions of care for Stage documents for the reasons described
C–CDA Release 2.0 is explicitly 3 of the EHR Incentive Programs. above. This pathway ensures maximum
indicated as the sole standard in a Response. We thank commenters for interoperability while balancing the
certification criterion, we would their suggestions to adopt Release 2.1 development burden.
reference both rather than require adherence to both Regarding the questions of
C–CDA versions in each of these versions Release 1.1 and Release 2.0. We clarification on the use of null values
criteria. agree that Release 2.1 largely provides and what constitutes an ‘‘indication of
Comments. Commenters agreed that none’’ for the purposes of meeting the
36 http://www.hl7.org/documentcenter/public/
C–CDA Release 2.0 offered EHR Incentive Program Stage 3 measure,
standards/dstu/CDAR2_IG_CCDA_CLINNOTES_
improvements compared to Release 1.1 R1_DSTUR2.1_2015AUG.zip. this issue concerns the information
for unifying summary care record 37 http://wiki.hl7.org/index.php?title= needed to fulfill the ‘‘automated
requirements and better enabling Consolidated_CDA_R2.1_DSTU_Update. numerator recording’’ and ‘‘automated
measure calculation’’ functions commenters suggested we require only technology must be able to display in
proposed at § § 170.315(g)(1) and (g)(2), the CCD, Referral Note, and (for human readable format the data
respectively. This issue concerns the inpatient settings only) Discharge included in a transition of care/referral
draft test procedure for § § 170.315(g)(1) Summary and allow health IT summary document. We explained that
and (g)(2) as related to transitions of developers to determine which we expected that Health IT Modules to
care, and we intend to update the test additional templates would be have some mechanism to track errors
procedures to include guidance on how appropriate to offer for the settings and encountered when assessing received
C–CDA R2.1 null values (including providers intended to be served by the C–CDA documents and we proposed
‘‘indication of none’’) are appropriately product. A few commenters suggested that health IT be able to track the errors
expressed by applying guidance from that we not prohibit the use of the encountered and allow for a user to be
the HL7 Examples Task Force. unstructured document template as it notified of errors or review the errors
We also highly recommend that could be a stepping stone to help produced. We stated these
health IT developers and providers providers begin using the C–CDA functionalities are an important and
follow the guidance provided in the standard and can be used to provide necessary technical prerequisite in order
HL7 Implementation Guide: S&I reports with images or scanned forms. to ensure that as data in the system is
Framework Transitions of Care Response. We thank commenters for parsed from a C–CDA for incorporation
Companion Guide to Consolidated-CDA the comments, and acknowledge that as part of the ‘‘clinical information
for Meaningful Use Stage 2, Release 1— some of the proposed C–CDA document reconciliation and incorporation’’
US Realm 38 that includes industry templates may not be applicable to all certification criterion the user can be
‘‘best practices’’ guidance for consistent settings. Therefore, we have required assured that the system has
implementation of the C–CDA Release that certified Health IT Modules be able appropriately interpreted the C–CDA it
1.1 standard, including for mapping to parse C–CDA Release 1.1 and C–CDA received.
Common MU Data Set elements into the Release 2.1 CCD, Referral Note, and (for Comments. There was overall support
C–CDA standard. It is our inpatient settings only) Discharge from commenters on the proposal to
understanding that the industry is Summary document templates for require Health IT Modules detect valid
developing an update to this certification to this criterion. We and invalid C–CDA documents.
‘‘companion guide’’ to provide guidance encourage health IT developers and However, similar to the comments
on implementing the C–CDA Release 2.1 providers to work together to determine above, commenters did not support the
standard. We encourage health IT if additional C–CDA templates would be proposal to require validation of both
developers to use the update to develop better suited for certain settings. For C–CDA Releases 1.1 and 2.0 because of
their products to the 2015 Edition example, the CCD may contain more the burden and complexity of
criteria that reference C–CDA Release information than is necessary for some processing two versions of the same
2.1 when it becomes available. care transitions and other C–CDA standard. A few commenters were
document templates may provide a concerned with the proposed
C–CDA Document Template Types more succinct and/or targeted summary requirement for the receiving system to
We proposed to require that all of a patient’s clinical information for manage an incorrectly formatted C–CDA
certified Health IT Modules be able to certain settings. We note that C–CDA document, and requested that this
parse C–CDA Release 2.0 documents Release 2.1 includes the same document burden should be on the sending
formatted according to the following templates included in Release 2.0. system. A few commenters also
document templates: Regarding the use of the unstructured requested clarification on whether the
• Continuity of Care Document document template, we believe that it receiver is required to notify the sender
(CCD); limits interoperability as data is not of the C–CDA document of errors.
• Consultation Note; exchanged in a structured and Commenters also requested clarification
• History and Physical; standardized (e.g., to certain vocabulary on how validation and display would be
• Progress Note; standards) manner. For the purposes of tested as it would be unrealistic for
• Care Plan; certification to this certification health IT to accept every single code in
• Transfer Summary; criterion, Health IT Modules cannot a system. Last, some commenters were
• Referral Note; and include the use of the unstructured concerned about the ‘‘alert fatigue’’ a
• Discharge Summary. document template. user could encounter if notified of every
These document templates include Valid/Invalid C–CDA System C–CDA error detected by the certified
clarifications and enhancements relative system.
Performance and Display
to Release 1.1, as well as new document Response. We thank commenters for
templates (i.e., Care Plan, Referral Note, We proposed that Health IT Modules their support of the proposal. As noted
and Transfer Summary). We also would need to demonstrate the ability to above, systems would be required to
proposed to prohibit the use of the detect valid and invalid C–CDA support validation and display for both
unstructured document template. documents, including document, Releases 1.1 and Release 2.1 to ensure
Comments. Commenters were section, and entry level templates for compatibility and interoperability. We
supportive of the new and clarified data elements specified in 2014 and reiterate as noted above that systems
document templates for more specific 2015 Editions. Specifically, that this will be tested to perform the validation
use cases where a CCD may contain would include the ability to detect and display functions for only the CCD,
more information than is necessary. invalid C–CDA documents, to identify Referral Note, and (inpatient settings
valid C–CDA document templates, to only) Discharge Summary templates.
However, a number of commenters were

concerned about the burden to certify detect invalid vocabularies and codes Regarding the burden to the receiving
all document templates, and noted that not specified in either the C–CDA 1.1 or system to process incorrectly formatted
not all document templates were 2.0 standards or required by this C–CDA errors, we note that all Health IT
applicable to all settings. As such, regulation, and to correctly interpret Modules certified to a 2015 Edition
empty sections and nullFlavor criterion that includes the functionality
38 http://www.hl7.org/implement/standards/ combinations per the C–CDA 1.1 or 2.0 to create a C–CDA are also required to
product_brief.cfm?product_id=374. standards. Last, we proposed that be certified to the ‘‘C–CDA Creation
Performance’’ certification criterion at for a provider to quickly find the requested that we act to address a C–
§ 170.315(g)(6). This certification clinical information they seek to make CDA’s ‘‘length’’ and users’ ability to
criterion requires that systems are able a care decision. more easily navigate to particular data
to create C–CDA documents in We note that CMS has finalized in the within the C–CDA, we have included
accordance with a gold standard that we EHR Incentive Programs Stage 3 and more precise requirements in this
provide, thereby reducing the potential Modifications final rule guidance that portion of the certification criterion.
for errors in a C–CDA sent by an permits a provider and organization Specifically, the 2015 Edition version
outgoing system (please refer to the (i.e., the ‘‘sender’’) to define the includes that a user must be able to: (1)
‘‘C–CDA creation performance’’ ‘‘clinical relevance’’ of information sent Directly display only the data within a
criterion in the preamble for further in a summary care record depending on particular section, (2) set a preference
details). the circumstances, as best fits the for the display order of specific sections,
However, we recognize that there may organizational needs, and as relevant for and (3) set the initial quantity of
still be errors in created C–CDA the patient population.39 CMS notes, sections to be displayed. We also clarify
documents from a sending system and however, that the sending provider has that the sole use of the CDA.xsl style
therefore continue to believe in the to have the ability to send all clinical sheet provided by HL7 to illustrate how
value of the receiving system to process notes or laboratory results in a summary to generate an HTML document from a
and validate C–CDA documents, care document if that level of detail is CDA document will not be acceptable to
including notifying the user of errors. requested by the receiving provider. meet these requirements. We believe
We clarify that the error notification While the guidance in the EHR these clarifications will help address
should be available to the receiving Incentive Programs Stage 3 and stakeholder concerns regarding the
user. Regarding error notification, Modifications final rule does address difficulty finding or locating the
systems would be required to ‘‘clinical relevance’’ from the sending pertinent and relevant clinical
demonstrate its ability to notify the user side and could result in a reduction in information on a patient from a ToC/
of errors or allow the user to review the the quantity of data potentially viewed referral summary received as a C–CDA
errors for the purposes of certification. by a recipient as ‘‘unnecessary’’ or not document. We intend to ensure that the
Per commenters’ concerns about ‘‘alert useful, we recognize that certain test procedure for this criterion
fatigue,’’ we note there is no explicit patients, such as those with complex thoroughly tests these aspects consistent
requirement that the user be interrupted and/or chronic conditions may have a with the certification criterion’s
regarding the availability of errors. transition of care/referral summary sent requirements. We also strongly urge the
Rather, that the user needed to be able to receiving providers with large health IT industry to dedicate additional
to access such errors. We anticipate that quantities of data included. In that focus toward improving the rendering of
validation and display would be tested respect, we included as part of the 2014 data when it is received. Putting such
through visual inspection that test data Edition Final Rule a specific ‘‘section data to use in ways that enable
in the form of C–CDA documents with views’’ capability in the ‘‘transitions of providers to quickly view and locate the
and without errors can be correctly care’’ certification criterion (adopted at information they deem necessary can
parsed and errors correctly identified. 45 CFR 170.314(b)(1)(iii)(C)), which we help improve patient care and prevent
We have finalized the requirement as described as having been added to the important information from being
part of this criterion that Health IT certification criterion in order to make inadvertently missed. We further note
Modules must be able to detect valid sure that health IT would be able to that standards experts are aware of the
and invalid transition of care/referral extract and allow for individual display stakeholder concerns discussed above,
summaries received and formatted in each additional section or sections (and and that the HL7 Structured Documents
accordance with C–CDA Release 1.1 and the accompanying document header Work Group is working on contributing
Release 2.1 for the CCD, Referral Note, information (i.e., metadata)) that were positive momentum to this issue.40 The
and (inpatient settings only) Discharge included in a transition of care/referral HL7 Structured Documents Work
Summary document templates, summary received and formatted in Group’s work involves developing
including detection of invalid accordance with the Consolidated CDA guidance on the ‘‘relevant’’ data that
vocabulary standards and codes, correct (77 FR 54219). should be sent by the sender. We
interpretation of empty sections and We indicated that this functionality encourage health IT developers to
null combinations, recording of errors/ would be useful in situations when a participate in this process and
notification of errors to the user, and the user wanted to be able to review other implement the industry principles
ability to display a human readable sections of the transition of care/referral arising out of this project.
formatted C–CDA (for both Releases 1.1 summary that were not incorporated (as
and 2.1). We discuss additional required by this certification criterion at Edge Protocols
clarifications regarding the display of 45 CFR 170.314(b)(1)), such as a We proposed to ‘‘carry-over’’ a
C–CDA sections below. patient’s procedures and smoking requirement from the 2014 Edition
Clinical Relevance of Summary Care status, and that the technology would Release 2 ‘‘transitions of care’’ criterion
Record Information need to provide the user with a at § 170.314(b)(8) that would require a
mechanism to select and just view those certified Health IT Module be able to
We have received feedback from
sections without having to navigate send and receive transition of care/
providers expressing difficulty finding
through what could be a lengthy referral summaries through a method
or locating the pertinent and relevant
document. that conforms to the ONC
clinical information on a patient from a
The section views capability remains Implementation Guide for Direct Edge
transition of care/referral summary as part of the 2015 Edition version of Protocols, Version 1.1 at § 170.202(d).
received as a C–CDA document. this criterion. Additionally, to address Comments. Commenters were
Commenters have indicated that data comments that raised concerns and generally in support of requiring one of
included in a transition of care/referral
summary document may be rendered 39 Please see the EHR Incentive Programs Stage 3 40 http://www.hl7.org/special/Committees/
and displayed as a long, multi-page and Modifications final rule published elsewhere in projman/searchableProjectIndex.cfm?action=edit&
document, which makes it challenging this issue of the Federal Register. ProjectNumber=1183.
the four Edge Protocols designated in Because we expect XDM packaging to be MIME types. In addition, XDM packages
the ONC IG for Direct Edge Protocols. created in accordance with the are commonly identified with
One commenter was concerned that the specifications included in IHE IT ‘‘application/zip’’ and ‘‘application/
edge protocols offer no additional value Infrastructure Technical Framework octet-stream’’ MIME types. However,
for those that have already implemented Volume 2b, Transactions Part B— these MIME types have not been
Direct. Sections 3.29—2.43, Revision 7.0, standardized by the community for
Response. As stated in the 2014 August 10, 2010 (ITI TF–2b),41 we transporting C–CDA and XDM files.
Edition Release 2 final rule, we believe proposed to adopt this as the standard Systems could potentially use other
that adoption of the ONC IG for Direct at § 170.205(p)(1) for assessing whether valid MIME types to send the
Edge Protocols can improve the market the XDM package was successfully documents. While these standard MIME
availability of electronic health processed. types provide sufficient information for
information exchange services for Comments. Commenters were receiving systems to render content,
transitions of care by separating content supportive of the proposal to they do not provide a way to distinguish
from transport related to transitions of demonstrate XDM package processing. the C–CDA and XDM documents from
care. We believe that certification to the Many commenters recommended that all the other documents that could be
Direct Edge Protocols IG can also enable processing on receipt depends on sent using the same MIME types. Until
greater certainty and assurance to health metadata in the XDM package that an appropriate set of MIME types are
IT developers that products certified to should be aligned with the general developed that can uniquely identify C–
this IG have implemented the IG’s edge metadata in Appendix B of the IHE Data CDA and XDM, there is widespread
protocols in a consistent manner (79 FR Access Framework Document Metadata acknowledgement that the receiving
54437). As such, we have finalized the Based Access Implementation Guide systems should accept all common
requirement that a certified Health IT that was published for public comment MIME types, and use the information
Module be able to send and receive on June 1, 2015.42 One commenter within the actual documents, to process
transition of care/referral summaries recommended that the certification C–CDA and XDM accordingly. Hence, in
through a method that conforms to the criterion point specifically to section order to facilitate interoperability, we
ONC Implementation Guide for Direct 3.32.4.1.4 of ITI TF–2b. expect Health IT Modules to be able to
Edge Protocols, Version 1.1. Response. We thank commenters for support all commonly used MIME types
We note that we inadvertently left out their support of the proposal and have when receiving C–CDA and XDM
a provision of the proposed regulation finalized this requirement that Health IT packages. We intend to update the test
text related to Edge Protocol Modules certified to an SMTP-based procedure to include guidance on
requirements. As noted above and in the edge protocol be able to receive and specific MIME types that we expect
Proposed Rule, we intended to ‘‘carry make available the contents of an XDM Health IT Modules to support, at a
over’’ the Edge Protocol requirements package formatted in accordance with
minimum.
included in § 170.314(b)(8) for this ITI TF–2b, which we have adopted at
criterion. Therefore, we have added to § 170.205(p)(1). We note that the ONC Common Clinical Data Set
the provision in § 170.315(b)(1)(i)(A) Implementation Guide for Direct Edge
We proposed to require Health IT
about sending transition of care/referral Protocols adopted at § 170.202(d) and
Modules to enable a user to create a
summaries through a method that required for this criterion as discussed
transition of care/referral summary that
conforms with the Edge Protocol and a above references the guidance in the
includes, at a minimum, the Common
requirement that it must also lead to the ONC XDR and XDM for Direct
Clinical Data Set for the 2015 Edition
summaries being processed by a service Messaging Specification for proper use
that includes references to new and
that has implemented Direct. This of metadata that is aligned with the IHE
addition parallels the Direct Edge Data Access Framework Document updated vocabulary standards code sets.
Protocol ‘‘receiving’’ requirements we Metadata Based Access IG. Therefore, Comments. Commenters were
proposed and have finalized. It also we do not believe it is necessary to supportive of this proposal overall. A
clarifies a consistent set of technical reference the IHE IG as these metadata few commenters were concerned about
capabilities for sending the Edge requirements are already referenced and specific data elements in the proposed
Protocol and technologies interacting required for this criterion. Similarly, our 2015 Edition Common Clinical Data Set
with services that have implemented requirement to adhere to the ITI TF–2b definition.
Direct, which again are the exact same would include any specific section Response. We thank commenters for
requirements included in § 170.314 required in the standard, and thus we their support and have adopted the
(b)(8) that we intended to duplicate in do not need to reference a specific requirement that Health IT Modules
this 2015 Edition criterion. section. enable a user to create a transition of
SMTP-based transport systems use care/referral summary that includes the
XDM Package Processing standard Multi-Purpose Internet Mail 2015 Edition Common Clinical Data Set
We proposed to include a specific Extension (MIME) to identify email at a minimum. We address the specific
capability in this certification criterion attachments and to enable receiving data elements in the 2015 Edition
that would require a Health IT Module computer systems to process Common Clinical Data Set definition in
presented for certification that is also attachments seamlessly. For example, a under section III.B.3 of this final rule.
being certified to the SMTP-based edge MIME type of ‘‘text/html’’ identifies text
Encounter Diagnoses
to demonstrate its ability to accept and styled in HTML format. C–CDA
process an XDM package it receives, documents are commonly identified We proposed to continue the
which would include extracting using ‘‘text/xml’’ and ‘‘application/xml’’ requirement from the 2014 Edition
relevant metadata and document(s). We ‘‘ToC’’ certification criterion that a
explained that this additional 41 http://www.ihe.net/Technical_Framework/
Health IT Module must enable a user to
requirement only applies to a Health IT upload/IHE_ITI_TF_Rev7-0_Vol2b_FT_2010-08- create a transition of care/referral
10.pdf.
Module presented for certification with 42 http://ihe.net/uploadedFiles/Documents/PCC/ summary that also includes encounter
an SMTP-based edge implementation IHE_PCC_IG_DAF_National%20Extension_Rev1.0_ diagnoses using either SNOMED CT®
and not an XDR edge implementation. PC_2015-06-01.pdf. (September 2014 Release of the U.S.
Edition as a baseline for the 2015 Comments. There was general support should be kept separate as it could be
Edition) or ICD–10–CM codes. for requiring the proposed data elements confusing if a patient has more than one
Comments. One commenter to be exchanged in order to improve suffix (e.g., JR and MD). Individuals may
recommended solely the use of ICD–10– patient matching. Some commenters also not use both suffixes in all
CM for encounter diagnoses and were concerned with conflicts between circumstances, so it may be difficult to
certification. Another commenter the proposed approach and existing match records using both.
requested clarification on whether the systems’ algorithms and patient Response. We agree with the
encounter diagnoses are meant to be matching protocols. A few commenters comments and have not adopted the
‘‘billing diagnoses’’ and whether the recommended that we wait until there constraint for suffix to adhere to the
health IT would need to include all is a consensus-based patient matching CAQH standard. We recommend that
billing diagnoses for encounters or just standard before adopting requirements health IT developers and providers
the primary encounter, and how for certification. A few commenters also follow the guidance for suffix in C–CDA
primary would be determined. noted that the proposal does not address Release 2.1 for exchange, which allows
Response. As stated in our 2014 data quality. for an additional qualifier for any suffix
Edition final rule (77 FR 54178 and Response. We note that systems can provided with the last name field.
54220), we believe that SNOMED CT® is continue to use their existing algorithms Comments. One commenter noted
the more appropriate vocabulary for and patient matching protocols and that that the CAQH Phase II Core 258:
clinical purposes and provides greater our proposed approach was not Eligibility and Benefits 270/271
clinical accuracy. However, it may be intended to conflict with any existing Normalizing Patient Last Name Rule
beneficial for inpatient Health IT practice. We reiterate that the proposed version 2.1.0 is intended for
Modules to be certified to and support data elements stem from the HITPC’s normalization of information upon
the use of ICD–10–CM to represent and HITSC’s recommendations and receipt rather than at the point of
diagnoses, and finalized the 2014 findings from the 2013 ONC initiative sending. Pre-normalization can lead to
Edition ‘‘transitions of care—create and on patient matching as described in the data loss and detract from patient
transmit’’ criterion at § 170.314(b)(1) to Proposed Rule (80 FR 16833–16834). matching. Therefore the commenter
allow for either ICD–10–CM or We continue to believe these recommended ONC not require the
SNOMED CT®. We continue this policy recommendations represent a first step CAQH Phase II Core 258: Eligibility and
and have finalized the requirement for forward that is consensus-based. We Benefits 270/271 Normalizing Patient
this 2015 Edition ‘‘ToC’’ certification agree that the proposal did not address Last Name Rule version 2.1.0 for
criterion that a Health IT Module enable data quality in the sense that it would normalizing last name in the sending of
a user to create a transition of care/ improve the ‘‘source’s’’ practices and transition of care/referral summary
procedures to collect highly accurate documents and rather point to it as
referral summary that includes
and precise data. However, we believe guidance for receiving systems.
encounter diagnoses using either
that including standards for the Response. We agree with the
SNOMED CT® (September 2015 Release commenter, and have not adopted the
of the U.S. Edition as a baseline for the exchange of certain data elements could
improve interoperability and provides constraint for last name normalization
2015 Edition 43) or ICD–10–CM codes. in accordance with the CAQH standard.
We note that our certification an overall level of consistency around
how the data are represented. We We recommend that health IT
requirement does not dictate what developers and providers follow the
encourage ongoing stakeholder efforts
encounter diagnoses providers would guidance for last name in C–CDA
focused on improving patient matching
include in a transitions of care Release 2.1 for exchange of transition of
through better data quality processes
document, only that certified Health IT care/referral summary documents.
and will continue to monitor and
Modules can enable a provider to Comments. A few commenters
participate in these activities.
include encounter diagnoses using Comments. Commenters suggested that the concept of ‘‘maiden
SNOMED CT® or ICD–10–CM. recommended that we ensure alignment name’’ is not used in all cultures and is
‘‘Create’’ and Patient Matching Data between the proposed data elements also gender-specific. Some commenters
Quality and corresponding standards with those noted that some nationalities, cultures,
in the C–CDA standard. or ethnic groups do not use this term
As a part of the ‘‘Create’’ portion of Response. We have performed an and, in other cases, an individual may
the ‘‘ToC’’ criterion in the 2015 Edition, analysis of the proposed data elements adopt more than one family name
we proposed to require a Health IT and standards with those in C–CDA during marriage. There are other cases
Module to be able to create a transition Release 2.1 and have made some where the last name or family name has
of care/referral summary that included a revisions as described below. In some been legally changed for other
limited set of standardized data in order cases, the ONC method may be more situations. Most commenters
to improve the quality of the data that constrained than what is in C–CDA recommended we instead use another
could potential be used for patient Release 2.1 and we believe there will be term that broadly captures these
matching by a receiving system. The no conflict. Rather the additional situations and allows for aliases that a
proposed standardized data included: constraint is intended to promote patient may use in these circumstances.
First name, last name, maiden name, patient matching and interoperability. Response. We thank commenters for
middle name (including middle initial), We also address standards for specific the feedback and have revised ‘‘maiden
suffix, date of birth, place of birth, elements below. name’’ to ‘‘previous name’’ to
current address, historical address, Comments. Commenters suggested accommodate for any other aliases
phone number, and sex, with that we should not reference the CAQH including the situations described above
constrained specifications for some of Phase II Core 258: Eligibility and by the commenters. We note that the
the proposed standardized data. Benefits 270/271 Normalizing Patient C–CDA Release 2.1 contains a field for
43 We refer readers to section III.A.2.c (‘‘Minimum
Last Name Rule version 2.1.0 for suffix ‘‘birth name’’ that can accommodate this
Standards’’ Code Sets) for further discussion of our
as it puts JR, SR, I, II, III, IV, and V in information.
adoption of SNOMED CT® as a minimum standards the same field as RN, MD, PHD, and Comments. A number of commenters
code set and our decision to adopt this version. ESQ. Commenters felt that these suffixes were concerned about including place
of birth in the list of data elements as distinguish between historical and C–CDA to bring about industry-wide
there is a lack of standards on current address as proposed. Because of consistency. We anticipate the C–CDA
representing the place of birth. Some the discrepancy between our proposal validation tool for 2015 Edition
systems include city, county, state, and and what the C–CDA Release 2.1 can ‘‘transitions of care’’ testing will carry
country, while other systems may only accommodate, we have revised the over the 2014 Edition testing and
include some of these elements. requirement to ‘‘address’’ (not specified suggest that health IT developers and
Therefore, these commenters stated that as historical or current). We note that implementers adhere to the guidance in
it would be difficult to standardize on C–CDA Release 2.1 can accommodate C–CDA Release 2.1 on the use of the
place of birth as proposed and it would more than one address. It is our HL7 postal format.
offer no additional value for improving understanding that the underlying Comments. A few commenters
patient matching. parent C–CDA standard (i.e., CDA) suggested we consider the addition of
Response. We agree with commenters included the ability to send a useable data elements to the proposed list, such
that the lack of standards for period with the address to specify as a social security number or the last
representing place of birth would not different addresses for different times of four digits of a social security number.
improve patient matching at this time the year or to refer to historical Response. We thank commenters for
and, therefore, have not finalized this addresses. However, this useable period the suggestions but do not agree and
data element requirement. was removed from C–CDA as it did not have not accepted these suggestions. We
Comments. A few commenters noted have enough use. We intend to work have evaluated the list proposed in the
concerns about including the hour, with stakeholders going forward in Proposed Rule 48 and continue to
minute, and second of the date of birth, assessing whether the useable period believe that it represents a good first
and suggested that the time zone is should be included in future versions of step toward improving patient matching
needed to correctly match records. the C–CDA standard or whether there in line with the HITSC, HITPC, and
Response. We note that as proposed are other methods for distinguishing ONC 2013 patient matching initiative
in the 2015 Edition, the hour, minute, historical or current address for recommendations. We intend to
and second of the date of birth were consideration in future rulemaking. continue our work in developing patient
optional or conditional fields based on Comments. A number of commenters matching best practices and standards,
whether they were included. Since we recommended ONC adopt the US Postal including evaluating the feasibility,
have not finalized the proposed Service (USPS) standard for efficacy, and, in some cases, the legality
requirement to include place of birth, representing address. Commenters of specifying other data elements for
we have revised the requirement as noted that the standard is widely patient matching. We may propose to
follows. We clarify that for the purposes supported by health care organizations expand this list or adopt a more
of certification that the hour, minute, today, and that it is recommended by sophisticated patient match policy in
and second for a date of birth are the American Health Information future rulemaking as standards mature.
optional for certification. If a product is Management Association.46 Another Comments. A few commenters noted
presented for certification to this commenter recommended we consider that a 100% patient match is impossible
optional provision, the technology must adoption of the GS1 Global Location to achieve in every instance.
demonstrate that the correct time zone Number standard. Response. We note that our proposal
offset is included. Response. We thank commenters for only concerns the ability of a certified
Comments. One commenter the input. At this point in time and Health IT Module to create a transition
supported the proposal to include since this patient matching requirement of care/referral summary document that
phone number in the list of patient focuses on the use and representation of contains the proposed data elements in
match elements. Another commenter address in the C–CDA standard, we accordance with the specified
recommended we specify a standard for believe that use of the C–CDA standards/constraints. The proposal
representing phone number. standard’s built-in requirements is the would not require a system to
Response. We clarify that we best, most incremental path forward. We demonstrate how it performs patient
proposed that the phone number must note the C–CDA Release 2.1 standard matching with these data for
be represented in the ITU format references the HL7 postal format. certification. As noted above, we believe
specified in the International Additionally, testing and validation to the algorithms and patient matching
Telecommunication Union (ITU)’s the HL7 postal format in the C–CDA protocols are best left to health IT
ITU–T E.123 44 and ITU–T E.164 standard is already available as part of systems and providers to determine at
standards.45 These are the best available 2014 Edition ‘‘transitions of care’’ this point in time. While the HITPC
industry standards for representing testing to C–CDA Release 1.1. We see a recommended 49 that we should
phone number and we have adopted need for continued industry work to develop, promote, and disseminate best
them for representing phone number in determine the appropriateness of practices, there is not an industry-wide
this certification criterion. existing standards and tools for standard for patient matching protocols
Comments. As stated above, normalizing postal address for health that is ready to require as a condition of
commenters suggested we perform an care use cases such as matching of certification. We intend to continue
analysis of the standards required by the electronic patient health records, and working with the industry to develop
C–CDA standard and resolve any intend to work with stakeholders in this these best practices, and will evaluate at
inconsistencies with our proposal. space. Thus, we look forward to a later point if certification would
Response. In our analysis of the continuing to work with stakeholders to
proposed data elements with the C–CDA analyze the USPS address standard 47 48 First name, last name, maiden name, middle
Release 2.1 standard as suggested by and other industry standards with name (including middle initial), suffix, date of
commenters, we found that the C–CDA birth, place of birth, current address, historical
respect to any future updates to the address, phone number, and sex, with constrained
Release 2.1 standard is not able to specifications for some of the proposed
46 http://perspectives.ahima.org/wp-content/ standardized data.
44 http://www.itu.int/rec/T-REC-E.123-200102-I/e. uploads/2014/12/PatientMatchingAppendixA.pdf. 49 http://www.healthit.gov/FACAS/sites/default/
45 http://www.itu.int/rec/T-REC-E.164-201011- 47 http://pe.usps.gov/cpim/ftp/pubs/Pub28/ files/standards-certification/8_17_2011Transmittal_
I/en. pub28.pdf. HITSC_Patient_Matching.pdf.
confer additional benefit for improving Chapter 8 of the white paper, ‘‘A Report specific requirements of the new
patient matching. Until such protocols on Direct Trust Interoperability Testing certification criteria.
are established and mature, our and Recommendations to Improve
C–CDA Data Provenance Request for
requirement addresses the HITPC’s first Direct Exchange.52
Comment
recommendation, which is to provide Response. As we did not include a
standardized formats for demographic proposal or request for comment, we We requested comment on the
data fields. thank the commenter for the maturity and appropriateness of the HL7
In consideration of public comments, recommendation and will review the IG for CDA Release 2: Data Provenance,
we have finalized the requirement that recommended material. Release 1 (US Realm) (DSTU) 53 for the
Health IT Modules must be able of tagging of health information with
Certification Criterion for C–CDA and provenance metadata in connection
creating a transition of care/referral
Common Clinical Data Set Certification with the C–CDA, as well as the
summary in accordance with just C–
CDA Release 2.1 as part of this We noted that no proposed 2015 usefulness of this IG in connection with
certification criterion that includes the Edition certification criterion includes certification criteria, such as ‘‘ToC’’ and
following data formatted to the just the C–CDA Release 2.0 and/or the ‘‘VDT’’ certification criteria.
associated standards/constraints where Common Clinical Data Set, particularly Comments. Although commenters
applicable: with the 2015 Edition not including a were supportive of the usefulness of
• First name; proposed ‘‘clinical summary’’ data provenance, the majority of
• Last name; certification criterion as discussed in commenters did not think the HL7 Data
• Previous name; the 2015 Edition Proposed Rule (80 FR Provenance standard was mature for
• Middle name (including middle 16850). We requested comment on adoption at this point in time.
initial); whether we should adopt a separate Response. We thank commenters for
• Suffix; 2015 Edition certification criterion for their input and will continue to monitor
• Date of birth—The year, month, and the voluntary testing and certification of the industry uptake and maturity of the
day of birth are required fields. Hour, health IT to the capability to create a HL7 Data Provenance standard in
minute, and second are optional fields; summary record formatted to the consideration of future rulemaking.
however, if hour, minute, and second C–CDA Release 2.0 with or without the • Clinical Information Reconciliation
are provided then the time zone offset ability to meet the requirements of the and Incorporation
must be included. If date of birth is Common Clinical Data Set definition.
unknown, the field should be marked as 2015 Edition Health IT Certification Cri-
Comments. We received comments in
null; terion
favor of adopting a new 2015 Edition § 170.315(b)(2) (Clinical information rec-
• Address; criterion that includes just the ability of onciliation and incorporation)
• Phone number—Represent phone a Health IT Module to enable a user to
number (home, business, cell) in the create a transition of care/summary care We proposed to adopt a 2015 Edition
ITU format specified in ITU–T E.123 50 record in accordance with C–CDA ‘‘clinical information reconciliation and
and ITU–T E.164 51 which we are Release 2.0 and with the ability to meet incorporation’’ certification criterion
adopting at § 170.207(q)(1). If multiple the requirements of the Common that is a revised (but largely similar to
phone numbers are present, all should Clinical Data Set. the 2014 Edition Release 2) version of
be included; and Response. We have adopted two new the ‘‘clinical information reconciliation
• Sex in accordance with the standard 2015 Edition certification criteria (with and incorporation’’ criterion adopted at
we are adopting at § 170.207(n)(1). no relation to the EHR Incentive § 170.314(b)(9). First, we proposed that
We note that we corrected the date of Programs) that include just the ability of Health IT Modules must be able to
birth requirements to specify the year, a Health IT Module to enable a user to incorporate and reconcile information
month, and day of birth as the required create (one criterion) and receive (one upon receipt of C–CDA’s formatted to
fields. We previously inadvertently criterion) a transition of care/referral both Release 1.1 and Release 2.0 for
listed ‘‘date’’ instead of ‘‘day.’’ summary in accordance with C–CDA similar reasons (e.g., for compatibility
Direct Best Practices Release 2.1 (create) and both C–CDA with Release 1.1) as proposed for the
Releases 1.1 and 2.1 (receive) and with ‘‘ToC’’ criterion described above.
Given feedback from stakeholders the ability to meet the requirements of Comments. Commenters were
regarding health IT developers limiting the Common Clinical Data Set at generally supportive of the proposal to
the transmission or receipt of different § 170.315(b)(4) and § 170.315(b)(5), adopt a criterion for ‘‘clinical
file types via Direct, we reminded all respectively. For the certification information reconciliation and
stakeholders in the Proposed Rule of the criterion adopted to ‘‘create’’ a incorporation’’ for interoperability.
following best practices for the sharing transition of care/referral summary at Response. We thank commenters for
of information and enabling the § 170.315(b)(4), we have also, for their support and have adopted a 2015
broadest participation in information consistency, include the same patient Edition criterion for ‘‘clinical
exchange with Direct: http://wiki.direct matching data as referenced by the information reconciliation and
project.org/Best+Practices+for+Content ‘‘ToC’’ certification criterion. We refer incorporation’’ with the following
+and+Workflow. We did not include a readers to the ‘‘Common Clinical Data changes and clarifications as discussed
proposal or request for comment related Set summary record—create’’ and below.
to this guidance. ‘‘Common Clinical Data Set summary Comments. Similar to the comments
Comments. One commenter record—receive’’ certification criteria in we received for the ‘‘ToC’’ criterion,
recommended we review the challenges this section of the preamble for a more commenters were not in favor of the
and solutions recommended by the detailed description of the rationale and proposed requirement to support both
DirectTrust in Chapter 2, Chapter 7 and
52 http://static1.1.sqspcdn.com/static/f/1340919/ 53 http://wiki.hl7.org/index.php?title=HL7_Data_
50 http://www.itu.int/rec/T-REC-E.123-200102-I/e.
26054983/1426686689687/Report+on+DirectTrust+ Provenance_Project_Space and http://gforge.hl7.
51 http://www.itu.int/rec/T-REC-E.164-201011- Interoperability+Testing.pdf?token=A0DNBiAq org/gf/project/cbcc/frs/?action=FrsRelease
I/en. jJ2YzuhUTn4vnBMrtVI%3D. Browse&frs_package_id=240.
versions of C–CDA Release 1.1 and 2.0 documents with no medications, against the information that was
because of the burden to receive and documents having variations of provided to incorporate.
process two versions of the same medication timing data). We also Comments. We received mixed
standard. proposed that problems be incorporated feedback on this proposal. Some
Response. As discussed in the in accordance with the September 2014 commenters were concerned that this
preamble of the ‘‘ToC’’ criterion above, Release of the U.S. Edition of SNOMED requirement would not provide added
we have adopted a requirement that CT® and that medications and benefit for Health IT Module users or
systems must be able to receive and medication allergies be incorporated in patients. Other commenters noted that
correctly process documents formatted accordance with the February 2, 2015 this requirement would be adding in a
to both C–CDA Releases 1.1 and 2.1. monthly version of RxNorm as a ‘‘create’’ function to this criterion,
While C–CDA Release 2.1 largely baseline and in accordance with our which they thought contradicted the
addresses compatibility issues with ‘‘minimum standards code sets’’ policy. modularity we previously introduced in
Release 1.1 and reduces the burden for Comments. A few commenters the 2014 Edition Release 2 final rule
systems receiving both versions, we are suggested we include additional data for when we made modifications to the
aware that a system developed strictly incorporation and reconciliation, such 2014 Edition ‘‘transitions of care’’ and
to Release 2.1 might not automatically as food allergies and intolerances, labs, ‘‘clinical information reconciliation’’
support receiving Release 1.1 C–CDAs and immunizations. criteria.
without additional development. Response. As stated in the 2014 Response. We believe that the
Therefore, this criterion will focus on Edition final rule, we continue to creation of a C–CDA based on the
functionalities to receive, incorporate, believe that problems, medications, and reconciliation and incorporation process
and reconcile information from a medication allergies are the minimum will improve and automate the testing
C–CDA formatted to Releases 1.1 and data that should be reconciled and and verification process. While there are
2.1. incorporated from a C–CDA (77 FR other methods of verifying
54223). We note that this minimum reconciliation, such as queries and list
C–CDA Document Templates and displays, an automated verification
requirement for certification would not
Reconciliation through the use of test tools provides
prohibit health IT developers from
We proposed that a certified Health IT including functionality to reconcile and the most assurance that the information
Module be able to receive, reconcile, incorporate a broader set of information was reconciled and incorporated
and incorporate information from the from a C–CDA, which is something we correctly. We do not believe this
C–CDA Release 2.0 CCD, Discharge encourage developers to pursue. requirement will add unnecessary
Summary, and Referral Note document Comments. One commenter suggested burden as it is our understanding that
templates at a minimum. Note that we that a provider may use different systems that receive, incorporate, and
incorrectly referenced the ‘‘Referral functionality for the reconciliation of reconcile C–CDA information can also
Summary’’ document template. There is medications distinct from the create a C–CDA. Furthermore, the
no ‘‘Referral Summary’’ document medication allergies and/or problems, purpose of this additional portion of the
template and we intended the ‘‘Referral and recommended that that certification certification criterion is to increase
Note’’ document template. criterion should allow for distinct or provider assurance that the
Comments. We did not receive combined reconciliation approaches. incorporation performed by a system
specific comments regarding the C–CDA Response. We clarify that the post-reconciliation is accurate and
document templates proposed for this certification criterion would allow for complete.
criterion. distinct (individual) or combined With respect to the comments that
Response. Although we did not reconciliation functions for mentioned an apparent contradiction
receive comments regarding the C–CDA medications, medication allergies, and with the requirement for ‘‘creating’’ a
document templates for this problems to be implemented so long as C–CDA as part of this certification
certification criterion, we maintain the all the functions can be demonstrated. criterion, we disagree, and remind
consistency decision discussed in the Comments. Commenters were commenters that the changes we made
‘‘ToC’’ criterion to require incorporation supportive of testing for this criterion to in the 2014 Edition Release 2 final rule
and reconciliation of information from verify a Health IT Module’s ability to were to better position the
the C–CDA Releases 1.1 and 2.1 CCD, incorporate valid C–CDAs with ‘‘incorporation’’ functionality in the
Referral Note, and (for inpatient settings variations in the data elements to be right certification criterion (79 FR
only) Discharge Summary document reconciled. Commenters believed this 54438–54439). Therefore, we have
templates. We believe this will provide would reasonably test the real-world adopted the requirement that Health IT
consistency between the minimum variation that may be found in C–CDA Modules be able to create a C–CDA
certification requirements for systems documents. Release 2.1 based on the reconciliation
creating and sending C–CDA documents Response. We thank commenters for and incorporation process that will be
for transitions of care and this criterion their support and intend for testing to verified during testing and certification.
for the receipt, incorporation, and verify a certified Health IT Module’s Note that this requirement applies to the
reconciliation of C–CDA information. ability to incorporate valid C–CDAs ability to create a C–CDA formatted to
with variations in the data elements. the C–CDA Release 2.1 CCD document
Data for Reconciliation template only.
We proposed that a Health IT Module C–CDA Creation for Validation of Comments. One commenter asked for
must be able to reconcile and Accurate Reconciliation clarification on whether the proposed
incorporate, at a minimum: problems, We proposed to require that a C–CDA regulation text ‘‘technology must be able
medications, and medication allergies be created based on the reconciliation to demonstrate that the transition of
from multiple C–CDAs, with testing for and incorporation process in order to care/referral summary received is or can
this specific system performance to validate the incorporation results. We be properly matched to the correct
verify the ability to incorporate valid expected that the generated C–CDA patient’’ means that Health IT Modules
C–CDAs with variations of data would be verified using test tools for must be able to auto-match to the
elements to be reconciled (e.g., conformance and can be checked correct patient. Commenters noted that
many systems allow for manual match, Response. We reiterate that for the We proposed to adopt a 2015 Edition
and that an auto-match may not be the purposes of testing and certification, certification criterion for e-prescribing
most appropriate method to match Health IT Modules must demonstrate that is revised in comparison to the
patient records. the ability to simultaneously display the 2014 Edition ‘‘e-prescribing’’ criterion
Response. We clarify that it was not data from at least two sources. While the (§ 170.314(b)(3)).
commenters’ point is fair it is not within
our intention to prescribe how patient First, we proposed to require a Health
scope for the purposes of testing and
match is performed for this criterion. IT Module certified to this criterion be
certification, which focuses on when
We have revised the regulation text to able to receive and respond to
there is data to reconcile. In other
reflect that the technology must words, the purpose of this certification additional National Council for
demonstrate that the received transition criterion is, in part, to assess Prescription Drug Programs (NCPDP)
of care/referral summary document can technology’s capability to reconcile data SCRIPT Standard Implementation Guide
be properly matched to the correct from two sources. Testing and Version 10.6 (v10.6) transactions or
patient. We leave the flexibility to the certification is focused on ensuring that segments in addition to the New
health IT developer and provider to that functionality exists and performs Prescription transaction, namely Change
determine the best method for patient correctly. Additionally, the criterion Prescription, Refill Prescription, Cancel
match. does not address the totality of Prescription, Fill Status, and Medication
Comments. A few commenters were capabilities that may be present in the History. We proposed to require that a
concerned with the proposed technology. In cases where a new Health IT Module be able to send and
requirement that for each list type (i.e., patient presents this specific receive end-to-end prescriber-to-
medications, medication allergies, or functionality may not be applicable or receiver/sender-to-prescriber
problems) the Health IT Module must used at all. transactions (bidirectional transactions).
simultaneously display the data from at • Electronic Prescribing The proposed transactions and reasons
least two sources. Commenters noted for inclusion for testing and certification
that there would not be two sources if 2015 Edition Health IT Certification Cri-
terion are outlined in Table 5 below.
the patient is new to the receiving § 170.315(b)(3) (Electronic prescribing)
system.
TABLE 5—PROPOSED ADDITIONAL 54 NCPDP SCRIPT V10.6 TRANSACTIONS FOR TESTING AND CERTIFICATION TO e-
PRESCRIBING CERTIFICATION CRITERION
NCPDP SCRIPT v10.6 Use case(s) Problem addressed/value in testing for certification
transaction or segment
Change Prescription (RXCHG, • Allows a pharmacist to request a change of a new Facilitates more efficient, standardized electronic
CHGRES). prescription or a ‘‘fillable’’ prescription. communication between prescribers and phar-
• Allows a prescriber to respond to pharmacy re- macists for changing prescriptions.
quests to change a prescription.
Cancel Prescription (CANRX, • Notifies the pharmacist that a previously sent pre- Facilitates more efficient, standardized electronic
CANRES). scription should be canceled and not filled. communication between prescribers and phar-
• Sends the prescriber the results of a prescription macists for cancelling prescriptions.
cancellation request.
Refill Prescription (REFREQ, • Allows the pharmacist to request approval for addi- Facilitates more efficient, standardized electronic
REFRES). tional refills of a prescription beyond those origi- communication between prescribers and phar-
nally prescribed. macists for refilling prescriptions.
• Allows the prescriber to grant the pharmacist per-
mission to provide a patient with additional refills or
decline to do so.
Fill Status (RXFILL) ..................... Allows the pharmacist to notify the prescriber about Allows the prescriber to know whether a patient has
the status of a prescription in three cases: (1) To picked up a prescription, and if so, whether in full
notify the prescriber of a dispensed prescription, or in part. This information can inform assessments
(2) to notify the prescriber of a partially dispensed of medication adherence.
prescription, and (3) to notify a prescriber of a pre-
scription not dispensed.
Medication History (RXHREQ, • Allows a requesting entity to generate a patient- Allows a requesting entity to receive the medication
RXHRES). specific medication history request. history of a patient. A prescriber may use this infor-
• The responding entity can respond, as information mation to perform medication utilization review,
is available, with a patient’s medication history, in- medication reconciliation, or other medication man-
cluding source, fill number, follow-up contact, date agement to promote patient safety.
range.
end-to-end prescriber-to-receiver which is embedded within NCPDP

We solicited comment on other testing. SCRIPT v10.6 for certification to the e-
NCPDP SCRIPT v10.6 transactions that Second, we proposed to require that prescribing criterion in the 2015
should be considered for testing and a Health IT Module certified to this Edition.55 We proposed this because we
certification, and for what use cases/ criterion enable a user to enter, receive,
value, and the factors to consider for and transmit codified Sig instructions in 55 NCPDP’s Structured and Codified Sig Format
a structured format in accordance with Implementation Guide v1.2 is within the NCPDP
54 We proposed to keep the ‘‘New Prescription’’ NCPDP Structured and Codified Sig SCRIPT v10.6 standard. https://www.ncpdp.org/
transaction for testing and certification. Format Implementation Guide v1.2 NCPDP/media/pdf/StandardsMatrix.pdf.
believe standardizing and codifying the Comments. Many commenters require for 2015 Edition testing and
majority of routinely prescribed suggested reducing the scope of this certification:
directions for use can promote patient proposed criterion to either divide out • New prescription transaction;
safety, as well as reduce disruptions to the requirements into separate • Prescription change request
prescriber workflow by reducing the certification criteria or to only require transaction;
number of necessary pharmacy call- the minimum functionalities needed to • Prescription change response
backs. We proposed that this achieve the corresponding proposed e- transaction;
requirement apply to the New prescribing objective for Stage 3 of the • Refill prescription request
Prescription, Change Prescription, Refill EHR Incentive Programs (80 FR 16747). transaction;
Prescription, Cancel Prescription, Fill Response. In finalizing the e- • Refill prescription response
Status, and Medication History prescribing criterion, we considered transaction;
prescription transactions or segments as whether the proposed functionality • Cancel prescription request
we understood that the NCPDP would help achieve interoperability transaction;
Structured and Codified Sig Format can between health IT systems and would • Cancel prescription response
be used for all NCPDP SCRIPT v10.6 align with the goals and objectives transaction; and
prescription transactions that include described in the ‘‘Federal Health IT • Fill status notification.
directions for medication use. We also We believe that providers that are e-
Strategic Plan.’’ 57 The reasons for the
proposed to require that a Health IT prescribing under Part D should have
finalized e-prescribing criterion and its
Module include all structured Sig already adopted NCPDP SCRIPT v10.6
included functionality are described
segment components enumerated in for these transactions as required
below in response to comments.
NCPDP SCRIPT v10.6 (i.e., Repeating effective November 1, 2013. Further, by
Comments. A number of commenters requiring these transactions as part of
Sig, Code System, Sig Free Text String, supported the additional NCPDP
Dose, Dose Calculation, Vehicle, Route certification, we are supporting the use
SCRIPT v10.6 transactions we proposed of additional NDPCP SCRIPT v10.6
of Administration, Site of to require for testing and certification to
Administration, Sig Timing, Duration, transactions in a standardized way.
this criterion, and believed the Comments. Some commenters also
Maximum Dose Restriction, Indication additional requirement would facilitate
and Stop composites). noted support for the medication history
bidirectional prescriber-pharmacist transaction request and response
We solicited comment on whether we communications and comprehensive transactions, and other commenters
should require testing and certification medication management. A number of noted that both pharmacy and EHR
to a subset of the structured and commenters were concerned about the systems have widely adopted the
codified Sig format component variable adoption and use of the medication history transactions.
composites that represent the most additional NDPCP SCRIPT v10.6 Response. As stated in the Proposed
common Sig instructions rather than the transactions that were proposed. A few Rule, we believe that all the above
full NCPDP Structured and Codified Sig commenters were concerned with the proposed transactions can facilitate
Format Implementation Guide v1.2. interruptive nature of real-time prescriber and pharmacist
NCPDP published recommendations for messaging alerts and suggested that they communications that advance better
implementation of the structured and be batch-processed to a team rather than care for patients and improve patient
Codified Sig format for a subset of a single provider for viewing. One safety. Therefore, in support of these
component composites that represent commenter suggested that we verify the goals and to harmonize with CMS’ Part
the most common Sig segments in the correct official names of the proposed D requirements, we have finalized our
NCPDP SCRIPT Implementation NCPDP SCRIPT v10.6 transactions. proposal to require that certified health
Recommendations Version 1.29.56 Regarding the medication history IT systems enable a user to prescribe,
Third, we proposed that a Health IT transactions, a few commenters noted send, and respond to the following
Module certified to this criterion be that many EHRs support additional NCPDP SCRIPT v10.6 transactions for
capable of limiting a user’s ability to means of retrieving medication history certification to the 2015 Edition e-
electronically prescribe all medications that can offer advantages to the NCPDP prescribing criterion:
only in the metric standard, and be medication history transactions (e.g., • New prescription transaction
capable of always inserting leading HL7, proprietary third party integration, (NEWRX);
zeroes before the decimal point for direct connection with third party • Prescription change request
amounts less than one when a user payers). transaction (RXCHG);
electronically prescribes medications. Response. We thank commenters for • Prescription change response
We also proposed that the Health IT their support of the proposal. Providers transaction (CHGRES);
Module not allow trailing zeroes after a that prescribe or dispense Medicare Part • Refill prescription request
decimal point. We stated our intent for D drugs using electronic transmission of transaction (REFREQ);
proposing these requirements was to prescriptions are required to comply • Refill prescription response
support more precise prescription doses with the standards that CMS has transaction (REFRES);
in order to reduce dosing errors and adopted under the Medicare • Cancel prescription request
improve patient safety. Prescription Drug, Improvement, and transaction (CANRX);
Last, we proposed to adopt and Modernization Act (MMA) of 2003. • Cancel prescription response
include the February 2, 2015 monthly CMS adopted NCPDP SCRIPT v10.6 for transaction (CANRES);
Part D e-prescribing in the 2013 • Fill status notification (RXFILL);
version of RxNorm in this criterion as

the baseline version minimum Physician Fee Schedule final rule (77 • Medication history request
standards code set for coding FR 69330–69331) effective November 1, transaction (RXHREQ); and
medications. 2013, including the following • Medication history response
transactions which we also proposed to transaction (RXHRES).
56 http://www.ncpdp.org/NCPDP/media/pdf/ We have confirmed the official name
SCRIPTImplementationRecommendationsV1- 57 http://www.healthit.gov/sites/default/files/9-5- of these transactions with NCPDP. We
29.pdf. federalhealthitstratplanfinal_0.pdf. note that the requirements we have
finalized outline the capabilities that NVLAP accredited testing laboratories. noted that there are newer versions to
certified health IT must be able to We strongly encourage persons or the NCPDP SCRIPT Implementation
support, and do not require providers to entities to submit such test procedures, Recommendations than v1.29. These
use these functionalities when e- test tools, and test data to us if they commenters were concerned that
prescribing. The requirements of believe such procedures, tools, and data guidance on implementing the most
providers and prescribers for e- could be used to meet certification common Sig instructions is still
prescribing are specified by other criteria and testing approval evolving and suggested that we wait
programs, such as the implementation requirements, including those for e- until there is more implementation
of the Medicare Modernization Act and prescribing functionalities. Given our experience with using the NCPDP
the EHR Incentive Programs. We also policy that permits any person or entity Structured and Codified Sig Format v1.2
note that there are other standards and to submit test procedures, test tools, and and later versions before considering
services available for requesting and test data for approval and use under the inclusion in a certification criterion. A
receiving medication history ONC Health IT Certification Program, number of commenters supported the
information. Our adoption of the we encourage stakeholders to review the Sig segment for the indication for the
NCPDP SCRIPT v10.6 medication Federal Register notice and submit test medication to be documented in
history request and response procedures, test tools, and test data for SNOMED CT® to assist the pharmacist
transactions is consistent with a approval by the National Coordinator in with medication counseling and care
standard that commenters agreed is accordance with the instructions coordination, whether or not ONC were
widely used and—as above stated—has outlined in the notice.58 to adopt the full NCPDP Structured and
been adopted by the health care We look forward to testing tools that Codified Sig Format v1.2.
industry. Our adoption of these allow pharmacy communications to Response. We thank commenters for
requirements does not preclude either be simulated or sent by a their detailed comments and
developers from incorporating and pharmacy system that has agreed to recommendations. We acknowledge the
using technology standards or services participate in the ONC Health IT limitations of the 140 character
not required by our regulation in their Certification Program as a pilot test structured and codified Sig, and the
health IT products. system that is able to emulate real-life concerns with low implementation of
Regarding how message notifications e-prescribing scenarios. We note that we the NCPDP SCRIPT Structured and
are presented to health IT users, we intend to analyze any differences Codified Sig Format v1.2 and later
believe this is a design feature that between our requirements for testing versions. In light of our decision to
should be left to providers and health IT and certification to this certification focus on interoperability and
developers to determine, including criterion and other industry certification considerations about the maturity of
whether batch notification is preferable programs for e-prescribing to determine standards, we have not finalized the
to real-time messaging alerts. opportunities for alignment. However, proposal to require a Health IT Module
Comments. Some commenters we note that industry certification certified to this criterion to enable a user
suggested that it was premature to programs may address a different use to enter, receive, and transmit codified
require end-to-end bidirectional testing case and potentially test more Sig instructions in a structured format.
because they believed pharmacy functionality than required by this While we continue to believe that e-
systems may not support the certification criterion. prescribed medication instructions
transactions. Commenters also asked for Comments. A number of commenters should be transmitted in a structured
clarification on how certified health IT were concerned with the limitation of format for improved patient safety and
would be tested to demonstrate end-to- the NCPDP Structured and Codified Sig for clearer communication of the
end bidirectional messaging. A number Format Implementation Guide v1.2 that prescribing information as intended by
of commenters suggested ONC consider limits the structured and codified Sig the prescriber, we do not believe a
deeming Surescripts certification to text element to 140 characters, and standard is ready for adoption at this
count towards meeting the requirements noted that it could hinder the ability to point in time. We will continue to
of ONC’s Health IT Certification transmit complex dosing instructions monitor CMS’s requirements for Part D
Program. A few commenters also were (e.g. tapers). Commenters noted that a e-prescribing, and may reconsider this
concerned about the differences stance for future rulemaking based on
later version of the NCPDP SCRIPT
between Surescripts and testing and newer versions of the NCPDP SCRIPT
Standard Implementation Guide
certification requirements under the Standard Implementation Guide that
expands this text element length to
ONC Health IT Certification Program. may provide implementation
Response. ONC published a notice in 1,000 characters, but recommended that
we not adopt this version until CMS has improvements.
the Federal Register (80 FR 32477) that While we are not adopting the NCPDP
restated our commitment to work with adopted a later version as a requirement
SCRIPT Structured and Codified Sig
the health IT industry towards a more for part of Part D e-prescribing.
Format v1.2 in its entirety, we agree
streamlined health IT testing and Commenters were also concerned that
with commenters on the potential
certification system. This notice the NCPDP Structured and Codified Sig
benefits of a field that captures the
addressed a flexibility included in the Format v1.2 is not widely implemented reason for the prescription. This
ONC Health IT Certification Program and needs more testing. A number of information has value for care
that allows the National Coordinator to commenters noted NCPDP is in the coordination between prescribers,
approve test procedures, test tools, and process of updating the NCPDP SCRIPT pharmacists, and care team members.
test data developed by non- Implementation Recommendations to NCPDP SCRIPT v10.6 supports the
governmental entities for testing reflect updates in guidance on exchange of the reason for the
efficiencies in the ONC Health IT implementation of the most common prescription in a few ways, including (1)
Certification Program. A person or Sig instructions. Some commenters also medication-associated diagnosis using
entity may submit a test procedure or 58 https://www.federalregister.gov/articles/2015/
diagnosis elements in the DRU (Drug
test tool (which includes test data) to 06/09/2015-13510/acceptance-and-approval-of-
Segment) and (2) medication indication
the National Coordinator for Health IT non-governmental-developed-test-procedures-test- using the indication elements in the SIG
to be considered for approval and use by tools-and-test-data-for. (Structured Sig Segment).
For the first method, NCPDP SCRIPT request and response, refill request and amounts less than one when a user
v10.6 supports use of ICD–9–CM codes response, fill status, and medication electronically prescribes all
or ICD- 10–CM codes with an additional history request and response NCPDP medications, as well as not allow
qualifier. However, the standard does SCRIPT v10.6 transactions that we have trailing zeroes after a decimal point.
not permit the medication-associated required in this criterion (see discussion Stakeholder feedback has indicated that
diagnosis to be exchanged using above). Again, we note that this medication labels will contain dosing
SNOMED CT® codes until version requirement would only apply to the instructions in the metric standard if the
2013011 and later. We continue to capability that a certified Health IT prescriber doses in the metric standard.
support SNOMED CT® as the Module certified to this criterion has to Along with federal partners (including
vocabulary code set for clinical demonstrate, not that a provider is the FDA and CDC),61 we encourage
diagnoses. Despite the limitation of required to populate the field for reason pharmacies to ensure the labels
NCPDP SCRIPT v10.6 regarding for the prescription when e-prescribing. maintain the metric standard for dosing
exchange of SNOMED CT® codes for For the first method described above, instructions. Guidance already exists
medication-associated diagnoses, e- we note that with compliance deadline encouraging this as a best practice for
prescribing transactions that include the of October 1, 2015, for use of ICD–10– medication labeling.62 We understand
reason for the prescription support CM and the effective date of this final that industry best practices also promote
patient safety and align with initiatives rule, we intend to test compliance with the provision of a metric dosing device
underway at HHS.59 While the use of ICD–10–CM for the purposes of testing along with oral liquid medications.63
ICD–10–CM for medication-associated and certification under the ONC Health Last, for purposes of patient safety, we
diagnoses is not ideal, the value of IT Certification Program. would also encourage health IT
requiring a field for medication- We are also including an optional developers to implement industry
associated diagnoses in accordance with provision that would test a Health IT recommendations around the use of
NCPDP SCRIPT v10.6 outweighs the Module’s ability to enable a user to ‘‘tall man lettering’’ to differentiate
limitations of that version of the receive and transmit the reason for the between drug names that are similar and
standard. We will consider requiring prescription using the indication commonly confused.64
certification for the medication- elements in the SIG Segment for those Comments. Commenters were
associated diagnosis using SNOMED developers that may have voluntarily supportive of the proposal to adopt the
CT® codes in a future version of this chosen to implement the Structured and February 2, 2015, monthly version of
certification criterion if we adopt a Codified Sig Format v1.2. RxNorm. A few commenters suggested
version of NCPDP SCRIPT that can Comments. Commenters were that we adopt this version at a
support medication-associated generally supportive of improving minimum, but allow implementation of
patient safety through use of the metric later versions.
diagnoses using SNOMED CT® codes.
standard for dosing, but recommended Response. We thank commenters for
The second method described above
that this requirement only apply to oral their support and have adopted the
(medication indication using indication
liquid medications. A number of September 8, 2015 monthly version of
elements in the SIG) does support the
commenters noted that the dose RxNorm.65 As we finalized in the 2014
use of SNOMED CT® vocabulary. In
quantity for non-oral, non-liquid Edition final rule (77 FR 54170), we
order to implement the indication
medications may not be representable remind stakeholders that our policy for
elements in the SIG, developers would
using metric units (e.g., number of puffs ‘‘minimum standards’’ code sets permits
need to implement at least a subset of
for inhalers, number of drops for ear and the adoption of newer versions of the
the structured and codified Sig format
eye drops, ‘‘thin film’’ for topic creams adopted baseline version minimum
component composites that represent and ointments). There was some standards code sets for purposes of
the most common Sig instructions as concern that pharmacies may translate certification unless the Secretary
described in the SCRIPT metric prescribing instructions into specifically prohibits the use of a newer
Implementation Recommendations more ‘‘patient friendly’’ instructions version (see § 170.555 and 77 FR 54268).
Version 1.29 60 and later. As we have (such as translating from mL to We agree with stakeholders that the
not adopted the proposal to require a ‘‘spoonfuls’’) that could lead to patient adoption of newer versions of RxNorm
Health IT Module certified to this dosing concerns. Commenters were also can improve interoperability and health
criterion to enable a user to enter, supportive of the proposal to require the IT implementation.
receive, and transmit codified Sig use of standard conventions for leading Comments. A few commenters noted
instructions in a structured format, zeroes and decimals (i.e., a leading zero there is a need for standards for e-
implementation of this second method is always inserted before the decimal prescribing of controlled substances
would depend on whether the point for amounts less than one, as well (EPCS). One commenter suggested that
developer voluntarily chooses to as not allowing trailing zeroes after a a standard for prior authorization (ePA)
implement Structured and Codified Sig decimal point). prescribing transactions is needed.
Format v1.2. Response. We thank commenters for Response. We thank commenters for
Given the options discussed above, their support of the proposal, and for these suggestions, but note that these
we have finalized a requirement that clarifying the issue about non-metric
requires a Health IT Module to enable dose quantities. Given this input and 61 http://www.cdc.gov/MedicationSafety/protect/
a user to receive and transmit the reason support, we have finalized the protect_Initiative.html#MedicationErrors.
for the prescription using the diagnosis requirement that a Health IT Module be
62 http://www.ncpdp.org/NCPDP/media/pdf/wp/
elements in the DRU Segment. This DosingDesignations-OralLiquid-

capable of limiting a user’s ability to
MedicationLabels.pdf.
requirement would apply to the new, electronically prescribe oral, liquid 63 http://www.ncpdp.org/NCPDP/media/pdf/wp/
change request and response, cancel medications in only metric standard DosingDesignations-OralLiquid-
units of mL (i.e., cc units will not be MedicationLabels.pdf.
59 http://chainonline.org/research-tools/ 64 http://www.ismp.org/Tools/tallmanletters.pdf.
allowed for certification). A Health IT
improving-hit-prescribing-safety/. 65 We refer readers to section III.A.2.c (‘‘Minimum
60 http://www.ncpdp.org/NCPDP/media/pdf/ Module certified to this criterion would Standards’’ Code Sets) for a more detailed
SCRIPTImplementationRecommendationsV1- also be required to always insert leading discussion of our adoption of the September 8, 2015
29.pdf. zeroes before the decimal point for monthly version of RxNorm.
comments are outside the scope of this CMS programs point to the use of providing additional context and
criterion as proposed. technology certified to create C–CDA information for providers to make care
• Common Clinical Data Set documents with the Common Clinical decisions when receiving and sending
Summary Record—Create; and Data Set, including for chronic care transition of care/referral summary
Common Clinical Data Set Summary management services in the CY 2016 documents. As noted above, certain
Record—Receive Physician Fee Schedule final rule (80 CMS programs have required or
FR 41796). CMS programs also encouraged that this data be transmitted
2015 Edition Health IT Certification Cri- encourage the use of certified health IT between care settings. Inclusion of this
terion for various settings and purposes.66 data will promote consistency for
§ 170.315(b)(4) (Common Clinical Data Set Accordingly, we have adopted a new transitions of care across care settings
summary record—create) and highlight ongoing efforts to develop
2015 Edition ‘‘Common Clinical Data
Set summary record—create’’ standards for representing this data
2015 Edition Health IT Certification Cri- certification criterion to support this electronically.
terion and other use cases. We have also Common Clinical Data Set Summary
§ 170.315(b)(5) (Common Clinical Data Set adopted a similar criterion that would
summary record—receive) Record—Receive
support receipt of health information
exchanged in accordance with this In addition to adopting a new
In the Proposed Rule under the functionality (Common Clinical Data Set certification criterion for ‘‘Common
proposed 2015 Edition ‘‘transitions of summary record—receive’’ certification Clinical Data Set summary record—
care’’ certification criterion, we solicited criterion). create,’’ we have also adopted a
comment on whether we should adopt complementary certification criterion
and make available for testing and Common Clinical Data Set Summary focused on the receipt and proper
certification a separate certification Record—Create processing of a transition of care/referral
criterion focused on the capability to This new criterion would require a summary formatted to C–CDA and with
create a summary record formatted to Health IT Module enable a user to create the Common Clinical Data Set. Our goal
the C–CDA Release 2.0 with or without a transition of care/referral summary is to ensure that when a C–CDA
the ability to meet the requirements of formatted in accordance with C–CDA document is created consistent with the
the Common Clinical Data Set Release 2.1 and that includes, at a ‘‘Common Clinical Data Set summary
definition. minimum, the Common Clinical Data record—create’’ certification criterion
Comments. Comments generally that the receiving system can properly
Set and patient matching data. For the
supported the proposal to adopt a process the information for informing
same reasons described in the ‘‘ToC’’
separate certification criterion for the care coordination. This has value for
certification criterion above, the patient
ability of a Health IT Module to create stakeholders such as providers who may
match data represent a first step forward
a summary care recorded formatted to be participating in other programs that
to improving the quality of data
the C–CDA standard. A few commenters require the use of the ‘‘Common Clinical
included in an outbound summary care
suggested that this certification criterion Data Set summary record—create’’
would only be valuable if the Common record to improve patient matching.
Please refer to our decision to adopt functionality as well as registries that
Clinical Data Set was included as well. may be recipients of this information.
Similar to the comments received for C–CDA Release 2.1 for all certification
criteria that reference C–CDA standard As stated in the Federal Health IT
the ‘‘ToC’’ criterion summarized Strategic Plan, core technical standards
previously in this section of the creation in the 2015 Edition as
described further in the preamble for the form the foundation for interoperability,
preamble, commenters were concerned and systems that send and receive
that C–CDA documents formatted to ‘‘ToC’’ certification criterion. Consistent
with our decision for the ‘‘ToC,’’ information in these common standards
Release 2.0 would not provide will help ensure the meaning of
compatibility with C–CDA Release 1.1. ‘‘clinical information reconciliation and
incorporation,’’ and ‘‘C–CDA creation information is consistently
These commenters recommended that understood.67
this certification criterion should performance’’ criteria described
elsewhere in this section of the In order to ensure the receiving
require creation of C–CDAs consistent system correctly processes the C–CDA
with C–CDA Release 2.1. preamble, this certification criterion
references the C–CDA Release 2.1 CCD, document, we will test that a system can
Response. We agree with commenters properly validate the information in
that this criterion will be valuable if it Referral Note, and (for inpatient settings
only) Discharge Summary document accordance with the same requirements
includes the capability to create a of the ‘‘ToC’’ criterion (e.g., parse, detect
C–CDA with the Common Clinical Data templates for this certification criterion.
We have also included the encounter and notify users of errors, identify valid
Set. This criterion may also be valuable document templates and process data
and less burdensome for health IT diagnoses (with either the September
2015 Release of the US Edition of elements, and correctly interpret empty
developers that design technology for sections and null combinations and be
other programs and settings outside of SNOMED CT® or ICD–10 codes),
able to display a human readable format
the EHR Incentive Programs that would cognitive status, functional status,
that contains the information in the
like to require or offer functionality for reason for referral (ambulatory only),
received C–CDA document in
the creation of C–CDA documents referring or transitioning provider’s
accordance with the C–CDA standard).
without the other requirements of the name and office contact information
These methods mirror those in the
2015 Edition ‘‘transitions of care’’ (ambulatory only), and discharge
‘‘ToC’’ criterion and will provide

criterion (e.g., transport requirements). instructions (inpatient only) which are
baseline assurance that a receiving
These programs and settings may find contained in the ‘‘transitions of care’’
system can properly process the C–CDA
value for providers to create a summary criterion. This data has value for
document as together they verify that
care record or transition of care the Health IT Module is correctly
66 We refer readers to section IV.B.4 (‘‘Referencing
document in accordance with the
the ONC Health IT Certification Program’’) of this
C–CDA standard and with the Common preamble for discussion of these programs and 67 http://www.healthit.gov/sites/default/files/9-5-
Clinical Data Set. For example, existing associated rulemakings. federalhealthitstratplanfinal_0.pdf.
interpreting the received C–CDA focused on specific capabilities that portability and the proposed
document information. would give providers easy access and an certification criterion. To provide
Consistent with our decision for the easy ability to export clinical data about additional clarity, we have decided to
‘‘ToC’’ and ‘‘clinical information their patients for use in a different simply name the adopted certification
reconciliation and incorporation’’ health information technology or a third criterion in this final rule ‘‘data export.’’
certification criteria described above, we party system for the purpose of their This certification criterion’s purpose
have required certification to the choosing. We emphasized that this is to enable a user to export clinical data
C–CDA Releases 1.1 and 2.1 CCD, capability would need to be user- from health IT for one patient, a set of
Referral Note, and (for inpatient settings focused and user-driven. We proposed patients, or a subset of that set of
only) Discharge Summary document to require that a user be able to patients. The functionality included in
templates for this certification criterion. configure a Health IT Module to create the criterion is intended to support a
As previously discussed, while C–CDA an export summary for a given patient range of uses determined by a user and
Release 2.1 largely promotes or set of export summaries for as many it was not our intention to prescribe or
compatibility with C–CDA Release 1.1, patients selected and that these export imply particular uses for this
receiving systems may have to perform summaries be able to be created functionality. We also note that this
additional processing to ensure Release according to certain document-template functionality is not intended to and may
1.1 conformance with Release 2.0. We types included in the C–CDA Release not be sufficient to accomplish a full
have included a requirement that Health 2.0. We proposed to require the migration from one product to another
IT Modules be able to receive C–CDA Common Clinical Data Set as the without additional intervention because
documents with the encounter minimum data that a Health IT Module of the scope of this criterion.
diagnoses (with either the September must be capable of including in an Specifically, the data and document
2015 Release of the U.S. Edition of export summary, in addition to templates specified in this criterion
SNOMED CT® or ICD–10–CM codes), encounter diagnoses (according to the would not likely support a full
cognitive status, functional status, standard specified in § 170.207(i) (ICD– migration, which could include
reason for referral (ambulatory only), 10–CM) or, at a minimum, the version administrative data such as billing
referring or transitioning provider’s of the standard at § 170.207(a)(4) information. The criterion’s
name and office contact information (September 2014 Release of the U.S. functionality could, however, support
(ambulatory only), and discharge Edition of SNOMED CT®), cognitive the migration of clinical data between
instructions (inpatient only) for the status, functional status, reason for health IT systems and can play a role in
same reasons we have included these referral and the referring or transitioning expediting such an activity if so
data in the ‘‘Common Clinical Data Set provider’s name and office contact determined by the user.
summary record—create’’ criterion information, and discharge instructions The ‘‘inpatient only’’ and
described above. for the inpatient setting. We proposed to ‘‘ambulatory only’’ portions of the
We have also included the ‘‘section require that a user would need to be criterion that require referral and
views’’ capability from the ‘‘ToC’’ able to be able to configure the discharge information, respectively,
certification criterion to ensure that technology to set the time period within were part of the scope of 2014 Edition
Health IT Modules certified to this which data would be used to create the ‘‘data portability’’ certification criterion,
certification criterion will be able to export summary or summaries, and that are part of the transition of care
extract and allow for individual display this must include the ability to enter in criterion, and are also referenced in by
each section (and the accompanying a start and end date range as well as the the ‘‘VDT’’ criterion. As such, we see no
document header information (i.e., ability to set a date at least three years compelling reason to change this
metadata)) that was included in a into the past from the current date. We criterion’s scope and have adopted the
transition of care/referral summary proposed to require that a user would criterion with these distinctions and
received and formatted in accordance need to be able to configure the data.
with C–CDA Releases 1.1 and 2.1. This technology to create an export summary Comments. Some commenters
will allow a user to select and just view or summaries based on specific user supported requiring all of the proposed
the relevant sections without having to selected events listed in the Proposed C–CDA document templates. Other
navigate a potentially length C–CDA Rule. We proposed to require that a user commenters stated that the number of
document. would need to able to configure and set document templates should be limited.
• Data Export the storage location to which the export Some commenters had
summary or export summaries were recommendations on alternative
2015 Edition Health IT Certification Cri- intended to be saved. vocabularies to include in the C–CDA.
terion Comments. Many commenters Response. Consistent with other
§ 170.315(b)(6) (Data export) expressed support of the concept of responses provided in this final rule,
‘‘data portability.’’ Many commenters this certification criterion requires
We proposed to adopt a 2015 Edition also requested that we clarify the conformance to the C–CDA R2.1. In
‘‘data portability’’ certification criterion purpose of data portability and provide consideration of comments received on
that was revised in comparison to the related use cases to distinguish ‘‘data the Proposed Rule, we have limited the
2014 Edition ‘‘data portability’’ portability’’ from the transition of care C–CDA document template scope for
certification criterion (§ 170.314(b)(7)). certification criterion. Some this criterion to the CCD document
Similar to the 2014 Edition version, we commenters also suggested renaming template. We note that the vocabularies
proposed to include the 2015 Edition the criterion to better describe its used by the C–CDA R2.1 are defined
‘‘data portability’’ criterion in the Base intended use. One commenter noted the through the Standards Developing
EHR definition (i.e., the 2015 Base EHR ‘‘ambulatory only’’ requirement Organization (SDO) process and we do
definition). To address feedback from included in the criterion seemed to be not seek to change that approach via
health IT developers and providers on confusing data portability with this rulemaking (i.e., we adopt the
the 2014 Edition certification criterion, transition of care. C–CDA R2.1 as published). We note that
the proposed ‘‘data portability’’ Response. We appreciate commenters’ we have adopted this criterion with the
certification criterion at § 170.315(b)(6) support of the concept of data proposed inclusion of the Common
Clinical Data Set and other specified certification, particularly in 2016, will execute the data export functionality,
data, including the updated minimum not have access to three or even one contending that limiting the users could
standards code sets we discuss in year’s worth of patient health address potential performance issues
section III.A.2.c (‘‘Minimum Standards’’ information that is conformant to the that may result when executing this
Code Sets) of this preamble. standards requirements of this criterion. functionality as well as issues related to
Comments. One commenter stated A health IT developer’s and Health IT use access or misuse.
that when a note is signed or an order Module’s access to such health Response. We thank commenters for
is placed does not necessarily indicate information, and the quality of such raising these issues and have modified
that all relevant documentation is ready health information, will also likely vary this criterion in response. We agree that
for export as the provider may enter considerably based on the customers this certification criterion could benefit
more information in the record or a (providers) it serves. This would further from requiring health IT to include a
result could come back from a complicate testing and certification, and way to limit the (type of) users that
laboratory order. The commenter stated potentially place certain health IT would be able to access and initiate data
that this could result in incomplete data developers and products at a export functions. Thus, consistent with
being exported. Another commenter disadvantage. Therefore, we have not other certification criteria that include
stated that there should be an adopted this proposed requirement. functionality to place restrictions on the
affirmative action by the user clearly We have finalized as part of this (type of) users that may execute this
indicating the intent to initiate a data criterion a specific capability that functionality, we have adopted
export. A commenter suggested removal expresses time-based configuration corresponding language in this final
of the requirements related to event requirements. This first portion of this criterion. However, we emphasize for
configuration, stating there was no clear part of the criterion expresses that a user stakeholders this additional ‘‘limiting’’
use case. Commenters also stated that must be able to configure a time period functionality on the type of users that
the dates in the ‘‘timeframe within which data would be used to may execute the data export
configuration’’ were unclear and sought create export summaries, which must functionality is intended to be used by
clarification on whether it was an include the ability to express a start and and at the discretion of the provider
admission date, an encounter date, the end date range. The second portion of organization implementing the
date the data was entered in the system this part of the criterion expresses three technology. In other words, this
or some other date. One commenter time-based actions/configurations a user functionality cannot be used by health
recommended that providers should must be able to complete based on the IT developers as an implicit way to
have access to the full set of data date range they have specified. A user thwart or moot the overarching user-
included in the certified health IT for would need to be able to: (1) Create driven aspect of this certification
the entire period covered by a provider’s export summaries in real-time (i.e., on criterion.
contract. The HITSC stated in written demand); (2) configure technology to • Data Segmentation for Privacy
advice to the National Coordinator that create such summaries based on a
the ‘‘trigger conditions’’ were not relative date and time (e.g., generate a 2015 Edition Health IT Certification Cri-
set of export summaries from the prior terion
appropriate and went beyond what it
month on the first of every month); and § 170.315(b)(7) (Data segmentation for pri-
believed the policy goals for this vacy—send)
criterion.68 (3) configure technology to create such
Response. In consideration of summaries based on a specific date and
comments, we have not finalized the time (e.g., generate a set of export 2015 Edition Health IT Certification Cri-
requirement to permit a user to summaries with a date range between terion
configure a data export based on signing January 1, 2015 and March 31, 2015 on § 170.315(b)(8) (Data segmentation for pri-
a note or placing an order. We believe April 1, 2015 at 1:00AM EDT). We vacy—receive)
that a time-based approach as the reiterate that a Health IT Module will
need to support the user’s ability to We proposed to adopt two new 2015
baseline scope for this certification
select and configure those dates and Edition certification criteria referred to
criterion is the most appropriate,
times. as ‘‘data segmentation for privacy
consistent with our policy goals, and
Comments. One commenter requested (DS4P)-send’’ and data segmentation for
helps balance user functionality
that the ‘‘file location’’ be a Direct privacy (DS4P)-receive.’’ These criteria
required for the purposes of certification
address or an external location in an were not proposed to be in scope for the
with developer burden. In that regard,
HIE or some other system. EHR Incentive Programs. Rather, they
by finalizing a time-based approach, we
Response. For the purposes of were proposed to be available for health
have determined that this final
certification, we clarify that a Health IT IT developers and other programs. The
certification criterion can be more proposed certification criteria focused
Module must, at a minimum, permit a
simply described by combining the on technical capabilities to apply and
user to select a local or network storage
proposed ‘‘timeframe’’ and ‘‘event’’ recognize security labels (i.e., privacy
location. We have intentionally left the
configurations into one provision. metadata tags) to a patient’s health
We have also not adopted the specific transport method (e.g., sending
to a Direct email address) or further record. We noted in the Proposed Rule
proposed time requirement that
product integration (e.g., routing the that the technical capabilities to do so
technology would need to include the
export to a web service, web service or would enable a sending provider’s
ability to set a date at least three years
integration engine) to the discretion of technology to tag a patient’s record such
into the past from the current date. We
the health IT developer and its that recipient of such a record (if such
have determined that we could not

customers. recipient had also implemented the
properly test and certify to such a
Comments. Commenters expressed technology) would be able to recognize
requirement. We acknowledge that some
concern that privacy and security issues that the patient’s record was ‘‘sensitive’’
Health IT Modules presented for
may arise when data is exported. Some and needed special protection under
68 https://www.healthit.gov/FACAS/sites/faca/ commenters suggested that the criterion federal or state privacy law. For
files/HITSC_Certification_NPRM_TSSWG_ should require an ability to limit the example, DS4P was piloted to support
Comments_2015-05-20.pdf. users that would be permitted to the exchange of health information
covered by 42 CFR part 2 (‘‘Part 2’’), not do so in the proposed regulation interoperability, supporting delivery
which are federal regulations text. system reform, reducing health
implementing the law protecting Commenters that expressed disparities, and supporting privacy
confidentiality of, and restricting access, opposition to the DS4P certification compliance), we have adopted the
to substance abuse related patient criteria and proposed standard stated proposed DS4P criteria. We note that
records. that the standard was immature and not these criteria are not part of the 2015
We proposed to adopt the DS4P widely adopted. The commenters Edition Base EHR definition, are not
standard as outlined in the HL7 Version expressed concern that segmentation required in the certification program
3 Implementation Guide: DS4P, Release can lead to incomplete records and that policies for health IT developers to seek
1 (DS4P IG), Part 1: CDA R2 and Privacy receiving systems may not know how to certification to, and are not required for
Metadata.69 The standard describes the handle the DS4P tagged data, which providers to participate in the EHR
technical means to apply security labels could lead to incomplete records that Incentive Programs. As we have stated,
to a health record and data may be may subsequently contribute to patient DS4P enables sensitive health
tagged at the document-level, the safety issues. Several comments stated information to be exchanged
section-level, or individual data that DS4P has only been piloted with electronically and we strongly
element-level. The DS4P standard also Part 2 data. One commenter requested encourage health IT developers to
provides a means to express obligations clarification on how a sending system include DS4P functionality and pursue
and disclosure restrictions that may will know if a receiving system supports certification of their products to these
exist for the data. The DS4P standard DS4P. Commenters also requested criteria in order to help support their
does not enforce privacy laws or alter guidance on how to visualize in the users’ compliance with relevant state
privacy laws. A healthcare provider is system that data may be incomplete or and federal privacy laws that protect
still responsible for ensuring that use, what workflows should be used when sensitive health information.
access, or disclosure of the sensitive segmented data is received. Several We agree with commenters that we
health information complies with commentators requested that we should explicitly state that document-
relevant state and federal law. DS4P consider the Integrating the Healthcare level tagging is the scope required for
supports that compliance in an Enterprise (IHE) IT Infrastructure certification and have made this
electronic health environment and is a Technical Framework Volume 4— modification to criteria. We have also
means for providers to electronically National Extensions—Section 3.1 Data clearly indicated in the DS4P-receive
flag certain pieces of data that may be Segmentation for Privacy (DS4P) 70 as an criterion that the ability to receive a
subject to those laws. Importantly, the alternative to the DS4P IG. summary record in accordance with the
DS4P standard is ‘‘law-agnostic’’ and Response. We appreciate the C–CDA R2.1 is required. This was
not restricted to Part 2 data. It may be thoughtful comments submitted on the inadvertently omitted from the
implemented to support other data proposed criteria. Notably, with respect criterion’s proposed regulation text, but
exchange environments in which to the comments we received that was referenced in the DS4P-send
compliance with state or federal legal expressed opposition to the DS4P criterion.
frameworks require sensitive health standard our analysis of the comments In response to the broader comments
information to be tagged and segmented. indicates that commenters were more that were critical of the notion of DS4P,
Comments. In general, most concerned with the complexity of the we reiterate that DS4P is a technical
commenters recognized the value in privacy law landscape than they were standard that helps healthcare providers
complying with laws that require about the technology itself. In this comply the laws applicable to them. As
protecting sensitive health information. regard, the vast majority of comments such, healthcare providers should
However, we received comments both focused on policy-related questions already have processes and workflows
expressing support and opposition to such as the likelihood that specialized to address their existing compliance
adopting the proposed certification privacy laws might create ‘‘holes’’ in the obligations. The DS4P standard does not
criteria at this time. Commenters in data. Additionally, we received no itself create incomplete records. Under
support of the DS4P certification criteria comments that provided substantive existing law patients already have the
and proposed standard pointed out the technical criticisms of the DS4P right to prevent re-disclosure of certain
standard was the best currently standard. types of data by withholding consent to
available option for protecting sensitive In reference to the DS4P standard’s its disclosure or to place restrictions on
health information and allows maturity, we note that it is considered its re-disclosure. DS4P allows providers
behavioral health, substance abuse, and a ‘‘normative’’ standard from the HL7 to tag data as sensitive and express re-
other data to be available at the point of perspective—a status which requires disclosure restrictions and other
care. Commenters cited teenagers, substantially higher HL7 membership obligations in an electronic form. DS4P
victims of intimate partner violence, participation compared to a Draft does not determine whether a
and patients with behavioral health or Standard for Trial Use (DSTU) status. segmentation obligation exists legally or
substance abuse conditions as While we recognize that to date the what that legal obligation means to the
particularly vulnerable populations that standard has not been widely adopted, recipient. Instead, DS4P allows for
would benefit from the ability to it has been used with Part 2 data and tagging and exchange of health
exchange sensitive health information other sensitive health information by information that has already been
electronically. Several commentators the Substance Abuse and Mental Health determined to be sensitive and in need
pointed out that, while we limited Services Administration (SAMHSA), the of special protections. In the absence of
segmentation to document-level tagging DS4P, this specially protected data may
U.S. Department of Veterans Affairs

in the Proposed Rule preamble, we did (VA), and private companies. still be exchanged, if consent is given
In consideration of the comments we for disclosure, by fax or mail, but these
received and several of HHS’ methods may make the data unavailable
product_brief.cfm?product_id=354 Completed in electronic form in the receiving
Normative Ballot in January 2014 and was overarching policy goals (enabling
successfully reconciled in February 2014. HL7 provider’s EHR.
approved the final standard for publication and 70 http://www.ihe.net/uploadedFiles/Documents/ We recognize that the current privacy
ANSI approved in May 2014. ITI/IHE_ITI_TF_Vol4.pdf. law landscape is complex. Despite the
complexities of the privacy law would require a Health IT Module to a glide path for adoption of EHRs by
landscape, we believe now is the time enable a user to record, change, access, home health care and hospice providers.
to support a standard that allows for create and receive care plan information Response. We thank commenters for
increased protection for individuals in accordance with the Care Plan their feedback. As stated in the
with sensitive health conditions and document template in the HL7 Proposed Rule (80 FR 16842), we
enables sensitive health information to Implementation Guide for CDA® believe the Care Plan document
flow more freely to authorized Release 2: Consolidated CDA Templates template has value for improving
recipients. Over 43 million Americans for Clinical Notes.74 We explained that coordination of care and provides a
ages 18 and up have some form of the C–CDA Release 2.0 contains a Care structured format for documenting
mental illness.71 As stated before, Plan document template that provides a information such as goals, health
providers already have workflows to structured format for documenting concerns, health status evaluations, and
care for individuals with these and information such as the goals, health interventions. It represents a consensus-
other sensitive health conditions. DS4P concerns, health status evaluations and based approach and is the best standard
allows providers the ability to move outcomes, and interventions. We available today for capturing and
away from fax-and-paper information emphasized that the Care Plan sharing care plan information. The
exchange into interoperable exchange of document template is distinct from the document template has also been
sensitive health information. ‘‘Plan of Care Section’’ in previous demonstrated through pilots in the S&I
Oftentimes, individuals with sensitive versions of the Framework. As such, we have adopted
health conditions require coordinated C–CDA, stating that the Care Plan this criterion. To note, we have adopted
care that is not possible if sensitive document template represents the the C–CDA Release 2.1 standard for this
health data cannot be exchanged. synthesis of multiple plans of care (for certification criterion for consistency
Additionally, the technical ability to treatment) for a patient, whereas the with our approach to the C–CDA in this
segment data supports the Precision Plan of Care Section represented one final rule and for the same substantive
Medicine Initiative 72 and delivery provider’s plan of care (for treatment). reasons discussed earlier in this
system reform 73 where those initiatives The Proposed Rule noted that the C– preamble under the ‘‘ToC’’ certification
depend on making computable CDA Release 2.0 had renamed the criterion.
individual’s choices about disclosure of previous ‘‘Plan of Care Section’’ as the Comments. A few commenters
their data. ‘‘Plan of Treatment Section (V2)’’ for suggested that it was not necessary to
The current DS4P standard does not clarity. We sought comment on whether adopt this certification criterion because
have a service discovery mechanism to we should require for certification to other proposed criteria also reference
determine if a potential recipient is able this criterion certain ‘‘Sections’’ that are the C–CDA standard and Care Plan
to receive a tagged document. We expect currently deemed optional as part of the template.
that providers will have to determine Care Plan document template for Response. As described in more detail
certification to this criterion, namely the in this preamble for the other
the receiving capabilities of their
‘‘Health Status Evaluations and certification criteria we have adopted
exchange partners, similar to how they
Outcomes Section’’ and ‘‘Interventions that reference the C–CDA standard (e.g.,
have to work with their exchange
Section (V2).’’ ‘‘ToC,’’ ‘‘data export,’’ and
partners today when they are manually
Comments. Commenters were ‘‘Consolidated CDA creation
exchanging sensitive health information
supportive of the proposal to adopt a performance’’), we have adopted
via fax. Additionally, the DS4P standard
new voluntary ‘‘care plan’’ criterion. reduced requirements for C–CDA
contains a human-readable text block
The commenters stated that the Care Release 2.1 document template
that will render in the recipients
Plan document template supports conformance per the use case(s) served
system—putting the human healthcare
broader information about the patient, by each certification criterion. As such,
user on notice that they are viewing the ‘‘ToC,’’ ‘‘data export,’’ ‘‘clinical
sensitive health information, allowing including education, physical therapy/
range of motion, and social information reconciliation,’’ and
them to take appropriate actions in their ‘‘Consolidated CDA creation
system manually. interventions not commonly found in
other parts of the C–CDA standard. A performance’’ criteria do not require the
We are not aware of implementations
few commenters stated that the C–CDA C–CDA Release 2.1 Care Plan document
that have used the IHE National
Release 2.0 Care Plan document template. Therefore, we have adopted
Extensions for Data Segmentation for
template only represents a ‘‘snapshot in this criterion to support the care
Privacy and do not agree with
time,’’ rather than a dynamic, planning use cases recited above and in
permitting it as an alternative approach
longitudinal shared care plan. Some the Proposed Rule.
to DS4P for the purposes of certification Comments. A commenter
at this time. commenters expressed concern that this
recommended that we be more specific
• Care Plan document template is new to C–CDA
Release 2.0 and suggested that there was about which optional (e.g., ‘‘MAY’’)
no implementation experience. Other items in the Health Concerns section of
terion commenters stated that clinician input the C–CDA Care Plan document
§ 170.315(b)(9) (Care plan) was factored into the development of template should be required.
the Care Plan document template and Response. As we stated in section
We proposed to adopt a new 2015 that there have been pilots through the III.A.2.b of this preamble regarding
Edition certification criterion that S&I Framework Longitudinal referenced standards for certification, if
an element of a standard or IG is
Coordination of Care Initiative.75

71 http://www.samhsa.gov/disorders.
Commenters suggested that the optional or permissive in any way, it
72 https://www.whitehouse.gov/sites/default/files/
inclusion of the Care Plan document will remain that way for testing and
docs/pmi_privacy_and_trust_principles_july_
template in certification would provide certification unless we specified
2015.pdf; see also https://www.whitehouse.gov/the- otherwise in regulation. To the
press-office/2015/01/30/fact-sheet-president-
obama-s-precision-medicine-initiative. 74 http://www.hl7.org/implement/standards/ commenter’s question, we have not
73 http://www.hhs.gov/healthcare/facts/blog/ product_brief.cfm?product_id=379. specified otherwise in regulation. We
2014/09/improving-health-care-delivery.html. 75 http://wiki.siframework.org/LCC+Pilots+WG. note, however, that we would expect
that health IT developers and providers 2015 Edition Health IT Certification Cri- certified to the 2015 Edition ‘‘CQM—
would work together to determine terion record and export’’ certification
whether the optional items are relevant § 170.315(c)(1) (Clinical quality measures— criterion in 2017.
and useful for the provider and patients record and export) Comments. The majority of
intended to be served by the Health IT commenters recommended adopting the
Module. We proposed to adopt a 2015 Edition HL7 CDA® R2 Implementation Guide:
Comments. Most commenters ‘‘clinical quality measures (CQM)— Quality Reporting Document
expressed support for requiring a Health record and export’’ certification Architecture—Category I (QRDA I);
IT Module to be certified to the criterion that was revised in comparison Release 1, DSTU Release 3, US Realm
optionally designated sections in the to the 2014 Edition ‘‘CQM—capture and (‘‘QRDA Category I Release 3 IG’’ or
C–CDA Release 2.0 Care Plan document export’’ certification criterion ‘‘Release 3’’).76 Commenters noted that
template to meet this criterion. (§ 170.314(c)(1)). In the Proposed Rule, CMS is using the QRDA Category I
Commenters noted the Health Status we explained that we would align our Release 3 IG for the 2015 update eCQM
Evaluations and Outcomes Section use of the term ‘‘record’’ used in other measures and the 2016 reporting period
incorporates patient-reported outcomes 2014 and 2015 Edition certification and recommended that we adopt this
criteria and proposed to call this version for program alignment.77
to improve care and assist with the long-
certification criterion ‘‘CQM—record Commenters indicated Release 3
term goal of a truly integrated care plan.
and export.’’ We proposed to require addresses known issues, fixes errors,
Commenters also suggested the
that a system user be able to export and adds missing content compared to
Interventions Section (V2) would be
CQM data formatted to the Quality earlier versions of the QRDA Category I
useful for patients and family
Reporting Document Architecture standard. Commenters also noted that
caregivers.
(QRDA) Category I standard at any time Release 3 uses an incremental version of
Response. We thank commenters for the user chooses for one or multiple
their feedback. We agree with the underlying data model (the Quality
patients and without subsequent Data Model 4.1.1) that is a step-wise
commenters that the Health Status developer assistance to operate. We also
Evaluations and Outcomes Section and approach toward harmonized CQM and
proposed to require that this CDS standards that stakeholders are
Interventions Section (V2) of the C–CDA certification criterion be part of the set
provide important information for developing.
of criteria necessary to satisfy the ‘‘2015 While commenters were supportive of
incorporating the patient’s perspective Edition Base EHR’’ definition (see also
in an effort to improve outcomes and the work and direction on harmonized
section III.B.1 of this preamble for a CQM and CDS standards to produce an
the long-term goal of a longitudinal, discussion of the 2015 Edition Base EHR
dynamic, shared care plan. Accordingly, anticipated QUICK FHIR-based DSTU,
definition). We solicited comment on all commenters noted that no such
we have specifically identified these the standard, including versions of
sections as required to be met for standard is currently available and that
QRDA Category I, we should adopt for
certification to this criterion. it is premature to require any such
this certification criterion with
standard for the 2015 Edition. Many
Comments. A few commenters consideration given to where the
commenters stated that stakeholders are
suggested that this criterion should also industry may be with adoption of CQM
still in the process of implementing
include a requirement for the receiving and CDS standards over the next few
QRDA and that we should adopt an
system of a C–CDA Care Plan to be able years. In particular, we identified
incremental version of QRDA rather
to reconcile the care plan information industry efforts to harmonize CQM and
than pivot to the QUICK standard at this
with the patient’s record in the CDS standards. We asked for comment
time.
receiving system. on the following version of QRDA or
Response. With consideration of
Response. While reconciliation is QRDA-like standards:
• HL7 Implementation Guide for CDA commenters’ feedback, we have adopted
important and may be appropriate for this criterion and the QRDA Category I
any future iteration of this certification Release 2: Quality Reporting Document
Architecture (QRDA), DSTU Release 2 Release 3 IG (both Volumes 1 and 2) for
criterion, this functionality is outside this criterion. In order to accommodate
the scope of our proposal. Therefore, we (July 2012);
• HL7 Implementation Guide for CDA Release 3, we are amending the
have not included in this criterion. We paragraph level at § 170.205(h) to move
note that the industry continues to Release 2: Quality Reporting Document
Architecture (QRDA), DSTU Release 2 the standard that is required for the
improve and develop advanced care 2014 Edition ‘‘CQM—capture and
planning standards and tools, which (July 2012) and the September 2014
Errata; or export’’ criterion to § 170.205(h)(1), and
may address the incorporation of care adopting Release 3 at § 170.205(h)(2).
planning information. As such, we will • A QRDA-like standard based on the
anticipated Quality Improvement and We agree with commenters that it is
continue to monitor these developments too early to adopt the QUICK CQM
for consideration in future rulemaking. Clinical Knowledge (QUICK) Fast
Healthcare Interoperability Resources standards, but will continue to support
Comments. A few commenters (FHIR)-based DSTU. the development and piloting of these
suggested that we are conflating certain In asking for comment, we sought to harmonized CQM and CDS standards
sections of the C–CDA Care Plan understand the tradeoffs stakeholders and reassess their appropriateness for
document template (e.g., Health perceive in adopting each standard certification at the time of a relevant
Concerns and Goals) with items considering that the EHR Incentive future rulemaking.
proposed in the Common Clinical Data Programs Stage 3 proposed rule Comments. Commenters expressed
Set. proposed that health IT certified to the support for the proposal to permit users
Response. We refer readers to our 2015 Edition would not be required to export CQM data formatted to the
response to this comment under the until January 1, 2018, but that EPs,
Common Clinical Data Set definition in eligible hospitals, and CAHs 76 http://www.hl7.org/implement/standards/
section III.B.3 of this preamble. product_brief.cfm?product_id=35.

participating in the EHR Incentive 77 http://www.cms.gov/Regulations-and-
• Clinical Quality Measures—Record Programs Stage 3 objectives and Guidance/Legislation/EHRIncentivePrograms/
and Export measures could upgrade to health IT eCQM_Library.html.
QRDA Category I standard for one or 54168) and continue to use the same as recited under the 2015 Edition
multiple patients at any time the user description for the 2015 Edition. We ‘‘CQM—record and export’’ criterion
chooses and without subsequent expect the functionalities of this summarized above, and to which we
developer assistance to operate. Some criterion to be available to any user, but refer readers. A few commenters
commenters requested clarification on the specification or limitation of types recommended that QRDA Category III
what constitutes ‘‘without subsequent of users for this functionality is outside (aggregate level CQM reports) should
developer assistance to operate’’ and the scope of certification to this not be required for this criterion.
noted that batch export could be criterion. Providers have the discretion Response. With consideration of
disruptive to overall EHR functionality. to determine the protocols for when and commenters’ feedback, we have adopted
A few commenters asked for which users should use this this criterion and the QRDA Category I
clarification of the use cases for export. functionality. Release 3 IG (both Volumes 1 and 2) for
Some commenters also requested • Clinical Quality Measures—Import this criterion. We note that we did not
clarification regarding who constitutes a and Calculate propose to require import of QRDA
‘‘user,’’ with a few commenters Category III files for this criterion and
suggesting that the ‘‘user’’ should only 2015 Edition Health IT Certification Cri- thus QRDA Category III is outside the
be those individuals with specific terion scope of this criterion.
administrative privileges. § 170.315(c)(2) (Clinical quality measures— Comments. Commenters expressed
Response. We thank commenters for import and calculate) support for the proposal to permit users
their support of the proposal. We have to import CQM data formatted to the
included in this criterion a requirement We proposed to adopt a 2015 Edition QRDA Category I standard for one or
that a user be able to export a data file ‘‘clinical quality measures (CQM)— multiple patients at any time the user
formatted in accordance with Release 3 import and calculate’’ certification chooses and without subsequent
for one or multiple patients that criterion that was revised in comparison developer assistance to operate. A few
includes all of the data captured for to the 2014 Edition ‘‘CQM—import and commenters asked for clarification of
each CQM to which the health IT was calculate’’ certification criterion the use cases for import, and the
certified. We believe that the ability to (§ 170.314(c)(2)). We proposed to justification for why all systems (even
export CQM data would serve two require that a system user be able to those previously considered ‘‘self-
purposes. First, this functionality will import CQM data formatted to the contained’’) must demonstrate import.
allow a provider or health system to QRDA standard for one or multiple These commenters noted that some
view and verify their CQM results for patients at any time the user chooses systems export CQM data to a third-
quality improvement on a near real-time and without additional assistance to party data aggregator or warehouse for
basis. Second, the export functionality operate. We proposed to no longer calculation, whereas other EHR systems
gives providers the ability to export include an exemption that would allow perform the calculation function itself.
their results to multiple programs, such a Health IT Module presented for In the latter case, some commenters
as those run by CMS, states, and private certification to § 170.315(c)(1), (c)(2), suggested it was not necessary for the
payers. and (c)(3) to not demonstrate the data system to be able to import CQM data.
As we discussed in the 2015 Edition import capability. Rather, we proposed A few commenters were not supportive
proposed rule (80 FR 16843), our intent that a Health IT Module would be of requiring import using the QRDA
is for users of certified health IT to be required to demonstrate that it could Category I standard. Rather, they
able to export CQM data formatted to import data in order to be certified to suggested import should be allowed
the QRDA Category I standard for one or this certification criterion even if it is using whatever standard or data
more patients without needing to also certified to provide ‘‘record and structure is already being used by the
request support from a developer. export’’ and ‘‘electronic submission/ system for import.
Stakeholders have noted that some report’’ functions. We solicited Response. We thank commenters for
health IT certified to the 2014 Edition comment on the version of QRDA or their support of the proposal and
‘‘CQMs—capture and export’’ criterion QRDA-like standards for individual requests for additional clarifications. We
do not provide users the ability to patient-level CQM reports we should have included in this criterion a
export QRDA Category I files ‘‘on adopt for this certification criterion. requirement that a user be able to
demand’’ and that users must submit We stated that we intend testing to the import a data file formatted in
requests for the health IT developer to 2015 Edition ‘‘CQM—import and accordance with Release 3 for one or
assist or perform the export function on calculate’’ certification criterion to multiple patients that includes all of the
their behalf. For testing and certification include the import of a larger number of data captured for each CQM to which
to the 2015 Edition ‘‘CQM—record and test records compared to testing for the the health IT was certified. We believe
export’’ criterion, we would expect 2014 Edition and to automatically de- that the ability to import CQM data
demonstration that the Health IT duplicate records for accurate CQM would serve two purposes. First, this
Module enables the user to export CQM calculation. We requested comment on functionality could streamline the
data formatted to the QRDA Category I this intent and the number of test testing and certification process by
standard for one or more patients records we should consider testing a importing QRDA Category I files rather
without needing additional developer Health IT Module for performing import than systems needing to manually enter
support. We believe that providers and and calculate functions. test patient data. Second, the import
health systems should determine the Comments. The majority of functionality can promote quality
protocols around when and how commenters recommended adopting the improvement and data sharing between
providers export CQM data, and we do HL7 CDA® R2 Implementation Guide: systems by providing systems the ability
not address this issue as part of Quality Reporting Document to import CQM data from other systems
certification as it is outside the scope of Architecture—Category I (QRDA I); in a standardized format. We note that
the ONC Health IT Certification Release 1, DSTU Release 3, US Realm ONC held a HITPC hearing on
Program. (‘‘QRDA Category I Release 3 IG’’ or certification in 2014 and the HITPC
We previously described a ‘‘user’’ in ‘‘Release 3’’). These commenters cited recommended CQM certification as a
the 2014 Edition final rule (77 FR the same reasons for adopting Release 3 top priority for providing value for
quality improvement and delivery Response. We thank commenters for transmission of clinical quality
system reform.78 While we are not supporting use of an increased number measurement data using the ‘‘base’’ (i.e.,
prescribing how data is imported into a of test records during the testing and industry-wide, non-program-specific)
system (e.g., mapped to a backend certification process and we agree that HL7 QRDA Category I and Category III
database or viewable to a provider as testing should more robustly test the standards, at a minimum (80 FR 24613–
part of the patient record), we believe pathways by which a patient can enter 24614). We also proposed, as part of this
that requiring the import functionality the numerator or denominator of a proposed criterion, to permit optional
can facilitate these use cases. measure, including exclusions and certification for health IT in accordance
As we discussed in the 2015 Edition exceptions. In regard to auto de- with the CMS ‘‘form and manner’’
proposed rule (80 FR 16843), our intent duplication, while we have adopted the requirements defined in the CMS QRDA
is for users of certified health IT to be requirement, we have not prescribed Implementation Guide.79 CMS specified
able to import CQM data formatted to how systems would demonstrate de- that health IT certified to this proposed
the QRDA Category I standard for one or duplication or what systems must do certification criterion would be required
more patients without needing to with the imported data. We are to meet the proposed CEHRT definition
request support from a developer. providing flexibility in allowing health for the EHR Incentive Programs.
Stakeholders have noted that some IT developers and providers to As detailed in the FY 2016 IPPS/
health IT certified to the 2014 Edition determine the most suitable methods for LTCH PPS proposed rule, we solicited
‘‘CQMs—import and calculate’’ criterion de-duplication and import of data for comment on the appropriate versions of
do not provide users to import QRDA the given situation. the Quality Reporting Document
Category I files ‘‘on demand’’ and that • Clinical Quality Measures—Report Architecture—Category I (individual
users must submit requests for the patient level quality reports) and
developer to assist or perform the 2015 Edition Health IT Certification Cri- Category III (aggregate level quality
terion reports) standards that should be
import function on their behalf. For § 170.315(c)(3) (Clinical quality measures—
testing and certification to the 2015 adopted. In order to give full
report) consideration to the comments received
Edition ‘‘CQM—import and calculate’’
on the appropriate versions of the
criterion, we would expect In the Proposed Rule, we stated that standards we should adopt, we did not
demonstration that the Health IT we intend to better align with the adopt a ‘‘CQMs-report’’ certification
Module enables the user to import CQM reporting requirements of other CMS criterion in the 2016 IPPS/LTCH PPS
data formatted to the QRDA Category I programs, and thus, would propose final rule (80 FR 49760). We stated that
standard for one or more patients certification policy for reporting of we anticipate adopting both the
without needing additional developer CQMs in or with annual PQRS and/or certification criterion and the
support. We believe that providers and Hospital IQR program rulemaking appropriate versions of the standards in
health systems should determine the anticipated in CY 2015. We explained a subsequent final rule later this year.
protocols around when and how that we anticipated proposing standards We also noted we intended to address
providers import CQM data, and we do for reporting of CQMs that reflect CMS’ comments received on both the
not address this issue as part of requirements for the ‘‘form and manner’’ proposed ‘‘CQMs-report’’ certification
certification as it is outside the scope of of CQM reporting (e.g., CMS program- criterion and the versions of the
the ONC Health IT Certification specific QRDA standards), allowing for standards in that same rule. We have
Program. annual updates of these requirements as used this final rule to address the
Comments. Commenters supported necessary. Under this approach, we comments and adopt the criterion and
our intent to increase the number of test noted that the ‘‘CQMs—report’’ standards as specified below.
records used during the testing and certification policy and associated Comments. Commenters were
certification process for this criterion. standards for the 2015 Edition that supportive of the proposal to adopt a
Most commenters recommended that support achieving EHR Incentive 2015 Edition certification criterion for
rather than test to a certain number of Programs requirements would be CQM reporting. There was mixed
records, testing should ensure that every proposed jointly with the calendar year feedback on whether a 2015 Edition
pathway by which a patient can enter (CY) 2016 PFS and/or IPPS proposed ‘‘CQMs—report’’ criterion should
the numerator or denominator of the rules. We clarified that we anticipated require adherence to the HL7 QRDA
given measure is tested. Commenters removing ‘‘electronic’’ from the name of Category I and Category III standards, or
were supportive of requiring health IT this certification criterion because we solely to the CMS QRDA
to demonstrate auto de-duplication of expected that all functions proposed in Implementation Guide. The majority of
imported records during the testing the 2015 Edition health IT certification commenters recommended that we not
process, but some commenters were criteria to be performed or demonstrated move to the Quality Improvement and
concerned about how systems would be electronically, unless specified Clinical Knowledge (QUICK) CQM 80
required to incorporate and reconcile otherwise. We also explained that we standards as they are unpublished and
imported data. Commenters requested anticipated naming this certification have not yet been balloted. Rather,
clarification on whether duplicate criterion ‘‘report’’ instead of commenters suggested we adopt
records would be determined by a ‘‘submission’’ to better align with the incremental versions the QRDA
duplicate record ID number or by language we use in other certification standards because health IT developers
requiring the system to compare the criteria that also require demonstration and providers have focused efforts on
data in two records and determine of a ‘‘reporting’’ functionality (i.e., to fully supporting QRDA reporting. To
whether it is a duplicate. Commenters submit data). this end, some commenters

were concerned about the amount of We subsequently proposed a 2015
work to reconcile data using the latter Edition ‘‘CQMs—report’’ certification 79 The CMS QRDA Implementation Guide can be
method. criterion in the 2016 IPPS/LTCH PPS accessed at http://www.cms.gov/Regulations-and-

Guidance/Legislation/EHRIncentivePrograms/
proposed rule that would require a eCQM_Library.html.
78 http://www.healthit.gov/facas/calendar/2014/ Health IT Module to enable a user to 80 http://wiki.siframework.org/
05/07/policy-certification-hearing. electronically create a data file for Clinical+Quality+Framework+Initiative.
recommended that we adopt Release 3 Errata. Further, Release 3 of the QRDA certification criterion would not require
of the QRDA Category I standard, and Category I IG also aligns with the CMS Health IT Modules to be recertified
the November 2012 version of the 2015 update to eCQM measures for 2016 annually as part of the ONC Health IT
QRDA Category III standard with the e-reporting (https://ecqi.healthit.gov/ Certification Program. However, in
September 2014 Errata. Other ecqm). conjunction with our CMS colleagues,
commenters did not support Release 3 We agree with commenters that it is we also clarify that CMS requires that
of the QRDA Category I standard, stating too early to adopt the QUICK CQM health IT be certified to the CMS QRDA
it was too immature for adoption. One standards, but will continue to support IG and be updated to the latest annual
commenter suggested that while Release the development and piloting of these measure specifications if providers
3 of QRDA Category I may be a new harmonized CQM and CDS standards intend to use the health IT to report
standard and require more work and reassess their appropriateness for CQMs electronically to CMS. This does
compared to Release 2 of QRDA certification at the time of a relevant not mean recertification is required each
Category I with the 2014 Errata, it offers future rulemaking. time the health IT system is updated to
more efficiencies and reduces errors that In sum, after consideration of public a more recent version of the CQMs. As
would ultimately improve eCQM comments, we have adopted a 2015 CMS stated in the 2016 IPPS/LTCH PPS
processing. Edition ‘‘CQMs—report’’ criterion that proposed rule, CMS intends to publish
Response. We thank commenters for requires a Health IT Module to enable a request for information (RFI) on the
their support for proposal and a user to (electronically) create a data establishment of an ongoing cycle for
comments regarding the versions of file for transmission of CQM data in the introduction and certification of
standards. We believe that certification accordance with: new measures, the testing of updated
to the HL7 QRDA Category I and III • HL7 CDA® R2 Implementation measures, and the testing and
standards provides a baseline for Guide: Quality Reporting Document certification of submission capabilities
interoperability of CQM data as these Architecture—Category I (QRDA I); (80 FR 24614–24615). We and CMS
standards are consensus-based and Release 1, DSTU Release 3 (US Realm) encourage readers to submit their
industry developed. Additionally, the (both Volumes 1 and 2); and comments and recommendations for
HL7 QRDA standards are program- • HL7 Implementation Guide for consideration upon publication of the
agnostic and can support a number of CDA® Release 2: Quality Reporting RFI.
use cases for exchanging CQM data. Document Architecture—Category III, • Clinical Quality Measures—Filter
Providers participating in CMS payment DSTU Release 1 (US Realm) with
programs such as the EHR Incentive September 2014 Errata. 2015 Edition Health IT Certification Cri-
Programs, IPPS, or Hospital IQR may All Health IT Modules must certify to terion
need to adhere to additional CMS QRDA the above standards to meet the § 170.315(c)(4) (Clinical quality measures—
reporting requirements as detailed in filter)
criterion. As noted above, the criterion
the CMS QRDA IG. However, we do not also includes an optional provision that
believe that all certified health IT is We proposed to adopt a new 2015
requires the electronic creation of a data
intended to be used for CMS reporting, Edition certification criterion that
file for transmission of CQM data that
and therefore have only included would require health IT to be able to
can be electronically accepted by CMS
requirements for reporting to CMS (e.g., record data (according to specified
(i.e., the form and manner of submission
use of the CMS QRDA IG) as an optional standards, where applicable) and filter
as specified in the CMS QRDA IG 81).
provision within the criterion. We note CQM results at both patient and
In order to accommodate the new
that the CMS QRDA IG has been aligned aggregate levels. We listed proposed
QRDA standards in the regulation text,
with the HL7 QRDA Category I and III data elements and vocabulary standards
we have revised the paragraph levels at
standards, but the CMS QRDA IG for some data elements to maintain
§ 170.205(h) and (k) to move the QRDA
includes additional requirements consistency in the use of adopted
standards adopted in the 2014 Edition
beyond the HL7 IGs specific to CMS national standards, and we clarified that
to § 170.205(h)(1) and (k)(1)
program reporting. a Health IT Module must be able to filter
respectively. We have also made a
Our adoption of an optional provision by any combination of the proposed
technical amendment to the regulation
to certify CQM reporting in the form and data elements (i.e., by any one (e.g.,
text for the 2014 Edition certification
manner of CMS submission allows CMS provider type) or a combination of any
criteria for capturing, calculating, and
to determine as part of its program of the data elements). We noted that the
reporting CQMs (at 45 CFR
requirements whether this optional combination requirement is different
170.314(c)(1), (c)(2), and (c)(3),
provision of the CQM reporting criterion than other certification criteria in the
respectively) to continue to reference
is required for participation in certain Proposed Rule in that it requires all
the appropriate implementation
CMS programs. For example, CMS has combinations to be demonstrated for
specifications.
proposed to revise the CEHRT definition certification and not just one. We
Comments. Commenters requested
to require health IT be certified to the requested comment on the
clarification on whether our proposal to
provision of the ‘‘CQMs—report’’ appropriateness of the proposed data
adopt a 2015 Edition ‘‘CQMs—report’’
criterion we have deemed optional (80 elements for CQM filtering, including
certification criterion through the 2016
FR 41880–41881), which would affect, whether they are being captured in
IPPS/LTCH PPS proposed rule implies
at a minimum, providers participating standardized vocabularies, and
that annual recertification to the
in the EHR Incentive Programs. additional data elements that we should
proposed criterion would be required as
We agree with the comments consider for inclusion and standardized
CMS updates the measure specifications

supporting the adoption of Release 3 of vocabularies that might be leveraged for
and the CMS QRDA IG annually.
the QRDA Category I IG as the IG will Response. We clarify that the proposal recording this information in health IT.
improve eCQM processing and reduce Comments. Many commenters were in
for a 2015 Edition ‘‘CQMs—report’’
errors. The IG will also better align with support of adopting a new criterion for
the C–CDA Release 2.1 for purposes of 81 Available at: https://www.cms.gov/regulations-
CQM filtering. Commenters noted the
interoperability as compared to QRDA and-guidance/legislation/ehrincentiveprograms/ benefit for supporting the identification
Category I Release 2 with the 2014 ecqm_library.html. and reduction of disparities by filtering
by patient demographics and problem adopted the following standards for this ‘‘demographics’’ criterion (80 FR 16816–
list. A number of commenters also criterion: 16817), and the request for comment for
supported the list of proposed data • HL7 CDA® R2 Implementation ‘‘future considerations for electronically
elements as a good starting point with Guide: Quality Reporting Document specified measures using Core Clinical
mature standards. Architecture—Category I (QRDA I); Data Elements’’ in the CMS 2016
Response. We thank commenters for Release 1, DSTU Release 3 (US Realm) Inpatient Prospective Payment System
the feedback. Our overall goal for this (both Volumes 1 and 2); and (IPPS) proposed rule (80 FR 24583–
functionality is to allow a provider to • HL7 Implementation Guide for 24584). Commenters suggested we work
make a query for CQM results using one CDA® Release 2: Quality Reporting to ensure alignment of the data
or a combination of data captured in the Document Architecture—Category III, proposed in this criterion with those in
certified Health IT Module for quality DSTU Release 1 (US Realm) with the Common Clinical Data Set definition
improvement and quality reporting September 2014 Errata.
and proposed for the demographics
purposes. We agree with commenters on Comments. One commenter expressed
concern that the proposed criterion aims criterion. Commenters also suggested
the value of this functionality for we work with CMS on the Core Clinical
identification of health disparities, to achieve attribution of eCQM results to
particular providers or groups of Data Elements definition.
helping providers identify gaps in
quality, and supporting a provider in providers for participation in certain Response. We thank commenters for
delivering more effective care to sub- quality reporting programs, but that the the recommendation to ensure data
groups of their patients. As such, we proposed functionality to filter does not definitions are aligned. This criterion
have adopted this certification criterion actually achieve attribution. The proposes a filter by ‘‘patient age’’
with the following modifications commenter noted that attribution whereas the Common Clinical Data Set
described below. requires a more complex approach than and demographics certification criterion
Comments. Some commenters noted is currently proposed with the filtering specify ‘‘date of birth.’’ For this
it would be valuable to filter both QRDA of CQM results using different certification criterion, we intend that
Category I and Category III quality combinations of data, and suggested that ‘‘patient age’’ is derived from the
reports for this criterion to assist with it was appropriate for the industry to patient’s date of birth, but specify
individual patient quality improvement develop attribution standards in ‘‘patient age’’ because we believe that
and for population health. One upcoming quality standards work. providers should be able to filter/query
commenter noted that providing a Response. We thank the commenter CQM results by the patient’s age rather
filtered view to the provider would for the feedback. We agree that proper than their date of birth. For example, the
allow for easy spot-checking of health attribution of eCQM results to a provider may query for patients older
disparity trends to inform quality particular provider or group of than a certain age, younger than a
improvement projects. providers will require a set of defined certain age, or between a range of ages.
Response. We thank commenters for processes. We believe that the Therefore, we have adopted patient age
the feedback and agree with the value of functionality in this criterion is a good as a data element for this certification
being able to filter QRDA I and Category step forward toward establishing such a criterion. We believe that all the other
III files as well as for providing a filtered process while the industry continues to data in this criterion are aligned with
view of the quality results for improve eCQM standards as described the 2015 Edition Common Clinical Data
supporting the quality improvement and further in the Proposed Rule (80 FR Set and ‘‘demographics’’ criterion. We
quality reporting use cases. QRDA 16842–16843). We intend to continue note that the ‘‘Core Clinical Data
Category I enables an individual patient- working with stakeholders to establish Elements’’ in CMS’ 2016 IPPS proposed
level quality report that contains quality standards and processes for proper rule is not being proposed for the 2016
data for one patient for one or more attribution of quality measure results for program year and is a comment
quality measures.82 The QRDA Category consideration in future rulemaking. solicitation for future rulemaking. We
III standard enables an aggregate quality Comments. A few commenters
intend to continue to work with CMS on
report containing calculated summary requested clarification of the language
alignment of data elements being
data for one or more measures for a in the preamble and suggested that
required for capture across programs.
specified population of patients within testing should not require that all
possible combinations of data be Comments. Commenters indicated
a particular health system over a some concern that providers may use
specific period of time.83 We have, demonstrated as it would be time-
consuming and a very large number. multiple Tax Identification Numbers
therefore, required that a Health IT
Response. We clarify that for testing (TINs) and different levels of TIN/
Module certified to this criterion must
Health IT Modules will not be tested to National Provider Identifier (TIN/NPI)
be able to filter CQM results at the
every possible combination of data, but combinations. There was general
patient and aggregate levels and be able
that any combination could be tested at support for the use of the NPI as a data
to create a data file of the filtered data
the discretion of the tester. We also note element for this criterion.
in accordance with the QRDA Category
that we have not prescribed a workflow Response. We believe that including
I and Category III standards, as well as
that must be demonstrated for TIN and NPI in this criterion offers a
be able to display the filtered data
certification in order to provide baseline for filtering by these data for
results in human readable format. To
flexibility as long as the desired certification. We would expect that any
align with the versions of the QRDA
outcome can be achieved. programs that may require CQM
standards we are adopting for the 2015 Comments. A few commenters
Edition ‘‘CQMs—record and export,’’ reporting using TIN and/or NPI would
indicated concern over the lack of provide additional guidance on the level
‘‘CQMs—import and calculate,’’ and alignment between the data and
‘‘CQMs—report’’ criteria, we have to use for participation in its programs.
associated standards proposed for this Therefore, we have adopted TIN and
criterion compared with our proposed
82 Available at: http://www.hl7.org/implement/ NPI as data elements for this criterion.
standards/product_brief.cfm?product_id=35. 2015 Edition Common Clinical Data Set
83 Available at: http://www.hl7.org/implement/ definition (80 FR 16871–16872), the Comments. There was general support
standards/product_brief.cfm?product_id=286. data proposed in the 2015 Edition for use of the Healthcare Provider
Taxonomy Code Set 84 for classifying Comments. As discussed in the work together to determine how to
provider types. Commenters indicated ‘‘transitions of care’’ criterion, a number provide results for queries for patient
they were not aware of additional of commenters suggested adoption of seen at a particular practice site address
existing standards for provider types. A the U.S. Postal Service postal address at this point in time, and note that
few commenters indicated concern that standard for address as concerns patient testing and certification will only test
providers can select multiple codes in matching. Commenters noted that the that a Health IT Module is able to filter
the NPI system that reflects their overall standard is widely supported by health CQM results by practice site address.
practice rather than their individual care organizations today and is Other programs that may require the use
specialty, and that the code may have recommended by the American Health of this certification criterion may
low reliability. Information Management Association.87 provide additional guidance on the
Response. We thank commenters for Some commenters were concerned definition of practice site address and
the feedback. We agree that the about complexity in systems being able guidance on attribution.
Healthcare Provider Taxonomy Code Set to choose the correct practice site that Comments. Commenters supported
(the ‘‘Code Set’’) is the best available a patient was seen at as a patient may the Public Health Data Standards
standard for classifying provider type at visit more than one practice site for a Consortium Source of Payment
this point in time, and have therefore given provider. Another commenter Typology Code Set 91 for representing
suggested we consider the GS1 Global patient insurance. SDOs such as ANSI
adopted the CMS Crosswalk: Medicare
Location Number (GLN) standard 88 for X12 and HL7 recognize the Source of
Provider/Supplier to Healthcare
practice site address as it is based on the Payment Typology Code Set for
Provider Taxonomy, April 2, 2015 as the
USPS standard and could be filtered to representing patient insurance in their
standard for provider type for this
provide a specific practice site address standards.92
criterion (to the version updated April
through the level of ‘‘party’’ and Response. We have adopted the
2, 2015 as a minimum version for
‘‘location’’ using the GS1 GLN standard. Public Health Data Standards
certification).85 This crosswalk maps the Response. We thank commenters for
Medicare Provider/Supplier type to the Consortium Source of Payment
the input. At this point in time, we Typology Code Set Version 5.0 (October
relevant healthcare provider taxonomy believe that use of the QRDA Category
codes. It is our understanding that when 2011) to represent patient insurance for
I and III standards which reference the this criterion.
a provider registers for an NPI number, HL7 postal format is an incremental step
they are required to select at least one Comments. Commenters expressed
toward an industry standard. This is the concern over the value set proposed to
provider type code from the Code Set, same HL7 postal format standard
but may select more than one code. represent patient sex.
referenced in C–CDA Release 2.1; and Response. We address the value set
However, the provider is required to QRDA is based on the same underlying for patient sex in the ‘‘demographics’’
select one code as the primary code. It standard as C–CDA (i.e., the CDA). certification criterion discussed in
is also our understanding that the NPI While we continue to analyze the USPS section III.A.3 of this preamble, to
record for a given provider contains all address standard 89 and other industry which we refer readers. As noted above
codes a provider selected, and so we standards, we believe these standards and recommended by commenters, we
would expect that CQM results could be were developed for other use cases have adopted the same standard for this
filtered by any one of the provider’s (such as the shipping and delivery of criterion as for the ‘‘demographics’’
selected codes (e.g., primary, secondary, mail or tracking medical products) than certification criterion, which supports
tertiary, etc.). In order to ensure the NPI for querying for health information in alignment and consistency.
record is up-to-date, we would the health care industry. We see a need Comments. Commenters expressed
recommend that health care providers for continued industry work to concern about the proposed requirement
update and/or verify their registration determine the appropriateness of to filter all 900+ race and ethnicity
annually in the CMS National Plan and existing standards and tools for codes in the ‘‘Race & Ethnicity—CDC’’
Provider Enumeration System normalizing postal address for health code system in PHIN VADS.
(NPPES) 86 to reflect the most accurate care uses cases, and intend to work with Response. We addressed the
codes for the type of care the provider stakeholders in this space. comments about the CDC Race and
is currently providing. There are three Testing and validation to the HL7 Ethnicity code set in the
methods by which an individual can postal format in the QRDA standard is ‘‘demographics’’ certification criterion
access the NPI files: (1) Through a already available as part of Cypress discussed elsewhere in this section of
downloadable file, (2) through a testing 90 to QRDA for the 2014 Edition the preamble, to which we refer readers.
display/query on the NPPES website, CQM certification criteria. We anticipate We continue to believe in the value of
and (3) through an interface to the the Cypress testing tool for 2015 Edition querying by granular patient race and
NPPES API. While health systems may CQMs criteria, including for CQM ethnicity for identification of health
keep their own internal records of NPI filtering, will carry over this testing and disparities and supporting a provider in
information for the providers practicing suggest that health IT developers and delivering more effective care to sub-
in their system, we recommend that any implementers adhere to the guidance in groups of their patients. As noted above
of the three above methods provides the the QRDA Category I and III standards and recommended by commenters, we
most up-to-date information and would adopted for this criterion for the HL7 have adopted the same standard for this
encourage systems to verify and use this postal format. We believe it is best left criterion as for the ‘‘demographics’’
information for their internal records. to health IT developers and providers to certification criterion, which supports
84 http://www.cms.gov/Medicare/Provider- 87 http://perspectives.ahima.org/wp-content/
alignment and consistency.
Enrollment-and-Certification/MedicareProviderSup uploads/2014/12/PatientMatchingAppendixA.pdf. Comments. Commenters expressed
Enroll/Taxonomy.html. 88 http://www.gs1.org/gln. concern on the level of complexity for
85 https://www.cms.gov/Medicare/Provider- 89 http://pe.usps.gov/cpim/ftp/pubs/Pub28/
Enrollment-and-Certification/MedicareProviderSup pub28.pdf. 91 http://www.phdsc.org/standards/pdfs/
Enroll/Downloads/TaxonomyCrosswalk.pdf. 90 http://projectcypress.org/. Cypress is the testing SourceofPaymentTypologyVersion5.0.pdf.

86 https://nppes.cms.hhs.gov/NPPES/ tool used to test and certify products for CQMs in 92 http://www.phdsc.org/standards/payer-
Welcome.do. the ONC Health IT Certification Program. typology.asp.
filtering by SNOMED CT® codes for authentication are costly and § 170.315(d)(2) (Auditable events and tam-
patient problem list. burdensome to implement. One per-resistance)
Response. We acknowledge commenter discussed digital signatures
commenters’ concerns about the level of as they relate to the authenticity of We proposed to adopt a 2015 Edition
complexity of filtering by SNOMED CT® medical documentation. ‘‘auditable events and tamper-
codes for this certification criterion. To Response. We have adopted this resistance’’ certification criterion that
lessen the burden while continuing to certification criterion largely as was unchanged in comparison to the
provide value for quality improvement, proposed. We have made one minor 2014 Edition ‘‘auditable events and
we clarify that for testing and revision by replacing the term ‘‘person’’ tamper-resistance’’ criterion
certification, a Health IT Module would in the criterion with ‘‘user.’’ This (§ 170.314(d)(2)) and sought comment
only need to demonstrate it can filter by revision is consistent with our use of the on two issues. First, given that it does
the parent level code in SNOMED CT® term ‘‘user’’ in the 2015 Edition. We not appear that the ASTM standard
as the code system is designed in a note that, notwithstanding this revision, indicates recording an event when an
hierarchical manner with more specific this criterion remains eligible for gap
codes grouped under more general individual’s user privileges are changed,
certification. we asked for comment on whether we
parent codes. In response to comments on multi-
Comments. One commenter suggested need to explicitly modify/add to the
factor authentication, we have not overall auditing standard adopted in
we consider adding the CMS adopted multi-factor authentication as
Certification Number (CCN) as an 170.210(e) to require such information
part of this criterion or in another
additional data element for this criterion to be audited or if this type of event is
criterion or requirement as we did not
as it is used by hospitals to report their propose such functionality. We will, already audited at the point of
CQM data to CMS. however, continue to track NSTIC. We authentication (e.g., when a user
Response. We thank the commenter will also monitor industry progress with switches to a role with increased
for the suggestion. At this current point multi-factor authentication and may privileges and authenticates themselves
in time, we believe there are consider multi-factor authentication to the system). We also sought
complexities with using the CCN as a certification for a future rulemaking as comments on any recommended
filter for CQMs. For example, a certified noted in our discussion of the HITSC standards to be used in order to record
Health IT Module may be certified recommendations below. those additional data elements. We
partway through a reporting year. The reiterated our policy in the 2014 Edition
Digital signatures were proposed as
CCN also represents a unique ‘‘auditable events and tamper
part of the ‘‘electronic submission of
combination of certified Health IT resistance’’ certification criterion in that
medical documentation’’ criterion, but
Modules a provider is using to meet the the ability to disable the audit log must
were not proposed as part of this
CEHRT definition requirements. Thus, be restricted to a limited set of users to
criterion. Accordingly, we have not
we are not clear on the use case that
adopted such a requirement as part of meet this criterion, and we stated that
would be served in requiring a Health
this criterion. We may, however, we believe our certification criterion is
IT Module certified to this criterion to
consider digital signatures as part of a appropriately framed within the
be able to filter CQM results by CCN.
future rulemaking. parameters of what our regulation can
We will consider the use cases and
implementation of using CCN for CQM HITSC Recommendations reasonably impose as a condition of
filtering for the potential expansion of certification. With regard to feedback to
We received recommendations from the Voluntary Edition proposed rule
this criterion through future rulemaking. the HITSC after the close of the public
• Authentication, Access Control, that there may be some events recorded
comment period for the Proposed Rule. in the audit log that may be more
and Authorization
The HITSC recommended the adoption critical to record than other events, we
of a certification criterion that would again sought comment on whether:
terion include capabilities to ‘‘continuously
There is any alternative approach that
§ 170.315(d)(1) (Authentication, access con- protect the integrity and confidentiality
we could or should consider; there is a
trol, and authorization) of information used to authenticate
users.’’ The HITSC stated that the critical subset of those auditable events
We proposed to adopt a 2015 Edition adoption of such a criterion would that we should require remain enabled
‘‘authentication, access control, and strengthen the authentication at all times, and if so, additional
authorization’’ certification criterion capabilities in currently certified health information regarding which events
that was unchanged in comparison to IT. The HITSC also recommended the should be considered critical and why;
the 2014 Edition ‘‘authentication, access adoption of a certification criterion for and any negative consequences may
control, and authorization’’ criterion multi-factor authentication. These arise from keeping a subset of audit log
(§ 170.314(d)(1)). recommendations for the adoption of functionality enabled at all times.
Comments. Commenters were certification criteria must proceed Comments. The majority of
generally supportive of this criterion as through the processes outlined in commenters requested that this criterion
proposed. One commenter suggested sections 3001 and 3004 of the Public remain as proposed and be eligible for
that we track the National Strategy for Health Service Act (HITECH Act), gap certification. Commenters
Trusted Identities in Cyberspace which may lead to a future rulemaking overwhelming agreed that emergency
(NSTIC) initiative and the NSTIC proposing the adoption of criteria that
access was being audited and is already

Trustmark Framework pilot. One include capabilities recommended by covered under the ASTM E2147
commenter was supportive of us the HITSC. standard. Some commenters expressed
adopting standards for multi-factor • Auditable Events and Tamper- support for specifically auditing user
authentication for remote authentication Resistance
to EHR systems, whereas another privilege changes with the HITSC
commenter pointed out that current TSSWG recommending that this
approaches to multi-factor terion
criterion require events to be audited in mixed and the HITSC continued to approval/denial, and updating are to be
accordance with NIST SP 800–92.93 support our current approach. As tracked as separate unique events or as
Most commenters, including the recited in the Proposed Rule, there are a single event with a single timestamp.
HITSC TSSWG, recommended that valid reasons for disabling the audit log. A couple of commenters suggested this
there should be no change in the We continue to believe that it is criterion include the capability to
requirements related to disabling and appropriate to restrict the ability to maintain the provenance of
enabling the audit log. A commenter disable the audit log to a limited set of amendments made by patients and other
noted that determining when the audit users, which permits the end user to patient generated health data to reduce
log should or should not be enabled is determine if, when, and by whom the the numbers of errors.
best defined by end-users of Health IT audit log may be disabled. As to the Response. We have adopted this
Modules and not the health IT alternative approach to always enabling certification criterion as proposed. The
developers. Commenters representing the audit log, we note that we have ‘‘tracking’’ or auditing of events
consumer organizations suggested that chosen to maintain the current mentioned by the commenter is outside
the audit log should not be able to be approach, but will consider as part of the scope of this criterion. Rather, we
disabled, which they argued would the finalizing of the 2015 Edition test would expect such actions to be subject
enhance consumer trust. Another procedure for this criterion what of an entity’s auditing technology and
commenter stated that any allowance for additional guidance we can provide practices. We appreciate the suggestion
disabling the audit logs, for any reason, related to auditable actions consistent to maintain provenance of amendments
compromises the integrity of the with the ASTM E2147 standard. made by patients and other patient
auditing. • Audit Report(s) generated health data, but this is outside
Commenters did not identify a critical the scope of the functionality proposed
subset of those auditable events that we 2015 Edition Health IT Certification Cri- for this criterion.
should require remain enabled at all terion • Automatic Access Time-Out
times. However, one commenter § 170.315(d)(3) (Audit reports)
suggested that as an alternative to 2015 Edition Health IT Certification Cri-
requiring the audit log to always be We proposed to adopt a 2015 Edition terion
enabled, we should provide regulatory ‘‘audit reports(s)’’ certification criterion § 170.315(d)(5) (Automatic access time-out)
guidance on the specific information to that was unchanged in comparison to
be included in the audit log, such as is the 2014 Edition ‘‘audit reports(s)’’ We proposed to adopt a 2015 Edition
stipulated in the ASTM E2147 standard. criterion (§ 170.314(d)(3)). ‘‘automatic access time-out’’
The commenter also recommended that Comments. Commenters certification criterion that was
we provide clarity on the scope of the recommended that we adopt this unchanged in comparison to the 2014
applicability of the ASTM standard as a criterion as proposed. A couple of Edition ‘‘automatic log-off’’ criterion
part of that guidance when it comes to commenters requested that we include (§ 170.314(d)(5)). In terms of the
whether the intent is to include only additional functionality in this criterion, functionality within the criterion, we
natural person/end user accesses or such as a filtering functionality (beyond proposed to restate the language to
other access such as ‘‘machine to sorting) and automated reporting require a Health IT Module to
machine.’’ without manual searches/sorting. demonstrate that it can automatically
Response. We have adopted this Response. We have adopted this stop user access to health information
criterion as proposed, except that we criterion as proposed. We appreciate after a predetermined period of
have revised the auditing standard commenters’ suggested additional inactivity and require user
referenced by this criterion and adopted functionalities, but these functionalities authentication in order to resume or
in § 170.210(e)(1)(i) 94 to include a are beyond the scope of our proposal. regain the access that was stopped. This
requirement to audit changes in user To note, certification serves as a proposal was based on feedback
privileges. With consideration of public baseline for health IT. We would expect previously received from the HITSC
comments, we believe that this is an health IT developers to incorporate such Privacy and Security Workgroup
event that should be audited for the functionalities to possibly differentiate (PSWG).95 The PSWG noted in June
purposes of certification. We do not, their products in the market or if 2014 that many systems are not session-
however, believe that at this time specifically desired by their customers based. Instead, systems may be stateless,
certification should expand to an (e.g., providers). clientless, and/or run on any device.
extensive list of auditable events as • Amendments The HITSC recommended that this
recommended by the HITSC TSSWG. certification criterion should not be
Rather, we believe that certification 2015 Edition Health IT Certification Cri- overly prescriptive so as to inhibit
should remain a baseline and health IT terion
system architecture flexibility. We
developers and providers can expand § 170.315(d)(4) (Amendments)
agreed with the substance of the PSWG
their auditing practices as appropriate. and HITSC recommendations and
We did not receive an overwhelming We proposed to adopt a 2015 Edition
‘‘amendments’’ certification criterion proposed to state the functionality
response or rationale from commenters
that was unchanged in comparison to required as specified above, noting that
that convinced us to change our
the 2014 Edition ‘‘amendments’’ we do not believe this would have any
approach to require that a Health IT
criterion (§ 170.314(d)(4)). We noted impact on testing and certification as
Module not permit an audit log to be
that this certification criterion only compared to testing and certification to
disabled. In fact, comments remained
partially addresses the amendment of the 2014 Edition ‘‘automatic log-off’’

93 http://csrc.nist.gov/publications/nistpubs/800- protected health information (PHI) criterion (i.e., the 2015 ‘‘automatic
92/SP800-92.pdf. requirements of 45 CFR 164.526.
94 We note that the ASTM E2147 standard has
Comments. Commenters supported 95 http://www.healthit.gov/facas/sites/faca/files/
been reapproved (in 2013) with no changes. We this criterion as proposed. A commenter HITSC_PSWG_2015NPRM_Update_2014-06-17.pdf.
have, therefore, revised the regulation text to reflect The HITSC Privacy & Security Work Group changed
the reapproval. http://www.astm.org/Standards/ requested clarification as to whether names and became the HITSC Transport & Security
E2147.htm. amendment steps such as request, Standards Work Group in July 2014.
access time-out’’ criterion would be Comments. Many commenters 2015 Edition Health IT Certification Cri-
eligible for gap certification). expressed support for leaving the terion
Comments. Commenters expressed certification criterion unchanged in § 170.315(d)(8) (Integrity)
support for this criterion as proposed. comparison to the 2014 Edition ‘‘end-
The HITSC Transport and Security user device encryption’’ criterion. Many We proposed to adopt a 2015 Edition
Standards Workgroup (TSSWG) again commenters also supported our ‘‘integrity’’ certification criterion that
recommended that we change the proposal for using the most recent was unchanged in comparison to the
language of the criterion to read version of Annex A as cited in the 2014 Edition ‘‘integrity’’ criterion
‘‘automatically terminate access to Proposed Rule. (§ 170.314(d)(8)). We did, however,
protected health information after a Response. We appreciate the support propose a change in how a Health IT
system- and/or administrator-defined expressed by many commenters. We Module would be tested and certified to
period of inactivity, and reinitiate the have adopted this certification criterion this criterion. We explained that the
session upon re-authentication of the as proposed, including the updated 2015 Edition ‘‘integrity’’ criterion would
user.’’ version of Annex A. be tested and certified to support the
Response. We thank commenters for Comments. Some commenters context for which it was adopted—upon
their support. We continue to believe suggested that we expanded the receipt of a summary record in order to
that the language offered by the TSSWG functionality of this criterion to include ensure the integrity of the information
prescribes a particular session-based server-side encryption or encryption of exchanged (see § 170.315(d)(8)(ii)).
design and is not the most appropriate data in-motion. One commenter said Therefore, we stated that we expect that
language for this criterion. As that data should be encrypted when this certification criterion would most
mentioned above, not all systems are using cloud storage technologies. frequently be paired with the ‘‘ToC’’
session-based. Therefore, we have Another commenter requested certification criterion for testing and
adopted this criterion as proposed. clarification if this criterion applied to certification.
• Emergency Access data at-rest or in-motion. We sought comment on if, and when,
Response. As described in the 2014 we should set the baseline for
2015 Edition Health IT Certification Cri- Edition final rule (77 FR 54236–54238), certification to the 2015 Edition
terion the functionality included in the 2014 ‘‘integrity’’ certification criterion at
§ 170.315(d)(6) (Emergency access) Edition certification criterion (and this SHA–2.99 In support of this potential
2015 Edition unchanged criterion) does change, we noted that SHA–2 has much
We proposed to adopt a 2015 Edition not focus on server-side or data center more security strength compared to the
‘‘emergency access’’ certification hosted technology. We recognize that SHA–1 standard. We also pointed out
criterion that was unchanged in these implementations could employ a that many companies, including
comparison to the 2014 Edition variety of different administrative, Microsoft and Google, plan to deprecate
‘‘emergency access’’ criterion physical, and technical safeguards, SHA–1 no later than January 1, 2017.
(§ 170.314(d)(6)). including hardware-enabled security Comments. Several commenters and
Comments. Commenters supported protections that would be significantly the HITSC expressed support for
this criterion as proposed. more secure than software oriented increasing the integrity standard to
Response. We have adopted this encryption capabilities. Rather, this SHA–2. One commenter pointed out
criterion as proposed. criterion focuses on data locally stored that NIST has deprecated the use of
• End-User Device Encryption on end-user devices after the use of the SHA–1, whereas another commenter
technology is stopped. claimed that health IT would have to
2015 Edition Health IT Certification Cri- Comments. Some commenters stated eventually get recertified to SHA–2 if
terion that we should address encryption key we moved to SHA–2 at a later date
§ 170.315(d)(7) (End-user device (beyond the effective date of this final
encryption)
management and key storage in this
certification criterion. rule) or in a future edition. A few
Response. We agree with commenters commenters requested that we wait
We proposed to adopt a 2015 Edition until 2017 or 2018 to increase the
‘‘end-user device encryption’’ that encryption controls depend on the
encryption key remaining secure. standard to SHA–1.
certification criterion that was Response. In 2012, NIST Special
unchanged in comparison to the 2014 However, this functionality is outside
the scope of the proposed criterion. We Publication 800–57 100 recommended
Edition ‘‘end-user device encryption’’ that federal systems not be permitted to
criterion (§ 170.314(d)(7)). We proposed also note that encryption key
management often occurs outside of create new hashes using SHA–1 starting
to require certification to this criterion in 2014. Given that NIST, technology
consistent with the most recent version certified health IT and depends on the
environment in which the certified companies, and health IT developers are
of Annex A: Approved Security moving away from SHA–1, we believe
Functions (Draft, October 8, 2014) for health IT is deployed, and, as such,
depends on organizational policy and now is the appropriate time to move
Federal Information Processing towards the more secure SHA–2
Standards (FIPS) Publication 140–2.96 security risk assessments. We encourage
stakeholders to follow applicable standard. Therefore, we will make this
We noted, however, that we do not new requirement effective with the
believe that this would have any impact guidance from the Office for Civil Rights
(OCR 97 and the National Institutes of effective date of this final rule. We note
on testing and certification as compared that there is no requirement obligating
to testing and certification to the 2014 Standards and Technology 98 for
securing encryption keys. health IT developers to get their

Edition ‘‘end-user device encryption’’ products certified to this requirement
criterion (i.e., the 2015 ‘‘end-user device • Integrity
immediately, and we would expect
encryption’’ criterion would be eligible 97 http://www.hhs.gov/ocr/privacy/hipaa/
for gap certification). administrative/breachnotificationrule/ 99 http://csrc.nist.gov/publications/fips/fips180-4/
brguidance.html. fips-180-4.pdf.
96 http://csrc.nist.gov/publications/fips/fips140-2/ 98 http://csrc.nist.gov/publications/nistpubs/800- 100 http://csrc.nist.gov/publications/nistpubs/800-
fips1402annexa.pdf. 111/SP800-111.pdf. 57/sp800-57_part1_rev3_general.pdf.
health IT developers to not begin specifications to enhance the ability to patient-centered care. One commenter
seeking certification to this criterion identify inappropriate access inside an urged us to adopt the ‘‘personal
until later in 2016 for implementation in entity or organized health care representative’’ term used in HIPAA.
2017 and 2018. We further note that arrangement and to provide reports with Response. We have adopted the
certification only ensures that a Health sufficiently relevant data. proposed introductory language as it
IT Module can create hashes using Response. We have adopted this clarifies that these capabilities must
SHA–2, it does not require the use of certification criterion as proposed. We enable patients and their authorized
SHA–2. For example, users of certified initially adopted an ‘‘accounting of representatives. We decline to use the
health IT may find it appropriate to disclosures’’ certification criterion to HIPAA term ‘‘personal representative.’’
continue to use SHA–1 for backwards supplement HITECH Act requirements Rather, we have adopted our proposal of
compatibility if their security risk and rulemaking by OCR (75 FR 2016–17 ‘‘patients (and their authorized
analysis justifies the risk. and 75 FR 44623–24) and believe there representatives)’’ to be consistent with
Consistent with this decision, we is value in its continue adoption as the approach we have used in previous
have also updated this criterion and proposed. We appreciate the suggested rulemakings that aligns with the use of
standard to reference the most recent revisions offered by commenters, but the term under the EHR Incentive
version of FIPS PUB 180–4, Secure Hash believe that alignment with an ‘‘account Programs. A ‘‘patient-authorized
Standard, 180–4 (August 2015).101 of disclosures’’ final rule will provide representative’’ is defined as any
the most certainty and useful individual to whom the patient has
2015 Edition Health IT Certification Cri- functionality for providers, while also granted access to their health
terion mitigating any health IT development information (see also 77 FR 13720).
§ 170.315(d)(9) (Trusted connection) and implementation burdens that may Examples would include family
accrue through compliance with members, an advocate for the patient, or
Please see the discussion under the potential multiple adopted versions of other individual identified by the
‘‘Application Access To Common this certification criterion. We believe it patient. A patient would have to
Clinical Data Set’’ certification criteria is most appropriate to wait and consider affirmatively grant access to these
later in this section of the preamble. the provisions of an ‘‘accounting of representatives with the exception of
disclosures’’ final rule to be issued by minors for whom existing local, state, or
2015 Edition Health IT Certification Cri- OCR before making any revisions to this federal law grants their parents or
terion guardians access without the need for
§ 170.315(d)(10) (Auditing actions on health
certification criterion. As currently
adopted, health IT developers have the the minor to consent and individuals
information) who are unable to provide consent and
option of pursuing certification to this
criterion if they deem it advantageous. where the state appoints a guardian (see
Please see the discussion under the
‘‘Application Access To Common • View, Download, and Transmit to also 77 FR 13720).
3rd Party Additionally, consistent with our
Clinical Data Set’’ certification criteria certification program approach to apply
later in this section of the preamble. particular privacy and security
• Accounting of Disclosures 2015 Edition Health IT Certification Cri-
certification criteria to a product’s
terion
§ 170.315(e)(1) (View, download, and trans- certification based on the scope of
mit to 3rd party) capabilities presented, we have
terion
§ 170.315(d)(10) (Accounting of disclosures) determined that this certification
We proposed to adopt a 2015 Edition criterion would be clearer and more
We proposed to adopt a 2015 Edition ‘‘view, download, and transmit to 3rd focused if we were to remove the secure
‘‘accounting of disclosures’’ certification party’’ (VDT) criterion that was revised access language included in (e)(1)(i) in
criterion that was unchanged in in comparison to the 2014 Edition favor of having a specific privacy and
comparison to the 2014 Edition ‘‘VDT’’ criterion (§ 170.314(e)(1)). security certification criterion that
‘‘accounting of disclosures’’ criterion would be applicable to this criterion. In
Clarified Introductory Text for 2015
(§ 170.314(d)(9)). We noted that the transitioning this text, we have also
Edition VDT Certification Criterion
2015 Edition criterion is no longer made a conforming revision to note that
We proposed to revise the the ‘‘technology’’ used would need to be
designated ‘‘optional’’ because such a
introductory text to lead with ‘‘Patients ‘‘internet-based’’ which we believe is a
designation is no longer necessary given
(and their authorized representatives) more generally applicable and
that we have discontinued the Complete
must be able to use health IT to . . .’’ innovation supportive term compared to
EHR definition and Complete EHR
We also proposed to use this same the user of the word ‘‘online,’’ which
certification beginning with the 2015
phrase at the beginning of each specific was part of the sentence that included
Edition certification criteria.
Comments. Commenters expressed capability for VDT to reinforce this the security specific language that we
support for this certification criterion as point. We noted that this does not have removed.
proposed. A commenter recommended override or substitute for an individual’s
right to access protected health Updated C–CDA and Common Clinical
removing the criterion until the HHS Data Set
Office for Civil Rights (OCR) issues a information (PHI) in a designated record
final rule for its previously published set under 45 CFR 164.524. We proposed to reference the updated
Comments. Many commenters voiced version of the C–CDA (Draft Standard
proposed rule regarding accounting of
support for the inclusion of ‘‘authorized for Trial Use, Release 2.0) for the ‘‘VDT’’
disclosures (76 FR 31426).102 Other

representative’’ in the introductory text criterion and noted that compliance
commenters recommended
of VDT, noting that specifically granting with Release 2.0 cannot include the use
strengthening this criterion and
the patient’s authorized representative of the ‘‘unstructured document’’
101 http://nvlpubs.nist.gov/nistpubs/FIPS/
the ability to view/download/transmit document-level template for
NIST.FIPS.180-4.pdf. patient health information reinforces the certification to this criterion. We also
102 http://www.gpo.gov/fdsys/pkg/FR-2011-05-31/ importance of the caregiver role on the solicited comment on whether we
pdf/2011-13297.pdf. care team and supports a vision of should limit the scope of the C–CDA
document created for the purposes of range of data) they wish to view, VDT—Application Access to Common
this criterion to just the CCD document download, or transmit. Specifically, we Clinical Data Set
template. We also solicited comment on have adopted within this criterion two We have addressed all comments on
whether we should require in this timeframe filters that patients must be this proposed provision under the
criterion to permit patients and their able to select and configure on their ‘‘Application Access to Common
authorized representatives to select their own. The first would ensure that a Clinical Data Set’’ in this section of the
health information for, as applicable, patient can select data associated with preamble.
viewing, downloading, transmitting, or a specific date (to be viewed,
API based on a specific date or time, a downloaded, or transmitted) and the Activity History Log
period of time, or all the information We proposed to include ‘‘addressee’’
second would ensure that the patient
available. as a new data element in the 2015
Comments. Multiple commenters could select data within an identified
date range (to be viewed, downloaded, Edition ‘‘VDT’’ criterion related to the
supported the reference to C–CDA
or transmitted), which must be able to activity history log. In the Proposed
Release 2.0 document template. Some
accommodate the patient selecting a Rule, we noted that this transactional
commenters voiced concern about
range that includes all data available to history is important for patients to be
adoption C–CDA Release 2.0 if
them. We also clarify that we are not able to access, especially if a patient
backwards compatibility is not fully
addressed. Other commenters suggested including the ability to select a specific actively transmits his or her health
additional information that patients may data element category as part of this information to a 3rd party or another
need outside of the C–CDA, including requirement, but reiterate that these health care provider.
referral summaries, discharge Comments. Commenters were
requirements represent a floor rather
instructions, documents listed in the generally supportive of this new data
than a ceiling, and health IT developers
Patient Health Information Capture element. One commenter suggested that
may choose to add other functionalities
criterion, and nutrition and diet orders. we not include transmission status in
as appropriate. The technology the final rule because few patients
Multiple commenters supported the specifications should be designed and
focus on the creation of a CCD actually transmit.
implemented in such a way as to Response. We have adopted the new
document template based on the C–CDA provide maximum clarity to a patient
Release 2 for the ‘‘VDT’’ criterion, data element of ‘‘addressee’’ as part of
(and their authorized representative) the VDT criterion. While fewer patients
stating that it would be less confusing about what data exists in the system and
for consumers who may not be able to may currently use ‘‘transmit’’ than
how to interpret it, and we expect that ‘‘view’’ or ‘‘download,’’ we anticipate
distinguish between different document
health IT developers will make choices that more patients will use this
types. In regard to our solicitation on
time and date range functionality, following design and usability best functionality in the future and that this
multiple commenters were in support of practices that will make it easier and information will be helpful for
adding such capabilities, while a few clearer for patients to find and use their transaction history.
commenters did not agree with records.
Patient Access to Laboratory Test
including this functionality. Diagnostic Image Reports Reports
Response. Consistent with our
decision for the ‘‘ToC’’ criterion, we will We proposed to require that a Health In the Proposed Rule, we noted recent
reference C–CDA Release 2.1 in the regulatory changes addressing the
IT Module would need to demonstrate
‘‘VDT’’ criterion. In response to public intersection of the CLIA rules, state laws
that it can make diagnostic image
comment, we have narrowed the scope governing direct patient access to their
reports available to the patient in order
of the C–CDA document templates to laboratory test reports, and the HIPAA
to be certified. We explained that a Privacy Rule. These regulatory changes
only the CCD for this criterion. We diagnostic image report contains a
emphasize that this requirement serves converged in a final rule that permits a
consulting specialist’s interpretation of patient, or his or her ‘‘personal
as a ‘‘floor’’ rather than a ‘‘ceiling’’ and
image data, that it is intended to convey representative,’’ as applicable, to request
that Health IT Modules and their
purchasers may choose to add the interpretation to the referring a copy of the patient’s completed test
additional document types as (ordering) physician, and that it reports directly from the laboratory or to
appropriate for different practice and becomes part of the patient’s medical request that the test results be
care settings. record. transmitted to a designated person. To
We have included an updated Comments. Commenters were ensure fidelity of such reports regardless
Common Clinical Data Set for the 2015 generally supportive of including of the system delivering laboratory
Edition that includes references to new diagnostic image reports and associated results to a patient, we proposed that a
and updated vocabulary standards code context in the ‘‘VDT’’ criterion. Some Health IT Module presented for
sets. Please also see the Common commenters requested clarification on certification to this criterion must
Clinical Data Set definition in section where this data would be accessible demonstrate that it can provide
III.B.3 of this preamble. within the C–CDA. laboratory test reports that include the
In consideration of public comments information for a test report specified in
that focused on our comment Response. We have adopted this 42 CFR 493.1291(c)(1) through (7); the
solicitation around the addition of date proposal to include the diagnostic information related to reference
and time filtering capabilities, we have imaging report (including the consulting intervals or normal values as specified
decided to adopt such requirements as specialist’s interpretation) as a in 42 CFR 493.1291(d); and the
part of this criterion. We believe that requirement in the ‘‘VDT’’ criterion. information for corrected reports as
adding this explicit functionality to the Health IT Modules may include this specified in 42 CFR 493.1291(k)(2).
certification criterion provides specific information in the ‘‘Results’’ section of Comments. One commenter suggested
clarity that patients should have certain the CCD. We clarify that unstructured that this requirement be removed until
baseline capabilities available to them data for the interpretation text is the C–CDA specification supports the
when it comes to selecting the data (or acceptable. requisite CLIA data referenced in the
Proposed Rule. Another commenter Certified Health IT Product List (CHPL) certification criterion. In order to satisfy
noted that some laboratory results listing. We believe this option adds this portion of the certification criterion
require provider annotation and/or transparency to what capabilities a Health IT Module must demonstrate
follow up testing before they can be products include and can better inform two forms of transmission:
released to the patient to avoid harm, purchasers. We have adopted Level AA (1) Email transmission (of a CCD) to
particularly with certain sensitive tests as a standard at § 170.204(a)(2). any email address; 103 and
such as HIV tests. Thus, a laboratory Additionally, we have determined that (2) An encrypted method of electronic
result awaiting provider annotation may the certification criterion’s requirements transmission.
not be fully ‘‘available’’ until the for the application of WCAG would be This approach will provide patients
annotation is complete. clearer if it were expressed in the with a readily understood and
Response. We have adopted the general requirement at the paragraph convenient option to simply send their
proposed laboratory test reports 170.315(e)(1)(i) since WCAG needs to health information via email. Patients,
requirement for the VDT criterion. We apply to all user viewable functionality under current HIPAA regulations,104
note that the C–CDA can support this and would equally apply to and include may presently ask that data be disclosed
information in a structured way using the user experience aspects of download to them via unencrypted email.
the ‘‘Result Observation Template’’ in and transmit. Therefore, including email as an option
the ‘‘Results’’ section. We recommend for transmission capabilities is
that health IT developers follow the best ‘‘Transmit’’ Request for Comment consistent with HIPAA as well as with
practices for use of these C–CDA We requested comment on (1) common communications for other
templates as outlined by HL7 (see, e.g., whether we should include the Direct purposes. We also provide and
HL7 Task Force Examples: http:// Project’s Implementation Guide for encourage an encrypted option for
wiki.hl7.org/index.php?title=CDA_ Direct Project Trust Bundle Distribution transmitting their health information if
Example_Task_Force). Further, we specification as part of certification for they prefer or need to transmit their data
strongly recommend an approach the ‘‘VDT’’ certification criterion; and with added security. There is a
favoring coded data where possible and (2) whether any additional requirements heightened interest in security of
appropriate, and anticipate that future are needed to support scalable trust information in transit and at rest across
certification editions will require more between Security/Trust Agents (STAs) all industries. As such, we encourage
extensively coded data. as well as ways in which we, in developers to provide innovative
collaboration with other industry options for individuals to easily and
Web Content Accessibility Guidelines stakeholders, could support or help efficiently protect their health
(WCAG) coordinate a way to bridge any gaps. information based on generally available
We proposed to modify the regulatory Comments. One commenter noted mechanisms for security and new
text hierarchy at § 170.204(a) to that the proposed inclusion of the Direct advances in this area. In either case—
designate the WCAG 2.0 Level A (Level Project’s Implementation Guide for whether by email or an encrypted
A) conformance at § 170.204(a)(1) Trust Bundle Distribution will be method—the goal is to support patients
instead of § 170.204(a). This would also confusing because most of the Direct in transmitting their health information
require the 2014 Edition ‘‘VDT’’ Project IG for the trust bundle focuses on demand to a third party of their own
certification criterion to be revised to on creating a trust bundle, not choice. We note that, for certification,
correctly reference § 170.204(a)(1). We consuming it. The commenter the encrypted method would be subject
also sought comment on whether we recommended pointing developers to to the 2015 Edition privacy and security
should adopt WCAG 2.0 Level AA Section 3.0 Trust Bundle Requestors for certification framework, particularly the
(Level AA) conformance requirements additional guidance, and that we ‘‘trusted connection’’ certification
for the ‘‘view’’ capability included in support participation in existing trust criterion. We refer readers to section
the 2015 Edition VDT criterion, instead communities such as the National IV.C.1 (‘‘Privacy and Security’’) of this
of the current Level A. Association for Trusted Exchange preamble for further discussion of the
Comments. Many commenters (NATE). Another commenter 2015 Edition P&S certification
representing the patient advocate recommended that we require EHR and framework and to the ‘‘application
community supported the increase to HISP vendors to preload all Blue Button access to Common Clinical Data Set’’
Level AA; additionally, the U.S. Access Patient Trust Bundles into their systems section of this preamble for more
Board noted that other federal agencies so providers using these systems can information of the ‘‘trusted connection’’
and programs are moving toward Level transmit records using the Direct certification criterion.
AA. Other commenters said that Level protocol. In adding flexibility to this portion of
A conformance was sufficient and that Response. Our intent is to ensure that the certification criterion, the other
level AA is not needed and overly an individual who wants to transmit his proposals and topics on which we
burdensome. or her health information to a third sought comment are moot. However, we
Response. We have adopted and party has options to be able to do so, wish to reiterate that for the purposes of
retained the Level A requirement for and those options should be easy and meeting the second form of
this criterion. However, we have convenient. Individuals who are more transmission, the Direct protocol is an
included Level AA as an optional concerned about sharing their data in encouraged and viable method,
component of this certification criterion transit can choose a more secure, simple especially since health IT developers
via an ‘‘or’’ in the certification criterion option for transmitting this information. have already been certified to this
so that if a developer so chooses it can To provide greater flexibility for functionality for the purposes of 2014
demonstrate that a Health IT Module patients to effectively use the ‘‘transmit’’ Edition certification, and will also be
can meet Level AA. We reiterate that the capability and to ensure that patients
‘‘or’’ does not mean that a technology have an easy and near universal ability 103 Please see the OCR frequently asked questions
would need to meet both levels. At a to send their health information to a for best practices regarding the use of email for
transmitting health information: http://
minimum it would need to meet Level destination they select, we have adopted www.hhs.gov/ocr/privacy/hipaa/faq/health_
A. We note that such information would a more flexible approach for testing and information_technology/570.html.
be listed with the product as part of its certifying ‘‘transmit’’ as part of this 104 45 CFR 164.524 and related guidance.
certified to this functionality as part of commenter also suggests that if the CMS health IT. ONC–ACBs also conduct
2015 Edition certification to support proposal is adopted, the criterion surveillance of certified health IT under
transitions of care requirements through should clearly define exclusion criteria. the ONC Health IT Certification Program
the 2015 Edition ‘‘ToC’’ criterion. Response. We have adopted this to ensure that health IT continues to
Additionally, we clarify that with criterion with modification. We have function as initially certified.
respect to the second method, health IT removed the specific security Surveillance can be initiated randomly
developers have the flexibility to either requirements out of the criterion or in response to complaints.
establish an encrypted connection because the appropriate privacy and For concerns and questions related to
between two end points or, security (P&S) requirements will be the EHR Incentive Programs, we refer
alternatively, secure the payload via applied through the 2015 Edition P&S readers to CMS and the EHR Incentive
encryption. In other words, we make no certification framework finalized in this Programs Stage 3 and Modifications
presumption and do not imply through final rule. To clarify, a Health IT final rule published elsewhere in this
the language in the second method that Module certified to this criterion will issue of the Federal Register. We note
only one approach will satisfy testing still need to demonstrate the same that health IT certified to certification
and certification. security requirements as included in the criteria that support percentage-based
proposed criterion (patient/user measures under the EHR Incentive
C–CDA Data Provenance Request for authentication and encryption and
Comment Programs (i.e., this criterion) must also
integrity-protection), but there will be be able to record, at a minimum, the
We refer readers to our response to more flexibility in that a health IT numerator for that measure per the
this request for comment under the developer can choose between message- CEHRT definition requirements and the
‘‘ToC’’ criterion. level or transport level certification in ‘‘meaningful use measurement
• Secure Messaging accordance with § 170.315(d)(9). calculation’’ certification criteria
Certification to this criterion will also (§ 170.315(g)(1) and (g)(2)).
2015 Edition Health IT Certification Cri- require certification to other privacy and
terion • Patient Health Information Capture
security criteria under the P&S
§ 170.315(e)(2) (Secure messaging) certification framework, including
automatic log-off (§ 170.315(d)(5)) and terion
We proposed to adopt a 2015 Edition the auditing criteria (§ 170.315(d)(2) and
‘‘secure messaging’’ certification § 170.315(e)(3) (Patient health information
(3)). Our revisions to the criterion and capture)
criterion that was unchanged in approach are consistent with our overall
comparison to the 2014 Edition ‘‘secure approach to applying the appropriate
messaging’’ criterion (§ 170.314(e)(3)). In following the HITSC
privacy and security certification recommendation for Health IT Module
Comments. The majority of requirements to each 2015 Edition
commenters supported this criterion as functionality to store an advance
certification criterion. We refer readers directive and/or include more
proposed. Some commenters suggested to section IV.C.1 (‘‘Privacy and
additional functionality for this information about the advance directive,
Security’’) of this preamble for further we proposed a 2015 Edition ‘‘patient
criterion, including the ability to track discussion of the 2015 Edition P&S
responses to patient-generated health information capture’’
certification framework, including certification criterion that would
messages, support languages other than specific application of the P&S
English, and other forms of ‘‘replace’’ the 2014 Edition ‘‘advance
certification framework to a Health IT directives’’ certification criterion
communication including audio, video, Module presented for certification to the
or images. A few commenters (§ 170.314(a)(17)) and apply to various
‘‘secure messaging’’ criterion in patient health information documents.
questioned whether patients’ devices conjunction with other certification
would need to be secure and encrypted, We stated that a Health IT Module
criteria.
and whether the encryption criteria would need to enable a user to: (1)
This criterion is no longer eligible for
would only apply to the message gap certification as the new hashing Identify (e.g., label health information
content. A commenter recommended standard (a hashing algorithm with a documents as advance directives and
that health IT developers should have to security strength equal to or greater than birth plans), record (capture and store)
preload trust bundles. Another SHA–2) applies to this criterion. and access (ability to examine or
commenter suggested that health IT We appreciate the suggested review) patient health information
developers should be prohibited from additional functionalities for inclusion documents; (2) reference and link to
charging significant add-on fees for in this criterion (tracking responses, use patient health information documents;
secure messaging. Another commenter of languages beyond English, and other and (3) record and access information
recommended that in-the-field forms of communication, and preloaded directly and electronically shared by a
surveillance is needed to ensure that trust bundles), but the functionalities patient.
health IT developers and providers were are beyond the scope of our proposal. We received general comments and
enabling this functionality. A We will consider these additional comments on each of the capabilities
commenter listed several issues functionalities for a future edition of included in the proposed criterion. We
associated with the EHR Incentive this criterion. We clarify in this final have divided and responded to the
Programs Stage 3 objective and measure rule that the encryption requirements comments in a similar manner.
related to secure messaging, including only apply to the message content and Comments. Commenters expressed
the lack of a routine secure messaging not to patients’ devices. general agreement with this criterion,
use case for eligible hospitals and CAHs, We cannot prescribe the fees health IT with broad support across health IT
that only certain types of secure developers charge for their certified developers, providers, consumers, and
messages would count, that the API health IT, but note that our transparency various advocacy groups. Commenters
alternative might drive down secure provisions (§ 170.523(k)) require ONC– stated that this functionality could
messaging using certified health IT, and ACBs to ensure that health IT support addressing health disparities in
that measurement should be based on developers make public the types of populations that are less likely to
those patients who ‘‘opt in.’’ This same costs they charge to enable certified execute healthcare planning documents
or provide health information to suffice for provider use, a Health IT appropriate standards that we could
providers. Module will still need to demonstrate adopt that cover all the conceivable use
Response. We thank commenters for the ability to link to an external site via cases.
their feedback. We have adopted this the internet for the purposes of This criterion was specifically
criterion as proposed with the revisions certification. The requirement of this included in the CEHRT definition to
and clarifications specified below. As provision does not go beyond this ensure, at a minimum, providers
adopted, we anticipate health IT specified functionality. participating in the EHR Incentive
developers will develop innovative and This criterion is subject to the 2015 Programs had this capability. While it
efficient ways to meet this criterion and Edition privacy and security (P&S) could potentially be used to support the
simultaneously support providers certification framework adopted in this Stage 3 objective and measure regarding
accepting health information from final rule. In this regard, a Health IT patient-generated health data, it was not
patient. Module certified to this criterion would proposed with the intention of it being
Identify, Record, and Access also need to be certified to the P&S the only means available for meeting the
Information Documents certification criteria in § 170.315(d)(1) Stage 3 objective and measure. Rather,
(authentication, access control, and the goal was to set a foundation for
Comments. Commenters universally authorization), (d)(2) (auditable events accepting information directly from
supported this proposed provision. and tamper resistance), (d)(3) (audit patients.
Response. We thank commenters for We do not seek to define the types of
reports), (d)(4) (amendments), (d)(5)
their support. We have adopted the health information that could be
(automatic log-off), and (d)(9) (trusted
capabilities of this provision (identify, accepted as we believe this should be as
connection).105 We believe these
record, and access information broad as possible. The types of health
certification criteria and included
documents) by combining them with the information could be documents as
capabilities will assist a provider in
proposed provision of this criterion that described in the Proposed Rule (e.g.,
protecting its health IT system against
included capabilities to record and advance directive or birth plans) or
potential security concerns. However,
access information directly and health information from devices or
we note that certification is a baseline.
electronically shared by a patient. The applications. The devices and
Health IT developers and providers
capabilities to identify, record, and applications could include home health
have the discretion to both determine
access patient health information or personal health monitoring devices,
what types of security features should
documents are essentially a subset of fitness and nutrition applications, or a
be implemented (e.g., multi-factor
the capabilities to record and access variety of other devices and
authentication) with the functionality
information directly and electronically applications. In addition, patient health
included in this criterion and whether
shared by a patient, except for the information could be accepted directly
to accept specific electronic information
proposed ‘‘identification’’ capability. and electronically through a patient
from a patient, such as a URL.
Therefore, we have specifically retained portal, an API, or even email.
the ‘‘identification’’ capability, while Record and Access Information Directly We have determined that it is most
merging the other capabilities to finalize Shared by a Patient appropriate to keep all the functionality
a provision that requires health IT to Comments. Many commenters in one criterion and combine
enable a user to identify, record, and expressed support for this provision, capabilities as noted above. We
access information directly and including not specifying standards for emphasize that it is always possible to
electronically shared by a patient (or compliance. A few commenters have multiple technologies certified
authorized representative). requested we identify standards or together as a one ‘‘Health IT Module’’ to
Reference and Link Documents ensure compatibility with other meet this criterion.
standards such as the C–CDA or Direct We note that we intend for ‘‘patient’’
Comments. Most commenters to be interpreted broadly to include an
supported this requirement, while some messaging protocol. Most commenters
sought clarification of this requirement. authorized representative. For clarity,
commenters did not agree that there was we have specified this intent in
value in linking documents and others A couple of commenters suggested we
drop this provision. A few commenters regulation.
expressed security concerns. A • Transmission To Immunization
commenter stated that a link could requested to know if this criterion was
intended to directly support the Registries
require additional log in credentials. A
few commenters also expressed proposed EHR Incentive Programs Stage
3 objective and measure regarding 2015 Edition Health IT Certification Cri-
concerns regarding a system’s need to terion
capture information from any external patient-generated health data and what
§ 170.315(f)(1) (Transmission to immuniza-
internet site, stating that a patient types of patient health information was tion registries)
(intentionally or unintentionally) could contemplated by this criterion. A
provide a URL to the provider that commenter suggested making this We proposed to adopt a 2015 Edition
contained a virus. functionality a separate criterion. ‘‘transmission to immunization
Response. The criterion focuses solely Response. The intent of this provision registries’’ certification criterion that
on the ability of the Health IT Module is to establish at least one means for was revised in comparison to the 2014
to be able reference (providing narrative accepting patient health information Edition ‘‘transmission to immunization
information on where to locate a directly and electronically from patients registries’’ criterion (§ 170.314(f)(2)). To
specific health information document) in the most flexible manner possible. note, we have structured the comments
and link to patient health information. This approach means focusing on we received and our responses based on
‘‘Linking,’’ as described in the Proposed functionality and not standards. the specific proposed provisions of this
Rule, requires a Health IT Module to Further, we do not believe there are criterion.
demonstrate it could link to an internet 105 We refer readers to section IV.C.1 (‘‘Privacy
Comments. Most commenters
site storing a health information and Security’’) of this preamble for further
supported the proposed criterion. Many
document. While an intranet link to a discussion of the 2015 Edition P&S certification commenters noted the value of the
health information document might framework. proposed criterion to bi-directional data
exchange of immunization data, which These commenters asked for proposed to adopt the HL7 Standard
was not supported by the functionality clarification of the required use of Code Set CVX—Vaccines Administered,
included in the 2014 Edition aggregated OMB standard values. updates through February 2, 2015 108 as
‘‘transmission to immunization Response. We appreciate the support the baseline version for certification to
registries’’ criterion. Commenters also for Release 1.5. We note that the CDC the 2015 Edition.
noted the importance of NDC and CVX has issued an addendum to Release We solicited comment on whether we
codes, but expressed concern regarding 1.5.106 The addendum consolidates the should allow use of NDC codes for
issues with NDC codes as discussed in IG information that clarifies the administered vaccines as an option for
more detail below. One commenter conformance requirements, but does not certification, but continue to require
suggested that intermediaries should be specify additional substantive CVX codes for administered vaccines for
able to play a role, such as requirements. The addendum also the 2015 Edition. We also solicited
transformation of the data, in the provides value set requirements, general comment on whether we should require
transmission of immunization data and clarifications, and errata. The errata CVX plus the HL7 Standard Code Set
that only one system in the process of provides corrections to the length, data MVX—Manufacturers of Vaccines Code
moving the immunization information type, data type descriptions, usage, Set (October 30, 2014 version) 109 as an
from sender to public health agency cardinality and/or value sets for various alternative to NDC codes for
should be required to be certified. message elements, as well as corrections administered vaccines, and we sought
Another commenter requested to, and addition of, conformance feedback on the implementation burden
clarification if the criteria would be part statements where they were mistakenly for health IT developers and health care
of the Base EHR definition. omitted. The addendum also includes providers related to requiring CVX plus
Response. We appreciate the support clarifications to use of coding systems MVX codes versus NDC codes for
for the proposed certification criterion. and value sets, additional examples of administered vaccines.
We have adopted this certification sending multiple forecast Comments. The majority of
criterion as proposed, but with an recommendations in a single message, commenters supported the use of NDC
update to the proposed IG and the usage of particular message elements codes for administered vaccines and
clarifications in response to comments (including those in the ORC and RXA CVX codes for historical vaccines.
discussed in detail below. We clarify for segments), and updates to the value sets Commenters stated that using NDC
commenters that any health IT can be for patient eligibility status and vaccine codes for administered vaccines is
certified to this criterion if it can meet funding source. We believe that Release valuable because NDC codes provide
all the requirements of the criterion, 1.5 and the addendum are important more granular data than CVX codes,
which include context exchange and components to advancing public health which can improve patient safety.
vocabulary standards but do not specify reporting and interoperability. We, Comments also stated that adopting
a transport standard or mechanism. We therefore, have adopted HL7 Version NDC for administered vaccines aligns
further clarify that this criterion is not 2.5.1: Implementation Guide for with on-going industry efforts related to
included in the 2015 Edition Base EHR Immunization Messaging, Release 1.5 vaccine data capture.
definition, but would support meeting (October 1, 2014) and HL7 Version Some commenters suggested that
one of measures under the public health 2.5.1: Implementation Guide for mapping NDC codes to CVX could be
objective of the EHR Incentive Programs Immunization Messaging, Release 1.5, burdensome for health IT developers
Stage 3. Addendum (July 2015) for the and immunization registries, especially
Implementation Guide for Transmission transmission to immunization for a multiple component vaccine.
to Immunization Registries requirement. We clarify that to meet this Commenters noted that NDC codes are
criterion, health IT must comply with subject to change and codes are added
We proposed to adopt the CDC’s
all mandatory requirements of Release and changed more frequently than CVX
updated implementation guide for
1.5 and its addendum, which would and MVX codes. Commenters further
immunization messaging, HL7 Version
include the coding for race and noted that the reuse of NDC codes by
2.5.1: Implementation Guide for
ethnicity. The 2015 Edition FDA can present difficulties regarding
Immunization Messaging, Release 1.5
‘‘demographics’’ criterion and Common the transmission of immunization data
(October 2014) (‘‘Release 1.5’’). We
Clinical Data Set requirements related to using such codes. One commenter
explained that the updated IG promotes
race and ethnicity are not implicated by requested clarification on when NDC
greater interoperability between
this criterion. and CVX codes are required and noted
immunization registries and health IT
the importance of clear requirements by
systems, addresses issues from the National Drug Codes for Administered states when NDC, CVX, or both codes
previous release, and revises certain Vaccinations would be needed.
HL7 message elements to reduce data
We proposed to require for Response. We appreciate commenters
element recording differences between
certification that a Health IT Module be support for the use of NDC codes for
states and public health jurisdictions.
able to electronically create administered vaccines and CVX codes
Comments. The majority of
immunization information for electronic for historical vaccines. For the purposes
commenters supported adoption of
transmission to immunization registries of administered vaccines, when an
Release 1.5, acknowledging that it
using NDC codes for vaccines immunization is reported at the time it
resolves known issues in the previous
administered (i.e., the National Drug is administered and the actual product
release and offers improved support for
Code Directory—Vaccine Codes, is known, the NDC code must be sent.
standard data transmission. Some
updates through January 15, 2015 107). We clarify that for when sending
commenters noted that Release 1.5
For historical vaccines, we proposed to historical vaccines and the actual NDC
includes references to the CDC Race and
continue the use of CVX codes and code is not available, CVX codes can be
Ethnicity code set for purposes of the
exchange of race and ethnicity data— 106 http://www.cdc.gov/vaccines/programs/iis/ 108 http://www2a.cdc.gov/vaccines/iis/
which is more granular regarding race technical-guidance/hl7.html. iisstandards/vaccines.asp?rpt=cvx.
and ethnicity options for reporting 107 http://www2a.cdc.gov/vaccines/iis/ 109 http://www2a.cdc.gov/vaccines/iis/
when compared to the OMB standards. iisstandards/ndc_tableaccess.asp. iisstandards/vaccines.asp?rpt=mvx.
sent as this method would be supported were not ready for bi-directional data requirements. Providers and health IT
by health IT certified to this criterion. exchange. Other commenters, however, developers may reconcile forecast and
We understand the concerns regarding noted that 28 Immunization Information history information in a manner that
ensuring that the appropriate amount of Systems (IIS) (which, according to the best meets their needs for workflow and
information is available for commenter, represents about 52% of patient safety.
immunizations and the concern reporting systems) have notified the • Transmission to Public Health
regarding mapping between NDC and CDC of their query capabilities in Agencies—Syndromic Surveillance
CVX for purposes of reporting. production today using HL7 2.5.1. The
Therefore, we finalize a criterion that commenter noted that the proportion 2015 Edition Health IT Certification Cri-
supports one set of codes to be used for would likely rise to near 100% by 2018. terion
administered vaccines at all times and A few commenters questioned the § 170.315(f)(2) (Transmission to public
another set of codes to be used for utility of the ability to query a state health agencies—syndromic surveillance)
historical vaccines at other times. registry.
Therefore, we have adopted the August Many commenters also expressed We proposed to adopt a 2015 Edition
17, 2015 version of the CVX code set as concern regarding reconciliation of certification criterion for transmission of
the minimum standards code set for forecasting data. One commenter noted syndromic surveillance to public health
historical vaccines. For purposes of that we should permit innovation to agencies that was revised in comparison
administered vaccines, we have adopted occur by not prescribing the workflows to the 2014 Edition version
the National Drug Codes (NDC)— related to reconciliation. Another (§ 170.314(f)(3)) for the inpatient setting.
Vaccine NDC Linker, updates through commenter noted that where bi- We noted, however, that this proposed
August 17, 2015 as the minimum directional exchange is already in certification criterion is unchanged (for
standards code set. We refer readers to production, several different workflows the purposes of gap certification) for the
section III.A.2.c (‘‘Minimum Standards’’ exist within health IT products for ambulatory setting. Given the varied
Code Sets) for further discussion of our reconciliation of immunization history. adoption of methods for transmitting
adoption of minimum standards code Commenters expressed support for syndromic surveillance information to
sets and our decision to adopt these vaccine forecasting, but many public health agencies from ambulatory
versions. commenters also stated that settings, we proposed to continue to
incorporating a forecast from an distinguish between ambulatory and
Immunization History and Forecast immunization registry into a health IT emergency department, urgent care, and
We proposed that a Health IT Module system could be difficult. Other inpatient settings.
would need to enable a user to request, commenters noted that some products Comments. Commenters expressed
access, and display a patient’s already have forecasting functions, such support for distinguishing ambulatory
immunization history and forecast from as CDS functions for forecasting settings from emergency department,
an immunization registry in accordance immunizations and, by association with urgent care and inpatient settings,
with Release 1.5. We requested forecasting, more complete data for especially given the variations in data
comment on whether we should include allergies and contraindications. requirements and readiness for data
an immunization history information Response. We have adopted the acceptance among the states. A
reconciliation capability in this criterion requirement for a Health IT Module to commenter also noted that the
and the factors we should consider enable a user to request, access, and distinction was appropriate because
regarding the reconciliation of display a patient’s immunization history ambulatory systems are still evolving.
immunization history information. We and forecast from an immunization Some commenters requested
explained that we believe that registry in accordance with the Release clarification of exclusions, active
bidirectional exchange between health 1.5 IG. We note that this criterion and engagement, and other requirements to
IT and immunization registries is its included capabilities are designed meet the syndromic surveillance
important for patient safety and and focused on health IT, such as EHRs. measure under the EHR Incentive
improved care. Immunization registries In this regard, the goal is that health IT Programs.
can provide information on a patient’s is certified to the criterion and its Response. We appreciate the support
immunization history to complement included capabilities (e.g., the Release offered by commenters and agree that it
the data in the health IT system. We 1.5 IG). Providers who adopt health IT is appropriate to distinguish between
noted that immunization registries also certified to this criterion would then settings. For questions related to the
provide immunization forecasting have the capabilities to meet EHR Incentive Programs, we refer
recommendations according to the requirements under the EHR Incentive readers to CMS and the EHR Incentive
Advisory Committee on Immunization Programs or query an IIS. Programs Stage 3 and Modifications
Practices (ACIP)’s recommendations. While we agree with commenters that final rule published elsewhere in this
This information allows for the provider some health IT (e.g., EHR products) may issue of the Federal Register.
to access the most complete and up-to- sometimes have a version of the
date information on a patient’s immunization history or a version of the Emergency Department, Urgent Care,
immunization history to inform forecast that may differ from the and Inpatient Settings
discussions about what vaccines a immunization registry, we still believe We proposed to adopt the PHIN
patient may need based on nationally that it is important for an EHR to receive Messaging Guide for Syndromic
recommended immunization the history and forecast from the Surveillance: Emergency Department,
recommendations. registry. Based on compliance with the Urgent Care, Inpatient and Ambulatory
Comments. Many commenters Release 1.5 IG, a user would be able to Care Settings, Release 2.0, September
recognized the benefit of bi-directional see and compare the forecast from the 2014 (‘‘Release 2.0’’), due to its
data exchange to patient safety and certified health IT (e.g., EHR products) improvements over previous versions.
population health, but some with the forecast from the immunization Comments. The majority of
commenters expressed concern. registry. However, we note that this commenters supported the proposed IG.
Commenters primarily expressed criterion does not prescribe a particular One commenter suggested that, due to
concern that immunization registries workflow or reconciliation state variability, a standard should not
be referenced until at least 75% of states laboratory information is reportable to appropriate for use in that particular
are committed to the use of a common public health through electronic setting.
standard. Other comments noted that laboratory reporting. These additional • Transmission To Public Health
Release 2.0 is the standard used by all data elements enable public health Agencies—Reportable Laboratory Tests
states accepting hospital-based jurisdictions to monitor the nation’s and Values/Results
syndromic surveillance data. A public health. We also clarify that the
commenter suggested that laboratory aggregated OMB value sets for race and 2015 Edition Health IT Certification Cri-
information be removed as required ethnicity are acceptable within Release terion
from the IG as states already collect this 2.0. We decline to make the optional § 170.315(f)(3) (Transmission to public
elements of the IG required for health agencies—reportable laboratory
information under electronic laboratory tests and values/results)
reporting. One commenter suggested certification as we believe that
that there was a potential discrepancy certification to the IG as published We proposed to adopt a 2015 Edition
between OMB value sets for race and appropriately supports the use case. We certification criterion that was revised
ethnicity and the CDC Race and also note that any IG instructions in comparison to the 2014 Edition
Ethnicity referenced code set in the IG. regarding the frequency of submission ‘‘transmission of reportable laboratory
Another commenter asked for are outside the scope of certification as tests and values/results’’ criterion
clarification of the ‘‘message frequency certification focuses on the technical (§ 170.314(f)(4)). We proposed to name
requirement of syndromic messages,’’ capabilities of the Health IT Module this criterion ‘‘transmission to public
noting that the requirements within presented for certification. health agencies—reportable laboratory
Release 2.0 may be burdensome for Ambulatory Syndromic Surveillance tests and values/results’’ to clearly
health IT developers. A commenter convey the capabilities included in this
requested that certification include We proposed to permit, for
ambulatory setting certification, the use criterion as they relate to the intended
optional data elements within the IG. recipient of the data. We proposed to
Response. We appreciate the overall of any electronic means for sending
syndromic surveillance data to public include and adopt an updated IG, the
support for this criterion and the HL7 Version 2.5.1 Implementation
Release 2.0 IG. The CDC has recently health agencies as well as optional
certification to certain syndromic Guide: Electronic Laboratory Reporting
published an updated version of the IG to Public Health, Release 2 (US Realm),
(April 21, 2015) 110 that reflects work to surveillance data elements. Due to the
continued lack of mature IGs, we DSTU R1.1, 2014 or ‘‘Release 2, DSTU
correct errors and clarify ambiguities R1.1’’) that addresses technical
proposed to provide the option for
that were present in the proposed corrections and clarifications for
health IT to electronically produce
version (dating back to Release 1.0) as interoperability with laboratory orders
syndromic surveillance information that
well as provide missing information. and other laboratory domain
contains patient demographics, provider
The CDC also recently published an implementation guides. Given the
specialty, provider address, problem
addendum to the IG, titled ‘‘Erratum to improvements included in the updated
list, vital signs, laboratory results,
the CDC PHIN 2.0 Implementation IG (Release 2, DSTU R1.1), we proposed
procedures, medications, and insurance.
Guide, August 2015; Erratum to the CDC Comments. Most commenters stated to adopt it at § 170.205(g)(2) and include
PHIN 2.0 Messaging Guide, April 2015 that the majority of public health it in the 2015 Edition ‘‘transmission of
Release for Syndromic Surveillance: jurisdictions do not accept ambulatory reportable laboratory tests and values/
Emergency Department, Urgent Care, syndromic surveillance data and that results’’ certification criterion at
Inpatient and Ambulatory Care the standards for ambulatory syndromic § 170.315(f)(3). We also proposed the
Settings’’ (‘‘Erratum’’).111 The Erratum surveillance are not mature. In September 2014 Release of the U.S.
consolidates Release 2.0 information particular, one commenter noted that Edition of SNOMED CT® and LOINC®
and clarifies existing conformance syndromic surveillance standards for version 2.50. We also proposed to make
requirements of the IG. For example, it ambulatory encounters remain ill- a technical amendment to the regulation
specifies conformance statements and defined and derivative of the inpatient text for the 2014 Edition criterion in
conditional predicates that clarify standards. A few commenters stated that order to have it continue to reference
message requirements. It also specifies the ‘‘flexibility’’ in certification created the appropriate standard and
value set requirements, provides general burden on both providers and health IT implementation specifications 112 after
clarifications, and PHIN MG corrections. developers to develop and implement we restructured the regulatory text
Overall, the April 21, 2015, updated health IT to meet the specified data hierarchy at § 170.205(g) to
version and the addendum do not create elements without an established use accommodate our 2015 Edition
additional substantive requirements in case across public health jurisdictions. proposal.
comparison to Release 2.0. Rather, Response. With consideration of Comments. Most commenters
through the corrections, clarifications, public comments, comments received supported the proposed criterion and
and additional information the IG will on a prior rulemaking (79 FR 54439– standards. A few commenters expressed
improve testing, certification, 54441), and stakeholder feedback concern with the proposed IG related to
implementation, and interoperability. through public health outreach, we have use of OIDs, SPM–22 and SPM–24.
Therefore, we have adopted this determined to not adopt certification Response. We appreciate the
criterion with both the April 21, 2015, requirements for the ambulatory setting. expression of support for this criterion
updated version and addendum. Without mature standards and the and the proposed standards. We note,
We believe that the additional IG widespread acceptance of ambulatory however, that the HL7 Public Health
requirements for laboratory information syndromic surveillance data across and Emergency Response Workgroup is
are critical for public health as not all public health jurisdictions, sufficient currently working on a newer version of
reason does not exist to justify
110 http://www.cdc.gov/nssp/documents/guides/ 112 HL7 2.5.1 and HL7 Version 2.5.1:
certification to the proposed
syndrsurvmessagguide2_messagingguide_phn.pdf. Implementation Guide: Electronic Laboratory
111 http://www.cdc.gov/nssp/documents/guides/ functionality. To clarify, the PHIN 2.0 Reporting to Public Health, Release 1 with Errata
erratum-to-the-cdc-phin-2.0-implementation-guide- IG does support the urgent care and Clarifications and ELR 2.5.1 Clarification
august-2015.pdf. ambulatory setting and would be Document for EHR Technology Certification.
the proposed IG that harmonizes with ‘‘transmission to cancer registries’’ template had grown into a large, multi-
the HL7 Laboratory Results Interface certification criterion (§ 170.314(f)(6)). level template that was difficult to
(LRI) profiles. Harmonization with LRI We proposed to adopt the HL7 implement and test. Similar changes
will address the noted concerns as well Implementation Guide for CDA© were made to the TNM Pathologic Stage
as ensure alignment across laboratory Release 2: Reporting to Public Health Observation template. Release 1.1 also
IGs, including the LRI IG and the Cancer Registries from Ambulatory addresses the contradictory use of
Laboratory Orders Interface (LOI) IG. Healthcare Providers Release 1 or ‘‘HL7 nullFlavor attributes. A final notable
This updated IG is not yet complete and Release 1 IG’’) to address technical revision is a constraint in the Cancer
cannot be adopted at this time. With corrections and clarifications for Diagnosis Observation that provided a
these considerations, we do not believe interoperability with EHRs and cancer choice between the TNM Pathologic
it would be appropriate to adopt the registries, at § 170.205(i)(2). We Stage Observation and a No Known
proposed IG as health IT developer and proposed to include the September 2014 TNM Pathologic Stage Observation was
provider efforts to meet and implement Release of the U.S. Edition of SNOMED replaced by a choice of standard
the requirements of the proposed IG CT® and LOINC® version 2.50 in this constraints on the same two templates.
would shortly be superseded by the criterion. We proposed to modify the This revision results in both an easier to
updated IG. Therefore, we have not 2014 Edition certification criterion to understand specification and a
adopted the proposed IG. We have also reference § 170.205(i)(1) to establish the simplified schematron file used for
not adopted the updated vocabulary regulatory text hierarchy necessary to validation.
standards because without a newer IG, accommodate the standard and IG We have adopted this criterion with
there is little benefit from having health referenced by the proposed 2015 Edition the updated IG, Release 1.1 (both
IT developers be tested and certified to certification criterion. Volumes 1 and 2). Commenters were
updated vocabulary standards for this Comments. The majority of supportive of our overall proposed
particular use case. commenters expressed support for this approach and the proposed IG. As
We have adopted a 2015 Edition criterion as proposed, including the HL7 detailed above, Release 1.1 addresses
‘‘transmission to public health Release 1 IG. Commenters stated that errors, ambiguities, implementation
agencies—reportable laboratory tests the proposed IG would provide issues, and commenters’ concerns.
and values/results’’ certification substantial improvements in cancer Therefore, the adoption of Release 1.1
criterion that requires adherence to the reporting. Commenters also expressed will lead to improved implementation
same standards as we referenced in the support for incorporating updated and interoperability.
2014 Edition ‘‘transmission of versions of SNOMED CT® and LOINC® Mapping to the NAACCR format is
reportable laboratory tests and values/ in this criterion as the vocabulary not included in the IG because the
results’’ criterion. Data from CDC and standards align with the IG mapping rules are complex, and can
CMS indicates that over 80% of requirements. Some commenters change over time based on continued
hospitals are already in the process of suggested mapping the IG to the input and refinement by the cancer
submitting electronic laboratory results currently used North American registry community. It is our
using the previously adopted standards Association of Central Cancer Registries understanding that the CDC will work
(HL7 Version 2.5.1 Implementation (NAACCR) format for any new cited closely with the cancer registry
Guide: Electronic Laboratory Reporting standards. A commenter contended community to develop mapping rules
to Public Health, Release 1 with Errata there was contradictory use of null for the IG and will incorporate the rules
and Clarifications, ELR 2.5.1 values within the proposed IG. A few into the software tools CDC provides
Clarification Document for EHR commenters expressed general concern state cancer registries. In regard to
Technology Certification, and versions regarding a lack of standardization concerns expressed about jurisdictional
of SNOMED CT® and LOINC®). Our across public health jurisdictions and variations, all public health
decision to adopt these same standards registries to accept data according to jurisdictions have all adopted the HL7
for the 2015 Edition criterion will proposed public health standards. IG Release 1 for cancer reporting and
ensure continuity in reporting and Response. We appreciate the overall will be moving to the updated version
reduce burden for providers as well as support for this criterion and the HL7 published by the CDC.
health IT developers as this criterion is Release 1 IG. The CDC recently We have adopted a newer baseline
eligible for gap certification. We will published and updated version of the IG versions of SNOMED CT® (September
continue to monitor the development of (HL7 CDA® Release 2 Implementation 2015 Release of the U.S. Edition) and
the updated IG and may consider Guide: Reporting to Public Health LOINC® (version 2.52) for the purposes
proposing it for adoption through a Cancer Registries from Ambulatory of certification. We refer readers to
future rulemaking to give health IT Healthcare Providers, Release 1; DSTU section III.A.2.c (‘‘Minimum Standards’’
developers and providers another Release 1.1, U.S. Realm) 113 (‘‘Release Code Sets) for further discussion of our
option to meet EHR Incentive Programs 1.1.’’). Release 1.1 involves technical adoption of minimum standards code
requirements for use of certified health corrections to Release 1. No new content sets and our decision to adopt these
IT to meet public health objectives and has been included. The templates in the versions.
measures. IG were versioned due to the versioning
Cancer Case Information
• Transmission To Cancer Registries of included templates (see the detailed
section ‘‘Changes from Previous We did not propose a ‘‘cancer case
2015 Edition Health IT Certification Cri- Version’’ in Volume 2 of this guide for information’’ criterion as part of the
2015 Edition (80 FR 16854–855), but
terion a detailed view of these changes). The

§ 170.315(f)(4) (Transmission to cancer reg- TNM Clinical Stage Observation was welcomed comments on this approach.
istries) separated into a nested series of smaller, Comments. Commenters expressed
easier to implement templates. To note, agreement with discontinuing the
We proposed to adopt a 2015 Edition the TNM Clinical Stage Observation ‘‘cancer case information’’ certification
‘‘transmission to cancer registries’’ criterion, with a commenter noting the
certification criterion that was revised 113 http://www.hl7.org/implement/standards/ relevant data elements are already
in comparison to the 2014 Edition product_brief.cfm?product_id=398. contained in the IG referenced in the
2015 Edition ‘‘transmission to cancer the 2015 Edition. The latter commenters provider name, office contact
registries’’ certification criterion. A stated that the IG is primarily driven by information, and reason for visit, and an
commenter asked for clarification as to clinical research requirements and has identifier representing the row and
whether the discontinuation of this not been adopted by the public health version of the trigger table that triggered
criterion affects the requirements of the community. Some commenters the case report).
‘‘transmission to cancer registries’’ expressed concern with the potential The CCD template of the C–CDA
certification criterion and the use of the FHIR standard, stating it is Release 2.1 is currently the most viable
requirements of the IG. immature and requires piloting and approach for achieving step (2) above.
Response. We thank commenters for initial deployments before it can be We note, however, that the CDC and
their feedback and have not adopted a adopted as a national standard. A CSTE, with the HL7 Public Health and
‘‘cancer case information’’ certification commenter recommended that case Emergency Response Working Group,
criterion. This decision has no impact reporting remain as a public health are currently developing C–CDA and
on the requirements of the 2015 Edition reporting option for the EHR Incentive FHIR IGs to specify the data needed in
‘‘transmission to cancer registries’’ Programs, but not be constrained by a the initial case report form and the data
certification criterion or the requirement to use a specific standard. that would be provided in the
requirements of the IG. Certification to Response. We understand information returned to the provider. As
the 2015 Edition ‘‘transmission to commenters’ concerns with the current standards evolve, additional/
cancer registries’’ criterion requires a state of standards available and the supplemental data would likely be
Health IT Module to demonstrate that it continual evolution of standards. We requested electronically about cases for
can create a file with the necessary also agree with commenters’ suggestions which public health has received an
cancer case information in accordance that an appropriate approach for this initial case report that is deemed
with the IG. criterion would be to permit flexibility reportable. To support this additional
• Transmission To Public Health for case reporting by not referencing a data reporting, the future might include
Agencies—Electronic Case Reporting specific content exchange standard for a FHIR-based approach that could
certification at this time. utilize the FHIR Structured Data
2015 Edition Health IT Certification Cri- We understand the industry is moving Capture (SDC) IG. Therefore, we believe
terion towards RESTful approaches and this overall initial certification approach
§ 170.315(f)(5) (Transmission to public considering FHIR for different exchange establishes necessary flexibility within
health agencies—electronic case report- patterns, including case reporting. To the ONC Health IT Certification Program
ing) accommodate this evolution, we have related to electronic case reporting in
not adopted the proposed IHE profile as that as technical approaches evolve to
We proposed to adopt a new 2015 part of this certification criterion or accomplish electronic case reporting
Edition ‘‘transmission to public health another exchange standard. We they can be certified. In the future, we
agencies—case reporting’’ certification understand that there are certain may be able to consider a specific
criterion, which would support the functional requirements that a Health IT standard for certification through
electronic transmission of case reporting Module would need to support to rulemaking.
information to public health agencies. enable electronic case reporting. We note that we have inserted
We proposed to require a Health IT Specifically, a Health IT Module would ‘‘electronic’’ in the criterion name to
Module to be able to electronically need to support the ability to emphasize the evolution of case
create case reporting information for electronically: (1) Consume and reporting and the importance of
electronic transmission in accordance maintain a table of trigger codes to electronic case reporting.
with the IHE Quality, Research, and determine which encounters should Comments. Many commenters
Public Health Technical Framework initiate an initial case report being sent expressed concern around the burden of
Supplement, Structured Data Capture, to public health; (2) when a trigger is connecting to multiple jurisdictions.
Trial Implementation (September 5, matched, create and send an initial case One commenter noted a typical practice
2014) standard. We noted that a Health report to public health; (3) receive and may be required to report in three
IT Module would need to demonstrate display additional information, such as different states using entirely different
that it can create and send a constrained a ‘‘notice of reportability’’ and data technologies, standards, and processes.
transition of care document to a public fields to be completed; and (4) submit The commenter recommended that the
health agency, accept a URL in return, a completed form. public health community develop a
be able to direct end users to the URL, Public health agencies have, however, single reporting hub where all reports
and adhere to the security requirements prioritized receiving the initial are submitted using the same
for the transmission of this information. electronic case report form, while technologies, standards, and processes.
In addition, we requested comment building the infrastructure to request A couple of commenter suggested the
on whether we should consider supplemental data over time. Given the use of a centralized platform or
adopting the HL7 FHIR Implementation priority to receive the initial case report intermediary, which could streamline
Guide: SDC DSTU that would be form, we have adopted the following connectivity and reduce jurisdictional
balloted in mid-2015 in place of, or functionality that supports the first two variability.
together with, the IHE Quality, identified steps above. To meet this Response. We agree with commenters
Research, and Public Health Technical certification criterion, a Health IT that a common public health interface
Framework Supplement. Module must be able to (1) consume and or intermediary would reduce the
Comments. Commenters expressed maintain a table of trigger codes to burden on health IT developers and
agreement on the importance of case determine which encounters should state and local public health agencies.
reporting for public health. Some initiate an initial case report being sent The CDC and the public health
commenters expressed no concerns with to public health to determine community have made an investment in
the IHE profile, while others were reportability; and (2) when a trigger is a centralized approach for receipt of
unsure whether public health agencies matched, create an initial case report electronic case reports. The CDC will
had been sufficiently involved in the that includes specific data (Common identify a test harness and tool for all
creation of the IG to warrant adoption in Clinical Data Set; encounter diagnoses; the functional requirements described
above. Additionally, as the CDC and We proposed to test and certify a have adopted this criterion as proposed
public health approach matures to Health IT Module for conformance with (with both Volumes 1 and 2 of the HAI
include other interfaces, the CDC will the following sections of the IG in IG). We intend to work with federal
continue to monitor the development of § 170.205(r)(1): HAI Antimicrobial Use partners, such as the CDC, to eliminate
standards to support these functional and Resistance (AUR) Antimicrobial or reduce any negative impacts on
requirements. As noted above, this may Resistance Option (ARO) Report health IT developers resulting from the
lead to future rulemaking for the (Numerator) specific document template frequency of reporting changes or the
certification of electronic case reporting. in Section 2.1.2.1 (pages 69–72); manner in which changes are
Comments. Many commenters Antimicrobial Resistance Option (ARO) implemented in the associated program.
identified a difference in the description Summary Report (Denominator) specific We note that certification to the adopted
of case reporting between the Proposed document template in Section 2.1.1.1 version of the standard is what is
Rule and the EHR Incentive Programs (pages 54–56); and Antimicrobial Use necessary to meet the CEHRT definition
Stage 3 proposed rule. In particular, a (AUP) Summary Report (Numerator and under the EHR Incentive Programs. In
commenter compared the examples Denominator) specific document regard to the concern about state
given for the Structured Data Capture template in Section 2.1.1.2 (pages 56– variations, this data will only be
standard proposed for case reporting in 58). We explained that we would expect collected by the CDC at the national
the Proposed Rule with the description a Health IT Module presented for level. The CDC is the only public health
of case reporting provided in the EHR certification to this criterion to conform agency that needs to be able to receive
Incentive Programs Stage 3 proposed to all named constraints within the these surveys electronically, which it is
rule, which focused on submitting specified document template. capable of doing. The use of a national
information about reportable conditions Comments. Most commenters interface for receipt avoids the problems
to monitor disease outbreaks. expressed support for the adoption the associated with jurisdictional variation.
proposed certification criterion and the For concerns and questions related to
Response. The examples in the included standard. A commenter stated
Proposed Rule of birth reports and other the EHR Incentive Programs, we refer
that data on antimicrobial use and readers to CMS and the EHR Incentive
public health reporting were not antimicrobial resistance are essential
examples of electronic case reporting. Programs Stage 3 and Modifications
components of antimicrobial final rule published elsewhere in this
The examples were meant to illustrate stewardship programs throughout the
how other public health domains have issue of the Federal Register.
nation and is a highlight of the National • Transmission To Public Health
accomplished public health reporting Action Plan for Combating Antibiotic Agencies—Health Care Surveys
through the use of the IHE RFD profile, Resistant Bacteria. Another commenter
upon which the IHE SDC profile stated that the data elements for 2015 Edition Health IT Certification Cri-
proposed for adoption is based. antimicrobial use and resistance terion
• Transmission To Public Health reporting are positive steps to help § 170.315(f)(7) (Transmission to public
Agencies—Antimicrobial Use And guide public health activities. health agencies—health care surveys)
Resistance Reporting Commenters also stated that the
proposed criterion and standard would We proposed to adopt a new 2015
2015 Edition Health IT Certification Cri- bolster the CDC’s National Healthcare Edition certification criterion for
terion Safety Network (NHSN) effort to transmission of health care surveys to
§ 170.315(f)(6) (Transmission to public develop coherent policies to fight public health agencies that would
health agencies—antimicrobial use and antibiotic resistance through the require a Health IT Module to be able
resistance reporting) to create health care survey information
reporting of standardized data about
antibiotic use and resistance. for electronic transmission in
We proposed to adopt a new 2015 A commenter expressed concern accordance with the HL7
Edition certification criterion that about the pace and volume of changes Implementation Guide for CDA®
would require a Health IT Module to be between versions of the standard, the Release 2: National Health Care Surveys
able to electronically create burden on health IT developers related (NHCS), Release 1—US Realm, Draft
antimicrobial use and resistance to the timing of deployments, and that Standard for Trial Use (December
reporting information for electronic NHSN does not accept data submitted 2014). 114 We explained that the
transmission in accordance with using prior versions. Another National Ambulatory Medical Care
specific sections of the HL7 commenter expressed concern about Survey (NAMCS) is a national survey
Implementation Guide for CDA® state variations that are not addressed designed to meet the need for objective,
Release 2—Level 3: Healthcare by this criterion, suggesting that the reliable information about the provision
Associated Infection Reports, Release 1, criterion and standard not be adopted and use of ambulatory medical care
U.S. Realm (August 2013) (‘‘HAI IG’’). until at least 75% of public health services in the U.S. We also explained
We explained that collection and agencies are committed to adopting this that the National Hospital Ambulatory
analysis of data on antimicrobial use standard. Medical Care Survey (NHAMCS) is
and antimicrobial resistance are A commenter stated that there were designed to collect data on the
important components of antimicrobial inconsistences in the EHR Incentive utilization and provision of ambulatory
stewardship programs throughout the Programs Stage 3 proposed rule related care services in hospital emergency and
nation and electronic submission of to this criterion regarding the standards outpatient departments. We clarified
antimicrobial use and antimicrobial available as well as a reference to that the proposed IG is intended for the
resistance data to a public health meeting the measure four times. transmission of survey data for both the
registry can promote timely, accurate, Another commenter suggested that the NAMCS (e.g., for ambulatory medical
and complete reporting, particularly if associated proposed measure under care settings) and NHAMCS (e.g., for
data is extracted from health IT systems Stage 3 should be limited to eligible hospital ambulatory settings including
and delivered using well established hospitals and CAHs (not EPs).
data exchange standards to a public Response. We appreciate the overall 114 http://www.hl7.org/implement/standards/
health registry. support for this criterion and the IG. We product_brief.cfm?product_id=385 .
emergency departments and outpatient only public health agency that needs to with applicable objectives and measures
departments). We noted that templates be able to receive these surveys under the EHR Incentive Programs.
included in the IG align with the C– electronically, which it is capable of We have changed the term
CDA standard. Additionally, we noted doing. The use of a national interface for ‘‘meaningful use’’ to ‘‘EHR Incentive
that the templates in the IG expand on receipt avoids the problems associated Programs’’ and removed ‘‘objective with
the scope of the original NAMCS and with jurisdictional variation. a’’ in the first sentence of the criterion
NHAMCS survey data elements. The • Automated Numerator Recording to more clearly align with the
templates do not constrain the data terminology and framework used under
collected to the narrow lists on the 2015 Edition Health IT Certification Cri- the EHR Incentive Programs.
survey instruments; rather they allow terion • Automated Measure Calculation
any service, procedure or diagnosis that § 170.315(g)(1) (Automated numerator re-
has been recorded. cording)
Commenters. Commenters terion
overwhelmingly supported the We proposed to adopt a 2015 Edition § 170.315(g)(2) (Automated measure cal-
certification criterion and the use of the ‘‘automated numerator recording’’ culation)
NHCS IG. Commenters expressed certification criterion that was
support for the continued effort to unchanged in comparison to the 2014 We proposed to adopt a 2015 Edition
advance use of health care surveys as a Edition ‘‘automated numerator ‘‘automated measure calculation’’
means of improving patient outcomes. recording’’ criterion. We noted that the certification criterion that was
Commenters also expressed support for test procedure for this criterion would unchanged in comparison to the 2014
the specified data elements in the IG. be different from the 2014 Edition Edition ‘‘automated measure
One commenter, however, questioned ‘‘automated numerator recording’’ calculation’’ criterion. We proposed to
the maturity of the standard and its certification criterion in order to remain apply the guidance provided for the
adoption for certification at this time. consistent with the applicable objectives 2014 Edition ‘‘automated measure
Commenters requested clarification (and and measures required under the EHR calculation’’ certification criterion in the
confirmation) on the surveys that must Incentive Programs. 2014 Edition final rule that a Health IT
be supported for the purposes of Comments. We received mixed Module must be able to support all
certification. In particular, a commenter comments in response to the proposal. CMS-acceptable approaches for
noted that it was not unclear whether A number of commenters supported this measuring a numerator and
the NAMCS and NHAMCS are the only criterion as proposed. A few denominator in order for the Health IT
surveys covered for certification. commenters stated that this criterion
A commenter requested information Module to meet the proposed 2015
has been burdensome and complicated Edition ‘‘automated measure
on the number of public health agencies
as its implementation has led to calculation’’ certification criterion.115
that can electronically accept data in
interruptions in provider workflows We also proposed that the interpretation
accordance with the IG.
Response. We appreciate the overall solely for the purposes of reporting on of the 2014 Edition ‘‘automated measure
support for this criterion and the IG. We measures under the EHR Incentive calculation’’ certification criterion in
have adopted this criterion as proposed. Programs. These commenters further FAQ 32 116 would apply to the 2015
While we understand the concerns that contended that such data collection was Edition ‘‘automated measure
this standard may not be fully mature, unrelated to improving patient care. A calculation’’ certification criterion. We
the IG has gone through the HL7 commenter suggested that we ensure also noted that the test procedure for
balloting process and is currently a Draft that the terminology used in the test this criterion would be different from
Standard for Trial Use, which is no procedures aligns with that used for the the 2014 Edition ‘‘automated measure
different than other standards in use measures under the EHR Incentive calculation’’ certification criterion in
today and adopted as part of the 2015 Programs. Another commenter order to remain consistent with the
Edition. Further, the CDC has been suggested that this criterion should be applicable objectives and measures
working with providers to submit this gap certification eligible if the required under the EHR Incentive
data electronically using these surveys associated EHR Incentive Programs Programs.
prior to this rulemaking. As such, we measure has not changed from Stage 2. Comments. We received mixed
believe that the IG is mature enough for Response. We have adopted this comments in response to our proposal.
widespread adoption. criterion as proposed. This criterion is One commenter noted that this criterion
We clarify that, as proposed, included in the CEHRT definition under and included functionality has value for
certification would cover the entire the EHR Incentive Programs. This helping providers understand their
NHCS IG. The NHCS IG consists of the certification criterion could ease the quality outcomes and performance on
National Hospital Care Survey, burden of reporting particularly for certain EHR Incentive Programs
NHAMCS, and NAMCS. In the Proposed small providers and hospitals (77 FR measures. A few commenters stated that
Rule, we focused on clarifying that the 54184). We will work to ensure this criterion has been burdensome and
NHAMCS and NAMCS were included consistency with the test procedure and complicated as its implementation has
in the IG and the changes in the surveys the measures under the EHR Incentive led to interruptions in provider
as compared to past versions. However, Programs. As stated in the 2015 Edition workflows solely for the purposes of
all three surveys are covered by the proposed rule (FR 80 16868), this reporting on measures under the EHR
NHCS IG and will be covered as part of certification criterion’s gap certification Incentive Programs. These commenters
testing and certification. eligibility is ‘‘fact-specific’’ and depends further contended that such data
All public health agencies may not be on any modifications made to the collection was unrelated to improving
able to receive this data electronically specific certification criteria to which patient care.
and that variability across jurisdictions this criterion applies. As mentioned
could be problematic. However, this above and in the Proposed Rule, it 115 77 FR 54244–54245.
data will only be collected by the CDC would also depend on changes to the 116 http://www.healthit.gov/policy-researchers-
at the national level. The CDC is the test procedure that are made to align implementers/32-question-11-12-032.
Commenters were generally proposed to include seventeen (17) • Section 170.315(a)(3) Computerized
supportive of applying the guidance certification criteria (seven new) in the provider order entry—diagnostic
provided in the 2014 Edition final rule 2015 Edition SED certification criterion imaging
(77 FR 54244–54245) and the guidance (80 FR 16857), and for each of the • Section 170.315(a)(4) Drug-drug, drug-
in FAQ 32 to the 2015 Edition criterion. referenced certification criteria and their allergy interaction checks
One commenter suggested that this corresponding capabilities presented for • Section 170.315(a)(5) Demographics
criterion should be gap certification certification, we proposed to require • Section 170.315(a)(6) Problem list
eligible if the associated EHR Incentive that user-centered design (UCD) • Section 170.315(a)(7) Medication list
Programs measure has not changed from processes must have been applied in • Section 170.315(a)(8) Medication
Stage 2. This commenter recommended order satisfy this certification criterion. allergy list
that ONC provide revised draft test We stated we intend to continue • Section 170.315(a)(9) Clinical
procedures for this criterion for public submission of summative usability test decision support
• Section 170.315(a)(14) Implantable
comment prior to the release of the final results to promote transparency and
device list
rule. foster health IT developer competition, • Section 170.315(b)(2) Clinical
Response. We have adopted this spur innovation, and enhance patient information reconciliation and
criterion as proposed. This criterion is safety. With this in mind, we sought incorporation
included in the CEHRT definition under comment on whether there are other • Section 170.315(b)(3) Electronic
the EHR Incentive Programs. This certification criteria that we omitted prescribing
certification criterion could improve the from the proposed SED criterion that
accuracy of measure calculations to commenters believe should be included. We believe the inclusion of criteria
reduce reporting burdens for EPs, such as ‘‘demographics,’’ ‘‘implantable
Comments. Comments generally device list,’’ ‘‘drug-drug, drug-allergy
eligible hospitals, and CAHs (77 FR supported the proposed SED criterion,
54244). We will apply the guidance in interaction checks for CPOE,’’ and
but questioned the number of ‘‘CDS’’ are appropriate because data
the 2014 Edition final rule and FAQ 32 certification criteria included. Some
to this criterion. entry errors and poor user interfaces for
commenters questioned rationale for responding to alerts and interventions
As stated in the 2015 Edition adding the new criteria and the
proposed rule (FR 80 16868), this can compromise patient safety. While
carryover inclusion of the ‘‘drug-drug, we do not have empirical data related to
certification criterion’s gap certification drug-allergy interaction checks for
eligibility is ‘‘fact-specific’’ and depends the ‘‘effectiveness’’ of the SED criterion,
CPOE’’ criterion, while other we believe that our approach
on any modifications made to the commenters generally questioned
specific certification criteria to which contributes to improving usability and
whether this criterion has contributed to patient safety through both the
this criterion applies. As mentioned improving usability or patient safety. A
above and in the Proposed Rule, it application of the SED criterion’s
few commenters suggested that this requirements to a significant number of
would also depend on changes to the criterion only apply to criteria that
test procedure that are made to align health technologies being used in the
involve tasks performed by clinical market today and in the future as well
with applicable objectives and measures users. A couple of commenters
under the EHR Incentive Programs. We as through the SED information being
expressed concern about the additional available on the CHPL for stakeholder
note that draft test procedures for the burden the new criteria presented.
2015 Edition were released with the review and evaluation.
publication of the Proposed Rule 117 and Response. We thank commenters for
their feedback. We have adopted the NISTIR 7742 Submission
were open for public comment from Requirements, New Requirements and
March 20, 2015, to June 30, 2015. proposed SED with revisions and
clarifications. We note that 5 criteria Compliance Guidance
Revised draft final test procedures will
be made available after publication of proposed for inclusion in the SED We proposed to include the specific
this final rule for public review and criterion have not been adopted as part information from the NISTIR 7742
comment. of the 2015 Edition. These criteria are: ‘‘Customized Common Industry Format
We have changed the first use of the ‘‘vital signs,’’ ‘‘eMAR,’’ ‘‘incorporate Template for Electronic Health Record
term ‘‘meaningful use’’ to ‘‘EHR laboratory tests/results,’’ and both Usability Testing’’ (NIST 7742) 118 in the
Incentive Programs’’ and removed its ‘‘decision support’’ criteria. regulation text of the 2015 Edition SED
second use in the criterion. We have Consequently, these criteria cannot be criterion to provide more clarity and
also removed the phrase ‘‘objective with included in the SED criterion and, specificity on the information requested
a.’’ We have made these revisions to therefore, there is only a net increase of in order to demonstrate compliance
more clearly align with the terminology two criteria subject to the SED criterion. with this certification criterion. We
and framework used under the EHR We do not believe this will create a reiterated that the information must be
Incentive Programs. significant burden for health IT submitted for each and every one of the
• Safety-Enhanced Design developers and note that many criteria specified in the 2015 Edition
developers have had their products SED criterion to become part of the test
2015 Edition Health IT Certification Cri- certified to the 2014 Edition versions of results publicly available on the
terion the criteria included in the 2015 SED Certified Health IT Product List (CHPL).
§ 170.315(g)(3) (Safety-enhanced design) criterion and the 2014 Edition SED We specified that all of the data
criterion. The criteria included in the elements and sections must be
We proposed to adopt a 2015 Edition
2015 Edition SED criterion are as completed, including ‘‘major findings’’

‘‘safety-enhanced design’’ (SED) follows (emphasis added for the new and ‘‘areas for improvement.’’
certification criterion that was revised criteria): We identified the table on page 11 of
in comparison to the 2014 Edition NISTIR 7742 for the submission of
• Section 170.315(a)(1) Computerized
‘‘safety-enhanced design’’ criterion. We demographic characteristics of the test
provider order entry—medications
117 http://healthit.gov/policy-researchers- • Section 170.315(a)(2) Computerized 118 http://www.nist.gov/manuscript-publication-
implementers/2015-edition-draft-test-procedures. provider order entry—laboratory search.cfm?pub_id=907312.
participants because it is important that measures and consider post-session contingent of commenters advocated for
the test participant characteristics satisfaction measures. Commenters 10 participants. A few commenters
reflect the audience of current and suggested that we use industry standard, suggested that the number of test
future users. In accordance with NISTIR literature-recognized satisfaction participants should remain as guidance.
7804 (page 8),119 we recommended that measures such as the Single Ease-of-use A few commenters also stated that a
the test scenarios be based upon an Question, System Usability Scale, or high participant threshold could be
analysis of critical use risks for patient Software Usability Measurement burdensome to small developers.
safety, which can be mitigated or Inventory. Commenters generally recommended
eliminated by improvements to the user Response. We thank commenters for that cohorts should be consistent with
interface design. their feedback. We have finalized our the capability under testing. Some
We strongly advised health IT proposed requirements with one commenters stated, for example, that
developers to select an industry revision. In response to comments, we clinicians would not be appropriate for
standard process because compliance now also permit the submission of an a more administrative capability such as
with this certification criterion requires alternative acceptable user satisfaction recording demographics. Commenters
submission of the name, description, measure to meet the requirements of gave mixed responses on whether this
and citation (URL and/or publication this criterion. Stated another way, a described approach should be required
citation) of the process that was health IT developer could meet the or simply guidance.
selected, and we provided examples of proposed NIST 7742 based approach for Response. As a general matter, the
method(s) that could be employed for user satisfaction or provide more users tested, the more likely
UCD, including ISO 9241–11, ISO documentation of an alternative developers will be able to identify and
13407, ISO 16982, ISO/IEC 62366, ISO acceptable user satisfaction measure. remedy design flaws. To this point,
9241–210 and NISTIR 7741. We We will take into consideration the research suggests that ‘‘with ten
explained that, in the event that a health other user satisfaction measures participants, 80 percent of the problems
IT developer selects a UCD process that identified by commenters in the are found whereas 95 percent of the
was not an industry standard (i.e., not development and finalization of the problems are found with twenty
developed by a voluntary consensus 2015 SED test procedures and related participants.’’ 121 For the purposes of
standards organization), but is based on guidance for complying with this this final rule, we have adopted a
one or more industry standard criterion and particularly the user provision as part of this criterion that
processes, the developer may name the satisfaction measure. requires 10 participants per criterion/
process(es) and provide an outline of capability as a mandatory minimum for
the process in addition to a short Number of Test Participants the purposes of testing and certification.
description as well as an explanation of We recommended following NISTIR We believe this minimum is responsive
the reason(s) why use of any of the 7804 120 ‘‘Technical Evaluation, Testing, to commenters and will ensure more
existing UCD standards was impractical. and Validation of the Usability of reliable summative testing results. We
We also noted that health IT developers Electronic Health Records’’ for human also believe this number will balance
can perform many iterations of the factors validation testing of the final any potential burden for health IT
usability testing, but the submission that product to be certified, and developers, including small developers.
is ultimately provided for summative recommended a minimum of 15 However, we strongly encourage health
usability testing and certification must representative test participants for each IT developers to exceed the mandatory
be an expression of a final iteration, and category of anticipated clinical end minimum in an effort to identify and
the test scenarios used would need to be users who conduct critical tasks where resolve more problems.
submitted as part of the test results. We the user interface design could impact We agree with commenters that
noted that we do not expect developers patient safety (e.g., physicians, nurse cohorts should not be limited to
to include trade secrets or proprietary practitioners, physician assistants, clinicians but instead consist of test
information in the test results. nurses, etc.) and who are not include participants with the occupation and
Comments. Commenters expressed employees of the developer company. experience that aligns with the
appreciation for the clarity the proposed We additionally requested comment on capability under testing. We believe,
2015 Edition SED criterion provided in whether we should establish a however, that it would be too restrictive
terms of requirements. Some minimum number(s) and user cohort(s) and complicated to establish cohort
commenters agreed with including for test participants for the purposes of requirements per criterion. Instead, we
major findings and areas for testing and certification to the 2015 continue to recommend that health IT
improvement sections in the summative Edition under the ONC Health IT developers follow NISTIR 7804 for
testing documentation, while other Certification Program. human factors validation testing of the
commenters did not support the public Comments. We received a large final product to be certified. We will
reporting of major findings and areas for number of comments in response to this also work with NIST to provide further
improvement because they argued that request for comment with the majority guidance as needed.
the information is usually meant to of commenters advocating for a required Request for Comment on Summative
inform the developer. minimum number of test participants and Formative Testing
Many commenters expressed concern and some commenters advocating for
on the proposed limitation for established user cohorts per capability. We requested comment regarding
measuring user satisfaction. Commenters strongly stated that options that we might consider in
addition to—or as alternatives to—
Commenters mentioned that user establishing a minimum number of

satisfaction ratings are often now based participants would allow for proper summative testing. We asked whether a
on non-standard surveying processes. validation of testing results. Many standardized report of formative testing
Commenters suggested that we not commenters advocated for a minimum 121 Pg. 42. NISTIR 7804 Technical Evaluation,
solely rely on task-based satisfaction of 12 or 15 participants. Another large Testing, and Validation of the Usability of
Electronic Health Records http://www.nist.gov/
119 http://www.nist.gov/customcf/get_ 120 http://www.nist.gov/customcf/get_ healthcare/usability/upload/EUP_WERB_Version_
pdf.cfm?pub_id=909701. pdf.cfm?pub_id=909701. 2_23_12-Final-2.pdf
could be submitted for one or more of and we included these types of changes federal government and SDOs (80 FR
the 17 proposed certification criteria for in our proposal to address adaptations 16858).
which summative testing would be and updates under the ONC–ACB Comments. The majority of
required, if formative testing reflected a Principles of Proper Conduct commenters supported the proposed
thorough process that has tested and (§ 170.523). criterion and its approach, with broad
improved the usability of a product. We discuss the comments received on support across health IT developers,
Additionally, we asked for feedback on this proposal and our response under providers, and consumers. A commenter
the requirements for such a formative section IV.D.6 of this preamble. questioned whether we provided the
testing report and on how purchasers • Quality Management System appropriate example standards, citing
would evaluate these reports. ISO 14971 as a risk-management
Comments. Commenters 2015 Edition Health IT Certification Cri- standard for medical devices and not a
acknowledged the benefits of formative terion QMS standard. Other commenters stated
testing, with some noting that it can act § 170.315(g)(4) (Quality management sys- that the identified standards were too
as a risk management process before tem) focused on medical devices. A few
getting to summative testing. The commenters indicated that other
We proposed to adopt a 2015 Edition
majority of the commenters, however, standards and processes should be
‘‘quality management system’’
were against formative testing as an considered as acceptable means for
certification criterion that was revised
alternative to summative testing. One meeting this criterion. These
in comparison to the 2014 Edition and
commenter stated that one of the main commenters specifically mentioned ISO
proposed that all Health IT Modules
objectives for the SED criterion is to 12207, IEEE 730, IEEE 1012, ISO 14764,
certified to the 2015 Edition would need
allow purchasers and consumers to ISO 80001, the health IT QMS standards
to be certified to the 2015 Edition QMS
compare competing products on the under development through the
criterion ‘‘quality management system’’
quality of human interaction and Association for the Advancement of
criterion. We proposed to require the
usability. The commenter contended Medical Instrumentation (AAMI), and
identification of the Quality
that test results are therefore publicly the accreditation process software
Management System (QMS) used in the
available for this purpose on the quality systems run by the Capability
development, testing, implementation,
Certified Health IT Product List (CHPL). Maturity Model Integration Institute
and maintenance of capabilities
The commenter maintained that this (CMMI). A few commenters expressed
certified under the ONC Health IT
essential function cannot be fulfilled, concern that it would be burdensome to
Certification Program. We specified that
however, with the results of formative map an internal QMS to one or more
the identified QMS must be compliant
testing as they cannot be compared QMS established by the federal
with a quality management system
across products but only between the government or SDO, including more
established by the federal government or burdensome on small health IT
iterations of a single product. The
commenter noted, as other commenters a standards developing organization; or developers.
did, that formative tests are intended to mapped to one or more quality A few commenters requested
identify problems rather than produce management systems established by the clarifications. A commenter noted that
measures. A few commenters suggested federal government or standards health IT developers use agile software
that we require both summative and developing organization(s). We stated development practices and requested
formative testing, while a few other that we will not permit health IT to be clarification if these processes would be
commenters suggested formative testing certified that has not been subject to a sufficient for certification. A commenter
was not reliable or useful. QMS and that we will require health IT asked how this criterion would apply to
Response. We thank commenters for developers to either use a recognized a self-developer or open source
their insightful feedback. We agree with QMS or illustrate how the QMS they software. A couple of commenters asked
the commenters that see value in used maps to one or more QMS how Health IT Modules would be
formative testing, but we also agree with established by the federal government or evaluated against this criterion,
the commenters that contend it should a standards developing organization(s) including what type of documentation
not be a substitute for summative testing (SDOs). We explained that we would be required for mapping and
for the purposes of this criterion. With encourage health IT developers to whether a documented combined QMS
this in mind and consideration of the choose an established QMS, however, approach for the entire Health IT
potential burden imposed by requiring developers may also use either a Module would be sufficient in lieu of a
both summative and formative testing, modified version of an established capability by capability identification.
we have decided to retain summative QMS, or an entirely ‘‘home grown’’ Response. We thank commenters for
testing requirements and not adopt QMS. In cases where a health IT their feedback and support. We have
formative testing requirements. developer does not use a QMS adopted this criterion as proposed with
established by the federal government or further clarification in response to
Retesting and Certification an SDO, we proposed to require the comments. We note that this criterion
We stated that we believe that ONC– health IT developers illustrate how their applies to any health IT presented for
ACB determinations related to the QMS maps to one or more QMS certification to the 2015 Edition,
ongoing applicability of the SED established by the federal government or including self-developed and open
certification criterion to certified health SDO through documentation and source software that is part of the Health
IT for the purposes of inherited certified explanation that links the components IT Module because one of the goals of
status (§ 170.550(h)), adaptations and of their QMS to an established QMS and this criterion is to improve patient
other updates would be based on the identifies any gaps in their QMS as safety through QMS.
extent of changes to user-interface compared to an established QMS. We We expect that ONC–ACBs will
aspects of one or more capabilities to added that documentation of the current certify health IT to this criterion in the
which UCD had previously been status of QMS in a health IT same manner as they certify health IT to
applied. We specified that ONC–ACBs development organization would be the 2014 Edition QMS criterion, but
should be notified when applicable sufficient. We also provided a list of accounting for any differences that are
changes to user-interface aspects occur, QMS standards established by the finalized through the 2015 Edition ACD
test procedure. To this point, we have testing, implementation, and Response. We thank commenters for
removed the term ‘‘compliant’’ from the maintenance of that capability must be their feedback. We have adopted this
provision requiring identification of a identified. Further, we proposed to criterion as proposed. We will work
QMS compliant with a quality permit that a health IT developer could with our federal partners (e.g., NIST,
management system established by the document that no health IT Administration for Community Living
federal government or a standards accessibility-centered design standard and Aging Policy, and the HHS Office
developing organization. Similar to the or law was applied to the health IT’s for Civil Rights) and consider comments
mapping provision, the focus and intent applicable capabilities as an acceptable on the final test procedure for this
of the provision (and the criterion as a means of satisfying this proposed criterion in providing more precise
whole) is the identification of the QMS, certification criterion. We added that identification and guidance on
not a determination of compliance by the method(s) used to meet this accessibility-centered standards and
the ONC–ACB. We note that the proposed criterion would be reported laws. We believe this criterion poses
identification of a single QMS is through the open data CHPL. We minimal burden on health IT developers
permitted for a Health IT Module, solicited comment on whether the as it only requires health IT developers
which is consistent with testing and standards and laws identified in the to identify relevant standards or laws;
certification to the 2014 Edition QMS Proposed Rule were appropriate and, alternatively, permits a health IT
certification criterion. examples and whether we should limit developer to state that its health IT
As noted in the 2014 Edition final the certification criteria to which this product presented for certification does
rule (77 FR 54191), we agree that criterion would apply. not meet any accessibility-centered
existing standards may not explicitly We explained that the proposed design standards or any accessibility
state support for agile development certification criterion would serve to laws. That said, as noted above, we
methodologies and that such methods increase transparency around the remind health IT developers and
may be part of an optimal QMS. As application of user-centered design providers that the existence of an option
such, documented agile development standards for accessibility to health IT to certify that health IT products do not
methodologies may be used in meeting and the compliance of health IT with meet any accessibility design standards
the mapping provision of this criterion. accessibility laws. We stated that this or comply with any accessibility laws
We will issue further compliance transparency would benefit health care does not exempt them from their
guidance as necessary, including providers, consumers, governments, and independent obligations under
through the 2015 Edition QMS test other stakeholders, and would applicable federal civil rights laws,
procedure. This guidance will include encourage health IT developers to including Section 504 of the
updated identification of QMS pursue the application of more Rehabilitation Act, Section 1557 of the
standards and more specification of accessibility standards and laws in Affordable Care Act, and the Americans
documentation requirements necessary product development that could lead to with Disabilities Act that require
to meet this criterion. Overall, we do not improved usability for health care covered entities to provide individuals
believe this criterion presents a providers with disabilities and health with disabilities equal access to
significant burden as many health IT care outcomes for patients with information and appropriate auxiliary
products have been previously certified disabilities. aids and services as provided in the
to the 2014 Edition QMS criterion and We also proposed to revise § 170.550 applicable statutes and regulations.
most, if not all, developers (with to require ONC–ACBs follow this We expect that ONC–ACBs will
previously certified products or not) proposed approach and referred readers certify health IT to this criterion in the
should have QMS documentation to section IV.C.2 of the Proposed Rule’s same manner as they certify health IT to
readily available for their health IT preamble for this proposal. the 2014 Edition QMS criterion, but
products as a standard practice. Comments. The vast majority of accounting for any differences that are
• Accessibility-Centered Design commenters supported the proposed finalized through the 2015 Edition ACD
criterion and its approach, with broad test procedure. We will issue further
2015 Edition Health IT Certification Cri- support across health IT developers, compliance guidance as necessary.
terion providers, and consumers. One • Consolidated CDA Creation
§ 170.315(g)(5) (Accessibility-centered de- commenter suggested that we narrow Performance
sign) the list of example standards to those
that have the widest applicability to 2015 Edition Health IT Certification Cri-
We proposed to adopt a new 2015 EHRs. Another commenter suggested terion
Edition ‘‘accessibility-centered design’’ that the focus should be on more § 170.315(g)(6) (Consolidated CDA creation
certification criterion that would apply accessibility-centered standards such as performance)
to all Health IT Modules certified to the ISO 9241–20 (2008) ‘‘Ergonomics of
2015 Edition and require the Human-System Interaction—Part 20: We proposed to adopt a new
identification of user-centered design Accessibility guidelines for information/ certification criterion at § 170.315(g)(6)
standard(s) or laws for accessibility that communication technology (ICT) that would rigorously assess a product’s
were applied, or complied with, in the equipment and services,’’ ISO 9241–171 C–CDA creation performance (for both
development of specific capabilities (2008) ‘‘Ergonomics of Human-System C–CDA Release 1.1 and 2.0) when it is
included in a Health IT Module or, Interaction—Part 171: Guidance on presented for a Health IT Module
alternatively, the lack of such software accessibility,’’ Section 508 of certification that includes within its
application or compliance. the Rehabilitation Act, and Section 504 scope any of the proposed certification
We proposed to require that for each of the Rehabilitation Act. A few criteria that require C–CDA creation
capability that a Health IT Module commenters suggested that this criterion (e.g., ‘‘transitions of care’’ at
includes and for which that capability’s would have a significant development § 170.315(b)(1)). We explained that to
certification is sought, the use of a burden for health IT developers. One implement this proposal, we would
health IT accessibility-centered design commenter requested clarification on amend § 170.550 to add a requirement
standard or compliance with a health IT how testing and certification will be that ONC–ACBs shall not issue a Health
accessibility law in the development, conducted. IT Module certification to a product that
includes C–CDA creation capabilities document template conformance, and with C–CDA creation required, C–CDA
within its scope, unless the product was vocabulary conformance. creation performance only has to be
also tested and satisfied the certification Comments. Similar to comments demonstrated once for each C–CDA
criteria requirements proposed at received to other certification criteria document template (e.g., C–CDA
§ 170.315(g)(6). If the scope of such as ‘‘transitions of care,’’ creation performance to the CCD
certification included multiple commenters did not support the template would not have to
certification criteria that require C–CDA proposal to be able to create C–CDA demonstrated twice if the Health IT
creation, we noted that § 170.315(g)(6) documents in accordance with both C– Module presents for certification to both
need only be tested in association with CDA Releases 1.1 and 2.0. ‘‘ToC’’ and the ‘‘data export’’ criteria).
one of those certification criteria and Response. We have adopted C–CDA Comments. One commenter was
would not be expected or required to be Release 2.1 for this certification concerned that the proposed regulation
tested for each. Specifically, we criterion for the same reasons as noted text language ‘‘upon the entry of clinical
proposed that three technical outcomes in the preamble for the ‘‘transitions of data consistent with the Common
be met: reference C–CDA match, care’’ criterion. Clinical Data Set’’ implies the incorrect
document template conformance, and workflow, and would only allow
C–CDA Document Templates creation to be done while the user
vocabulary conformance.
We noted that we coordinated with We proposed that Health IT Modules finishes creating or composing the C–
our colleagues at NIST and understand would have to demonstrate compliance CDA document. The commenter noted
that NVLAP-Accredited Testing with the C–CDA creation performance that there is an additional step between
Laboratories would retain the C–CDA functions of this criterion for the creation and sending where additional
files created under test and contribute following C–CDA Release 2.0 document vocabulary mapping steps need to be
them to an ONC-maintained repository. templates: applied.
Comments. A number of commenters • Continuity of Care; Response. We thank the commenter
• Consultation Note; for the input. We clarify that the
expressed support for the proposal for
• History and Physical; purpose of the phrase was to provide a
this certification criterion that would • Progress Note; clear scope to the certification criterion
test a Health IT Module’s C–CDA • Care Plan; for health IT developers. Given that the
creation performance as proposed. Some • Transfer Summary; C–CDA includes many section
commenters suggested that the gold • Referral Note; and templates to represent data outside of
standard needs to be specific on what to • Discharge Summary (for inpatient the data specified by the Common
do with optionality permitted in the C– settings only). Clinical Data Set definition, we sought
CDA standard. A few commenters Comments. A few commenters to indicate that testing would be limited
requested clarifications on how the gold suggested that ONC not require to only the data within scope for the
standard would be structured, whether certification to all proposed document Common Clinical Data Set definition.
it would be one or multiple documents, templates and indicated that not all We have modified the language in the
and whether the testing would be done document templates are applicable to certification criterion to more clearly
through an automated tool or by visual every setting. They also cited potential reflect this scope limitation.
inspection. development burdens with the proposed
Response. We thank commenters for scope. C–CDA Completeness
their support and have adopted a C– Response. As discussed in the Due to past feedback from providers
CDA creation performance certification preamble for other certification criteria that indicated the variability associated
criterion with the following changes that include C–CDA creation within its with different functionalities and
described below. As discussed in the scope, we have limited the C–CDA workflows within certified health IT can
2014 Edition Release 2 proposed rule Release 2.1 document template ultimately affect the completeness of the
(79 FR 10899), we continue to believe in requirements based on the use case for data included in a created C–CDA, we
the value of this capability to promote each certification criterion. Therefore, requested comment on a proposal that
the ability of providers to exchange C– some criteria (e.g., ToC) require three C– would result in a certification
CDA documents and subsequently be CDA templates whereas others (e.g., care requirement to evaluate the
able to parse and use the C–CDA plan) only require one C–CDA template. completeness of the data included in a
received. This is especially important As such, we have required that C–CDA C–CDA. This additional requirement
for interoperability when the C–CDA creation performance be demonstrated would ensure that the data recorded by
standard allows for optionality and for the C–CDA Release 2.1 document a user in health IT is equivalent to the
variations. templates required by the 2015 Edition data included in a created C–CDA.
We intend to publish sample gold certification criteria presented for Comments. We received mixed
standard C–CDA documents on certification. For example, if a Health IT comments in response to this request for
www.healthit.gov or another ONC- Module only included § 170.315(e)(1) comment. One commenter was
maintained repository for the public to within its certificate’s scope, then only supportive of the proposal. Another
review and provide comment. We also the Continuity of Care Document (CCD) commenter requested clarification on
anticipate that there will be multiple document template would be applicable whether the request for comment
gold standard documents for each C– within this criterion. Conversely, if a intended to specify how the user
CDA document template we require for Health IT Module designed for the interface captures specific data using
this criterion with variations in each to inpatient setting included specific vocabulary, and was not
test optionality for which the C–CDA § 170.315(b)(1) within its certificate’s supportive of imposing data capture
standard allows. With respect to testing, scope, then all three document requirements for this criterion. One
we anticipate that testing will be templates referenced by that criterion commenter was concerned that ONC
performed, at a minimum, through a would need to evaluated as part of this was being too prescriptive by soliciting
conformance testing tool and could also certification criterion. comment on this potential requirement
include visual inspection as necessary If the scope of certification includes to test C–CDA completeness and
to verify reference C–CDA match, more than one certification criterion suggested ONC test this in a sub-
regulatory manner and/or through by individuals and caregivers accessing providers will need to have health IT
improved conformance test tools. One their health data, including the certified to both the VDT certification
commenter suggested that some C–CDA ‘‘multiple portal’’ problem, by criterion and these three ‘‘API’’ criteria
document templates do not include all potentially allowing individuals to to meet Stage 3 Objectives 5 and 6, we
information entered into an EHR for aggregate data from multiple sources in have removed the API functionality
certain use cases, as some document a web or mobile application of their embedded within the VDT certification
templates are meant to include targeted choice. We emphasized that the criterion and adopted these three
and specific information for a particular proposed approach was intended to criteria to simplify our rule and reduce
setting to which a patient is being provide flexibility to health IT redundancy.
transitioned. developers to implement an API that For the purposes of testing for each of
Response. We thank commenters for would be most appropriate for its the ‘‘API’’ certification criteria, a health
the input and, in consideration of the customers and allow developers to IT developer will need to demonstrate
comments, have adopted this proposal leverage existing standards that most the response (i.e., output) for each of the
as part of this certification criterion. As health IT developers would already data category requests and for the ‘‘all’’
we stated in the Proposed Rule, the need in order to seek certification for request, the output according to the C–
intent and focus of this proposal was to other criteria. CDA in the CCD document template.
ensure that however data is entered into Because many commenters provided For all other aspects of these
health IT—via whatever workflow and feedback on the ‘‘API’’ criterion within certification criteria, we expect the
functionality—that the C–CDA output the context of the ‘‘VDT’’ criterion and testing would include, but not be
would reflect the data input and not be in the order of this final rule the VDT limited to, attestation, documentation,
missing data a user otherwise recorded. discussion comes first, we address all functional demonstration, and visual
We also clarify that the scope of the data comments to proposed § 170.315(g)(7) inspection.
for this certification criterion is limited here. We appreciate suggestions as to a
to the Common Clinical Data Set Comments. The HITSC recommended ‘‘sub-regulatory approach’’ and will
definition. We did not intend imply and that we permit Health IT Modules to consider whether such approaches
note that that this criterion does not certify towards each of the three API could fit within our regulatory structure
prescribe how the user interface scenarios (get patient identifier, get as well as lead to consistent and
captures data. document, get discrete data) efficient testing and certification.
individually, while stating the Comments. Multiple commenters
Repository of C–CDA Documents expectation that Health IT developers voiced concern that we did not name a
and provider organizations should standard for API functionality in the
We did not receive any comments
ensure that the APIs work together Proposed Rule. Of these commenters,
regarding our understanding that
functionally. The HITSC also some suggested that we specifically
NVLAP-Accredited Testing Laboratories
recommended providing a ‘‘sub- name FHIR as the standard for this
would retain the C–CDA files created
regulatory flexibility’’ certification criterion, while others expressed
under test and contribute them to an
testing approach to allow developers to concern that FHIR is not yet mature
ONC-maintained repository. We note
achieve certification by participating in enough for inclusion in regulation, and
that we intend to implement this
‘‘a public-private effort that provides suggested that ONC eliminate or make
repository as noted in the Proposed
adequate testing and other governance optional API functionality until a time
Rule.
sufficient to achieve functional when API standards have undergone
• Application Access To Common more testing in the market. However,
interoperability.’’
Clinical Data Set Response. We agree with the many commenters strongly supported
approach suggested by the HITSC to the inclusion of API functionality for
split our original proposed certification patient access, discussing the criterion’s
terion
§ 170.315(g)(7) (Application access—patient criterion into three separate certification provision of more flexibility and choice
selection) criteria with each individual criterion for the consumer, better facilitation of
focused on specific functionality. Based communication and education for
on prior experience with certification individuals, fostering of more efficient
2015 Edition Health IT Certification Cri- criteria that ‘‘lump’’ functionality and modern information exchange, and
terion together that can otherwise be encouraging innovation by app
§ 170.315(g)(8) (Application access—data separately performed, we believe that developers and entrepreneurs to create
category request)
this additional flexibility will allow for better online experiences for users.
health IT developers to be more Several commenters also voiced support
2015 Edition Health IT Certification Cri- innovative. This will enable additional for the approach of encouraging
terion modularity as part of the ONC Health IT movement towards APIs, without
§ 170.315(g)(9) (Application access—all Certification Program in the event that locking in any specific standard, and
data request) a health IT developer seeks to change urged ONC to maintain an open,
and recertify one of the three API transparent process with public input as
We proposed a new 2015 Edition functionalities and leave the other two it works with industry to identify and
criterion at § 170.315(g)(7) that would capabilities unchanged. The three develop emerging standards in this
require health IT to demonstrate it could certification criteria will be adopted at space.
provide application access to the § 170.315(g)(7), (g)(8), and (g)(9). Each Response. We have adopted three new
Common Clinical Data Set via an will include the documentation and criteria as a new component of the 2015
application programming interface terms of use requirement that was part Base EHR definition in § 170.102. We
(API), and requiring that those same of the single proposed criterion. appreciate the number of detailed and
capabilities be met as part of the ‘‘VDT’’ Additionally, in consideration of this thoughtful comments on this criterion,
criterion. We noted that providing API change and because CMS has required and the concerns regarding
functionality could help to address as part of the EHR Incentive Program standardization. We agree with the
many of the challenges currently faced Stage 3 and Modifications final rule that many comments supportive of the
inclusion of API functionality for Health Response. We have adopted a final protected according to § 170.210(a)(2) or
IT Modules, and note that in addition to criterion without the proposed (c)(2). As such, we do not believe it is
enhanced flexibility for consumers and requirement for registration of third necessary to specifically name HTTPS
increased innovation, we believe that party applications. Our intention is to and/or SSL/TLS as this standard already
the ‘‘API’’ criteria will enable easier encourage dynamic registration and covers encryption and integrity
access to health data for patients via strongly believe that registration should protection for data in motion.
mobile devices, which may particularly not be used as a means to block While we appreciate the concerns of
benefit low income populations where information sharing via APIs. That is, commenters regarding privacy and
smartphone and tablet use may be more applications should not be required to security of third party applications, we
prevalent than computer access. pre-register (or be approved in advance) note that the regulation of third party
Regarding comments on with the provider or their Health IT applications is outside the scope of
standardization, we believe that the Module developer before being allowed certification, unless those applications
criterion is at an appropriate level of to access the API. Under the 2015 are seeking certification as Health IT
specificity given the ongoing Edition privacy and security (P&S) Modules. As consumer applications,
development of API standards for health certification framework, health IT third-party applications may fall under
care, and continue to support our initial certified to the API criteria must support the authority of the Federal Trade
proposal to allow for a flexible approach an application connecting to the API. Commission (FTC). In addition, if third-
without naming a specific standard. The P&S certification framework for the party applications are offered on behalf
However, we emphasize that we intend API criteria requires that a Health IT of a HIPAA covered entity or business
to adopt a standards-based approach for Module certified to this criterion be associate, they would be governed by
certification in the next appropriate capable of ensuring that: valid user the HIPAA Privacy and Security Rules
rulemaking and we note the existence credentials such as a username and as applicable to those entities. We also
and ongoing piloting of promising work password are presented (that match the note that the Federal Trade Commission
such as the Fast Healthcare credentials on file at the provider for and the National Institute of Standards
Interoperability Resources (FHIR) that user); the provider can authorize and Technology (NIST) have issued
specification. We agree with the user to view the patient’s data; the guidance regarding third-party
commenters’ suggestions that ONC application connects through a trusted applications; we encourage third-party
continue to monitor and actively connection; and the access is audited application developers to take
participate in industry efforts to support (§ 170.515(d)(1); (d)(9); and (d)(2) or advantage of these resources.122
testing of these and other emerging (d)(10); respectively). These certification Comments. Commenters pointed out
standards. We understand that many requirements should be sufficient to that the proposed process for certifying
Health IT Modules have APIs today and allow access without requiring further security & privacy requirements for the
‘‘Application Access to Common
providing for flexibility in the final rule application pre-registration. The
Clinical Data Set’’ criterion was
will allow them to certify their existing applicable P&S certification criteria are
inconsistent with the proposed privacy
APIs. discussed in more detail below.
and security certification approach
Security We intend to pursue a standards- listed in Appendix A of the Proposed
based approach for this criterion in the Rule’s preamble. The HITSC
We proposed that the API include a future, but believe that providing recommended that we include
means for the establishment of a trusted flexibility currently is more appropriate encryption and integrity protection as a
connection with the application that as emerging standards continue to security requirement for the ‘‘API’’
requests patient data. We stated that this mature and gain traction in industry, criterion.
would need to include a means for the and consistent with our overall Response. We agree with
requesting application to register with ‘‘functional’’ approach to the API commentators that the approach from
the data source, be authorized to request certification criteria at § 170.315(g)(7), our prior rules and our most recent
data, and log all interactions between (g)(8), (g)(9). We recognize and Proposed Rule were inconsistent. We
the application and the data source. encourage the work being done to have finalized an approach that
Comments. Multiple commenters develop emerging standards in this standardizes the way Health IT Modules
cited a need to provide security space, including OAuth, OpenID certify for privacy and security (P&S).
standards for this criterion while also Connect, UMA, and the Open ID For consistency, we have moved the
noting that current and emerging Foundation’s HEART profile. trusted connection security
standards, such as OAuth, are not yet Accordingly, we emphasize that the requirements included proposed
tested and fully mature for inclusion in security controls mentioned in the § 170.315(g)(7)(i) into two new
regulation. Other commenters suggested Proposed Rule establish a floor, not a certification criteria under § 170.315(d)
that ONC specifically name OAuth and/ ceiling. We encourage organizations to and have applied them back to the three
or some combination of OAuth, Open ID follow security best practices and adopted ‘‘API’’ certification criteria as
Connect, and User Managed Access implement security controls, such as part of the 2015 Edition P&S
(UMA) as the standards for penetration testing, encryption, audits, certification framework
authentication and authorization within and monitoring as appropriate, without
this criterion. A few commenters cited adversely impacting a patient’s access to 122 See, e.g., NIST Technical Considerations for
other standards, such as HTTPS and data, following their security risk Vetting 3rd Party Mobile Applications, available at
SSL/TLS. Multiple commenters noted assessment. We expect health IT http://csrc.nist.gov/publications/drafts/800-163/
sp800_163_draft.pdf; FTC, Careful Connections:

that the consumers of the API—the web developers to include documentation on Building Security in the Internet of Things (Jan.
and mobile applications—were how to securely deploy their APIs in the 2015), available at https://www.ftc.gov/tips-advice/
ultimately the entities responsible for public documentation required by the business-center/guidance/careful-connections-
security, rather than the Health IT certification criteria and to follow building-security-internet-things; FTC, Mobile App
Developers: Start with Security (Feb. 2013),
Module itself, and that the market for industry best practices. We also seek to available at https://www.ftc.gov/tips-advice/
third party applications is currently clarify that a ‘‘trusted connection’’ business-center/guidance/mobile-app-developers-
unregulated. means the link is encrypted/integrity start-security.
(§ 170.550(h)).123 To be certified for the increase security risks. In particular, selection of appropriate and reasonable
‘‘API’’ criteria, a Health IT Module must these commenters called for security security safeguards.
certify to either Approach 1 (technically standards to specify the manner in It is important to recognize that an
demonstrate) or Approach 2 (system which the API is authorized, API may be used to enable a patient to
documentation) for the following authenticated, and how data must be access data in the Designated Record Set
security criteria: secured in transit. for that individual, pursuant to 45 CFR
• Section 170.315(d)(1) Response. Entities must follow federal 164.524(a)(1).128 Additionally, the
‘‘authentication, access control, and and state requirements for security. electronic tools an individual uses to
authorization;’’ APIs, like all technology used in a handle or transport data in the
• Section 170.315(d)(9) ‘‘trusted HIPAA-regulated environment, must be
individual’s custody are not required to
connection;’’ and meet the HIPAA Security Rule. Those
implemented consistent with the
• Section 170.315(d)(10) ‘‘auditing HIPAA Security Rule. Namely, covered
tools cannot pose an unreasonable
actions on health information’’ or threat to the covered entity’s system, but
entities and their business associates
§ 170.315(d)(2) ‘‘auditable events and the tools used by the individual
must perform a security risk assessment
tamper resistance.’’ themselves are not regulated by HIPAA.
and must meet the HIPAA Security Rule
We intended the trusted connection For example, a patient may insist that in
standards, consistent with their risks to
requirement to encompass encryption providing an electronic copy of data
the administrative, technical, and
and integrity. The ‘‘trusted connection’’ about them, the email that delivers the
physical security of the ePHI they
criterion at § 170.315(d)(9) requires ePHI to the patient is not encrypted.129
maintain. The security safeguards
health IT to establish a trusted A patient may also select a third party
required by certification establish a floor
connection in accordance with the product that will receive their data
of security controls that all APIs must
standards specified in § 170.210(a)(2) through the API that is not subject to
meet; an organization’s security risk
and (c)(2). We have adopted HIPAA Security Rule requirements.
assessment may reveal additional risks Comments. Several commenters
§ 170.315(d)(10) ‘‘auditing actions on that must be addressed in the design or
health information’’ as an abridged stated that APIs should align with
implementation their EHR’s particular patient privacy expectations.
version of § 170.315(d)(2) ‘‘auditable API or they may have additional
events and tamper resistance’’ as some Response. We appreciate the
regulatory requirements for security. commenters’ concerns about patient
of the capabilities included in Therefore, users of health information
§ 170.315(d)(2) would likely not apply privacy expectations and agree that use
technology should include APIs in their of APIs must align with all federal and
to a Health IT Module certified only to security risk analysis and implement
the ‘‘API’’ criteria, such as recording the state privacy laws and regulations. We
appropriate security safeguards. We also expect APIs to be used in circumstances
audit log status or encryption status of strongly encourage health IT developers
electronic health information locally when consent or authorization by an
to build security into their APIs and individual is required, as well as in
stored on end-user devices by the applications following best practice
technology. A Health IT Module circumstances when consent or
guidance, such as the Department of authorization by an individual is not
presented for certification to the ‘‘API’’ Homeland Security’s Build Security In
criteria, depending on the capabilities it legally required for access, use or
initiative.124 We also reiterate that at disclosure of PHI. In other words, APIs,
included for certification, could be this time, we are requiring a read-only
certified to either § 170.315(d)(2) or like faxes before them, will be used in
capability—read-only capabilities may light of the existing legal framework that
(d)(10) as part of the 2015 Edition P&S have fewer security risks because the
certification framework. already supports the transmission of
EHR does not consume external data. protected health information, sensitive
We have removed the requirement
that the API must include a means for Provider organizations already health information, and applicable
the requesting application to register transmit information outside their consent requirements.
with the data source. Our intention was networks such as electronic claims In circumstances where there is a
that APIs should support dynamic submission, lab orders, and VDT requirement to document a patient’s
registration that does not require pre- messages. These transmissions may be request or particular preferences, APIs
approval before an application requests occurring using APIs today. Therefore, can enable compliance with such
data from the API. However, from the provider organizations could already be documentation requirements. The
comments received it was clear that our implementing safeguards needed to HIPAA Privacy Rule 130 permits the use
intention was not understood. Further, secure APIs. We encourage providers to of electronic documents to qualify as
open source standards for dynamic employ resources released by OCR and writings for the purpose of proving
registration are still under active ONC, such as the Security Risk signature, e.g., electronic signatures.
development, there is currently no Assessment Tool 125 and the Guide to Electronic signatures can be captured by
consensus-based standard to apply, and Privacy and Security of Electronic a patient portal or an API, absent the
we do not want registration to become Health Information,126 as well as the application of a more privacy-protective
a barrier for use of Health IT Modules’ Office for Civil Rights’ website 127 to state law.
APIs. We are removing this requirement make risk-based decisions regarding The existing legal framework would
at this time for the purposes of their implementation of APIs and the support the use of APIs to facilitate
certification and will consider verifying patient access to electronic health
this technical capability for a potential 124 https://buildsecurityin.us-cert.gov/. information or patient access requests
125 ONC Security Risk Assessment Tool: http://

future rulemaking.
www.healthit.gov/providers-professionals/security- 128 45 CFR 164.524(a)(1): http://www.gpo.gov/
Comments. Several commenters risk-assessment. fdsys/pkg/CFR-2013-title45-vol1/xml/CFR-2013-
expressed concern that APIs may 126 ONC Guide to Privacy and Security of title45-vol1-sec164-501.xml.
Electronic Health Information: http:// 129 HHS Office for Civil Rights FAQs on HIPAA:
123 We refer readers to section IV.C.1 (‘‘Privacy www.healthit.gov/sites/default/files/pdf/privacy/ http://www.hhs.gov/ocr/privacy/hipaa/faq/health_
and Security’’) of this preamble for further privacy-and-security-guide.pdf. information_technology/570.html.
discussion of the 2015 Edition P&S certification 127 HHS Office for Civil Rights: http:// 130 45 CFR part 160 and Part 164, Subparts A and
framework. www.hhs.gov/ocr/office/index.html. E.
made pursuant to 45 CFR 164.524 to must be included in the technical together; thus applications connecting
transmit their information to a documentation also required to be made to the API would be able to request data
designated third party. For example, an available as part of certification. Once on a specific patient, as described in the
individual may request a copy of their the specific ID or other token is returned ‘‘API—patient selection’’ criterion,
data from their provider’s API using in a response, we expect and intend for using an obtained ID or other token. At
software tools of the individual’s the other ‘‘API’’ criteria discussed below this time, we have decided not to
choosing. Assuming the individual has to be able to use the ID or other token include an additional patient list
been properly authenticated and to then perform the data requests. creation requirement. However, we
identity-proofed, the provider’s emphasize that this initial set of APIs
Data Requests, Response Scope, and
obligation under HIPAA is to fulfill the represents a floor rather than a ceiling,
Return Format
‘‘access’’ request through the API if that and we expect developers to build
functionality is available, because that is We proposed that the API would need enhanced APIs to support innovation
the medium so chosen by the patient. to support two types of data requests and easier, more efficient access to data
The addition of APIs to the technical and responses: ‘‘by data category’’ and in the future.
landscape of health IT does not alter ‘‘all.’’ In both cases, the proposed scope In response to concerns regarding the
HIPAA requirements, which support for certification was limited to the data return format for the data-category
reliance on the established and specified in the Common Clinical Data request, we have decided to make that
prevailing standards for electronic proof Set. For ‘‘by data category,’’ the API requirement more flexible and have
of identity.131 This policy supports the would need to respond to requests for removed the specific proposed language
availability of health information for each of the data categories specified in of XML or JSON to say in the final
treatment, payment, and health care the Common Clinical Data Set and criterion that the returned data must be
operations (45 CFR 164.506) and return the full set of data for that data in a computable (i.e., machine readable)
leverages the progress already made to category. We also proposed that as the format.
operationalize privacy laws in an return format for the ‘‘by data category,’’ In response to comments concerning
electronic environment, while that either XML or JSON would need to the ‘‘all-request,’’ we clarify that the API
facilitating interoperability. be produced. ‘‘All’’ requests for a functionality must be able to respond to
specific patient would return a patient’s requests for all of the data included in
Patient Selection fully populated summary record the CCDS on which there is data for
We proposed that the API would need formatted in accordance with the C– patient, and that the return format for
to include a means for the application CDA version 2.0. this functionality would be limited to
to query for an identification (ID) or Comments. Commenters suggested the C–CDA’s CCD document template.
other token of a patient’s record in order several specific changes to this criterion, We believe that focusing on the CCD
to subsequently execute data requests including: We should clarify that access document template will reduce the
for that record. is for a specific patient; we should implementation burden for health IT
Comments. Commenters noted that include a requirement that applications developers to meet this certification
standardization of this requirement be able to request specific date ranges, criterion and will help application
should include industry-accepted ability to request patient lists or other developers connecting to Health IT
standards such as IHE PDQ or PIX identified populations; and we should Modules’ APIs because they will know
query. remove the return format of either XML with specificity what document
Response. Consistent with our or JSON, because some APIs could template they are going to receive.
approach throughout the ‘‘API’’ criteria, return data in HL7 v2 format. For the With regard to requests for each ‘‘data
we decline to require a specific standard ‘‘data category’’ request requirement, category,’’ for the purposes of
at this time, although we intend to do commenters asked that ONC clarify certification, the technology must
so in a future rulemaking. We note that whether ‘‘each’’ means a query limited demonstrate that it can respond to
the standards suggested by commenters to one category at a time, or whether requests for each individual data
have been adopted in industry and we combinations of categories can be category one at a time. However, this is
encourage Health IT Modules to identify requested at one time. For ‘‘all’’ a baseline for the purposes of testing
and implement any existing standards requests, some commenters suggested and certification and health IT
that best support the needs of their that this functionality should support developers are free to enable the return
users. We have adopted these final the ability to view or download based of multiple categories at once if they
requirements in the certification on specific data, time, or period of time; choose to build out that functionality.
criterion adopted in § 170.315(g)(7). It other commenters urged us to focus first Similar to our response for ‘‘VDT’’
includes the proposed requirement with on the narrow set of capabilities initially criterion, we clarify that patients should
specific conforming adjustments to be proposed to gain experience, and add be provided access to any data included
its own certification criterion. The additional capabilities in future in the Common Clinical Data Set.
criterion specifies that technology will certification. Most commenters As with the VDT requirement, we
need to be able to receive a request with supported focusing on the CCD have adopted date and time filtering
sufficient information to uniquely document to create clear expectations requirements as part of this criterion.
identify a patient and return an ID or and enhance interoperability. Two We agree with commenters that adding
other token that can be used by an commenters were opposed to restricting this functionality to these criteria will
application to subsequently execute the use of C–CDA 2 to CCD document provide clarity that patients should have
requests for that patient’s data. We do type because other document types (i.e. certain baseline capabilities available to
not presume or prescribe a particular Transfer Summary, Referral Note and them when it comes to selecting the
method or amount of data by which Care Plan) are very commonly used data (or range of data) they wish to
technology developer implements its documents in the real world, and would access using an application that
approach to uniquely identify a patient. not be available through this interacts with the Health IT Module’s
However, we note that such information functionality. APIs. Specifically, we have adopted two
Response. We expect that all three timeframe requirements: First, to ensure
131 NIST SP 800–63–2. API capabilities would function that an application can request data
associated with a specific date, and the applications that only interact with 2015 Edition Health IT Certification Cri-
second, to ensure that an application certain Health IT Modules. As stated terion
can request data within an identified previously in this preamble, we intend § 170.315(h)(1) (Direct Project)
date range, which must be able to to require a standards-based approach to
accommodate the application requesting this criterion in the next appropriate We proposed to adopt a certification
a range that includes all data available rulemaking and we encourage vendors criterion that includes the capability to
for a particular patient. The technology to start piloting the use of existing and send and receive according to the
specifications should be designed and emerging API standards. By requiring Applicability Statement for Secure
implemented in such a way as to return that documentation and terms of use be Health Transport (the primary Direct
meaningful responses to queries, open and transparent to the public by Project specification). We noted that we
particularly with regard to exceptions requiring a hyperlink to such previously adopted this capability for
and exception handling, and should documentation to be published with the the 2014 Edition at § 170.314(b)(1),
make it easy for applications to discover product on the ONC Certified Health IT (b)(2) and (h)(1). We proposed to
what data exists for the patient.
Product List, we hope to encourage an include as an optional capability for
Documentation and Terms of Use open ecosystem of diverse and certification the capability to send and
We proposed that the required innovative applications that can receive according to the Implementation
technical documentation would need to successfully and easily interact with Guide for Delivery Notification in
include, at a minimum: API syntax, different Health IT Modules’ APIs. Direct, Version 1.0, June 29, 2012
function names, required and optional • Transport Methods and Other (‘‘Delivery Notification IG’’). We
parameters and their data types, return Protocols explained that the primary Direct
variables and their types/structures, Project lacked certain specificity and
We proposed two ways for providers consistency guidance such that
exceptions and exception handling
to meet the 2015 Edition Base EHR deviations from normal message flow
methods and their returns. We also
definition using health IT certified to could result if Security/Trust Agents
stated that the terms of use must include
the API’s developer policies and transport methods. The first proposed (STAs) implemented only requirements
required developer agreements so that way to meet the proposed 2015 Edition denoted as ‘‘must’’ in Section 3 of the
third-party developers could assess Base EHR definition requirement would primary Direct Project. As a result, STAs
these additional requirements before be for a provider to have health IT may not be able to provide a high level
engaging in any development against certified to § 170.315(b)(1) and (h)(1) of assurance that a message has arrived
the API. We also proposed that health (Direct Project specification). This at its destination. We further stated that
IT developers would need to submit a would account for situation where a the Delivery Notification IG provides
hyperlink to ONC–ACBs, which the provider uses a health IT developer’s implementation guidance enabling
ONC–ACB would then submit as part of product that acts as the ‘‘edge’’ and the STAs to provide a high level of
its product certification submission to HISP. The second proposed way would assurance that a message has arrived at
the Certified Health IT Product List be for a provider to have health IT its destination and outlines the various
(CHPL) that would allow any interested certified to § 170.315(b)(1) (‘‘ToC’’ exception flows that result in
party to view the API’s documentation criterion) and (h)(2) (‘‘Direct Project, compromised message delivery and the
and terms of use. Edge Protocol, and XDR/XDM’’). This mitigation actions that should be taken
Comments. One commenter suggested would account for situations where a by STAs to provide success and failure
that ONC should clarify whether our provider is using one health IT notifications to the sending system.
intent is that terms of use would developer’s product that serves as the Comments. Commenters
replace, include, or overlap with HIPAA ‘‘edge’’ and another health IT overwhelmingly supported the adoption
privacy policies that health care developer’s product that serves as a of this criterion as proposed. Many
providers are required to provide their HISP.132 To fully implement this commenters also expressed strong
patients. Another commenter voiced approach, we proposed to revise support for the optional delivery
concern that the API-consuming § 170.550 to require an ONC–ACB to notification provision as a means to
application should be the party ensure that a Health IT Module includes support specific business practices.
responsible for assuring effective use of the certification criterion adopted in Some commenters stated that delivery
the API in terms of safety, security, § 170.315(b)(1) in its certification’s notification will only work when both
privacy, and accessibility. Multiple scope in order to be certified to the receiving and sending parties support
commenters suggested that ONC place certification criterion proposed for the functionality and, thus, delivery
certain restrictions on terms of use, adoption at § 170.315(h)(1). We lastly notification must be required of both
including limits on any fees, copyright, proposed to revise the heading of sending and receiving entities in order
or licensing requirements on APIs. § 170.202 from ‘‘transport standards’’ to for it to work. Commenters also
Response. We emphasize that nothing
‘‘transport standards and other requested clarification regarding
in this criterion is intended to replace
protocols.’’ ‘‘ownership’’ and maintenance of the
federal or state privacy laws and
We received minimal comments on Direct Project, including some that
regulations, nor the contractual
these proposals and discussed what recommended that ‘‘ownership’’ should
arrangements between covered entities
belong to a SDO.
and business associates. Placing comments we received under the
requirements or limitations on the ‘‘Direct Project, Edge Protocol, and Response. We have adopted a revised
specific content of the terms of use is XDR/XDM’’ certification criterion criterion in comparison to our proposal
beyond the scope of certification. below. and the related 2014 Edition
However, we reiterate that our policy certification criteria. After careful
• Direct Project
intent is to allow patients to access their consideration of comments, we believe
data through APIs using the it is appropriate to adopt the
132 See the 2014 Edition Release 2 final rule for
applications of their own choosing, and more discussion on such situations (79 FR 54436–
Applicability Statement for Secure
limit the creation of ‘‘walled gardens’’ of 38). Health Transport, Version 1.2 (August 3,
2015).133 This new version of the long term. We believe this step is both Applicability Statement for Secure
specification includes updates that necessary and critical for Direct Health Transport, Version 1.2 (August 3,
improve interoperability through the specifications to be well maintained and 2015).135 This new version of the
clarification of requirements that have industry supported over time. specification includes updates that
been subject to varying interpretations, • Direct Project, Edge Protocol, and improve interoperability through the
particularly requirements around XDR/XDM clarification of requirements that have
message delivery notifications. This been subject to varying interpretations,
version also clarifies pertinent 2015 Edition Health IT Certification Cri- particularly requirements around
requirements in the standards terion message delivery notifications. This
underlying the Applicability Statement § 170.315(h)(2) (Direct Project, Edge Pro- version also clarifies pertinent
for Secure Health Transport. Migration tocol, and XDR/XDM) requirements in the standards
to this newer version will provide underlying the Applicability Statement
improvements for exchange of health We proposed a 2015 Edition ‘‘Direct, for Secure Health Transport. Migration
information and should have minor Edge Protocol, and XDR/XDM’’ to this newer version will provide
development impacts on health IT certification criterion that included improvements for exchange of health
developers. Further, we expect that three distinct capabilities. The first information and should have minor
many developers and technology proposed capability focused on development impacts on health IT
organizations that serve as STAs will technology’s ability to send and receive developers. Further, we expect that
quickly migrate to version 1.2 due to its according to the Applicability Statement many developers and technology
improvements. We note, for certification for Secure Health Transport (the organizations that serve as STAs will
to this criterion, we have made it a primary Direct Project specification). quickly migrate to version 1.2 due to its
requirement to send and receive The second proposed capability focused improvements. For certification to this
messages in only ‘‘wrapped’’ format on technology’s ability to send and criterion, we have made it a requirement
even though the specification (IG) receive according to both Edge Protocol to send and receive messages in only
allows use of ‘‘unwrapped’’ messages. methods specified by the standard ‘‘wrapped’’ format even though the
This requirement will further improve adopted in § 170.202(d). The third specification (IG) allows use of
interoperability among STAs, while proposed capability focused on ‘‘unwrapped’’ messages. This
having minor development impact on technology’s ability to send and receive requirement will further improve
health IT developers. according to the XDR and XDM for interoperability among STAs while
We have also adopted as a Direct Messaging Specification. We having minor development impact on
requirement for this criterion the noted that these three capabilities were health IT developers.
Implementation Guide for Delivery previously adopted as part the 2014 We have also adopted as a
Notification in Direct, Version 1.0, June Edition, including through the 2014 requirement for this criterion the
29, 2012. While we proposed this IG as Edition and 2014 Edition Release 2 final Implementation Guide for Delivery
an optional provision, we agree with rules, and we reminded health IT Notification in Direct, Version 1.0, June
commenters that this functionality must developers that best practices exist for 29, 2012. While we proposed this IG as
be required to best support the sharing of information and enabling an optional provision, we agree with
interoperability and exchange, the broadest participation in commenters that this functionality must
particularly for both sending and information exchange with Direct.134 be required to best support
receiving parties. As we stated in the Comments. Commenters interoperability and exchange,
2014 Edition Release 2 proposed rule overwhelmingly supported the adoption particularly for both a sending and
(79 FR 10914–915), the capabilities in of this criterion as proposed. A receiving HISP. As we stated in the 2014
this IG provide implementation commenter suggested that the primary Edition Release 2 proposed rule (79 FR
guidance enabling HISPs to provide a Direct Project specification should only 10914–915), the capabilities in this IG
high level of assurance to senders that be included in the Direct Project provide implementation guidance
a message has arrived at its destination, certification criterion (§ 170.315(h)(1)). enabling HISPs to provide a high level
a necessary component to A commenter requested clarification on of assurance to senders that a message
interoperability. the anticipated advantage(s) of has arrived at its destination, a
We appreciate the recommendations certifying with XDR/XDM. A necessary component to
and questions regarding ‘‘ownership’’ of commenter stated some systems are still interoperability.
the Direct specifications. We clarify that using SMTP and IMAP. Another We require the use of XDR/XDM to
although ONC played a significant role commenter stated that while certified support interoperability and ensure that
in the creation and coordination of the Health IT Modules may implement certain messages packaged using XDR/
Direct specifications that ONC does not Direct Edge protocols there is no XDM can be received and processed.
‘‘own’’ them. Rather, the specifications requirement for HISPs to adopt the This is the same approach we required
are publicly available and we view them protocol. Commenters also requested with the 2014 Edition. We also refer
as maintained by the community of clarification regarding ‘‘ownership’’ and readers to the ‘‘ToC’’ certification
stakeholders who have and continue to maintenance of the Direct project, with criterion discussed earlier in this
support the Direct specifications. To some recommending that ‘‘ownership’’ preamble for further explanation of the
that end, as a participant in this should belong to a SDO. interoperability concerns related to the
community, we have been working with Response. We have adopted this as a use of XDR/XDM. We clarify for
other stakeholders to locate an revised criterion in comparison to our commenters that for health IT to be
appropriate SDO who can maintain and proposal and the related 2014 Edition certified to this criterion it must be able
mature these specifications over the certification criteria. After careful to support both of the Edge Protocols
consideration of comments, we believe
133 http://wiki.directproject.org/file/view/ 135 http://wiki.directproject.org/file/view/
Applicability%20Statement%20for%20Secure
it is appropriate to adopt the Applicability%20Statement%20for%20Secure
%20Health%20Transport%20v1.2.pdf/556133893/ %20Health%20Transport%20v1.2.pdf/556133893/
Applicability%20Statement%20for%20Secure 134 http://wiki.directproject.org/Best+Practices+ Applicability%20Statement%20for%20Secure
%20Health%20Transport%20v1.2.pdf. for+Content+and+Workflow. %20Health%20Transport%20v1.2.pdf.
methods referenced in the Edge IG specifications under the ‘‘Direct Project’’ proposed ‘‘unchanged’’ 2015 Edition
version 1.1 (i.e., the ‘‘IHE XDR profile certification criterion. certification criteria to the
for Limited Metadata Document corresponding 2014 Edition certification
4. Gap Certification Eligibility Table for
Sources’’ edge protocol or an SMTP- criteria (80 FR 16868). We noted that
2015 Edition Health IT Certification
focused edge protocol (SMTP alone or with respect to the 2015 Edition
Criteria
SMTP in combination with either certification criteria at § 170.315(g)(1)
IMAP4 or POP3)). We have previously defined gap through (g)(3) that gap certification
We note that even though the Edge certification at 45 CFR 170.502 as the eligibility for these criteria would be
Protocol requires support for XDS certification of a previously certified
fact-specific and would depend on any
limited metadata, XDR/XDM supports Complete EHR or EHR Module(s) to: (1)
modifications made to the specific
capability to transform messages using all applicable new and/or revised
certification criteria to which these
full metadata wherever appropriate. certification criteria adopted by the
Secretary at subpart C of part 170 based ‘‘paragraph (g)’’ certification criteria
Therefore, we require that a Health IT
on the test results of a NVLAP- apply.
Module must support both the XDS
Metadata profiles (Limited and Full), as accredited testing laboratory; and (2) all Comments. We did not receive
specified in the underlying IHE other applicable certification criteria specific comments on the gap
specifications, to ensure that the adopted by the Secretary at subpart C of certification eligibility table or our
transformation between messages part 170 based on the test results used described gap certification policy.
packaged using XDR/XDM are done to previously certify the Complete EHR Response. We have revised the
with as much appropriate metadata as or EHR Module(s) (for further proposed ‘‘gap certification eligibility’’
possible. explanation, see 76 FR 1307–1308). Our table to reflect the adopted 2015 Edition
This criterion requires the three gap certification policy focuses on the certification criteria discussed in section
capabilities specified (Direct Project differences between certification criteria
III.A.3 of this preamble. Table 6 below
specification, Edge Protocol compliance, that are adopted through rulemaking at
provides a crosswalk of ‘‘unchanged’’
and XDR/XDM processing) because it different points in time. This allows
2015 Edition certification criteria to the
must support interoperability and all health IT to be certified to only the
differences between certification criteria corresponding 2014 Edition certification
potential certified exchange options as
well as support a provider in meeting editions rather than requiring health IT criteria. These 2015 Edition certification
the Base EHR definition. As we to be fully retested and recertified to criteria have been identified as eligible
discussed above, a provider could use certification criteria (or capabilities) that for gap certification. We note that with
an ‘‘independent’’ HISP to meet the remain ‘‘unchanged’’ from one edition respect to the 2015 Edition certification
Base EHR definition. In such a case, the to the next and for which previously criteria at § 170.315(g)(1) (‘‘automated
HISP would need to be certified to this acquired test results are sufficient. numerator recording’’) and (g)(2)
criterion in order for the provider to use Under our gap certification policy, (‘‘automated measure calculation’’), a
it to meet the Base EHR definition, ‘‘unchanged’’ criteria are eligible for gap gap certification eligibility
which is part of the CEHRT definition certification, and each ONC–ACB has determination would be fact-specific
under the EHR Incentive Programs. discretion over whether it will provide and depend on any modifications to the
Therefore, there is incentive for a HISP the option of gap certification. certification criteria to which these
to be certified to this criterion. For the purposes of gap certification, criteria apply and relevant Stage 3
Please see our prior response we included a table in the Proposed meaningful use objectives and
regarding the ‘‘ownership’’ of the Direct Rule to provide a crosswalk of the measures.
TABLE 6—GAP CERTIFICATION ELIGIBILITY FOR 2015 EDITION HEALTH IT CERTIFICATION CRITERIA
2015 Edition 2014 Edition
Regulation section Regulation section

Title of regulation paragraph Title of regulation paragraph
170.315 170.314
(a)(1) ........................... Computerized provider order entry—medica- (a)(1) .......................... Computerized provider order entry
tions. (a)(18) ........................ Computerized provider order entry—medica-
tions
(a)(2) ........................... Computerized provider order entry—labora- (a)(1) .......................... Computerized provider order entry
tory. (a)(19) ........................ Computerized provider order entry—labora-
tory
(a)(3) ........................... Computerized provider order entry—diag- (a)(1) .......................... Computerized provider order entry
nostic imaging. (a)(20) ........................ Computerized provider order entry—diag-
nostic imaging
(a)(4) ........................... Drug-drug, drug-allergy interaction checks for (a)(2) .......................... Drug-drug, drug-allergy interaction checks
CPOE.
(a)(7) ........................... Medication list .................................................. (a)(6) .......................... Medication list
(a)(8) ........................... Medication allergy list ...................................... (a)(7) .......................... Medication allergy list
(a)(10) ......................... Drug-formulary and preferred drug list checks (a)(10) ........................ Drug-formulary checks
(a)(11) ......................... Smoking status ................................................ (a)(11) ........................ Smoking status
(d)(1) ........................... Authentication, access control, and authoriza- (d)(1) .......................... Authentication, access control, and authoriza-
tion. tion
(d)(3) ........................... Audit report(s) .................................................. (d)(3) .......................... Audit report(s)
(d)(4) ........................... Amendments .................................................... (d)(4) .......................... Amendments
(d)(5) ........................... Automatic access time-out ............................... (d)(5) .......................... Automatic log-off
(d)(6) ........................... Emergency access ........................................... (d)(6) .......................... Emergency access
(d)(7) ........................... End-user device encryption ............................. (d)(7) .......................... End-user device encryption
(d)(11) ......................... Accounting of disclosures ................................ (d)(9) .......................... Accounting of disclosures
TABLE 6—GAP CERTIFICATION ELIGIBILITY FOR 2015 EDITION HEALTH IT CERTIFICATION CRITERIA—Continued
2015 Edition 2014 Edition
Regulation section Regulation section

Title of regulation paragraph Title of regulation paragraph
170.315 170.314
(f)(3) ............................ Transmission to public health agencies—re- (f)(4) ........................... Inpatient setting only—transmission of report-
portable laboratory tests and values/results. able laboratory tests and values/results
5. Not Adopted Certification Criteria comment on the on the feasibility and our proposed method could lead to data
This section of the preamble discusses implementation considerations for integrity issues and patient safety
proposed certification criteria included proposals that rely on less granular concerns. Commenters suggested that
in the Proposed Rule that we have not LOINC® codes for attribution to vital the industry is working to define a
adopted and requests for comments on sign measurements and the inclusion of methodology for structured data capture
potential certification criteria included accompanying metadata. In the through initiatives like the S&I
in the Proposed Rule. We summarize Proposed Rule’s section III.B.3 Framework Structured Data Capture
the comments received on these (‘‘Common Clinical Data Set’’), we Initiative,138 and that ONC should not
proposed criteria and requests for stated that vital signs would be adopt requirements for structured data
comments and provide our response to represented in same manner for the capture as part of certification until
those comments. ‘‘Common Clinical Data Set’’ definition there is a consensus-based way forward.
• Vital Signs, Body Mass Index, and as it applies to the certification of health A few commenters were concerned that
Growth Charts IT to the 2015 Edition, with the the metadata could be lost or hidden
We proposed to adopt a 2015 Edition exception of the proposed optional vital from the user’s view when exchanged,
‘‘vital signs, BMI, and growth charts’’ signs. resulting in the receiving user’s inability
certification criterion that was revised Comments. We received mixed to accurately and safety interpret the
in comparison to the 2014 Edition ‘‘vital feedback to the overall proposal, with vital sign measurement.
signs, BMI, and growth charts’’ criterion many commenters suggesting that (1) Some commenters noted that
(§ 170.314(a)(4)). Specifically, we ONC should not be mandating how vital SNOMED CT® is the international
proposed to: (1) Expand the types of signs are recorded natively within standard used for vital signs. One
vital signs for recording; 136 (2) require certified Health IT Modules, and (2) the commenter noted that IHE is working
that each type of vital sign have a proposed approach to require recording with the Department of Veterans Affairs
specific LOINC® code attributed to it; of vital signs using a less granular and other stakeholders to create a utility
(3) that The Unified Code of Units of LOINC® code with associated metadata that would allow conversion from
Measure, Revision 1.9, October 23, 2013 was not a mature or the right approach SNOMED CT® to LOINC® or to make
(‘‘UCUM Version 1.9’’) 137 be used to for ensuring semantic interoperability. data accessible from other countries that
record vital sign measurements; and (4) Many commenters suggested that ONC use SNOMED CT® for vital signs.
that certain metadata accompany each should only specify how vital signs are Many commenters suggested that the
vital sign, including date, time, and exchanged for the Common Clinical complexity of the proposed approach
Data Set. for recording vital signs with metadata
measuring- or authoring-type source. In
Concerning the proposal to specify would require extensive rework and
providing this proposal, we stated
how vital signs are recorded natively in mapping of existing systems resulting in
awareness that several stakeholder
a health IT system, commenters noted little additional benefit for workflow,
groups are working to define unique,
that there would be workflow and usability, and semantic interoperability.
unambiguous representations/
usability issues, such as requiring the As such, commenters stated there was
definitions for vital signs along with
user to enter in metadata every time a little incentive to certify to the proposed
structured metadata to increase data
vital sign is taken. As vital signs are criterion for vital signs as it was not
standardization for consistent
routinely taken as a part of every patient proposed as a requirement for
representation and exchange. To ensure
visit in many provider settings, this participation in the EHR Incentive
consistent and reliable interpretation Programs. Commenters also noted that
when information is exchanged, we could be burdensome and time-
most 2014 Edition certified health IT
stated that vital signs should be consuming.
Regarding the proposed approach to capture vital signs data in different
captured natively. In addition, we methods based on the product and
proposed ‘‘optional’’ pediatric vital record vital signs using a less granular
LOINC® code with associated metadata, provider setting, but all of them still
signs for health IT to electronically support the exchange of vital signs as
record, change, and access. With regard commenters had a number of concerns.
specified by the industry-accepted C–
to the proposed metadata, we requested Some commenters were concerned that
CDA standard. Thus, most health IT
comment on additional information that LOINC® was designed as a pre-
already supports mapping to accepted
we should consider for inclusion and coordinated code system (e.g., some
industry standards for exchange today.
the best available standards for LOINC® codes for vital signs are pre- Response. We thank commenters for
representing the metadata consistently specified to the site of vital sign the thoughtful and detailed feedback.
and unambiguously. We also requested measurement, method of vital sign
We agree with commenters’ concerns

measurement, and/or device used to
136 Per 80 FR 16818: Systolic blood pressure, take vital sign), but that our proposal to 138 https://www.google.com/url?sa=t&rct=j&q=&
diastolic blood pressure, body height, body weight use a less granular code with associated esrc=s&source=web&cd=1&cad=rja&uact=8&ved=
measured, heart rate, respiratory rate, body metadata to assist with interpretation 0CCUQFjAA&url=http%3A%2F%2Fwiki.si
temperature, oxygen saturation in arterial blood by framework.org%2FStructured%2BData%2BCapture
pulse oximetry, body mass index (BMI) [ratio], and would treat LOINC® as a post- %2BInitiative&ei=l3KiVYW-MIKU-AH0kbjwCg&
mean blood pressure. coordinated code system. Since LOINC® usg=AFQjCNFOieJjmvmMPbgBjd2zJ3igsdJVbw&
137 http://unitsofmeasure.org/trac/. does not include specific syntax rules, sig2=GESy7uftrinE-ohpXqMQjw.
regarding the proposed approach to 2014 Edition ‘‘image results’’ criterion, address these concerns and will
record vital signs natively within a the support interoperability, nor serve an consider whether it is appropriate to
certified Health IT Module using less identified HHS or other program include such a criterion and associated
specific LOINC® codes and associated requiring the use of health IT certified standards in a future rulemaking as
metadata. Our long-term goal is for a to this functionality. In the response to HHS’ work to support the Precision
vital sign measurement to be the commenters recommending DICOM Medicine Initiative matures.140
semantically interoperable during as the standard we should adopt, we • Patient List Creation
exchange and thereby retain its meaning will further assess whether there is an We proposed to adopt a 2015 Edition
and be correctly interpretable by a appropriate use case for the adoption of ‘‘patient list creation’’ certification
receiving system user. As vital signs a certification criterion that requires the criterion that was unchanged in
data relates to clinical decision support use of the DICOM standard as part of comparison to the 2014 Edition ‘‘patient
(CDS) and other quality reporting any future rulemaking. However, for the list creation’’ criterion (§ 170.314(a)(14))
improvement tools, we continue to particular criterion we proposed, we and explained the expectation that a
believe that vital signs should be refer readers to our prior thoughts on Health IT Module must demonstrate its
consistently and uniformly captured in the appropriateness of adopting DICOM capability to use at least one of the more
order to apply industry-developed CDS (77 FR 54173). specific data categories included in the
and CQM standards. However, as noted • Family Health History—Pedigree ‘‘demographics’’ certification criterion
by commenters, the proposed approach In the Proposed Rule, we proposed a (§ 170.315(a)(5)) (e.g., sex or date of
does not fully achieve these goals and 2015 Edition ‘‘family health history— birth).
does not offer an added benefit to the pedigree’’ certification criterion that Comments. The majority of
current 2014 Edition approach of required health IT to enable a user to commenters supported this criterion as
requiring vital signs exchange using create and incorporate a patient’s FHH proposed, but some commenters
industry standards and capture in a according to HL7 Pedigree standard and questioned why health IT developers
standards-agnostic manner. We expect the HL7 Pedigree IG, HL7 Version 3 would seek certification to this criterion
the industry to develop a consensus- Implementation Guide: Family History/ and why providers would adopt health
based approach for structured data Pedigree Interoperability, Release 1.139 IT certified to this criterion because it
capture, including for vital signs, and Comments. While some commenters did not support an objective or measure
we will continue to support these supported adoption of this functionality of the proposed EHR Incentive Programs
processes in consideration of a future and criterion, many commenters Stage 3 or another program requirement.
rulemaking. Given these considerations, expressed concerns about the standard Conversely, some commenters suggested
we have not adopted a 2015 Edition and IG. Commenters stated that there that we adopt a ‘‘patient list creation’’
‘‘vital signs, BMI, and growth charts’’ has been very little adoption of the criterion that had more functionality
certification criterion at this time, as we Pedigree standard and IG. Commenters that would be valuable to providers.
believe there is no added certification also expressed specific concerns about These commenters suggested that the
value for capturing vital signs in either the standard and IG. Commenters noted criterion included required
the proposed manner or in a simply that the standard is out of date (not been functionality to select, sort, and create
standards-agnostic manner. updated since 2009) and not in sync patient lists on, for example: on all
• Image Results with HL7 V3-based standards. patient demographics, vital signs,
We proposed to adopt a 2015 Edition Commenters also stated that the IG was orders, and referrals, and allergies
‘‘image results’’ certification criterion immature and had not been updated beyond medication allergies.
that was unchanged in comparison to since 2013. In particular, commenters Commenters stated that such enhanced
the 2014 Edition ‘‘image results’’ noted that the W3C XML schema functionality would improve patient
criterion (§ 170.314(a)(12)). language cannot represent all tracking and the monitoring of health
Comments. The majority of constraints expressed in the base disparities.
commenters supported this criterion as specifications referenced in the IG and Response. We have not adopted this
proposed, but some commenters that there was a lack of clear guidance certification criterion as part of the 2015
questioned why health IT developers on interactions and appropriate Edition at this time. We have considered
would seek certification to this criterion implementations, which would likely public comments and no longer believe
and why providers would adopt health lead to inconsistent implementations. there is sufficient value in making this
IT certified to this criterion because it Overall, commenters suggested that a criterion available for certification as
did not support an objective or measure criterion not be adopted with the proposed. The criterion was proposed
of the proposed EHR Incentive Programs Pedigree standard and associated IG with limited functionality that did not
Stage 3 or another program requirement. until the standard and IG have been go beyond the 2014 Edition ‘‘patient list
Some commenters also questioned the appropriately updated, including creation’’ criterion. Further, as
value of this criterion without a addressing the interoperability proposed, it does not serve an identified
required standard, with a few interactions that need to be supported, HHS or other program. We will,
commenters recommending the matured, and widely adopted. however, consider the comments
adoption of the Digital Imaging and Response. We thank commenters for recommending more enhanced
Communication in Medicine (DICOM) their detailed feedback. We have not functionality as we consider
standard. adopted this criterion as part of the 2015 certification criteria for future
Response. We have not adopted this Edition at this time. We agree with rulemaking.
certification criterion as part of the 2015 • Electronic Medication
commenters that further effort is

Edition at this time. We have considered necessary to address their concerns Administration Record
public comments and no longer believe before adoption of this criterion and We proposed to adopt a 2015 Edition
there is sufficient value in making this associated standards. We intend to electronic medication administration
criterion available for certification as follow up with relevant stakeholders to record (eMAR) certification criterion
proposed. The criterion was proposed that was unchanged in comparison to
with functional requirements that do 139 http://www.hl7.org/implement/standards/
not advance functionality beyond the product_brief.cfm?product_id=301. 140 http://www.nih.gov/precisionmedicine/.
the 2014 Edition ‘‘eMAR’’ criterion Release 1.2. We requested comment on resources to adopting the harmonized
(§ 170.314(a)(16)). specific types of CDS Knowledge standards upon their completion.
Comments. The majority of Artifacts for testing and certification to Therefore, these commenters stated that
commenters supported this criterion as the HeD standard Release 1.2, and on they do not intend to adopt the HeD
proposed, but some commenters standards’ versions to consider as standards because the standards are
questioned why health IT developers alternative options, or for future based on a different data model (the
would seek certification to this criterion versions of this certification criterion, Virtual Medical Record or vMR) than
and why providers would adopt health given the ongoing work to harmonize the anticipated harmonized CDS and
IT certified to this criterion because it CDS and quality measurement CQM standards. A few commenters
did not support an objective or measure standards. noted that they did not support any
of the proposed EHR Incentive Programs • Decision Support—Service proposal to offer certification for
Stage 3 or another identified program In the Proposed Rule, we proposed to functionalities or standards that did not
requirement. A few commenters adopt a new 2015 Edition ‘‘decision directly support a requirement of the
requested clarification as to whether support—service’’ certification criterion proposed the EHR Incentive Programs
bar-code scanning is required to meet that, for the purposes of certification, Stage 3.
this criterion, with a couple of would require health IT to demonstrate Response. We thank commenters for
commenters recommending that bar- that it could electronically make an their thoughtful feedback. We
code scanning be part of this criterion information request with patient data acknowledge that the overall direction
to improve patient safety. and receive in return electronic clinical of health IT developers and providers is
Response. We have not adopted this guidance in accordance with an HeD to continue to support and eventually
certification criterion as part of the 2015 standard and the associated HL7 adopt the harmonized CDS and CQM
Edition at this time. We have considered Implementation Guide: Decision standards. Therefore, we agree with
public comments and no longer believe Support Service, Release 1.1 (March commenters that meeting the proposed
there is sufficient value in making this 2014), US Realm DSTU Specification.142 ‘‘decision support ’’ criteria and HeD
criterion available for certification as We specified that health IT would need standards would likely be inconsistent
proposed. The criterion was proposed to demonstrate the ability to send and with this overall direction and require
with functional requirements that do receive electronic clinical guidance inefficient use of resources. As such, we
not advance functionality beyond the according to the interface requirements also agree with comments that few, if
2014 Edition ‘‘eMAR’’ criterion, support defined in Release 1.1. We requested any, health IT developers would get
interoperability, nor serve an identified comment on alternative versions of certified to the proposed criteria and
program requiring the use of health IT standards and on future versions of this very few providers would demand CDS
certified to this functionality. We will certification criterion to advance the functionality using the HeD standards.
consider whether we should propose work to harmonize CDS and quality Accordingly, we have not adopted these
the same or a more enhanced eMAR measurement standards. certification criteria. We will continue
certification criterion in future We have summarized and responded to monitor the development and
rulemaking, including giving to comments on these ‘‘decision implementation of the harmonized CDS
consideration to the value of identifying support’’ criteria together as the and CQM standards; and will consider
or requiring specific assistive referenced HeD standards were whether to propose certification criteria
technologies (e.g., bar-code scanning) developed by one S&I initiative to that include these standards in a future
for demonstrating compliance with the rulemaking.
address two use cases, we received
functional requirements of the criterion. • Incorporate Laboratory Tests and
similar comments on both proposals,
• Decision Support—Knowledge and have determined to not adopt both
Values/Results
Artifact; and Decision Support—Service We proposed to adopt a 2015 Edition
criteria.
• Decision Support—Knowledge ‘‘incorporate laboratory tests and
Comments. Many commenters values/results’’ certification criterion
Artifact
In the Proposed Rule, we proposed to supported the overall goals of the HeD that was revised in comparison to the
adopt a new 2015 Edition ‘‘decision standards to provide standardized ways 2014 Edition ‘‘incorporate laboratory
support—knowledge artifact’’ to exchange decision support artifacts tests and values/results’’ criterion
certification criterion that, for the and request decision support (§ 170.314(b)(5)). We proposed to adopt
purposes of certification, would require information. However, these same and include the HL7 Version 2.5.1
health IT to demonstrate that it could commenters recommended ONC not Implementation Guide: S&I Framework
electronically send and receive clinical adopt these criteria because of the Lab Results Interface, Draft Standard for
decision support (CDS) knowledge ongoing work to develop harmonized Trial Use, Release 2, US Realm (‘‘LRI
artifacts in accordance with a Health CDS and clinical quality measure (CQM) Release 2’’) in the final 2015 Edition
eDecisions (HeD) standard. To assist the standards through the Clinical Quality ‘‘transmission of laboratory test reports’’
industry in producing and sharing Framework Standards & Interoperability criterion for the ambulatory setting. We
machine readable files for (S&I) Framework Initiative.143 explained that the LRI Release 2
representations of clinical guidance, we Commenters noted that the harmonized addresses errors and ambiguities found
proposed to adopt the HL7 Version 3 standards are expected to offer clinical in LRI Release 1 and harmonizes
Standard: Clinical Decision Support and operational improvements for interoperability requirements with other
Knowledge Artifact Specification, quality improvement over existing laboratory standards we proposed to
standards. These commenters also adopt in this final rule (e.g., the HL7
Release 1.2 DSTU (July 2014) (‘‘HeD

standard Release 1.2’’) 141 and to require stated that they expect health IT Version 2.5.1 Implementation Guide:
developers and providers to dedicate S&I Framework Laboratory Orders from
health IT to demonstrate it can
electronically send and receive a CDS 142 http://www.hl7.org/documentcenter/public/
EHR, DSTU Release 2, US Realm, 2013).
artifact formatted in the HeD standard We proposed that a Health IT Module
standards/dstu/HL7_DSS_IG%20_R1_1_
2014MAR.zip. would be required to display the
141 http://www.hl7.org/implement/standards/ 143 http://wiki.siframework.org/ following information included in
product_brief.cfm?product_id=337. Clinical+Quality+Framework+Initiative. laboratory test reports it receives: (1)
The information for a test report as EHR–S Functional Requirements LRI providers’’ criterion (§ 170.314(b)(6)).
specified in 42 CFR 493.1291(a)(1) IG/Testing and Certification We stated that we renamed the criterion
through (a)(3) and (c)(1) through (c)(7); Requirements—Request for Comment to more clearly indicate its availability
the information related to reference We sought comment on the HL7 EHR– for the certification of health IT used by
intervals or normal values as specified S Functional Requirements for the any laboratory. We proposed to adopt
in 42 CFR 493.1291(d); the information V2.5.1 Implementation Guide: S&I and include the HL7 Version 2.5.1
for alerts and delays as specified in 42 Implementation Guide: S&I Framework
Framework Lab Results Interface R2,
CFR 493.1291(g) and (h); and the Lab Results Interface, Draft Standard for
Release 1, US Realm, Draft Standard for
information for corrected reports as Trial Use, Release 2, US Realm (‘‘LRI
Trial Use, Release 1 (‘‘EHR–S IG’’),
specified in 42 CFR 493.1291(k)(2). We Release 2’’) in the criterion and
under ballot reconciliation with HL7 144
also proposed to require a Health IT discussed our rationale for its inclusion
in describing the requirements related to
Module to be able to use, at a minimum, in the 2015 Edition ‘‘incorporate
the receipt and incorporation of
LOINC® version 2.50 as the vocabulary laboratory tests and values/results.’’ We
laboratory results for measuring
standard for laboratory orders. further explained that inclusion of this
conformance of a Health IT Module to
standard for certification should not
Comments. We received mixed LRI Release 2. We also requested only facilitate improved interoperability
comments on this proposed certification comment on uniform testing and of electronically sent laboratory test
criterion. Some commenters generally certification approaches, specifically for reports, but also facilitate laboratory
supported adopting the LRI Release 2 the EHR–S IG. compliance with CLIA as it relates to
IG. Other commenters also expressed Comments. Commenters stated that the incorporation and display of test
support for inclusion of LOINC©. One while progress has been made with the results in a receiving system. We also
commenter pointed out potential issues EHR–S IG, the standard has not yet been proposed to require a Health IT Module
with the use of LOINC© as its use may finalized and remains unproven. One to be able to use, at a minimum,
conflict with CLIA reporting commenter requested that we consider LOINC® version 2.50 as the vocabulary
requirements for the test description this IG for inclusion in a later edition of standard.
and that in some cases a textual certification. Some commenters noted Comments. We received similar
description from the laboratory must be that the functional requirements would comments to those received for the
displayed for CLIA reporting. This only govern a Health IT Module’s ability proposed ‘‘incorporate laboratory tests
commenter encouraged the to receive specific laboratory result and values/results’’ certification
harmonization of requirements with content, and there is no corresponding criterion described above (i.e., some
CMS and CDC for CLIA reporting to guarantee that a laboratory system will general support for adoption and other
eliminate potential conflicts. Some send well-formatted results using the commenters expressed concern). In
commenters expressed concerns that the EHR–S IG. Another commenter regard to expressed concerns, as recited
proposed LRI Release 2 IG was recommended that additional State under ‘‘incorporate laboratory tests and
immature and noted additional pilots variation and certification needs be values/results’’ certification criterion,
and potential refinements should be accounted for in the IG. A commenter commenters stated that the proposed
pursued before requiring adoption of the stated that the HL7 Allergies and LRI Release 2 IG was immature and
IG for certification. Intolerances Workgroup 145 will noted additional pilots and potential
produce standards on allergies and refinements should be pursued before
Response. We have not adopted this intolerances and that these standards requiring adoption of the IG for
certification criterion as part of the 2015 should be utilized in expanding a future certification. Commenters also
Edition at this time. We have made this or revised version of the EHR–S IG to expressed concern with the use of
determination based on a number of addresses genotype-based drug LOINC© in relation to CLIA
factors, including (among other aspects) metabolizer rate information requirements. One commenter requested
that this criterion is no longer appropriately. that data provenance requirements be
referenced by the EHR Incentive Response. We thank commenters for included in the standard and/or the
Programs and that the best versions of their feedback. We have not adopted the criterion.
the IGs (LRI and EHR–S Functional EHR–S IG primarily because we have Response. We have not adopted this
Requirements for LRI) that could be not adopted this certification criterion. certification criterion as part of the 2015
associated with this criterion are not We also agree with commenters that the Edition at this time. We have made this
sufficiently ready. We agree with IG is not yet ready for adoption. The determination based on the same factors
commenters regarding the LRI Release 2 comments we received will be used to recited for the proposed 2015 Edition
IG lack of readiness for widespread inform any future rulemaking related to ‘‘incorporate laboratory tests and
adoption. We believe, however, that LRI Release 2 and EHR–S IG. values/results’’ certification criterion as
there is great promise and value in the • Transmission of Laboratory Test this criterion is similarly situated as
LRI Release 2 IG for improving the Reports discussed below. This criterion is no
interoperability of laboratory test We proposed to adopt a 2015 Edition longer referenced by the EHR Incentive
results/values, the electronic exchange ‘‘transmission of laboratory test reports’’ Programs and the best version of the LRI
of laboratory test results/values, and certification criterion that was revised IG that could be associated with this
compliance with CLIA for laboratories. in comparison to the 2014 Edition criterion is not sufficiently ready. We
To that end, we emphasize that we ‘‘transmission of electronic laboratory agree with commenters regarding the
remain committed to continued tests and values/results to ambulatory LRI Release 2 IG lack of readiness for
collaboration with stakeholders to take widespread adoption. We believe,

the necessary steps to support 144 http://www.hl7.org/participate/ however, as stated under the
widespread adoption of this IG, onlineballoting.cfm?ref=nav#nonmember. Access to ‘‘incorporate laboratory tests and
including the availability of test tools the current draft of the EHR–S IG is freely available values/results’’ certification criterion
for review during the public comment period by
for industry use. As necessary and establishing an HL7 user account. response to comments, that there is
feasible, we also remain interested in 145 http://www.hl7.org/implement/standards/ great promise and value in the LRI
supporting appropriate pilots for the IG. product_brief.cfm?product_id=308. Release 2 IG for improving the
interoperability of laboratory test Comments. Some commenters • SOAP Transport and Security
results/values, the electronic exchange supported the concept of health IT being Specification and XDR/XDM for Direct
of laboratory test results/values, and compatible with accessibility Messaging
compliance with CLIA for laboratories. technology. Conversely, other We proposed to adopt a 2015 Edition
To that end, we emphasize that we commenters stated that complying with ‘‘SOAP Transport and Security
remain committed to continued the criterion would be burdensome and Specification and XDR/XDM for Direct
collaboration with stakeholders to take would effectuate policy that should not Messaging’’ certification criterion that
the necessary steps to support be part of certification. A few included the capability to send and
widespread adoption of this IG, commenters contended that text-to- receive according to the Transport and
including the availability of test tools speech capabilities would be costly to Security Specification (also referred to
for industry use. As necessary and implement organization-wide and are as the SOAP-Based Secure Transport
feasible, we also remain interested in not frequently appropriate for many RTM) and its companion specification
supporting appropriate pilots for the IG. health care workflows, particularly XDR and XDM for Direct Messaging
• Accessibility Technology when considering privacy issues. A few Specification. We noted that we
Compatibility commenters suggested that this criterion previously adopted these capabilities for
We proposed to adopt a new 2015 should include other assistive the 2014 Edition at § 170.314(b)(1),
Edition ‘‘accessibility technology technology beyond screen readers. One (b)(2) and (h)(3).
commenter stated that many operation Comments. We received comments in
compatibility’’ certification criterion
systems are already equipped with support of the proposed certification
that would offer health IT developers
accessibility features. criterion. One commenter suggested that
that present a Health IT Module for
Response. We thank commenters for support of XDM should be eliminated
certification to one or more of the
their feedback. We have not adopted and replaced with a translation solution.
clinical, care coordination, and patient
this certification criterion as part of the We received also received a number of
engagement certification criteria listed
2015 Edition at this time. We believe comments from the Immunization
in proposed § 170.315(a), (b), or (e) the
additional research is necessary into the Information System (IIS) community
opportunity to have their health IT
appropriate accessibility technologies noting their reliance on SOAP as the
demonstrate compatibility with at least
that should be referenced by such a recommended transport mechanism for
one accessibility technology for the exchange of immunization information
criterion and could be supported by a
user-facing capabilities included in the in many jurisdictions.
testing infrastructure.
referenced criteria. By ‘‘opportunity,’’ We also believe further research or Response. We thank commenters for
we noted that we meant that the evidence is needed to determine their feedback. We have not adopted
proposed criterion would be available whether customers would make this certification criterion as part of the
for certification but not required (i.e., by purchasing decisions based on whether 2015 Edition at this time. The SOAP
the ONC Certification Program or the a health IT product was certified as specification was originally adopted as
EHR Incentive Programs). We explained being compatible with a text-to-speech an alternative to, or for use in
that to meet this proposed certification technology or simply based on whether conjunction with, the Direct Project
criterion, a Health IT Module would a health IT product is compatible with specification. The goal was to offer more
need to demonstrate that the capability the desired accessibility technology certified ways to support the EHR
is compatible with at least one (e.g., Braille capability). In this regard, Incentive Program Stage 2 meaningful
accessibility technology that provides we did not propose that health IT must use transition of care/exchange measure,
text-to-speech functionality to meet this have certain accessibility capabilities which required the use of certified
criterion. We noted that an accessibility beyond text-to-speech and, more technologies in the transmission of
technology used to meet this criterion importantly, that it must be certified to health information. There is no longer
would also not be ‘‘relied upon’’ for this criterion. Therefore, we have not an explicit need for certification to
purposes of § 170.523(f). However, we adopted the proposed criterion. SOAP because the corresponding health
stated that it would need to be We do, however, believe that information exchange objectives in the
identified in the issued test report and certification can currently support the EHR Incentive Programs Stage 3 and
would ultimately be made publicly accessibility of health IT through other Modifications final rule published
available as part of the information means. As such, we have adopted the elsewhere in this issue of the Federal
ONC–ACBs are required to report to proposed ‘‘accessibility-centered Register permit any transport
ONC for inclusion on the CHPL so that design’’ certification criterion. We refer mechanism (i.e., not necessarily the use
users would be able to identify the readers to section III.A.3 of this of a certified transport method). In
accessibility technology with which the preamble for further discussion of this addition, as part of SOAP testing under
certified Health IT Module criterion. Independent of this the ONC Health IT Certification
demonstrated its compatibility. certification requirement, we remind Program, only base SOAP standards,
We sought comment on the extent to health IT developers seeking such as the web services standards (WS-
which certification to this criterion certification and providers using *) are tested. For implementation,
would assist in complying with Section certified health IT of their independent health IT systems have to layer in
504 of the Rehabilitation Act of 1973 (29 obligations under applicable federal additional profiles (IHE based such as
U.S.C. 794) and other applicable federal civil rights laws, including Section 504 XDS) and IGs (e.g., NwHIN specs for
(e.g., Section 508 of the Rehabilitation of the Rehabilitation Act, Section 1557 patient discovery, query for documents,
Act of 1973) and state disability laws. of the Affordable Care Act, and the and retrieve documents) that utilize
We also sought comment on whether Americans with Disabilities Act that SOAP. The current testing for SOAP
certification to this criterion as require covered entities to provide does not test for these additional
proposed would serve as a valuable individuals with disabilities equal standards since there has not been a
market distinction for health IT access to information and appropriate convergence in the industry for a
developers and consumers (e.g., ‘‘Health auxiliary aids and services as provided concise set of IGs. Thus, the current
IT Module with certified accessibility in the applicable statutes and testing of SOAP does not provide the
features’’). regulations. rigor or assurance to health IT users that
systems using SOAP will ultimately processing responses according to the • Healthcare Provider Directory—
enable them to exchange seamlessly. We IHE HPD Profile. Query Response
expect the convergence on standards Comments. Many commenters We proposed to adopt a new
will be accomplished through SDOs. confirmed the value of provider certification criterion that would focus
In response to the XDM comment, we directories and the ability for EHRs to on the ‘‘query response’’ and include
had paired the ‘‘XDR/XDM for Direct’’ query a provider directory. Most the corresponding set of capabilities to
with SOAP to enable the testing of commenters stated that the proposed respond to a provider directory query.
SOAP with XDR using XDM packaging. IHE HPD standard was immature and This proposed criterion was intended to
had few current implementations complement the certification criterion
While the comments from the IIS
beyond pilot projects, with some we proposed for adoption related to
community are beyond the scope of this
commenters expressing concern about health IT issuing a healthcare provider
proposal, we note for clarity that
the costs associated with potential directory ‘‘query request,’’ and we
consistent with the approach under the
changes as the standard matures. Other explained that the proposed separation
EHR Incentive Programs Stage 2 final
commenters expressed concern with would provide developers with the
rule (77 FR 53979), in the EHR Incentive
potential performance issues related to flexibility to test and certify for provider
Programs Stage 3 and Modifications
federated queries as well as the directory ‘‘query’’ independent of the
final rule published elsewhere in this
potential to proliferate redundant data. provider directory ‘‘response.’’ We
edition of the Federal Register, CMS
Commenters also noted, to ensure stated that a health IT system would be
adopts flexibility with respect to the
quality data, there needs to be: able to be presented for testing and
public health and clinical data registry
Centralized directories; a governance certification to both proposed
reporting objectives at
model for a centralized approach; and certification criteria if applicable or just
§ 495.316(d)(2)(iii). This policy allows
uniform directory sharing strategies to one or the other as appropriate based
states to specify the means of
among providers, organizations, and on the product’s capabilities.
transmission of public health data, and We proposed that directory sources
otherwise change the public health intermediaries. A commenter
recommended the S&I Framework must demonstrate the capability to
agency reporting objective, so long as respond to provider directory queries
the state does not require functionality revisit consider expanding the scope of
the use cases for provider directories according to the IHE HPD profile and
greater than what is required under the must respond to the following provider
Medicare EHR Incentive Program and any solutions beyond query and
response to include the maintenance of directory queries: Query for an
CEHRT definition and the 2015 Edition individual provider; query for an
certification criteria adopted in this provider directories.
Some commenters stated a preference organizational provider; and query for
final rule. relationships between individual
for an approach that utilized a RESTful
• Healthcare Provider Directory— providers and organizational providers.
architecture, such as FHIR, noting that
Query Request In addition we proposed including an
a service stack utilizing SOAP protocols
We proposed a new 2015 Edition optional capability within this
(as used by the IHE HPD protocol) is
‘‘healthcare provider directory—query certification criterion to address
more difficult to implement and
request’’ certification criterion that federated requirements that would
maintain.
would require a Health IT Module to be require a Health IT Module to follow the
Response. We thank commenters for
capable of querying a directory using approved federation option of for IHE
their feedback and appreciate their
the Integrating the Healthcare Enterprise HPD to accomplish querying in
comments in supporting the use of
(IHE) 146 Healthcare Provider Directory federated environments. The federation
provider directories. We have not
(HPD).147 In addition, we proposed change proposal was approved in
adopted this criterion as part of the 2015
including an optional capability within September, 2014 and was incorporated
Edition at this time. As noted in the
this certification criterion that addresses into the IHE HPD Profile.
draft ONC 2015 Interoperability Comments. Commenters submitted
federated requirements. This optional Standards Advisory (draft ISA), the IHE
capability would require a Health IT the same or equivalent comments as
HPD Profile is a provider directory those submitted on the proposed
Module to follow the approved standard and was listed as the best
federation option of IHE HPD 148 to ‘‘healthcare provider directory—query
available standard in the draft ISA.149 request’’ certification criterion, which
accomplish querying in federated However, we agree with commenters
environments. The proposed are described above.
that the IHE HPD standard requires Response. We have not adopted this
certification criterion sought to establish further implementation to ensure criterion for reasons specified in our
a minimum set of queries that a Health stability and support widespread response above for the proposed
IT Module could support. We specified adoption and the same is true for the healthcare provider directory—query
that the capabilities required by a federated concepts. We also agree with request’’ certification criterion.
Health IT Module would include: (1) commenters that RESTful solutions are • Electronic Submission of Medical
Querying for an individual provider; (2) being defined and may be a viable Documentation
querying for an organizational provider; alternative in the near future. We note We proposed to adopt a new 2015
(3) querying for both individual and that HHS remains committed to Edition ‘‘electronic submission of
organizational provider in a single advancing policies related to provider medical documentation’’ (esMD)
query; (4) querying for relationships directories as a means of furthering certification criterion that focused on
between individual and organizational health information exchange and the electronic submission of medical
providers; and (5) electronically interoperability. We believe that documentation through four specific
continued work in this space can inform capabilities.
146 http://wiki.ihe.net/index.php?title=
the development and implementation of We proposed Capability 1 would
Healthcare_Provider_Directory. provider directory standards for
147 http://www.ihe.net/uploadedFiles/Documents/
require a Health IT Module be able to
ITI/IHE_ITI_Suppl_HPD.pdr.
consideration in future rulemaking. support the creation of a document in
148 http://www.ihe.net/uploadedFiles/Documents/ accordance with the HL7
ITI/IHE_ITI_Suppl_HPD.pdf. 149 http://www.healthit.gov/standards-advisory. Implementation Guide for CDA Release
2: Additional CDA R2 Templates— of 2002 (FISMA),152 and Federal Bridge the sender and ensure that the recipient
Clinical Documents for Payers—Set 1, Certification Authority (FBCA) can validate that the authenticity and
Release 1—US Realm in combination requirements.153 For the purposes of integrity of the transaction information,
with the C–CDA Release 2.0 standard. testing and certification, we proposed and it is not intended to replace the
We proposed to adopt the most recent that cryptographic module requirements digital signature requirements defined
version of the CDP1 IG, which is must be met through compliance in either Capability 2 or 3 above.
designed to be used in conjunction with documentation, and the remaining Comments. A few commenters
C–CDA Release 2.0 templates and makes capabilities listed in the Proposed Rule expressed support for this criterion.
it possible for providers to exchange a would be met through testing and However, many more commenters
more comprehensive set of clinical certification assessment. We also expressed concerns. Commenters stated
information. We explained that a Health proposed that a Health IT Module must that the IG was immature, there had
IT Module must be able to create a demonstrate the ability to validate a been few pilots, and it was not proposed
document that conforms to the CDP1 digital signature embedded in a C–CDA as required for Stage 3 of the EHR
IG’s requirements along with Release 2.0 document that was Incentive Programs. A few commenters
appropriate use of nullFlavors to conformant with the DSDR IG. The also expressed concern about advancing
indicate when information is not requirements proposed to perform this a digital signature standard that may
available in the medical record for action are included in the DSDR IG. conflict with the existing Drug
We proposed Capability 3 would Enforcement Administration (DEA)
section or entry level template required
require a Health IT Module be able to standard for electronic prescribing of
in the CDP1 IG. In addition, we
support the creation and transmission of controlled substances. Other
proposed that a conformant Health IT
‘‘external digital signatures’’ for commenters expressed concerns that the
Module must also demonstrate the documents that may be used to sign any
ability to generate the document level changes to existing administrative and
document for the purpose of both data clinical workflows would be required to
templates as defined in the C–CDA integrity and non-repudiation. The
Release 2.0, including the unstructured integrate esMD at a significant cost and
esMD Initiative defines the resource burden.
document. We proposed a list of the requirements in the Author of Record
applicable document templates within Response. We have not adopted this
Level 1: Implementation Guide; 154 and criterion as part of the 2015 Edition at
the C–CDA Release 2.0 and CDP1 IG we proposed to adopt the IG. We this time. We acknowledge and agree
that would need to be tested and explained that this ‘‘signing’’ capability with commenters’ stated concerns about
certified for specific settings for which is intended for use when the sender of the relative immaturity of the proposed
a Health IT Module is designed: one or more documents needs to ensure standards and recommendations for
(regardless of setting) Diagnostic that the transmitted documents include further industry piloting and
Imaging Report; Unstructured the non-repudiation identity of the implementation to determine the
Document; Enhanced Operative Note sender and ensure that the recipient can usefulness of the standards for meeting
Document; Enhanced Procedure Note validate that the documents have not the stated use cases. We will continue
Document; Interval Document; been altered from the time of signing, to monitor the development and
(ambulatory setting only) Enhanced and it is not intended to replace the implementation of esMD and will
Encounter Document; and (inpatient ability to embed multiple digital consider whether proposing a
setting only) Enhanced Hospitalization signatures in a C–CDA Release 2.0 and certification criterion or criteria to
Document. CDP1 IG document. support esMD is appropriate for a future
We proposed Capability 2 would We proposed Capability 4 would rulemaking.
require a Health IT Module be able to require a Health IT Module to support • Work Information—Industry/
support the use of digital signatures the creation and transmission of digital Occupation (I/O) Data—Request for
embedded in C–CDA Release 2.0 and signatures for electronic transactions for Comment
CDP1 IG documents templates by the purpose of both data integrity and In the Proposed Rule, we requested
adopting the HL7 Implementation Guide non-repudiation authenticity. The esMD that commenters consider what
for CDA Release 2: Digital Signatures Initiative defines the requirements in additional support might be needed for
the Provider Profiles Authentication: health IT developers, implementers, and
and Delegation of Rights, Release 1
Registration Implementation Guide; 155 users to effectively include a
(DSDR IG).150 This DSDR IG defines a
and we proposed to adopt the IG. We certification criterion that would require
method to embed digital signatures in a
explained that this ‘‘signing’’ capability health IT to enable a user to record,
CDA document and provides an
is intended for use when the sender or change, and access (all electronically)
optional method to specify delegation of
recipient of a transaction needs to the following data elements in
right assertions that may be included
ensure that the transmitted information structured format:
with the digital signatures. We proposed
include the non-repudiation identity of • Patients’ employment status and
that for the purposes of certification, the
optional method must be demonstrated 152 http://csrc.nist.gov/drivers/documents/FISMA-
primary activities (e.g., volunteer work);
to meet this certification criterion. The final.pdf. • Patients’ current I/O, linked to one
Proposed Rule listed the requirements 153 http://www.idmanagement.gov/sites/default/ another and with time-stamp, including
that a system used to digitally sign C– files/documents/FBCA%20Certificate%20Policy% start date;
CDA Release 2.0 or CDP1 IG documents 20v2.27.pdf. • Patients’ usual I/O, linked to one
154 http://wiki.siframework.org/file/view/
must meet to create a valid digital another and with time-stamp, including
esMD%20AoR%20Level%201%20Implementation
signature that meets Federal Information %20Guide%20v5%20FINAL.docx/539084894/ start year and duration in years; and
Processing Standards (FIPS),151 Federal esMD%20AoR%20Level%201%20Implementation • Patients’ history of occupation with
Information Security Management Act %20Guide%20v5%20FINAL.docx. a time and date stamp for when the
155 http://wiki.siframework.org/file/view/
history was collected (to note, this is
esMD%20Use%20Case%201%20Implementation
%20Guide%20v24%20FINAL.docx/539084920/
focused on the capability to record a
product_brief.cfm?product_id=375. esMD%20Use%20Case%201%20Implementation history, not a requirement that a history
151 http://www.nist.gov/itl/fips.cfm. %20Guide%20V24%20FINAL.docx. must be recorded or that a patient
history be recorded for a certain System (NAICS) and the Bureau of vocabulary code sets may be
historical period of time). Labor Statistics Standard Occupational appropriate; and
We also solicited public comment on Codes (SOC). Commenters mentioned • The concepts/values we should use
the experience health IT developers and that this work is still underway and to capture U.S. military service or all
health care providers have had in suggested we wait until this standard is uniformed service status. We ask
recording, coding, and using I/O data, available for use before adopting commenters to consider the work of
which included any innovation that is requirements for capture of I/O NIOSH on I/O information as it relates
making I/O data more useful for information through certification. to capturing military service.
providers. Commenters stated that the NAICS/SOC Comments. A large number of
To better understand the health care code set is considered the most commenters suggested that we adopt
needs associated with work data, we authoritative and mature code set. These certification to capture military service.
specifically solicited public comment comments further stated that the Commenters stated that capturing
from health care providers, provider adoption of SNOMED CT® would not information on military service could
organizations, and patients on the align with the NAICS/SOC code set or identify significant occupational
following: the NIOSH tool and, therefore, could exposure risks unique to military
• The usefulness for providers to be potentially create unnecessary burden. service, including overseas deployment
able to access current and usual I/O and Response. We thank commenters for and combat environments. Commenters
related data in the EHR, including the thoughtful feedback. As stated in the stated that capturing a patient’s military
whether additional data elements, such 2015 Edition proposed rule (80 FR service could also ensure that a patient
as work schedule, are useful. 16829), we continue to believe in the receives all the applicable health care
• The usefulness of a history of value of I/O information to provide benefits (e.g., military and veteran’s
positions provided as current I/O, with opportunities for health care providers benefits), s/he is entitled to by alerting
data from each position time-stamped, to improve patient health outcomes for medical professionals to the patient’s
linked, retained, and accessible as part health issues wholly or partially caused service history. Commenters stated that
of the longitudinal patient care by work and for health conditions capturing military service information
(medical) record. whose management is affected by work. could also enable the assembly of a
• Narrative text (vs. codes) for both complete longitudinal record of care for
Our long-term goal is for health care
current and usual I/O. a U.S. service member, including
• CDC_Census codes for both current providers to use I/O information to
merging of health care data from
and usual I/O; available through PHIN assess symptoms in the context of work
different sources.
VADS at https://phinvads.cdc.gov/vads/ activities and environments, inform
Some commenters supported and
SearchVocab.action. patients of risks, obtain information to opposed the collection of non-military
• SNOMED CT® codes for occupation assist in return-to-work determinations service uniformed service status (e.g.,
(current codes or potentially developed and evaluate the health and information service data for U.S. Public Health
codes). needs of groups of patients. Service and National Oceanic and
• Other standards and codes that may Given the feedback about the Atmospheric Administration uniformed
be in use by the health IT industry for immaturity of the standards currently officers) as part of military/uniformed
both current and usual I/O. available for supporting these goals, we service data or collected separately.
Comments. Many commenters have not adopted a 2015 Edition In regard to vocabulary standards for
supported the capture of structured certification criterion for the collection collecting military service information,
industry/occupation (I/O) data in EHRs of I/O information. We are, however, commenters submitted mixed comments
and other health IT systems to improve optimistic about the NIOSH-led effort to on whether SNOMED CT® codes were
patient health outcomes for health develop a tool based on the NAICS/SOC sufficiently detailed and captured the
issues wholly or partially caused by code set and believe that it can provide right types of military service
work and for health conditions whose a much-needed authoritative standard information. Commenters pointed out
management is affected by work. These that can enable the detailed recording of that SNOMED CT® contains some
commenters stated that the structured I/O titles. We intend to monitor the concepts to capture high-level military
capture of I/O information would also development of such a tool and will history, including current or past active
improve interoperability as the consider it and the additional comments military service and combat zone
information being collected today is we received regarding structured service. However, other commenters
largely unstructured. Commenters did, capture of I/O information for future expressed concern that current
however, express a number of concerns rulemaking. SNOMED CT® codes for military history
relating to maturity of available • U.S. Uniformed/Military Service are not detailed enough to be of clinical
standards for representing the Data—Request for Comment value. As an example, commenters
information and the time needed for a To improve coding of military and all noted that while SNOMED CT® can
provider to collect structured I/O uniformed history, we stated in the document general information about
information. In regard to standards, a Proposed Rule that a promising path whether the person served in the
number of commenters suggested that forward would be to add codes to the military, it does not allow for the
the codes currently available in U.S. Extension of SNOMED–CT®. capture of the individual’s specific
SNOMED CT® are not specific enough Therefore, we requested comment on occupation.
to capture the level of I/O detail that the following: Commenters stated that the NIOSH
would be of clinical value. Instead, • Whether a potential certification work on developing a tool for industry
commenters stated that the industry is criterion should be focused solely on and occupation codes as described in
working through a NIOSH-led effort to U.S. military service or all uniformed the ‘‘Work Information—Industry/
develop an interface between health IT service members (e.g., commissioned Occupation Data—Request for
and an I/O coding knowledge engine officers of the USPHS and NOAA); Comment’’ section above would include
that would guide users through • Whether the U.S. Extension of detailed codes for military service
choosing CDC Census I/O titles based on SNOMED–CT® is the most appropriate branch; service status; commissioned,
the North American Industry Coding vocabulary code set or whether other warrant officer, non-commissioned and
enlisted service; and many occupational other categorical clinical findings or Many other commenters also cited
areas. Commenters noted, however, that laboratory-derived data.156 concerns over other CDS alert fatigue,
the NIOSH tool is not expected to be In collaboration with the National poor return on investment, high costs of
able to capture Military Occupational Institutes of Health, we solicited testing, and the staff resources needed to
Specialty (MOS) codes maintained by comment on whether: maintain the CDS in a rapidly evolving
the Armed Forces or areas of service • The 2015 Edition ‘‘medication area with little evidence to show that it
(such as ships, stations, and combat allergy list’’ certification criterion improves overall outcomes or reduces
theaters). should include the capability to costs. A few commenters noted the
integrate genotype-based drug existence of third-party web services
Response. We thank commenters for metabolizer rate information; that provide drug-genome interaction
the thoughtful feedback. As stated in the • the 2015 Edition ‘‘drug-drug, drug- checking functionality that are easily
2015 Edition proposed rule (80 FR allergy interactions checks for CPOE’’ integrated with EHRs.
16830), we continue to believe in the certification criterion or as a separate Response. While we believe in the
value of capturing patient military certification criterion should include value of CDS including drug-drug/drug-
service and other uniformed service pharmacogenomic CDS for ‘‘drug- allergy interaction checks for improving
information. We believe recording U.S. genome interactions;’’ patient safety, we agree that standards
uniformed/military service information • we should offer 2015 Edition are not mature to support incorporating
can have many benefits. It can help in certification for CDS that incorporate a pharmacogenomics data into health IT
identifying epidemiological risks for patient’s pharmacogenomic genotype certification at this point in time. We
patients such as those noted above. It data into the CPOE prescribing process encourage the industry to continue its
can assist in ensuring that a patient with the goal of avoiding adverse work on developing standards for
receives all the health care benefits he prescribing outcomes for known drug- incorporating this information into
or she is entitled to by alerting medical genotype interactions; health IT. We note that we view the use
professionals to the patient’s service • there are certification approaches of pharmacogenomics data in health IT
history, which can facilitate the that could enhance the end-user’s as one of the early tangible products of
coordination of benefits. This (provider’s) adoption and continued use the Precision Medicine Initiative,157 and
information can also increase the ability of health IT implementations that guide intend to monitor and consider
to assemble a longitudinal record of care prescribing through CDS using developments in this field for future
for a U.S. service member, such as by pharmacogenomic data; and rulemaking.
requesting or merging of a patient’s • there are existing or developing
electronic health record stored by the standards applicable to the capture, Privacy and Security Considerations for
Department of Defense, Veteran’s Health storage, display, and exchange of Pharmacogenomics
Administration, and/or another health potentially clinically relevant genomic We solicited comment on whether:
care provider. data, including the pharmacogenomic • We should offer certification for
Our long-term goal is for health care subset. health IT functionality that could
providers to use military service Comments. Most commenters agreed
facilitate HIPAA-compliant sharing of
information to provide better care for on the value of pharmacogenomics data
discrete elements of a patient’s genomic
our nation’s veterans. However, given as an integral part of medicine in the
information from their record to the
the feedback about SNOMED CT and the future, but indicated that the standards
family history section of a relative’s
NIOSH tool under development, we were currently not mature enough to
record;
support this functionality and that it
have not adopted a 2015 Edition
was premature to attempt to include it • the proposed ‘‘data segmentation
certification criterion for military for privacy’’ criteria would provide
service. We plan to continue to work in certification. Commenters noted that
the inclusion of pharmacogenomics data needed health IT functions with respect
with the appropriate stakeholders to to the storage, use, transmission, and
can link variants to changes in drug
develop the appropriate values and code disclosure of genetic, genomic, and
metabolism or response, especially
sets that would enable consideration of pharmacogenomics information that is
when clinical guidelines exist about
a relevant certification criterion in a subject to protections under HIPAA and
dosing for variant carriers and how it
future rulemaking. additional state and federal privacy and
can enable pharmacogenomic-based
• Pharmacogenomics Request for therapeutic recommendations integrated protection laws such as the Genetic
Comment into computerized systems for drug Information Nondiscrimination Act
prescription, automated medication (GINA); 158
Pharmacogenomics data identifies
surveillance, and EHRs. • the proposed ‘‘data segmentation
genetic variants in individuals that alter
In certain instances, commenters for privacy’’ criteria adequately balance
their metabolism or other interactions
supported inclusion of the complex genetic privacy issues, such as
with medications and can lead to
pharmacogenomic variant causing the those related to behavioral health, with
serious adverse events. This information the clinical value of context-appropriate
is being included in an increasing allergy if such information is known for
the patient. However, other commenters availability of a patient’s actionable
number of FDA-approved drug labels. genetic and genomic information;
Health IT that can capture suggested that studies are needed to
prove effectiveness and support • health IT should be required to
pharmacogenomics information could
inclusion of such data. Some apply different rules for the use and
be used to improve patient safety and
exchange of genetic, genome, and
enhance patient outcomes. In the commenters cited drug-drug and drug-

allergy interaction alerts without an pharmacogenomics data based on
Proposed Rule, we stated that to our
appropriate filter as the largest source of different groupings of diseases or
knowledge, in general, health IT has not
alert fatigue in relation to the value. conditions based on the sensitivity of
yet captured genomic and genetic
patient information—the presence of 156 http://www.genomebc.ca/education/articles/ 157 http://www.nih.gov/precisionmedicine/.
clinically significant genomic variants— genomics-vs-genetics/; and http://www.who.int/ 158 http://ghr.nlm.nih.gov/spotlight=thegenetic
in a structured manner such as exists for genomics/geneticsVSgenomics/en/. informationnondiscriminationatgina.
the information, such as those related to • It would not include privacy and Commenters provided varying
behavioral health; and security capabilities and certification recommendations for the criteria that
• there are other factors we should criteria. should be included in the Base EHR
consider for health IT that allows the • It would only include capabilities definition. Some commenters stated that
user to use or disclose genetic to record and export CQM data separating privacy and security
information in a manner compliant with (§ 170.315(c)(1)) and not the other CQM certification criteria from the Base EHR
federal and state privacy laws. capabilities such as import, calculate, definition is overly burdensome or
and ‘‘report to CMS.’’ confusing, or may create security gaps.
Comments. Many commenters noted • It would include the 2015 Edition A commenter recommended that the
privacy concerns stating it is essential to ‘‘smoking status’’ certification criterion ‘‘data export’’ and ‘‘application access to
understand and implement proper as patient demographic and clinical Common Clinical Data Set’’ criteria are
privacy and security requirements health information data consistent with more appropriate as ‘‘modular’’
associated with certified functionalities. statutory requirements.159 certification, rather than as part of the
Commenters indicated certified • It would include the 2015 Edition Base EHR definition. A commenter
functionalities must not lead to ‘‘implantable device list’’ certification suggested that ‘‘drug-drug, drug-allergy
discrimination against individuals or criterion as patient demographic and interaction checks for CPOE’’ criterion
their families who may be at risk of clinical health information data be included in the Base EHR definition
developing future health issues. These consistent with statutory as it is specifically for CPOE, which is
commenters were concerned that there requirements.160 part of the Base EHR definition. Some
is not sufficient technical maturity to • It would include the 2015 Edition commenters rejected the idea of
support privacy protections for genetic ‘‘application access to Common Clinical including the ‘‘implantable device list’’
data, segmented to the genetic data Data Set’’ certification criterion as a criterion in the Base EHR definition,
atom. In particular, commenters were capability to both capture and query while other commenters supported
concerned about behavioral health information relevant to health care inclusion of this criterion and noted that
implications, the risk of revealing latent quality and exchange electronic health this capability would improve care
conditions and providing information information with, and integrate such coordination. A few commenters voiced
on close relatives, and the effect on information from other sources.161 support for the inclusion of the Direct
insurance coverage. In addition to • It would include the proposed 2015 Edge Protocol as an alternative to Direct
privacy concerns, select comments Edition certification criteria that Project. Some commenters
noted ethical and legal implications of correspond to the remaining 2014 recommended that sexual orientation
any gene-related functionality. Some Edition certification criteria referenced and gender identity data be included in
commenters suggested that the features in the ‘‘2014 Edition’’ Base EHR the Base EHR definition.
of the ‘‘data segmentation for privacy’’ definition (i.e., CPOE, demographics, Response. We have renamed the
criteria should be incorporated into any problem list, medication list, current Base EHR definition at § 170.102
inclusion of pharmacogenomic data. medication allergy list, CDS, transitions as the 2014 Edition Base EHR definition
Response. We thank commenters for of care, data portability, and relevant and adopted the 2015 Base EHR
sharing their concerns and feedback. As transport certification criteria). On the definition largely as proposed. In Table
noted above, standards are not mature to inclusion of transport certification 7 below, we list the 2015 Edition
support incorporating criteria, we proposed to include the certification criteria included in the
pharmacogenomics data into health IT ‘‘Direct Project’’ criterion 2015 Edition Base EHR definition. Many
certification at this point in time. We (§ 170.315(h)(1)) as well as the ‘‘Direct of the proposed criteria have been
will continue to consider privacy and Project, Edge Protocol and XDR/XDM’’ revised in response to comments and we
security implications and stakeholder criterion (§ 170.315(h)(2)) as equivalent refer readers to section III.A.1 of this
concerns as they relate to any potential alternative means for meeting the 2015 preamble for a detailed discussion of
future rulemaking for Edition Base EHR definition. those criteria and revisions.
pharmacogenomics data. To note, we Comments. A commenter Since the establishment of the 2014
have adopted the proposed ‘‘data recommended removing the Base EHR Edition Base EHR definition (77 FR
segmentation for privacy’’ criteria (see definition from the 2015 Edition 54263–64), we have tried to limit the
section III.3 of this preamble) and will rulemaking and including it in the EHR criteria included in the Base EHR
further assess and consider its value in Incentive Programs rulemaking. Several definition to those necessary to meet the
the segmentation of individually commenters suggested that we modify HITECH Act requirements and our
identifiable genetic information that is the Base EHR definition to policy goals. In this regard, we have not
protected by federal and state privacy accommodate use of health IT that is included ‘‘drug-drug, drug-allergy
laws as part of any future rulemaking certified to the 2014 Edition and the interaction checks for CPOE’’ criterion
related to pharmacogenomics data. 2015 Edition, stating that this will give in the 2015 Edition Base EHR definition
providers flexibility as they upgrade to just as we did not for the 2014 Edition
B. Definitions 2015 Edition and begin to achieve Stage Base EHR definition (see 77 FR 54264).
1. Base EHR Definitions 3. We have, however, included the
‘‘implantable device list’’ criterion in
We proposed to adopt a Base EHR 159 A Base EHR is the regulatory term we have
this 2015 Edition Base EHR definition
definition specific to the 2015 Edition given to what the HITECH Act defines as a for the reasons stated in the Proposed
‘‘qualified EHR.’’ Our Base EHR definition(s)
(i.e., a 2015 Edition Base EHR Rule (80 FR 16825) and discussed under
include all capabilities found in the ‘‘qualified

definition) at § 170.102 and rename the EHR.’’ Please see the 2014 Edition final rule (77 FR the ‘‘implantable device list’’ criterion
current Base EHR definition at § 170.102 54262) for further explanation. in section III.A.1 of this preamble. We
as the 2014 Edition Base EHR definition. 160 A capability included in the Base EHR
have also included the Direct transport
We proposed a 2015 Edition Base EHR definition, which originates from the ‘‘qualified alternatives for the reasons discussed in
EHR’’ definition found in the HITECH Act.
definition that would differ from the 161 These are capabilities inlcuded in the Base the Proposed Rule (80 FR 16862) and
2014 Edition Base EHR definition in the EHR definition, which originate from the ‘‘qualified under ‘‘transport methods and other
following ways: EHR’’ definition found in the HITECH Act. protocols’’ in section III.A.1 of this
preamble. In response to comments and certification to ensure that its health IT We seek to clarify the 2015 Base EHR
other considerations, the has the applicable privacy and security definition in response to comments.
‘‘demographics’’ certification criterion capabilities in order to be certified. This First, the Base EHR definition is just a
(§ 170.315(a)(5)) now includes sexual is counter to the approach under the definition not a single certified product.
orientation and gender identity as data 2014 Edition Base EHR definition, As noted in 2014 Edition final rule (77
elements, thus including this data in the which puts the onus on the provider to FR 54263), the Base EHR definition may
2015 Edition Base EHR definition. We ensure he/she has health IT certified to be met using multiple Health IT
discuss this further under the the privacy and security criteria Modules. Therefore, to the commenter’s
‘‘demographics’’ certification criterion included in the Base EHR definition. point, Health IT Modules separately
in section III.A.1 of this preamble. We The CQM capabilities noted above as certified to the ‘‘data export,’’
also note that given our decision to split not included in the 2015 Edition Base ‘‘application access’’ criteria, and other
the ‘‘application access to Common EHR definition have, however, been criteria included in the 2015 Edition
Clinical Data Set’’ criterion into three included the Certified EHR Technology Base EHR definition can be combined to
separate criteria, we have accordingly (CEHRT) definition under the EHR meet the definition. Second, we believe
modified the 2015 Edition Base EHR Incentive Programs. We refer readers to the defining of the Base EHR definition
definition to include these three criteria. the next section (‘‘2. Certified EHR should remain in the rulemaking as the
In regard to the lack of inclusion of Technology Definition’’) and Table 4 Base EHR definition is only one part of
privacy and security criteria in the 2015 found in section III.A.3 (‘‘2015 Edition the CEHRT definition and may serve
Edition Base EHR definition, we believe Health IT Certification Criteria other purposes beyond its inclusion in
commenters are confused by our Associated with the EHR Incentive the CEHRT definition and supporting
approach. As discussed in more detail Programs Stage 3’’) of this preamble for the EHR Incentive Programs. Third,
under the ‘‘privacy and security’’ further information and guidance on the with the 2014 and 2015 Base EHR
heading in section IV.C.1 of this relationship of the 2015 Edition Base definitions’ inclusion in the CEHRT
preamble, Health IT Modules presented EHR definition and the 2015 Edition definition and the CEHRT definition’s
for certification to criteria listed in the certification criteria with the CEHRT included flexibility to use both health IT
2015 Base EHR definition and other definition. We also refer readers to the certified to the 2014 and 2015 Editions
2015 Edition certification criteria will be CEHRT definition finalized in the EHR for the specified EHR reporting periods,
subject to the applicable privacy and Incentive Programs Stage 3 and we do not believe there would be a
security criteria for the purposes of Modifications final rule published benefit to developing a single Base EHR
certification. Our new privacy and elsewhere in this issue of the Federal definition that referenced both the 2014
security certification approach places Register as the authoritative source for and 2015 Editions. Rather, we believe
responsibility more clearly on the health the requirements to meet the CEHRT this would cause confusion, particularly
IT developer presenting its product for definition. in relationship to the CEHRT definition.
TABLE 7—CERTIFICATION CRITERIA REQUIRED TO SATISFY THE 2015 EDITION BASE EHR DEFINITION
Base EHR capabilities Certification criteria
Includes patient demographic and clinical health information, such as med- Demographics § 170.315(a)(5).
ical history and problem lists. Problem List § 170.315(a)(6).
Medication List § 170.315(a)(7).
Medication Allergy List § 170.315(a)(8).
Smoking Status § 170.315(a)(11).
Implantable Device List § 170.315(a)(14).
Capacity to provide clinical decision support .................................................... Clinical Decision Support § 170.315(a)(9).
Capacity to support physician order entry ......................................................... Computerized Provider Order Entry § 170.315(a)(1), (2) or (3).
Capacity to capture and query information relevant to health care quality ...... Clinical Quality Measures—Record and Export § 170.315(c)(1).
Capacity to exchange electronic health information with, and integrate such Transitions of Care § 170.315(b)(1).
information from other sources. Data Export § 170.315(b)(6).
Application Access—Patient Selection § 170.315(g)(7).
Application Access—Data Category Request § 170.315(g)(8).
Application Access—All Data Request § 170.315(g)(9).
Direct Project § 170.315(h)(1) or
Direct Project, Edge Protocol, and XDR/XDM § 170.315(h)(2).
Marketing Base EHR definition) (see also 77 FR certified health IT, including ensuring
54273). the public disclosure of certain
In the Proposed Rule, we noted that Comments. A commenter requested information for certified health IT (see
we would continue the same marketing clarification regarding how we § 170.523(k)); the proper use of the
policy that we adopted for the 2014 anticipate ONC–ACBs will monitor the Certified HIT certification mark (see
Edition as it relates to the 2015 Edition use of the term ‘‘Base EHR definition.’’ § 170.523(l)); and responsibilities under
Base EHR definition (i.e., health IT Response. We will maintain this ISO/IEC 17065 (2012) (ISO 17065),162 to
developers would have the ability to policy with the 2015 Edition. We which they are accredited. In regard to
market their technology as meeting the anticipate that ONC–ACBs will continue ISO 17065, section 4.1.3.2 states
2015 Edition Base EHR definition when to monitor health IT developers and ‘‘incorrect references to the certification
their Health IT Module(s) is/are certified their certified health IT as they do now scheme or misleading use of licenses,
to all the 2015 Edition certification with regard to the 2014 Edition Base
criteria included in the 2015 Edition EHR definition. ONC–ACBs have 162 This standard is incorporated by reference in
various oversight responsibilities for 45 CFR 170.599.
certificates, marks, or any other Many commenters suggested that the for health IT that supports care and
mechanism for indicating a product is CEHRT definition should accommodate practice settings beyond those included
certified, found in documentation or use of health IT certified to the 2014 in the EHR Incentive Programs. We
other publicity, shall be dealt with by Edition and health IT certified to the explained the procedural requirement to
suitable action.’’ Consistent with the 2015 Edition as this approach would remove the previous name from the CFR
performance of these responsibilities, give providers flexibility as they and add the new name. We also
we anticipate ONC–ACBs will be able to upgrade to 2015 Edition. Many proposed to change references to the
identify any improper marketing commenters also requested that we ‘‘Common MU Data Set’’ in the 2014
association of certified health IT with work closely with CMS and other Edition (§ 170.314) to ‘‘Common
the ‘‘Base EHR definition.’’ We also note organizations to align any changes to the Clinical Data Set.’’
that any purchaser or other stakeholder CEHRT definition or adoption of Comments. The majority of
may inform us of any alleged improper proposed criteria for inclusion in commenters expressed support for the
marketing association of certified health programs beyond the EHR Incentive name change. One commenter did not
IT with the ‘‘Base EHR definition.’’ Programs. support the name change stating it
Response. We have finalized our would add confusion and lack of
2. Certified EHR Technology Definition proposal to remove the CEHRT continuity. One commenter stated the
We proposed to remove the Certified definition for 2015 certification. As term ‘‘clinical’’ may be too restrictive.
EHR Technology (CEHRT) definition proposed in the EHR Incentive Programs Response. We thank commenters for
from § 170.102, effective with this final Stage 3 proposed rule, a combination of the support for the name change and
rule. We explained that the CEHRT health IT certified to the 2014 Edition have finalized this proposal and related
definition has always been defined in a and 2015 Edition may be used during changes to the CFR. The term ‘‘Common
manner that supports the EHR Incentive EHR reporting periods through calendar Clinical Data Set’’ aligns with our
Programs and would more appropriately year 2017. Table 4 found in section approach to make the ONC Health IT
reside solely within the EHR Incentive III.A.3 (‘‘2015 Edition Health IT Certification Program more open and
Programs regulations to be consistent Certification Criteria Associated with accessible to other types of health IT
with our approach in this final rule to the EHR Incentive Programs Stage 3’’) beyond EHR technology and for health
make the ONC Health IT Certification provides guidance on the relationship of IT that supports care and practice
Program more open and accessible to the 2015 Edition certification criteria
settings beyond those included in the
other types of health IT beyond EHR with the CEHRT definition and Stage 3
EHR Incentive Programs. We believe
technology and for health IT that of the EHR Incentive Programs. We also
‘‘clinical’’ is a suitable descriptor for the
supports care and practice settings refer readers to the EHR Incentive
purpose and context within which the
beyond those included in the EHR Programs Stage 3 and Modifications
Common Clinical Data Set has been
Incentive Programs. We noted that this final rule published elsewhere in this
defined (i.e., for the certification of
removal of the definition should add issue of the Federal Register as the
health IT under the ONC Health IT
administrative simplicity in that authoritative source for the
Certification Program).
regulatory provisions, which EHR requirements to meet the CEHRT
definition (and meaningful use We refer readers to Table 8 below for
Incentive Programs participants must a complete listing of the data included
meet (e.g., the CEHRT definition), objectives and measures). We note that
supplemental guidance documents we in the Common Clinical Data Set and
would be defined within the context of the associated standards.
rulemakings for those programs. We intend to issue with this final rule will
further noted that, as proposed in the also identify the 2015 Edition Vocabulary Standards
EHR Incentive Programs Stage 3 certification criteria necessary to meet
We proposed to revise the definition
proposed rule (80 FR 16767), CMS the CEHRT definition and are associated
to include new and updated standards
would adopt a CEHRT definition in 42 with meaningful use objectives and
and code sets (HL7 Version 3 for sex;
CFR 495.4 that would cover all relevant measures. We further note that we
‘‘Race & Ethnicity—CDC’’ code system
compliance timelines (i.e., specify the intend to work closely with CMS and
in PHIN VADS and the OMB standard
CEHRT definition applicable for each other stakeholders to ensure alignment
for race and ethnicity; RFC 5646 for
year/EHR reporting period) and EHR of the 2015 Edition and CEHRT
preferred language, the September 2014
Incentive Programs requirements. We definition to support settings, use cases,
Release of the U.S. Edition of SNOMED
explained that the CEHRT definition and programs beyond the EHR Incentive
CT® for problems and procedures; the
proposed by CMS would also continue Programs.
February 2, 2015 monthly version of
to point to the relevant Base EHR 3. Common Clinical Data Set Definition RxNorm for medications and
definitions 163 adopted or proposed by medication allergies; and LOINC®
We received general comments on our
ONC and to other ONC-adopted and version 2.50 for laboratory tests). We
overall proposal and comments on the
proposed certification criteria relevant noted that for race and ethnicity a
data and vocabulary standards included
to the EHR Incentive Programs. Health IT Module must be able to
in the proposed definition. We have
Comments. The overwhelming express both detailed races and
divided and responded to the comments
majority of commenters were supportive ethnicities according to the ‘‘Race &
in a similar manner.
of moving the CEHRT definition into the Ethnicity—CDC’’ code system and the
EHR Incentive Programs. One Name Change aggregate OMB code for each race and
commenter requested that we and CMS We proposed to revise the ‘‘Common ethnicity identified by the patient.
identify which certification criteria are MU Data Set’’ definition in § 170.102 We emphasized that the proposed
required for to meet the CEHRT and change the name to ‘‘Common revisions would not change the
definition and be a meaningful user. Clinical Data Set,’’ which aligned with standards, codes sets, and data
163 This is required by the HITECH Act under the
our proposed approach to make the requirements specified in the Common
term ‘‘Qualified EHR’’ and references a
ONC Health IT Certification Program Clinical Data Set for 2014 Edition
foundational set of certified capabilities all EPs, more open and accessible to other types certification and would only apply to a
eligible hospitals, and CAHs need to adopt. of health IT beyond EHR technology and Health IT Module certified to the 2015
Edition certification criteria that CVX code because a mapping from NDC We have not adopted the proposed
reference the Common Clinical Data Set. codes to CVX codes is publicly vital signs criterion as discussed in
Comments. The majority of available. Therefore, for the purposes of section III.A.5 above.
commenters expressed support updating including immunizations in the Comments. Commenters generally
the definition to reflect new and Common Clinical Data Set for 2015 supported the expanded list of proposed
updated standards and code sets. Some Edition certification, immunizations vital signs for the Common Clinical Data
commenters stated that specific versions would be required to be coded Set with concerns on a few items. For
of vocabulary standards may become according to the CVX code set (HL7 systolic and diastolic blood pressure, a
obsolete or superseded and systems Standard Code Set CVX—Vaccines few commenters did not support the
should be permitted to use later Administered, updates through separating out of these from blood
versions. February 2, 2015) and the NDC code set pressure generally as their systems
Response. We thank commenters for (NDC—Vaccine NDC Linker, updates allow both to be collected in one field
their support. We have adopted the through January 15, 2015). with a delineator (e.g., a comma or
proposed data elements and referenced forwards-slash) that can be used to parse
Comments. Multiple commenters
standards for the Common Clinical Data the two fields. A few commenters
expressed concerns with mapping
Set definition. We note that we have suggested that ‘‘body weight measured’’
burden. One commenter stated that the
adopted newer versions of SNOMED specifies the method of measurement
inclusion of immunizations mapped to
CT®, RxNorm, and LOINC® than we and noted that there are other ways that
NDC codes may be problematic as most
proposed as the baseline versions for body weight is collected, such as self-
providers may not include NDC codes
certification. We have also more reporting. There was a lot of concern
when documenting immunizations
specifically identified the CDC Race and over the choice of ‘‘oxygen saturation in
particularly for historical
Ethnicity code set (CDC Race and arterial blood by pulse oximetry’’ and a
immunizations and immunizations few commenters suggested there are
Ethnicity Code Set Version 1.0 (March
received outside the practice setting. multiple ways of collecting pulse
2000)) as compared to the identification
Some commenters commented that IIS oximetry. Commenters noted that BMI is
in the Proposed Rule. We note this code
transmission doesn’t seem to align since typically a calculated value from height
set remains part of the PHIN Vocabulary
IIS transmission is based on HL7 V2 and and weight, and were concerned that
Access and Distribution System (VADS)
not C–CDA R2. users should not be allowed to manually
Release 3.3.9. We refer readers to
section III.A.2.c (‘‘Minimum Standards’’ Response. We have included enter in a BMI as it could be incorrectly
Code Sets) for further discussion of our immunizations in the definition calculated. Last, commenters were
adoption of minimum standards code according to the standards proposed. concerned that mean blood pressure is
sets and our decision to adopt these We note that we have adopted newer not a vital sign typically collected in all
newer versions. We also remind readers versions of NDC and CVX than we provider settings, and is more specific to
that health IT developers may seek proposed as the baseline versions for surgery, ED, and ICU settings.
certification to newer versions than the certification. We refer readers to section Response. We thank commenters for
adopted baseline versions of minimum III.A.2.c (‘‘Minimum Standards’’ Code their feedback. While we have not
standards code sets, unless the Secretary Sets) for further discussion of our adopted the proposed 2015 Edition
specifically prohibits it. adoption of minimum standards code ‘‘vital signs’’ criterion as discussed in
Comments. One commenter requested sets and our decision to adopt these section III.A.5 above, we have included
clarification regarding which codes for newer versions. We do not believe this vital signs in the Common Clinical Data
race and ethnicities are included in the creates an undue mapping burden as Set for certification to the 2015 Edition
Common Clinical Data Set. CDC provides a publicly available consistent with the same vocabulary
Response. Both the CDC Race and mapping of NDC codes for vaccines to standards as specified by the C–CDA
Ethnicity code set in PHIN VADS and CVX codes.164 We also note that these Release 2.1 standard (i.e., vital signs are
the OMB standard for race and ethnicity requirements are to test and certify a exchanged using a LOINC® code, and
are included for certification to the 2015 Health IT Module’s capabilities; and with a Unified Code of Units of Measure
Edition, but only the OMB standard for they do not require a provider to send (UCUM) code for the unit of measure
certification to the 2014 Edition. an immunization using a certain code. associated with the vital sign
Comments. One commenter requested IIS transmission based on HL7 V2 serves measurement). We discuss the list of
clarification if the C–CDA Release 1.1 a different use case than the Common vital signs that must be exchanged in
will be applicable for certification to the Clinical Data Set and the C–CDA, which this manner below, including changes
‘‘Common MU Data Set’’ or the support transitions of care, data export, made in comparison to our proposals.
Common Clinical Data Set. API access, and a patient’s ability to We continue to differentiate between
Response. For the 2014 Edition view, download, and transmit their systolic and diastolic blood pressure as
certification criteria that reference the health information. two distinct vital signs, but note that
Common Clinical Data Set (formerly the Health IT Modules may store and
‘‘Common MU Data Set’’), the C–CDA Vital Signs display the two values in one field as
Release 1.1 is the referenced standard. long as they are exchanged as two
We proposed to include vital signs in
separate fields. We have revised ‘‘body
Immunizations the Common Clinical Data Set according
weight measured’’ to ‘‘body weight.’’ We
to specific LOINC® codes, metadata, and
We proposed to include have revised ‘‘oxygen saturation in
relevant UCUM unit of measures. We
immunizations in the Common Clinical arterial blood by pulse oximetry’’ to
also proposed to offer optional

Data Set for 2015 Edition certification. ‘‘pulse oximetry’’ and will allow
certification to pediatric vital signs as
We noted that the C–CDA Release 2.0 implementers, for the purposes of
part of the Common Clinical Data Set.
could support NDC codes as a testing and certification, to choose the
translational data element, but the CVX 164 http://www2a.cdc.gov/vaccines/iis/
LOINC® code with ‘‘pulse oximetry’’ in
code is required to accompany it. We iisstandards/vaccines.asp?rpt=ndc. See also: http://
its name that best represents the method
stated that it would not be a heavy www2a.cdc.gov/vaccines/iis/iisstandards/ of measurement for exchange. We note
burden to map from an NDC code to a ndc_tableaccess.asp. that we believe that inhaled oxygen
concentration is a necessary guidance provided in C–CDA Release ‘‘goals,’’ and ‘‘health concerns’’ in the
measurement in order to correctly 2.1 for exchanging vital signs. ‘‘Common Clinical Data Set’’ for
interpret the pulse oximetry Comments. Commenters were certification to the 2015 Edition to
measurement, and are including it in generally supportive of the proposed replace the concept of the ‘‘care plan
the list of vital signs for exchange. This optional pediatric vital signs. field(s), including goals and
does not mean that providers are Response. We have adopted the instructions’’ which is part of the
required to capture this measurement pediatric vital signs as proposed for ‘‘Common MU Data Set’’ in the 2014
every time, only that certified Health IT inclusion in the Common Clinical Data Edition. We clarified that we intend
Modules are able to exchange the value Set definition as optional for exchange. ‘‘care plan field(s), including goals and
if present. Last, we have removed BMI We note that as discussed in the 2015 instructions’’ to be a single provider’s
and mean blood pressure from the list Edition proposed rule, CDC documentation of their assessment, plan
of vital signs. recommends the use of these pediatric of treatment, goals, and health concerns
In summary, we require that the vital signs for settings of care in which for the patient, and we stated that this
following vital signs must be exchanged pediatric and adolescent patients are clarification applies for 2014 Edition
as part of the Common Clinical Data Set seen (80 FR 16818–16819) as part of best certification. We proposed this
using a LOINC® code and with a UCUM practices. The availability of a reference clarification to better align with the
code for the unit of measure associated range/scale or growth curve can help terms used in the C–CDA Release 2.0,
with the vital sign measurement: with proper interpretation of the which includes the ‘‘Assessment and
• Systolic blood pressure; measurements for the BMI percentile Plan Section (V2),’’ ‘‘Assessment
• Diastolic blood pressure; per age and sex and weight for age per Section (V2),’’ ‘‘Plan of Treatment
• Body height; length and sex. Thus, we are including Section (V2),’’ ‘‘Goals Section,’’ and
• Body weight; the reference range/scale or growth ‘‘Health Concerns Section.’’ In previous
• Heart rate; curve for each of these two pediatric iterations of the C–CDA, we explained
• Respiratory rate; vital signs as part of the Common that the ‘‘Plan of Treatment Section’’
• Body temperature; Clinical Data Set definition for was called the ‘‘Plan of Care Section,’’
• Pulse oximetry; and certification, and would suggest that which resulted in confusion on whether
• Inhaled oxygen concentration. providers include this information as the information was intended to
We believe this list represents vital appropriate. We note that the C–CDA represent a single encounter or the
signs commonly collected across Release 2.1 standard does allow for synthesis of multiple encounters. For
provider settings today and is a start at including additional clinically relevant that reason, the ‘‘Plan of Care Section’’
defining a minimum set of vital signs, information with vital signs. was proposed to be called the ‘‘Plan of
but note that we will continue to work Treatment Section’’ to indicate that it is
Unique Device Identifier(s) intended to represent a single encounter
with stakeholders to determine and
We proposed to include the Unique and not to be confused with the ‘‘Care
consider if this list should be revised
Device Identifier(s) of a patient’s Plan document template.’’
through a future rulemaking.
Implantable Device(s) for certification to For certification to the 2015 Edition,
Comments. A number of commenters
the 2015 Edition. we proposed to include in the Common
were concerned that UCUM does not Comments. Some commenters were in Clinical Data Set ‘‘assessment and plan
allow for mixing of units, and were agreement with including UDIs, while of treatment,’’ ‘‘goals,’’ and ‘‘health
therefore concerned that a height of 5 other commenters suggested removing concerns’’ data in accordance with the
feet and 6 inches (5′6″) could not be UDIs until more progress has been made C–CDA Release 2.0 ‘‘Assessment and
represented with an associated UCUM with medical device identifier Plan Section (V2)’’ or both the
code for the unit of measure. manufacturers and utilization among ‘‘Assessment Section (V2)’’ and ‘‘Plan of
Response. We note that systems have providers. Treatment Section (V2);’’ the ‘‘Goals
the flexibility to choose how to display Response. We have included UDIs in Section;’’ and the ‘‘Health Concerns
the vital sign measurement. Our the definition and require it be recorded Section.’’ We encouraged health IT
requirement only specifies that the vital in accordance with the ‘‘Product developers to allow for structured
sign measurement must be exchanged Instance’’ in the ‘‘Procedure Activity documentation or tagging that would
using an applicable unit of Procedure Section’’ of the C–CDA 2.1. allow a provider to choose relevant
measurement with a UCUM code. This specificity within the C–CDA will pieces of assessment, plan of treatment,
Therefore, systems could exchange a make this information more easily goals, and health concerns data that
height of 5′6″ as 66 inches or 5.5 feet or retrievable. As discussed in more detail could be synthesized into a
167.64 centimeters using the under the ‘‘implantable device list’’ comprehensive care plan. We noted that
appropriate UCUM code to represent the certification criterion in section III.A.3 all proposed 2015 Edition certification
unit of measure for the measurement. of this preamble, this information leads criteria that reference the ‘‘Common
Note that we provide this as an example to improved patient safety when Clinical Data Set’’ (e.g., the ‘‘ToC’’
only, and leave the decision on the available to providers. By including this criterion) would therefore also require a
appropriate unit of measure to the information in the Common Clinical Health IT Module to be able to capture
developers and providers. As noted in Data Set, a Health IT Module certified ‘‘assessment and plan of treatment,’’
the 2015 Edition proposed rule (80 to criteria referencing the Common ‘‘goals,’’ and ‘‘health concerns’’ data.
FR16818), LOINC provides a translation Clinical Data Set would be capable of Comments. A couple of commenters
table 165 that enumerates UCUM syntax exchanging this information and further expressed concern regarding whether
for a subset of UCUM codes that are facilitating improvements in patient this proposal aligned with the C–CDA
commonly used in health IT that may be safety. standard. One commenter found this
a useful reference for stakeholders. We inclusion to be duplicative since it is
would also suggest that health IT Assessment and Plan of Treatment, captured under ‘‘Care Plan Field(s)’’ and
developers and providers follow the Goals, and Health Concerns ‘‘Problems.’’ A few commenters noted
We proposed to include the that we should clarify the intent of the
165 https://loinc.org/downloads/usage/units. ‘‘assessment and plan of treatment,’’ ‘‘Goals Section’’ and ‘‘Health Concerns
Section.’’ These commenters noted that ‘‘Goals Section;’’ and ‘‘Health Concerns the Common Clinical Data Set
the ‘‘Goals Section’’ and ‘‘Health Section’’). We clarify that we will certify definition.
Concerns Section’’ of the C–CDA Care Health IT Modules to the ‘‘Goals Response. We have not included any
Plan document template provide more Section’’ and the ‘‘Health Concerns of this data in the definition as this was
structure and were originally designed Section’’ from the Care Plan document outside the scope of our proposal and,
to be used with the Care Plan document template for the purposes of meeting the more importantly, inclusion at this time
template. However, other C–CDA Common Clinical Data Set definition.
would not give full consideration to the
document templates, like CCD, allow for Thus, other C–CDA document templates
maturity of related standards, the
health concerns and goals to be such as CCD, Referral Note, and
readiness of health IT developers to
included as a narrative within the Discharge Summary would need to be
exchange this data, the clinical
‘‘Assessment Section (V2),’’ ‘‘Plan of able to exchange the structured ‘‘Goals
relevance of the data, and other
Treatment Section (V2),’’ or Section’’ and ‘‘Health Concerns
Section’’ in order to meet the Common considerations for some of the data such
‘‘Assessment and Plan Section (V2).’’ as any potential privacy and security
Clinical Data Set definition.
Response. We have reviewed the C– concerns. We note, however, that we
CDA 2.1 standard and believe there is Sexual Orientation, Gender Identity, have taken the intermediate step of
no misalignment with our proposal and and Other Data including SO/GI data in the 2015
that it provides the requisite specificity We received recommendations for the Edition ‘‘demographics’’ criterion,
we described in the Proposed Rule (80 inclusion of data in Common Clinical which is a criterion included in the
FR 16872). Therefore, we have adopted Data Set that we did not propose. 2015 Edition Base EHR definition. We
the specific data elements as proposed Comments. Commenters refer readers to section III.A.3 of this
(i.e., ‘‘Assessment Section (V2)’’ and recommended that we include sexual preamble for more information on the
‘‘Plan of Treatment Section (V2)’’ or orientation and gender identity (SO/GI), 2015 Edition ‘‘demographics’’ criterion
‘‘Assessment and Plan Section (V2);’’ military history, and nutritional data in and SO/GI data.
Sex No associated standard. The standard specified in §

170.207(n)(1)- Birth sex must be coded
in accordance with HL7 Version 3 (V3)
Standard, Value Sets for
AdministrativeGender and NullFlavor
attributed as follows:
(1) Male. M
(2) Female. F
Unknown. nullFlavor UNK
Race The standard specified in § The standard specified in § 170.207(f)(2)

170.207(f)(1)- The Office of - CDC Race and Ethnicity Code Set
Management and Budget Standards Version 1.0 (March 2000); and
for Maintaining, Collecting, and
Presenting Federal Data on Race The standard specified in§ 170.207(f)(1)
and Ethnicity, Statistical Policy for each race identified in accordance §
Directive No. 15, as revised, 170.207(f)(2).
October 30, 1997 (see "Revisions to
the Standards for the Classification
of Federal Data on Race and
Preferred The standard specified in § The standard specified in §

Language 170.207(g)(1)- As specified by the 170.207(g)(2)- Request for Comments
Library of Congress, ISO 639-2 (RFC) 5646.
alpha-3 codes limited to those that
also have a corresponding alpha-2
code in ISO 639-1.
ER16OC15.003</GPH>
Problems At a minimum, the standard At a minimum, the standard specified in

specified in§ 170.207(a)(3)- § 170.207(a)(4)- IHTSDO SNOMED
IHTSDO SNOMED CT®, U.S. Edition, September 2015
CT® International Release July Release.
2012 and US Extension to
SNOMED CT® March 2012
Release.
Medication At a minimum, the standard At a minimum, the standard specified in

Allergies specified in§ 170.207(d)(2)- § 170.207(d)(3)- RxNorm, a
RxNorm, a standardized standardized nomenclature for clinical
nomenclature for clinical drugs drugs produced by the United States
produced by the United States National Library of Medicine, September
National Library of Medicine, 8, 2015 Release.
2012 Release.
ER16OC15.004</GPH>
ER16OC15.005</GPH>
Unique Device UDI data not included for 2014 In accordance with the "Product
Identifier( s) Edition certification. Instance" in the "Procedure Activity
(UDis) for a Procedure Section" of the standard
Patient's specified in§ 170.205(a)(4).
Implantable
Device(s) § 170.205(a)(4)- HL7 Implementation
Guide for CDA® Release 2:
Consolidated CDA Templates for

Clinical Draft Standard for Trial
ER16OC15.006</GPH>
Use, Release 2.1.
Unique device identifier is defmed as it

is in 21 CFR 801.3 - means an identifier
that adequately identifies a device
through its distribution and use by
meeting the requirements of 830.20 of
this chapter. A unique device identifier is
composed of:
(1) A device identifier --a mandatory,
fixed portion of a UDI that identifies the
specific version or model of a device and
the labeler of that device; and
(2) A production identifier --a
conditional, variable portion of a UDI
that identifies one or more of the
following when included on the label of
the device:
(i) The lot or batch within which a device
was manufactured;
(ii) The serial number of a specific
device;
(iii) The expiration date of a specific
device;
(iv) The date a specific device was
manufactured;
(v) For an HCT/P regulated as a device,
the distinct identification code required
by 1271.290(c) ofthis chapter.
Implantable device is defined as it is in

21 CFR 801.3- means a device that is
intended to be placed in a surgically or
naturally formed cavity of the human
body. A device is regarded as an
implantable device for the purpose of
this part only if it is intended to remain
implanted continuously for a period of
3 0 days or more, unless the
Commissioner of Food and Drugs
determines otherwise in order to protect
human health.
Goals Not applicable (refer to care plan In accordance with the "Goals Section"
field(s), including goals and of the standard specified in §

instructions - see 170.20
ER16OC15.007</GPH>
Alignment With Clinical Practice Identifier and Product Identifier instead B. Modifications to the ONC Health IT
We requested comment in the of the term ‘‘UDI data.’’ The commenter Certification Program
Proposed Rule on ways in which we can contended that this would align better
with FDA terminology. In the Voluntary Edition proposed
engage the public to keep the Common rule (79 FR 10929–30) we recited our
Clinical Data Set relevant to clinical Response. We thank commenters for
their support. We are adopting the authority and the history of the ONC
practice as the data included in the Health IT Certification Program. The
Common Clinical Data Set may change cross-referenced FDA definitions as
proposed. In regard to the history includes multiple requests for
over time. comment and significant stakeholder
Comments. A commenter suggested recommendation to use the term
‘‘identifiers,’’ we agree that our feedback on making the certification
we limit the use of highly prescriptive program more accessible to health IT
criteria, permitting innovation and terminology related to UDIs should
more closely align with FDA beyond EHR technology and health care
clinical appropriateness to exist within settings and practices not directly tied
‘‘guardrails.’’ Another commenter terminology and the UDI final rule to
prevent any unnecessary confusion. to the EHR Incentive Programs. With
encouraged us to seek input from consideration of stakeholder feedback
provider specialty societies and Therefore, we have revised our
terminology use within this final rule and our policy goals, we attempted to
organizations to ensure the interests of
and refer readers to the ‘‘implantable make the ONC Health IT Certification
clinicians are properly represented,
device list’’ certification criterion Program more open and accessible
including concerns about clinical
discussed earlier in this preamble for through a proposal in the Voluntary
workflows.
further details. Edition proposed rule (79 FR 10918–20)
Response. We thank commenters for
to create ‘‘meaningful use’’ (MU) and
their feedback. We will take these IV. Provisions of the Proposed Rule non-MU EHR Modules. We determined
comments under consideration for Affecting the ONC Health IT that our proposal was not the best
further development and uses of the Certification Program
approach in a subsequent final rule (79
Common Clinical Data Set to support
A. Subpart E—ONC Health IT FR 54472–73). Since that rulemaking,
interoperability, program alignment,
Certification Program the HITPC issued recommendations
and patient care.
We proposed to replace the term supporting certification for care/practice
4. Cross-Referenced FDA Definitions ‘‘HIT’’ with the term ‘‘health IT’’ and to settings beyond the ambulatory and
We proposed to adopt in § 170.102 change the name of the ‘‘ONC HIT inpatient settings.166 In response, we
new definitions for ‘‘Implantable Certification Program’’ to the ‘‘ONC reconsidered how best to structure the
Device,’’ ‘‘Unique Device Identifier,’’ Health IT Certification Program’’ program and make it open and
‘‘Device Identifier,’’ and ‘‘Production wherever these references occur in accessible to more types of health IT,
Identifier’’ as discussed in the Proposed subpart E. In referring to the health IT that supports a variety of care
Rule’s sections for the ‘‘implantable certification program, we noted that the and practice settings, and programs that
device list’’ certification criterion. We term ‘‘health’’ is capitalized. We also may reference the ONC Health IT
proposed to adopt the same definitions proposed to remove § 170.553 Certification Program, including
already provided to these phrases at 21 ‘‘Certification of health information Medicaid and Medicare payment
CFR 801.3 and emphasized that technology other than Complete EHRs programs and various grant programs. In
capitalization was purposefully applied and EHR Modules’’ as no longer the Proposed Rule, we proposed
to each word in these defined phrases relevant due to proposals in the revisions to the ONC Health IT
in order to signal to readers that they Proposed Rule for the ONC Health IT Certification Program to achieve these
have specific meanings. Certification Program that would make goals, including new certification
Comments. Commenters expressed the program more open and accessible criteria for use cases and health care
unanimous support for our proposed to health IT beyond EHR technology.
166 http://www.healthit.gov/facas/sites/faca/files/
approach to cross-reference relevant Comments. Commenters were broadly
TransmittalLetter_LTPAC_BH_Certification.pdf and
FDA definitions. One commenter supportive of these proposals. http://www.healthit.gov/facas/sites/faca/files/
recommended that we use the term Response. We have adopted these HITPC_LTPAC_BH_Certification_
ER16OC15.008</GPH>
‘‘identifiers’’ when referring to Device proposals as proposed. Recommendations_FINAL.pdf.
settings beyond the EHR Incentive commenters requested that we clarify developers from seeking certification to
Programs. what exactly constitutes a Health IT § 170.315(g)(1) or (2) in support of their
Comments. Most commenters Module, saying that deviations in this customers’ and providers’ needs related
supported the increase in scope of definition will lead to inaccurate to the EHR Incentive Programs.
technologies and health care settings to assessments of workload requirements Comments. A commenter stated that
include lab information systems, HISPs, and scope of impact to implement a these criteria and their functionality
HIEs, LTPAC, behavioral health, and specific certification criterion. have been well-established through
pediatrics. Commenters supported Response. We thank commenters for certification to the 2014 Edition
opening the certification program to their feedback. The 2014 Edition ‘‘automated measure calculation’’ and
greater accessibility to more health IT, Release 2 final rule discontinued the ‘‘automated numerator recording’’
allowing for greater flexibility and use ‘‘Complete EHR’’ certification concept certification criteria; and therefore, their
of a variety of health IT products and (see 79 FR 54443–45). ‘‘Complete EHR’’ removal should have minimal effect.
services, and advancing interoperability certification will not be available to the Several commenters voiced support for
beyond narrowly defined EHR 2015 Edition. removal of these requirements. One
technology. Some commenters, The definition of a Health IT Module commenter noted that this change will
however, opposed a more open ONC is any service, component, or not reduce the requirements for
Health IT Certification Program and the combination thereof that can meet the accredited testing laboratories to test nor
use of certified health IT beyond the requirements of at least one certification ONC–ACBs to certify these criteria
EHR Incentive Programs, including criterion adopted by the Secretary (see when a health IT developer elects to
linking forms of Medicare and Medicaid § 170.102). This essentially means any certify a product for use in the EHR
reimbursement to the use of certified type of technology that could be Incentive Programs. A commenter
health IT. certified to one or more certification disagreed with removal of these criteria,
Response. We disagree with the criteria under the ONC Health IT stating that this functionality is
commenters that do not support a more Certification Program. For example, a important for EPs and EHs to meet
open ONC Health IT Certification Health IT Module could be certified to requirements under the EHR Incentive
Program and the use of certified health only the 2015 Edition ‘‘CPOE— Programs and for purposes of their own
IT beyond the EHR Incentive Programs. Medications’’ criterion and the other quality improvement efforts.
We believe the ONC Health IT required mandatory and conditional Response. We have adopted our
Certification Program should be open criteria (i.e., the 2015 Edition ‘‘safety- proposed approach in that we will not
and accessible to more types of health enhanced design,’’ ‘‘quality require ONC–ACBs to certify Health IT
IT, health IT that supports a variety of management system,’’ ‘‘accessibility- Modules to the 2015 Edition
care and practice settings, and programs centered design,’’ and applicable ‘‘meaningful use measurement’’
beyond the EHR Incentive Programs. We privacy and certification criteria). certification criteria. However, the EHR
have finalized provisions and adopted Alternatively, a Health IT Module could Incentive Program Stage 3 and
2015 Edition certification criteria to be certified to practically all the 2015 Modifications final rule includes a
support these goals. As discussed in Edition certification criteria. While we CEHRT definition that will require EPs,
more detail below in regard to appreciate commenters’ requests for eligible hospitals, and CAHs to have
referencing the use of certified health further specificity for the Health IT health IT certified to these criteria in
IT, ONC and HHS continue to encourage Module definition, we believe that this order to meet the CEHRT definition.
the use of certified health IT to support definition affords flexibility for health Accordingly, we encourage health IT
interoperability and health information IT developers and providers in terms of developers supporting providers
exchange across diverse care and what technologies are presented for participating in the EHR Incentive
practice settings, including the linking certification and to what certification Programs or providers’ quality
of certified health IT to reimbursement criteria (e.g., technology provided by a improvement needs to seek certification
under HHS payment programs. HISP that is presented for certification to these criteria as appropriate for their
to the 2015 Edition ‘‘Direct Project, Edge Health IT Modules (e.g., a Health IT
1. Health IT Modules Protocol, and XDR/XDM’’ certification Module is presented for certification to
We proposed to rename EHR Modules criterion (§ 170.315(h)(2)) or an EHR a criterion that supports a Stage 3
as Health IT Modules by removing the technology presented by a developer for objective with a percentage-based
EHR Module definition from the CFR at certification to the 2015 Edition ‘‘CDS’’ measure and the Health IT Module can
§ 170.102 and adding the ‘‘Health IT certification criterion (§ 170.315(a)(9)). meet the ‘‘automated numerator
Module’’ definition. We proposed this recording’’ criterion or ‘‘automated
change to be effective with this final 2. ‘‘Removal’’ of Meaningful Use
measure calculation’’ criterion) for their
rule, and we proposed to make this Measurement Certification
Health IT Module (e.g., the Health IT
change applicable for certification to the Requirements
Module is presented for certification to
2014 Edition and 2015 Edition. We We proposed to not require ONC– a criterion that supports a Stage 3
stated that the proposed change would ACBs to certify Health IT Modules to objective percentage-based measure and
have no substantive impact on the the 2015 Edition ‘‘meaningful use the Health IT Module can meet the
technologies that might be, or have measurement’’ certification criteria ‘‘automated numerator recording’’
been, certified under the ONC Health IT (§ 170.315(g)(1) ‘‘automated numerator criterion or ‘‘automated measure
Certification Program. We also noted recording’’ and § 170.315(g)(2) calculation’’ criterion).
that technologies already certified to the ‘‘automated measure calculation’’). We
2014 Edition as EHR Modules, and their explained that we believe this will make 3. Types of Care and Practice Settings
use to meet the CEHRT definition, the ONC Health IT Certification more We commented in the Proposed Rule
would not be affected by this proposal. accessible to the certification of health that we had proposed a diverse edition
Comments. Many commenters IT for other purposes beyond the EHR of health IT certification criteria with
strongly supported the removal of Incentive Programs. We also capabilities included that could support
‘‘Complete EHR’’ certification in favor of emphasized that this proposed approach a wide range of providers practicing in
modular certification. A couple of would not preclude health IT various settings. We stated that we
anticipated that we would issue general pacemakers), personal health record and practice settings and the proposals
interoperability guidance for the 2015 systems, health and fitness centers, free- to make the ONC Health IT Certification
Edition when it became final, but that standing weight-loss centers. One Program open and accessible to more
we had no plans to independently commenter recommended including types of health IT and health IT that
develop and issue certification ‘‘paths’’ standards and capabilities to include e- supports a variety of care and practice
or ‘‘tracks’’ by care or practice setting signatures to the Home Health and settings, would permit further
(e.g., a ‘‘LTPAC certification’’) because it Hospice Plans of Treatment. referencing and use of certified health
would be difficult to independently Multiple commenters suggested that IT. We proceeded to cite other HHS
devise such ‘‘paths’’ or ‘‘tracks’’ in a modular certification should follow programs that reference certification
manner that was sure to align with other ‘‘tracks’’ or ‘‘pathways’’ for specialists to criteria and the ONC Health IT
relevant programs and specific identify what they need. Some Certification Program (80 FR 16874).
stakeholder needs. We explained that commenters requested that we publish Comments. One commenter
we are best suited for supporting the guidelines as to which criteria are recommended that we not over-specify
development of standards for specific applicable to which care settings. These or over-bundle a singular certification
settings/use cases and providing commenters suggested that criterion that could cause a mismatch
technical assistance to both health IT ‘‘certification tracks’’ could be between what a federal program
developers and providers about the established for each different segment of requires and what is defined as a single
certification criteria, the standards and the provider market (laboratories, criterion. Another commenter
capabilities they include, and the behavioral health, long-term care, etc.) recommended that we allow for at least
processes of the ONC Health IT looking for alignment and 18 months in advance of any
Certification Program. We stated that we interoperability across certification compliance dates for providers and
would welcome working with HHS ‘‘tracks.’’ A commenter questioned how health IT developers to successfully test
agencies, other agencies, or provider we and stakeholders would monitor and deploy required certified health IT,
associations, in identifying the claims that a set of independently stating that an 18-month minimum
appropriate functionality and certified Health IT Modules meet the timeframe is important to ensure that
certification criteria to support their requirements of the path or track. the process provides good design while
stakeholders, including jointly Response. We appreciate the breadth reducing risks to care and safety.
developing specialized certification and diversity of comments on potential Response. We agree with the
‘‘paths’’ or ‘‘tracks.’’ We noted that such future certification criteria that could commenter that it is important to try to
an approach would be consistent with include capabilities to support different properly scope a certification criterion
stakeholder feedback we received care settings and use cases. Consistent so that the capabilities included are
through rulemaking (79 FR 54473–74) with our request for comment in the consistent with current health IT
and the HITPC recommendations for us Proposed Rule, we will carefully technologies and design practices. In
to work with HHS agencies and other consider these suggestions for future this regard, we have separated out
agencies. certification criteria. capabilities that have once been
We sought comment on potential As mentioned in the Proposed Rule proposed or adopted in a single
future certification criteria that could and recited above, we do not intend to criterion (e.g., see the ‘‘CPOE’’ criteria or
include capabilities that would develop certification ‘‘tracks’’ or the ‘‘application access’’ (‘‘API’’)
uniquely support LTPAC, behavioral ‘‘pathways’’ for particular provider criteria).
health, or pediatrics care/practice specialties or settings within this final We also agree with the commenter
settings, as well as other settings. In rule because it would be difficult for us that sufficient lead time must be
particular, we sought comment on to independently devise such ‘‘paths’’ or provided for development, testing,
whether certification criteria focused on ‘‘tracks’’ in a manner that was sure to certification, and implementation before
patient assessments for certain settings align with other relevant programs and certified health IT is required for use.
would be of value to health IT specific stakeholder needs. We are, With this final rule and the EHR
developers and health care providers. however, working with our colleagues Incentive Programs Stage 3 and
Comments. A commenter suggested within HHS to identify capabilities and Modifications final rule, providers and
that patient assessments should not be certification criteria that support other health IT developers have 27 months
included in future certification criteria. programs and use cases. We also before health IT certified to the 2015
A commenter requested that EHR continue to welcome the opportunity to Edition must be used to meet the
certification standards adequately collaborate with representatives from CEHRT definition adopted in the EHR
capture and address data elements different provider and specialties Incentive Programs Stage 3 and
necessary to support the home care societies as well as health IT developers Modifications final rule published
setting—specifically for durable medical to determine what certification criteria elsewhere in this issue of the Federal
equipment prosthetics, orthotics, and and ‘‘tracks’’ could be identified and Register. This timeframe should provide
supplies (collectively, DMEPOS). The developed to support various care and sufficient time for development, testing,
HITPC listed several entities that may practice settings and particular use certification, and implementation of
find certification requirements cases. We do not anticipate monitoring certified health IT. We plan to continue
applicable to them, including pharmacy any developed certification ‘‘tracks.’’ to work with our colleagues in HHS to
information systems, long-term services Rather, we anticipate that a program or ensure that proper lead time is
and support providers (transport, meals, association, as applicable, would considered with respect to the required
care management services, etc.), develop any necessary compliance use of certified health IT.
ambulance providers, blood banks, end- requirements. We continue to support the use of
stage renal disease facilities, free- certified health IT and the ONC Health
standing cancer hospitals, visiting nurse 4. Referencing the ONC Health IT IT Certification Program to support
services, outpatient surgical centers, Certification Program interoperability and health information
telehealth and monitoring, personal We stated in the Proposed Rule that exchange across diverse care and
health devices (e.g. bands, watches, the adoption of proposed criteria that practice settings. To note and building
monitors), biomedical tech devices (e.g., support functionality for different care on the references we cited in the
Proposed Rule, the HHS interoperability for interoperability with health P&S criteria in favor of what we thought
strategy and the encouraged use of information exchanges. would better balance the burden
certified health IT are mentioned in the potentially posed by our rulemaking.
C. Health IT Module Certification
Prospective Payment System and Thus, the P&S criteria were made part
Requirements
Consolidated Billing for Skilled Nursing of the 2014 Edition Base EHR definition
Facilities for FY 2015 proposed rule (79 1. Privacy and Security that all EPs, eligible hospitals, and
FR 45652), the Conditions of We proposed a new approach for CAHs participating in the EHR Incentive
Participation for Home Health Agencies privacy and security (P&S) certification Programs must meet in order to satisfy
proposed rule (79 FR 61185), the CY to the 2015 Edition. In our past the CEHRT definition (meaning each
2016 Home Health Prospective Payment rulemakings, we discussed and provider needed post-certification to
System Rate Update; Home Health instituted two different policy ultimately have technology certified to
Value-Based Purchasing Model; and approaches and sought comment on the P&S criteria).
Home Health Quality Reporting others for ensuring that health IT and Based on recommendations from the
Requirements proposed rule (80 FR providers have privacy and security HITSC, in the Proposed Rule, we
39844), and the End-Stage Renal Disease capabilities while also trying to proposed a revised P&S certification
minimize the level of regulatory burden approach for the 2015 Edition so that
Prospective Payment System, and
imposed on health IT developers. With each certification criterion has a set of
Quality Incentive Program proposed
the 2011 Edition, we included an appropriate P&S ‘‘safeguards’’ that must
rule (80 FR 37852). The required use of
upfront requirement that required be in place. We proposed to require that
certified health IT continues to be Health IT Modules to meet all P&S an ONC–ACB must ensure that a Health
referenced for chronic care management certification criteria as a condition of IT Module presented for certification to
services in CY 2016 Physician Fee certification unless the health IT any of the certification criteria that fall
Schedule final rule (80 FR 41796). developer could demonstrate that into each regulatory text ‘‘first level
Further, the Mechanized Claims certain P&S capabilities were either paragraph’’ category of § 170.315 (e.g.,
Processing and Information Retrieval technically infeasible or inapplicable. § 170.315(a)) identified below would be
Systems (MMIS) proposed rule (80 FR With the 2014 Edition, we eliminated certified to either Approach 1
20464) requires that state MMIS systems the upfront requirement for each Health (technically demonstrate) or Approach 2
align with adopted standards and allow IT Module to be certified against the (system documentation) as follows:
TABLE 9—PROPOSED 2015 EDITION PRIVACY AND SECURITY CERTIFICATION FRAMEWORK
If the Health IT Mod- It will need to be certified to Approach 1 or Approach 2 for each of the P&S certification criteria listed in the ‘‘Approach
ule includes capabili- 1’’ column
ties for certification
listed under: Approach 1 Approach 2
§ 170.315(a) ............ § 170.315(d)(1) (authentication, access For each applicable P&S certification criterion not certified for approach 1, there
control, and authorization), (d)(2) must be system documentation sufficiently detailed to enable integration such
(auditable events and tamper resist- that the Health IT Module has implemented service interfaces for each appli-
ance), (d)(3) (audit reports), (d)(4) cable privacy and security certification criterion that enable the Health IT
(amendments), (d)(5) (automatic log- Module to access external services necessary to meet the privacy and secu-
off), (d)(6) (emergency access), and rity certification criterion.
(d)(7) (end-user device encryption).
§ 170.315(b) ............ § 170.315(d)(1) through (d)(3) and
(d)(5) through (d)(8) (integrity).
§ 170.315(c) ............ § 170.315(d)(1) through (d)(3).
§ 170.315(e) ............ § 170.315(d)(1) through (d)(3), (d)(5),
and (d)(7).
§ 170.315(f) ............. § 170.315(d)(1) through (d)(3) and
(d)(7).
§ 170.315(h) ............ § 170.315(d)(1) through (d)(3).
§ 170.315(i) ............. § 170.315(d)(1) through (d)(3) and
(d)(5) through (d)(8).
We explained that under the P&S proposed Approach 2, we did not a health IT developer would have to
certification framework we proposed, a propose to permit the 2011 Edition redundantly certify products that have a
health IT developer would know exactly policy of allowing for a criterion to be shared security infrastructure.
what it needed to do in order to get its met through documentation that the Response. We appreciate the broad
Health IT Module certified and a criterion is inapplicable or would be support expressed for the proposed
purchaser of a Health IT Module would technically infeasible for the Health IT framework. We have adopted the P&S
know exactly what privacy and security Module to meet. certification framework as proposed. As
functionality against which the Health Comments. Most commenters were recited above and stated in the Proposed
IT Module had to be tested in order to supportive of our proposed P&S Rule, we continue to believe it is not
be certified. We further explained that, certification framework, including the necessary to permit health IT developers
because we explicitly proposed which HITSC. One commenter recommended to attest that certain P&S criteria are
P&S certification criteria would be that we keep the option for a health IT inapplicable or infeasible because we
applicable to the associated criteria developer to attest that a certain security have specified which P&S certification
adopted in each regulatory text ‘‘first criterion is inapplicable or infeasible. criteria are applicable to a Health IT
level paragraph’’ category and also Another commenter was concerned that Module based on the other adopted
2015 Edition certification criteria for exchange functionality for the ‘‘CPOE— three ‘‘API’’ certification criteria as part
which it is presented for certification to laboratory’’ certification criterion. By of the P&S certification framework.
as well as also permitting certification not adopting the content exchange These new criteria are derived from the
through Approach 2. We clarify that functionality (LOI standard), testing and security requirements included in the
Approach 2 provides health IT certification will not involve the proposed ‘‘API’’ criterion in the
developers with the ability to preparation of patient laboratory data Proposed Rule and have been applied
demonstrate through system for transmission consistent with the back to the ‘‘API’’ criteria adopted in
documentation that products share a proposed standards. Therefore, the this final rule.
security infrastructure, giving ‘‘integrity’’ certification criterion We have separated out the ‘‘patient
developers the option to certify the (§ 170.315(d)(8)) does not need to be engagement’’ category (§ 170.315(e)) by
security infrastructure only once. applied to the category of criteria (i.e., criterion to provide clarity and
Comments. Several commenters § 170.315(a)). appropriate application of privacy and
provided feedback suggesting which The application of the ‘‘amendment’’ security capabilities. In this regard, we
2015 Edition P&S certification criteria criterion is not necessary for care do not apply ‘‘end-user device
should apply to each grouping of 2015 coordination. We have made the encryption’’ to the ‘‘secure messaging’’
Edition certification criteria in Table 9 ‘‘amendment’’ criterion applicable to and ‘‘patient health information
above. Commenters recommended that the ‘‘clinical care’’ category of criteria capture’’ criteria as that was not our
we should add the: (i.e., § 170.315(a)). The functionality intention. We have added the new
• ‘‘Integrity’’ certification criterion
certified under the ‘‘clinical care’’ ‘‘trusted connection’’ criteria to the
(§ 170.315(d)(8)) to the clinical
category focuses on data capture and is ‘‘patient engagement’’ category
certification criteria (§ 170.315(a)) due
more appropriate for application of the (§ 170.315(e)) to compliment the
to transmissions of laboratory data per
‘‘amendment’’ criterion, while the ‘‘care revisions we made to the ‘‘VDT’’ and
the proposed ‘‘CPOE—laboratory’’
coordination’’ category focuses on the ‘‘secure messaging’’ criteria as part of
certification criterion (§ 170.315(a)(2));
• ‘‘Amendments’’ certification transmission of health information and the overall P&S certification framework
criterion (§ 170.315(d)(4)) to the care not patient interaction related to and to support the functionality
coordination criteria (§ 170.315(b)) to amending the record. included in the ‘‘patient health
support patient requested amendments; We agree with commenters that the information capture’’ criterion. Please
and ‘‘automatic access time-out’’ criterion see the discussions of these criteria
• ‘‘Automatic access time-out’’ should apply to the clinical quality earlier in this preamble for further
certification criterion (§ 170.315(d)(5)) measures criteria for the reasons details.
to the clinical quality measures criteria provided by the commenters and have In this final rule, we require that an
(§ 170.315(c)) since patient health included it as applicable to § 170.315(c) ONC–ACB must ensure that a Health IT
information is evident in many quality under the P&S certification framework. Module presented for certification to
measurement implementations. As discussed in the ‘‘application access any of the certification criteria that fall
Response. We have not adopted the to Common Clinical Data Set’’ section of into each regulatory text ‘‘first level
commenter’s recommendation to apply this preamble, we have adopted and paragraph’’ category of § 170.315 (e.g.,
the ‘‘integrity’’ certification criterion applied new P&S criteria (‘‘trusted § 170.315(a)) identified in Table 10
(§ 170.315(d)(8)) to the clinical connection’’ (§ 170.315(d)(9) and below is certified to either Approach 1
certification criteria because we have ‘‘auditing actions on health (technically demonstrate) or Approach 2
not adopted the proposed content information’’ (§ 170.315(d)(10)) to the (system documentation) as follows:
TABLE 10—FINAL 2015 EDITION PRIVACY AND SECURITY CERTIFICATION FRAMEWORK

It will need to be certified to Approach 1 or Approach 2 for each of the P&S certification criteria listed in the
If the Health IT Module includes ‘‘Approach 1’’ column
capabilities for certification listed
under: Approach 1 Approach 2
§ 170.315(a) ................................ § 170.315(d)(1) (authentication, access control, and For each applicable P&S certification criterion not
authorization), (d)(2) (auditable events and tamper certified for approach 1, the health IT developer
resistance), (d)(3) (audit reports), (d)(4) (amend- may certify for the criterion using system docu-
ments), (d)(5) (automatic log-off), (d)(6) (emer- mentation sufficiently detailed to enable integration
gency access), and (d)(7) (end-user device with external services necessary to meet the cri-
encryption). terion.
§ 170.315(b) ................................ § 170.315(d)(1) through (d)(3) and (d)(5) through
(d)(8) (integrity).
§ 170.315(c) ................................ § 170.315(d)(1) through (d)(3) and (d)(5) *.
§ 170.315(e)(1) ........................... § 170.315(d)(1) through (d)(3), (d)(5), (d)(7), and
(d)(9)(trusted connection) *.
§ 170.315(e)(2) and (3) ............... § 170.315(d)(1) through (d)(3), (d)(5), and (d)(9) *.
§ 170.315(f) ................................. § 170.315(d)(1) through (d)(3) and (d)(7).
§ 170.315(g)(7), (8) and (9) * ...... § 170.315(d)(1) and (d)(9); and (d)(2) or (d)(10) (au-
diting actions on health information) *.
§ 170.315(h) ................................ § 170.315(d)(1) through (d)(3).

* Emphasis added to identify additions to the framework as compared to the Proposed Rule.
We clarify that of the adopted 2015 criteria specified in § 170.315(g)(1) capabilities included in these criteria,
Edition certification criteria, only the through (6) are exempt from the P&S which do not implicate privacy and
privacy and security criteria and the certification framework due to the security concerns.
In order to be issued a certification, a capabilities of a certification criterion. We noted that paragraph (g) also
Health IT Module would only need to However, it does not ensure the includes a requirement for ONC–ACBs
be tested once to each applicable appropriate implementation of the to certify all Health IT Modules
privacy and security criterion identified capabilities. For example, in the context presented for certification to the 2015
as part of Approach 1 or Approach 2 so of a Health IT Module’s certification to Edition to § 170.315(g)(4) (quality
long as the health IT developer attests the ‘‘VDT’’ criterion (§ 170.315(e)(1)), system management) and (g)(8)
that such privacy and security additional required certification to the (accessibility-centered design). We
capabilities apply to the full scope of ‘‘end-user device encryption’’ criterion explained that the proposed
capabilities included in the requested is intended to apply to the storage certification requirements for
certification, except for the certification actions that the Health IT Module is § 170.315(g)(3) and (4) maintain the
of a Health IT Module to § 170.315(e)(1) programmed to take (i.e., creation of policy approach established with
‘‘VDT’’ and (e)(2) ‘‘secure messaging.’’ temp files, cookies, or other types of certification to the 2014 Edition (see
For each criterion, a Health IT Module cache approaches) and not an § 170.550(f)(2) and (3)), which ensures
must be separately tested to individual or isolated user action to Health IT Modules, as applicable, are
§ 170.315(d)(9) because of the specific save or export a file to their personal certified to these specific safety and
capabilities for secure electronic electronic storage media. quality certification criteria. We also
transmission and secure electronic Comments. A commenter stated that explained that the proposed
messaging included in each criterion, the P&S certification framework is more certification requirement for
respectively. specific than the approach prescribed in § 170.315(g)(6) is associated with the
Comments. We received several the HIPAA Security Rule. Another new ‘‘Consolidated CDA creation
comments requesting clarification on commenter stated that we should not performance’’ criterion we proposed for
our proposal to allow a health IT name specific encryption and hashing the 2015 Edition. We reiterated that the
developer to certify for P&S criteria standards because the information requirement is similarly designed to
using system documentation sufficiently security risk landscape is constantly ensure that Health IT Modules (with
detailed to enable integration with evolving. Consolidated CDA creation capabilities
external services necessary to meet P&S Response. The P&S certification within their scope) are also certified to
certification criteria (Approach 2). One framework focuses on the capabilities of the ‘‘Consolidated CDA creation
commenter requested clarification health IT certified to the 2015 Edition. performance’’ criterion. We noted the
regarding how an ONC–ACB would It is not designed nor could it align with proposed certification requirements for
verify that documentation was sufficient each covered entity’s responsibilities § 170.315(g)(8) were associated with the
to implement the interface. Another under the HIPAA Security Rule, which new ‘‘accessibility-centered design’’
commenter pointed out that interfaces focus on a risk-based approach to criterion we proposed for the 2015
to external systems may carry an security. We note, however, that the Edition, which patterned the
additional cost. Other commenters adoption of health IT certified to the certification approach of the 2014
questioned whether the lack of 2015 Edition under the P&S framework Edition ‘‘quality system management’’
standardized interfaces will lead to may support a provider’s compliance criterion.
security gaps or be an impediment to with the HIPAA Security Rule and other Comments. Commenters supported
information sharing. federal and state privacy and security the proposed revisions to § 170.550.
Response. System documentation for laws. We do not require specific Response. We thank commenters for
Approach 2 requires a clear description standards for encryption and hashing. their support. We have added paragraph
of how the external services necessary Rather, we require any encryption (g) to § 170.550 as proposed with a
to meet the applicable P&S criteria algorithm identified by the National minor cross-reference revision that
would be deployed and used. We note Institute of Standards and Technology points to the 2015 Edition
that Approach 2 is one of two options (NIST) as an approved security function ‘‘accessibility-centered design’’ criterion
that provide health IT developers more in Annex A of the Federal Information codified in § 170.315(g)(5) instead of
certification flexibility. Health IT Processing Standards (FIPS) Publication proposed paragraph (g)(8).
developers and their customers have the 140–2, October 8, 2014.167 For hashing,
discretion to seek certification to the we require any hashing algorithm with D. Principles of Proper Conduct for
approach (Approach 1 or 2) that best security strength equal to or greater than ONC–ACBs
meets their needs, taking into account SHA–2 as identified by NIST as an 1. ‘‘In-the-Field’’ Surveillance and
efficiencies, costs, and security approved security function in that Maintenance of Certification
concerns. We further note that the publication.
actual implementation of privacy and We proposed new requirements for
security capabilities is outside the scope 2. Design and Performance ‘‘in-the-field’’ surveillance and
of certification, but in most instances, is (§ 170.315(g)) maintenance of certification under the
guided by applicable federal and state We proposed to revise § 170.550 to ONC Health IT Certification Program.
privacy and security laws. We are add paragraph (g), which would require The requirements would clarify and
supportive of the unencumbered ONC–ACBs to certify Health IT Modules expand ONC–ACBs’ existing
exchange of health information and note to certain proposed certification criteria surveillance responsibilities, including
that certified capabilities should not be under § 170.315(g). We proposed to the responsibility to perform
implemented in a way that precludes require ONC–ACBs to certify Health IT surveillance of certified capabilities ‘‘in
health information sharing. the field.’’ We explained that in-the-
Modules to § 170.315(g)(3) (safety-

Comments. A commenter requested enhanced design) and § 170.315(g)(6) field surveillance is necessary to
clarification on how a health IT (Consolidated CDA creation provide assurance to customers,
developer could guarantee certain performance) consistent with the implementers, and users that health IT
functionality, particularly end-user requirements included in these criteria. certified on behalf of ONC will continue
device encryption. to meet the requirements of its
Response. Certification ensures that a 167 http://csrc.nist.gov/publications/fips/fips140- certification when it is implemented
Health IT Module can meet the 2/fips1402annexa.psf. and used in a production environment.
Through our proposal, we sought to Comments. We received mixed While ONC–ACBs are already
promote greater consistency, comments on our focus on ‘‘in-the- required to conduct in-the-field
transparency, and rigor in the field’’ surveillance. The commenters surveillance as part of their overall
surveillance of certified capabilities and who supported our focus on surveillance approaches, we agree with
to provide stakeholders with greater surveillance of certified health IT these commenters that establishing
clarity and predictability regarding this capabilities ‘‘in the field’’ expressed more explicit and more rigorous
important aspect of the ONC Health IT strong support for our proposal to define requirements will promote greater
Certification Program. and establish clear and explicit consistency and clarity regarding ONC–
Our proposal defined in-the-field expectations for in-the-field ACBs’ responsibilities for conducting
surveillance and specified certain surveillance. Commenters stated that in-the-field surveillance, which will in
conditions and procedures under which clearer and more rigorous requirements turn improve the reliability and
ONC–ACBs would be required to for in-the-field surveillance would performance of certified health IT and
initiate in-the-field surveillance of promote confidence in certifications help identify and address potential non-
certified Complete EHRs and certified issued on behalf of ONC and conformities.
Health IT Modules. We delineated significantly improve the reliability and Comments. Other commenters, mostly
separate requirements for surveillance performance of certified health IT. One health IT developers, were less
based on complaints or other ONC–ACB specifically endorsed these supportive of in-the-field surveillance.
information about potential non- requirements and our commitment to They cautioned that some factors that
conformities (‘‘reactive surveillance’’) ensure that certified health IT may affect the performance of certified
and for surveillance based on a random capabilities function for providers in health IT—such as how the health IT is
sampling approach (‘‘randomized their local offices and hospitals in the configured, implemented and adopted
surveillance’’). In addition, we specified same manner demonstrated by the by users and integrated with other
certain corrective action plan health IT developer in a controlled health IT components as part of
requirements and procedures that testing environment. Another ONC– complex, local implementations—may
would apply in the context of ACB specifically supported the concept be challenging for ONC–ACBs to
randomized surveillance. ONC–ACBs of in-the-field surveillance in the evaluate or could in some cases be
would also be required to report the context of complaint-based surveillance, beyond the scope of a health IT’s
results of their in-the-field surveillance which has been a focus of the current certification. Some commenters asserted
to the National Coordinator on at least approach to in-the-field surveillance that ONC–ACBs may lack the
a quarterly basis and, separately, to developed through our annual sophistication or expertise to
report corrective action plan surveillance guidance. distinguish certification non-
information to the publicly accessible conformities from other factors that may
Several commenters described
open data CHPL detailed in our separate cause certified health IT to perform
specific challenges they or their
proposal ‘‘Open Data Certified Health IT differently in the field than in a
members had encountered with certified
Product List (CHPL).’’ controlled testing environment. In
To implement the new requirements health IT capabilities that failed to
particular, current certification
for in-the-field surveillance outlined in perform in an acceptable manner when
requirements may be tested with an
the Proposed Rule, we proposed to add implemented in the field. For example,
established workflow (often the health
§ 170.556 (In-the-field surveillance and one commenter stated that it had IT developer’s ‘‘optimal workflow’’) but
maintenance of certification for health witnessed several instances in which made available to users with additional
IT) and amend § 170.503 (ONC–AA certified health IT that had successfully workflow and implementation options.
Ongoing Responsibilities) and § 170.523 demonstrated the ability to send a single According to these commenters, an
(ONC–ACB Principles of Proper standards-compliant continuity of care ONC–ACB unfamiliar with a particular
Conduct). document in a controlled testing variation could incorrectly regard it as
environment could not ‘‘scale’’ and send a non-conformity. Separately, a few
Definition and Principles for In-the- multiple standards-compliant
Field Surveillance commenters asserted that end-users
continuity of care documents when with whom an ONC–ACB would
We proposed to explicitly define in- deployed in a production environment. conduct in-the-field surveillance may
the-field surveillance to mean an ONC– Commenters stated that our proposed lack the necessary skill and knowledge
ACB’s assessment of whether a certified in-the-field surveillance requirements to properly demonstrate certified health
Complete EHR or certified Health IT would help identify and address these IT capabilities, or may be susceptible to
Module to which it has issued a kinds of apparent non-conformities. ‘‘leading questioning’’ (presumably by
certification continues to conform to the Response. We thank these the ONC–ACB conducting the
certification’s requirements when the commenters for their feedback. They surveillance).
health IT is implemented and in use in underscore our view of the importance Response. We appreciate the concerns
the field. This assessment would require of in-the-field surveillance for ensuring raised by commenters and acknowledge
an ONC–ACB to assess the technology’s that providers and other stakeholders that in-the-field surveillance presents
capabilities in a production can rely on certifications issued on unique challenges. However, we
environment and, where applicable, behalf of ONC. This basic assurance disagree with the suggestion that ONC–
would be based on the use of the protects the integrity of the ONC Health ACBs lack the sophistication or
capabilities with protected health IT Certification Program and federal expertise to perform in-the-field
information (PHI), unless the use of test health IT investments because it enables surveillance or to do so in a reliable and
data were specifically approved by the customers, implementers, and users to objective manner.
National Coordinator. We explained that select appropriate technologies and Under the ONC Health IT
such surveillance could be performed capabilities; identify potential Certification Program, ONC–ACBs’
through an in-person site visit or by implementation or performance issues; surveillance approaches must include
remote observation. We solicited and implement certified health IT in a the use of consistent, objective, valid,
comments on these and other predictable, reliable, and successful and reliable methods, subject to the
approaches to in-the-field surveillance. manner. ongoing supervision of the ONC–AA.
(§ 170.503(e)(2)). In addition, the methodologies and approaches. While environment, are too numerous and
requirements for in-the-field these must include, they need not be varied to anticipate or to reduce to
surveillance established by this final limited to, observing the performance of simple rules of universal application.
rule build on those with which ONC– certified capabilities in the field. Thus In light of these complexities, we
ACBs are already familiar, including the in addition to observing how identified the basic principles that
requirements for in-the-field capabilities function in the field, an would guide an ONC–ACB’s
surveillance that have existed since the ONC–ACB might supplement its field surveillance of certified health IT in the
establishment of the Permanent observations with information related to field. (80 FR 16877). In response to
Certification Program in 2011.168 Since the certified technology gleaned from commenters’ requests for additional
that time, it is our experience that ONC– other sources of surveillance, such as clarity, we further elaborate on these
ACBs have become increasingly adept at user surveys, reviewing developers’ principles below. We believe that with
analyzing the performance of certified complaint logs and defect tickets these additional clarifications, the
health IT in the field, including working (including the developer’s root cause principles we have identified will
with developers and end-users to analysis and resolution of tickets), and provide ONC–ACBs with clear and
identify the causes of reported problems attempting to replicate reported predictable guidance and ensure that in-
and to distinguish certification issues problems in a controlled environment. the-field surveillance is conducted in a
from other factors that may affect the These and other appropriate fair, reliable, and consistent manner
performance of certified health IT. For investigative and diagnostic techniques across all health IT products and
all of these reasons, we are confident may help ONC–ACBs more effectively implementations.
that ONC–ACBs will be able to meet target and conduct their field Analysis and Examples of Non-
their responsibilities for conducting in- assessments and inform their overall Conformities in the Field
the-field surveillance. assessments of certified health IT
Comments. Given the unique capabilities in the field. Comments. Some commenters asked
challenges associated with in-the-field We also agree that ONC–ACBs should, us to clarify whether an ONC–ACB’s
surveillance, some commenters where appropriate, involve health IT evaluation of certified health IT
suggested that, in addition to observing developers in their surveillance capabilities in the field must be limited
how certified capabilities operate in a activities. For example, an ONC–ACB to those aspects of the health IT that
production environment, ONC–ACBs could require a health IT developer to were tested in a controlled environment.
should be permitted to use other provide technical assistance to the In this connection, a few commenters
methods to inform their evaluation of ONC–ACB in understanding and stated that certain factors—such as how
technology in the field. For example, the analyzing variations not seen during the certified capabilities are made available
ONC–AA stated that attempting to testing and certification process and to and implemented by users in the
replicate reported problems in a other complexities. ONC–ACBs could field—are beyond the scope of
controlled testing environment may also require or permit health IT certification under the ONC Health IT
provide a better basis for identifying a developers to assist in analyzing and Certification Program and therefore
suspected non-conformity than relying determining the causes of issues, cannot give rise to a ‘‘non-conformity.’’
on in-the-field observations. Separately, provided such assistance does not Response. An ONC–ACB’s assessment
several commenters, including the compromise the ONC–ACB’s of certified health IT in the field is not
ONC–AA, suggested that ONC–ACBs independence or the requirements of its limited to aspects of the technology that
should work closely with health IT accreditation. were tested in a controlled environment.
developers in analyzing complaints and Comments. Several commenters Rather, an ONC–ACB must consider the
requested additional clarity regarding unique circumstances and context in
other information about potential non-
the precise standards that would govern which the certified health IT is
conformities. The commenters stated
an ONC–ACB’s assessment of certified implemented and used in order to
that including developers in the
capabilities in the field. Some properly assess whether it continues to
surveillance process would be
commenters stated that the standards perform in a manner that complies with
important because ONC–ACBs may not
articulated in the Proposed Rule did not its certification.
be familiar with a developer’s particular
provide a sufficiently objective basis for Testing is an important part of an
technology and implementations.
determining that certified health IT, ONC–ACB’s overall analysis of health IT
Moreover, health IT developers may
once implemented, no longer conforms under the ONC Health IT Certification
have internal complaint and quality
to the requirements of its certification. Program. For practical reasons,
management programs that could be
Some commenters requested that we however, testing focuses on particular
leveraged to provide insight into
provide detailed guidance and bright- use cases and necessarily reflects
problems and their causes.
line rules to guide ONC–ACBs in assumptions about how capabilities will
Response. We appreciate these
making these determinations. be implemented and used in practice.
suggestions, which are consistent with
Response. While we understand the Thus while test results provide a
the approach to in-the-field surveillance
desire for bright-line rules, we do not preliminary indication that health IT
we envisioned in the Proposed Rule. We
think it practicable or a useful exercise meets the requirements of its
agree with commenters that the
to attempt to anticipate and prescribe certification and can support the
assessment of certified health IT in a
detailed rules for every conceivable capabilities required by the certification
production environment may require
situation in which an ONC–ACB may criteria to which the technology was
ONC–ACBs to employ a variety of
discover a non-conformity during its certified, that determination is always
168 76 FR 1282 (clarifying our expectation under surveillance of technology in the field. subject to an ONC–ACB’s ongoing
the Permanent Certification Program that an ‘‘ONC– In practice, certified health IT may be surveillance, including the ONC–ACB’s
ACB would focus its surveillance activities on integrated with a wide range of other evaluation of certified capabilities in the
whether the Complete EHRs and/or EHR Modules systems, processes, and people and may field. Indeed, a fundamental purpose of
it has certified continue to perform ‘in the field’
. . . as they did when they were certified.’’); see
be customized and used in many in-the-field surveillance is to identify
also ONC, ONC Health IT Certification Program, different ways. These circumstances, deficiencies that may be difficult to
Program Policy Guidance #13)–01. which are inherent to the production anticipate or that may not become
apparent until after certified health IT is must also comply with additional developer, the developer was solely
implemented and used in a production program requirements as a condition of responsible for implementing routine
environment. That purpose would be certification.170 updates in return for an annual
entirely frustrated if an ONC–ACB’s While these requirements vary based maintenance fee, which the provider
assessment of technology in the field on the specific certification criteria or had paid in full.
were confined to those aspects of the program requirements at issue, all of Based on these facts, the ONC–ACB
technology’s performance specifically them focus on the responsibilities of would find a non-conformity because
delineated in test procedures. health IT developers and those aspects the failure of the certified health IT to
Comments. Several commenters of their technology that they can function as expected was due solely to
stated that, depending on the reasonably influence or control. the actions of the developer that
circumstances, certified health IT that Accordingly, if an ONC–ACB finds that prevented the user from accessing
has been implemented in the field may health IT, as implemented in the field, capabilities to which the health IT was
be unable to demonstrate certified cannot demonstrate required certified.
capabilities for reasons that are beyond capabilities in a compliant manner, the • Scenario B: An ONC–ACB initiates
the health IT developer’s control. For ONC–ACB must determine the reasons in-the-field surveillance of a Health IT
example, users may customize certified for the failure, including the roles of the Module certified to the clinical decision
health IT capabilities in ways that could technology as well as the health IT support certification criterion
not be anticipated by the developer or developer, users, and other parties. If § 170.315(a)(9). The ONC–ACB observes
that conflict with the developer’s the ONC–ACB finds that the developer the use of the capability at a location at
explicit instructions regarding the or its technology were a substantial which it has been implemented. The
proper implementation and cause of the failure, the ONC–ACB ONC–ACB observes as a user
configuration of its technology. These would conclude that the health IT does unsuccessfully attempts to view user
and other factors beyond the control of not meet the requirements of its diagnostic or therapeutic reference
a developer should not, according to certification. By contrast, if the ONC– information for a patient as required by
these commenters, be grounds for a ACB finds that the failure was caused the criterion. Upon further evaluation,
determination of non-conformity. exclusively by factors far removed from the ONC–ACB learns that the provider
Response. We recognize there may be the control or responsibility of the had notified the developer that it did
instances in which certified health IT developer, the ONC–ACB would regard not wish to purchase or sublicense the
cannot successfully demonstrate those factors as beyond the scope of the standard clinical reference information
implemented capabilities for reasons health IT’s certification and would not bundled with the developer’s clinical
that the developer cannot reasonably find a non-conformity. The following decision support technology and
influence or control. We clarify that, as contrasting scenarios provide an requested instead that the developer
discussed below, these circumstances example of these requirements in integrate its technology with the
would be beyond the scope of the health practice. provider’s preferred third-party database
IT’s certification and would not give rise • Scenario A: An ONC–ACB initiates of clinical reference information. The
to a non-conformity. in-the-field surveillance of a Health IT developer agreed to integrate the third-
A non-conformity arises when Module certified to the clinical decision party database information as requested,
certified health IT fails to conform to the support certification criterion at but in writing advised the provider that,
requirements of its certification under § 170.315(a)(9). The ONC–ACB observes because the developer did not have a
the ONC Health IT Certification the use of the capability at a location at sublicensing agreement in place with
Program. Those requirements take which it has been implemented. The the third-party vendor, the provider
several forms and may apply to aspects ONC–ACB observes as a user would be responsible for obtaining and
of the design and performance of unsuccessfully attempts to access user maintaining the necessary licenses for
technology as well as the diagnostic or therapeutic reference access to the third-party vendor’s
responsibilities of health IT developers. information for a patient as required by database. The developer successfully
In particular, certified health IT must be the criterion. The ONC–ACB then integrated the third-party database
able to support the capabilities and uses performs a series of troubleshooting and information as requested, and the
required by applicable certification diagnostic exercises with the provider certified capabilities performed as
criteria, and developers must make such and the developer of the certified Health expected using the third-party database
capabilities available in ways that IT Module. After additional fact-finding information for several months prior to
enable them to be implemented and and analysis, the ONC–ACB concludes the ONC–ACB’s surveillance. However,
used in production environments for that the failure of the technology to at the time of the surveillance, access to
their intended purposes.169 Developers perform as expected was caused by the the third-party database information had
failure to implement a routine update of been temporarily suspended because of
169 Most certification criteria permit technology to the linked referential clinical decision the provider’s failure to pay several
be designed and made available to users in any way support component of the Health IT outstanding invoices from the third-
that meets the outcomes required by the criteria. Module. Under the terms of the party vendor—the result of an oversight
Several certification criteria, however, also in the provider’s accounting
prescribe specific requirements for how certified provider’s agreement with the
capabilities are designed or made available to users. department. Because of the suspension
For example, the safety-enhanced design criterion 170 In addition to the reequirements established in service, the technology, which was
(§ 170.315(g)(3)) requires developers to apply user- by adopted certification criteria, a Complete EHR or otherwise performing as certified, was
centered design processes to the capabilities Health IT Module’s certification is also conditioned unable to retrieve and display user
referenced in that criterion during the design and on the health IT developer’s compliance with
development of certified health IT. Other certain program requirements that are necessary to diagnostic and therapeutic reference
certification criteria require developers to identify the basic integrity and effectiveness of the ONC information.
specific design or performance characteristics of Health IT Certification Program. These Based on these facts, the ONC–ACB
their technology, such as the quality management requirements include, for example, the mandatory would not find a non-conformity
system (§ 170.315(g)(4)) and accessibility-centered disclosure requirements (§ 170.523(k)(1)) and the
design standard or law (§ 170.315(g)(5)) used in the requirements related to displaying the ONC
because, while the technology was
development, testing, implementation, and Certified HIT Certification and Design Mark unable to perform required capabilities
maintenance of the capability. (§ 170.523(1)). in the field, the failure was caused by
factors far removed from the control or Based on these facts, the ONC–ACB practices that limit or interfere with
responsibility of the developer. Indeed, would find a non-conformity. access to certified health IT capabilities.
the developer took care to warn the Specifically, the developer has Response. Under the expanded
provider that, while the technology restricted access to training materials transparency and disclosure
could be customized to support third- and instructions that are needed to requirements at § 170.523(k)(1), which
party database information, the provider access and capability and successfully are discussed in section IV.D.2 of this
would be responsible for maintaining use it to achieve the technical outcomes preamble, a health IT developer must
any necessary licenses for access to the contemplated by § 170.315(b)(6). disclose all known material limitations
third party database information. Indeed, as the scenario illustrates, the and types of costs associated with its
Comments. Some commenters stated restriction effectively prevents a user certified health IT. The failure to
that contractual restrictions or other from using the data export capability at disclose this information is a violation
limitations on the use of a developer’s all. As such, the technology no longer of an explicit certification program
certified health IT should be treated as conforms to the requirements of its requirement (§ 170.523(k)(1)) and thus
a non-conformity, while several other certification. constitutes a non-conformity. The
commenters asked for additional • Scenario D: An ONC–ACB initiates disclosure violation may also give rise
guidance on this issue. in-the-field surveillance of a Health IT to a separate non-conformity in the
Response. As the scenarios above Module certified to the data export event that the failure to disclose the
illustrate, because developers sell and criterion at § 170.315(b)(6). The ONC– required information has substantially
license certified technology in many ACB observes the use of the capability impaired, or would be likely to
different ways and often in conjunction at a location at which it has been substantially impair, the ability of one
with many other related products and implemented. The user is able to or more users (or prospective users) to
services, an ONC–ACB’s evaluation of successfully create a set of export implement or use the developer’s
technology in the field will necessarily summaries for patients in real time but certified health IT in a manner
require a consideration of the manner in is unable to configure the technology to consistent with its certification.
which the developer makes its certified create a set of export summaries based As an example, if the developer in
technology and associated capabilities on a relative time and date (e.g., the first Scenario D above failed to disclose the
available to customers and users, of every month at 1:00 a.m.). The ONC– technical limitation described in that
including a consideration of ACB contacts the health IT developer, scenario, the ONC–ACB would find a
implementation options, contractual which explains that the ability to create non-conformity to the disclosure
terms, and other factors that could affect export summaries based on a relative requirements at § 170.523(k)(1). This
the performance of the capabilities in time and date is an ‘‘advanced determination would be warranted
the field. For example, an ONC–ACB functionality’’ that the developer has because the developer’s failure to
would find a non-conformity were it to disabled by default. The developer will disclose the limitation could
determine that a developer had imposed only enable the functionality if a substantially interfere with the ability of
restrictions or limitations 171 on its customer specifically requests it. a user or prospective user to implement
technology (or the use of its technology) Based on these facts, the ONC–ACB the data export capability in a manner
that substantially interfered with users’ would find a non-conformity. consistent with the technology’s
ability to access or use certified Specifically, the developer has placed a certification to § 170.315(b)(6).172
capabilities for any purpose within the technical limitation on its technology by Given the risk of non-conformity
scope of the technology’s certification, disabling and thus preventing users created by the failure of a developer to
as in the following scenarios. from accessing functionality within the disclose the kinds of material
• Scenario C: An ONC–ACB initiates scope of the technology’s certification to information described above, and the
in-the-field surveillance of a Health IT the data export capability. Indeed, the concomitant requirement for ONC–
Module certified to the data export ability to create a set of export ACBs to evaluate such disclosures in
criterion at § 170.315(b)(6). The ONC– summaries based on a relative time and order to properly evaluate certified
ACB observes the use of the capability date is expressly required by technology in the field, we have
§ 170.315(b)(6)(iii)(B)(2). That a
at a location at which it has been finalized elsewhere in this final rule our
customer must specifically request that
implemented. The ONC–ACB observes proposal to expand and clarify the types
the developer turn on the functionality
as a user unsuccessfully attempts to of information that developers are
is a substantial interference with a
create a set of export summaries using required to disclose as a condition of
user’s ability to access and use this
the required standard for patients whose certification under the ONC Health IT
aspect of the certified capability. As
information is stored in the technology. Certification Program. We discuss these
such, the technology no longer conforms
The ONC–ACB contacts the health IT disclosure requirements in detail in
to the requirements of its certification.
developer, which explains that to utilize Comments. Some commenters asked section IV.D.2 of this preamble,
the data export capability, a user must whether a developer’s failure to disclose ‘‘Transparency and Disclosure
load a series of coded instructions into known material limitations or types of Requirements.’’
the technology using the developer’s costs associated with its certified health For the foregoing reasons, and with
proprietary scripting language. IT would give rise to a non-conformity. the clarifications discussed above, we
However, the developer restricts the Several commenters assumed that it have finalized as proposed the
ability of users to access training would and stated that, together with the definition of in-the-field surveillance at
materials or instructions that would more meaningful transparency and § 170.556(a).
allow them to acquire the necessary disclosure requirements we proposed, Reactive Surveillance
knowledge and expertise to perform this assessing the effect of developers’
function. We proposed to clarify and add to
disclosures on the performance of
ONC–ACBs’ responsibilities for
171 Potential restrictions and limitations are
certified health IT in the field would
discussed in detail in section IV.D.2 of this
promote greater transparency and 172 The ONC–ACB would also find a separate
preamble, ‘‘Transparence and Disclosure reliability of certified health IT non-conformity to § 170.315(b)(6), for the reasons
Requirements.’’ capabilities and help mitigate business explained in connection with Scenario D.
conducting ‘‘reactive surveillance’’— comments summarized below, we are requirements for health IT developers at
that is, surveillance of certified health finalizing the reactive surveillance § 170.523(k)(1).
IT initiated on the basis of complaints requirements at § 170.556(b), subject to Whether reactive surveillance must
or other indications that the health IT the revisions discussed below. The include in-the-field surveillance or may
does not conform to the requirements of revisions address the request from employ other methods is governed by
its certification. We proposed to create commenters for clarification of the the definition and principles for in-the-
an explicit duty for an ONC–ACB to interaction between the proposed field surveillance described earlier in
initiate such surveillance whenever it reactive surveillance requirements and this preamble and codified at
becomes aware of facts or circumstances ONC–ACBs’ existing obligations to § 170.556(a), including the nature of the
that call into question the continued conduct reactive surveillance. suspected non-conformity and the
conformity of a certified Complete EHR The proposed reactive surveillance adequacy of other forms of surveillance
or certified Health IT Module to the requirements focused primarily on an under the circumstances. In most cases,
requirements of its certification ONC–ACB’s duty to initiate surveillance the need to evaluate the certified health
(including conformity both to applicable of certified health IT in the field. IT in the field will be obvious from the
certification criteria as well as to other Specifically, we stated that an ONC– nature of the suspected non-conformity.
requirements of certification, such as ACB would be required to initiate in- For example, if a problem with a
the disclosure requirements at the-field surveillance whenever it certified health IT capability is reported
§ 170.523(k)(1)). Further, we proposed becomes aware of facts or circumstances to arise only in connection with a
that whenever an ONC–ACB initiates that call into question health IT’s specific local implementation option, an
reactive surveillance, it would be continued conformity to the ONC–ACB would likely need to observe
required, as a matter of course, to assess requirements of its certification (80 FR the relevant capabilities in the field in
the health IT developer’s compliance 16878). However, we agree with the order to fully analyze the cause of the
with the disclosure requirements at observation of several commenters that problem and determine whether it is the
§ 170.523(k)(1). requiring ONC–ACBs to initiate in the result of a non-conformity. In other
Comments. Many commenters agreed field surveillance in all cases would be cases, the need for in-the-field
with the proposed requirements for unnecessarily prescriptive. In some surveillance may become apparent only
reactive surveillance. Commenters cases, an ONC–ACB will be able to after other surveillance methods and
stated that strengthening surveillance, investigate and evaluate a putative non- techniques have failed to isolate the
including in-the-field surveillance, conformity just as effectively by using cause of the problem.
based on complaints and other traditional forms of surveillance that do
In-the-field surveillance may also be
information about the real-world not depend on observing certified health
necessary to determine a developer’s
performance of capabilities would IT capabilities in the field. For example,
compliance with certification program
provide greater assurance to providers an ONC–ACB may identify and
requirements, such as the mandatory
that they will in fact be able to substantiate non-conformities through
disclosure requirements at
implement and use the capabilities to conventional desk-audits followed by
§ 170.523(k)(1). While non-compliance
which health IT has been certified. The re-testing of Health IT Modules in a
with these requirements may often be
ONC–AA and ONC–ACBs largely controlled environment. As another
established from complaints and a
supported our proposed reactive example, an ONC–ACB may perform an
review of a developer’s disclosures,
surveillance requirements and urged us audit of a developer’s complaint
to focus primarily on refining this processes to identify potential non- certain kinds of undisclosed limitations
aspect of in-the-field surveillance and compliance with the requirements of on the capabilities of certified health IT
not the proposed randomized ISO/IEC 17065. Similarly, an ONC–ACB may need to be confirmed through in-
surveillance requirements. may audit a developer’s website and the-field surveillance of the technology,
Some commenters, mostly ONC– other communications to identify or may not be discovered at all except
ACBs, sought greater clarity regarding potential non-compliance with the upon observing the operation of
the interaction between the proposed disclosure requirements certified capabilities in the field.
reactive surveillance requirements and (§ 170.523(k)(1)), the Criteria and Terms Comments. A number of commenters
ONC–ACBs’ existing responsibilities for of Use for the ONC Certified HIT asked us to articulate more precise
conducting reactive and other forms of Certification and Design Mark standards for when an ONC–ACB would
surveillance pursuant to the (§ 170.523(l)), or other certification be required to initiate reactive
requirements of their accreditation to requirements. surveillance. Some of these commenters
ISO/IEC 17065 and authorization to Because our intent was to build stated that ONC–ACBs would not be
issue certifications under the ONC upon—not supplant—these traditional able to consistently apply the standard
Health IT Certification Program. forms of surveillance, we have revised set forth in the Proposed Rule, which
Relatedly, several commenters noted the requirements at § 170.556(b) as would require an ONC–ACB to initiate
that the proposed duty to initiate follows. Under § 170.556(b), an ONC– reactive surveillance whenever it
reactive surveillance would require in ACB has a duty to initiate reactive becomes aware of facts or circumstances
all cases that such surveillance take surveillance—including, as necessary, that would cause a reasonable person to
place in the field; these commenters in-the-field surveillance—whenever it question a certified Complete EHR or
regarded this as an overly broad becomes aware of facts or circumstances certified Health IT Module’s continued
requirement that could unnecessarily that would cause a reasonable person to conformity to the requirements of
supplant other forms of ‘‘traditional’’ question a certified Complete EHR or certification.
surveillance that, depending on the certified Health IT Module’s continued Response. As requested by
circumstances, may be more effective conformity to the requirements of its commenters, we provide the following
and less burdensome. certification. Such conformity includes additional guidance on the
Response. We thank commenters for both ongoing conformity to applicable circumstances that would trigger an
their thoughtful comments on this certification criteria as well as ONC–ACB’s duty to initiate reactive
aspect of our proposal. In consideration compliance with other requirements of surveillance under the requirements at
of these comments and the additional certification, including the disclosure § 170.556(b).
In determining whether to initiate and using the data export capability in public health agencies that may not be
reactive surveillance, an ONC–ACB accordance with the requirements of the certified health IT users. All of this
must consider and weigh the volume, certification criterion at § 170.315(b)(6). information would compose the facts
substance, and credibility of complaints We believe the foregoing principles and circumstances of which an ONC–
and other information received against and examples will provide sufficient ACB is aware and is required to
the type and extent of the alleged non- clarity and practical guidance for ONC– consider in determining whether to
conformity, in light of the ONC–ACB’s ACBs regarding their responsibilities for initiate surveillance.
expertise and experience with the conducting reactive surveillance
pursuant to § 170.556(b). If necessary, Randomized Surveillance
particular capabilities, health IT, and
certification requirements at issue. For we will issue additional guidance to In addition to reactive surveillance,
example, if an ONC–ACB receives a ONC–ACBs to assist them in conducting we proposed to require ONC–ACBs to
number of anonymous complaints such surveillance in a consistent, initiate in-the-field surveillance on a
alleging general dissatisfaction with a objective, and reliable manner. ‘‘randomized’’ basis for the certification
particular certified Health IT Module, Comments. A commenter suggested criteria prioritized by the National
the ONC–ACB is not be required to that reactive surveillance should be Coordinator. For those prioritized
initiate surveillance (though it would based solely on complaints submitted certification criteria, an ONC–ACB
not be precluded from doing so). In directly to ONC–ACBs. The commenter would be required each calendar year to
contrast, if an ONC–ACB receives stated that ONC–ACBs ‘‘can’t be randomly select at least 10% of the
several complaints alleging, for expected to keep ears to the ground’’ to Complete EHRs and Health IT Modules
example, that a particular certified monitor the trade press, user group to which it has issued a certification.
Health IT Module is unable to message boards, blogs, analyst reports, The ONC–ACB would then be required
electronically create a set of export and other sources of information, which to initiate in-the-field surveillance of
summaries in accordance with the data may not be credible. Another each such certified Complete EHR or
export certification criterion at commenter asked us to clarify that in certified Health IT Module at the lesser
§ 170.315(b)(6), the ONC–ACB must determining whether to initiate reactive of 10 or 5% of locations at which the
initiate surveillance of the Health IT surveillance, ONC–ACBs would be technology is implemented and in use
Module unless a reasonable person in required to consider complaints from in the field. The locations would be
the ONC–ACB’s position would doubt persons other than providers and users selected at random, subject to certain
the credibility or accuracy of the of certified health IT (such as public sampling considerations and limited
complaints. A reasonable basis for doubt health agencies and other recipients of exclusions described in the Proposed
might exist if the ONC–ACB had electronic health information that may Rule.
not themselves use certified health IT).
recently responded to the very same We stated that randomized
Response. Under the requirements
issue and determined through in-the- surveillance would enable ONC–ACBs
adopted in this final rule, an ONC–ACB
field surveillance of the Health IT has a duty to initiate reactive to identify non-conformities that are
Module at several different locations surveillance whenever it becomes aware difficult to detect through complaint-
that the reported problem was due to a of facts or circumstances that call into based or other reactive forms of
‘‘bug’’ arising from an unsupported use question the continued conformity of surveillance. Randomized surveillance
of the Health IT Module that the health IT to which it has issued a would also enable an ONC–ACB to
developer had specifically cautioned certification. We do not prescribe new detect patterns of non-conformities that
users about in advance. requirements for ONC–ACBs to indicate a more widespread or recurring
An ONC–ACB’s decision to initiate proactively monitor any particular problem requiring a comprehensive
reactive surveillance must also take into source of information (such as the trade corrective action plan. We proposed that
account complaints and other press or user forums), as ONC–ACBs are a pattern of non-conformity would exist
information indicating whether a health already required obtain and synthesize if an ONC–ACB found that a certified
IT developer has disclosed all known information about certified health IT Complete EHR or certified Health IT
material information about certified from multiple sources. Module failed to demonstrate
capabilities, as required by Regardless of the form of the conformity to any prioritized
§ 170.523(k)(1). The failure to disclose information or how it comes to an ONC– certification criterion at 20% or more of
this information calls into question the ACB’s attention, if the information the locations surveilled. Upon such a
continued conformity of those suggests that health IT the ONC–ACB finding, the ONC–ACB would deem the
capabilities because it creates a has certified may no longer conform to certified Complete EHR or certified
substantial risk that existing and the requirements of its certification, the Health IT Module ‘‘deficient’’ and
prospective users will encounter ONC–ACB is required to initiate impose a corrective action plan on the
problems implementing the capabilities surveillance. For example, an ONC– developer of the certified Complete EHR
in a manner consistent with the ACB may become aware of a potential or certified Health IT Module. We
applicable certification criteria. Thus in non-conformity through user surveys specified certain elements and
the example above, if the complaints and other ‘‘behind-the-scenes’’ procedures that would be required for
received by the ONC–ACB suggested surveillance of users and products. Or such corrective action plans.
that the developer knew about but failed an ONC–ACB may become aware of a Comments. We received strong
to disclose the data export issue to potential non-conformity while auditing support for our proposal to require
users, the ONC–ACB would be required a developer’s website and other ONC–ACBs to perform ‘‘randomized’’
to initiate in-the-field surveillance of the disclosures. ONC will also share surveillance as part of their in-the-field
certified Health IT Module to verify information with ONC–ACBs, which surveillance approach. Several
whether the developer had failed to may well come from the trade press and commenters who supported our
disclose known material information other sources. And, of course, an ONC– proposal urged us to minimize the
and, if so, whether the failure to ACB will receive complaints from a associated disruption and other burdens
disclose that information prevented variety of sources, including, as one for providers who participate in
users from reasonably implementing commenter suggested, entities such as randomized surveillance.
A number of commenters—including on complaints and other evidence of ONC–ACB to surveil the technology at
the ONC–AA and the ONC–ACBs— potential non-conformities. Balancing the lesser of 5% or 10 locations, as we
raised concerns regarding this aspect of these considerations, we are persuaded had proposed, could be simultaneously
our proposal. The ONC–ACBs estimated that starting with a less ambitious both burdensome and yet unlikely to
that performing randomized approach to randomized surveillance yield statistically significant or
surveillance on 10% of certified will allow us to refine this aspect of generalizable results. It also reflects our
products, even at the relatively small surveillance over time and will provide recognition, underscored by the
number of locations specified in the the best path to achieving our overall comments, that well-established
Proposed Rule, would as much as goal of strengthening in-the-field methodologies and standards for post-
double the total cost of certification and surveillance and making it more market surveillance used in other
divert an inordinate amount of time and meaningful. industries typically focus on conformity
resources away from other important Accordingly, we have revised the testing of discrete products or
certification and surveillance activities. proposed randomized surveillance components in isolation and thus
Meanwhile, commenters including the requirements as follows. First, we have provide little guidance for formulating
ONC–AA doubted that the proposed reduced the annual sample size for appropriate sampling and statistical
sample size would be sufficient to randomized surveillance. Instead of methods under the ONC Health IT
detect patterns of non-conformities or to 10% of all certified Complete EHRs and Certification Program. Given the lack of
determine with any degree of certified Health IT Modules, an ONC– suitable reference models in other
confidence how widespread a particular ACB must perform randomized industries, we agree with commenters
non-conformity may be. In this surveillance on 2% of certified that this particular aspect of an ONC–
connection, commenters pointed out Complete EHRs or certified Health IT ACB’s randomized surveillance
that surveilling a randomly selected Modules each year. Based on current approach would benefit from additional
certified Complete EHR or certified data on the CHPL, we estimate this experience and piloting. Thus we intend
Health IT Module at the lesser of 10 or could require ONC–ACBs to perform to work with ONC–ACBs and the ONC–
5% of locations at which the technology randomized surveillance of up to 24 AA and issue guidance as necessary to
is installed may not yield a statistically products per calendar year (depending refine these aspects and ensure the use
significant result. For example, if an on the total number of products the of consistent and reliable methods
ONC–ACB were to randomly select a ONC–ACB has certified, which we across ONC–ACBs and their
Health IT Module installed at 40 expect will increase with the addition of surveillance approaches.
locations, the ONC–ACB would only be Health IT Modules certified to the 2015 Finally, we have eliminated the
required to perform in-the-field Edition). We believe this new minimum concept of ‘‘deficient surveillance
surveillance at 2 locations. The ONC– threshold will provide additional results’’ and instead applied the
AA stated that performing surveillance insight and experience related to proposed corrective action plan
of certain certified capabilities, such as randomized surveillance. This specific requirements across-the-board to all
interoperability or privacy and security, baseline will establish a randomized types of surveillance and confirmed
at only 2 locations would be insufficient surveillance program that advances our non-conformities. Thus, if an ONC–ACB
to identify all but the grossest non- policy aims while reducing the burden performs randomized surveillance for a
conformities. of randomized surveillance for all certified Complete EHR or certified
Some commenters felt that it was stakeholders and making this initial Health IT Module and confirms a non-
premature to codify a specific approach approach more manageable for ONC– conformity, it must institute a corrective
to randomized surveillance and that we ACBs. That being said, we intend to action plan under § 170.556(d) and
should instead create a ‘‘pilot study’’ or continually review surveillance results report related information to the open
allow ONC–ACBs to continue to and experiences to determine whether data CHPL, as required by
experiment with approaches to and how to increase this threshold over § 170.556(e)(3). This requirement
randomized surveillance in order to time (e.g., whether an incrementally applies regardless of whether the non-
gauge the willingness of providers to rising threshold over time would be conformity meets the 20% ‘‘deficiency
participate, potential methodologies, appropriate and effective). We also threshold’’ described in the Proposed
and the costs and benefits of this type intend to pursue and investigate other Rule. These changes are described in
of surveillance. avenues that could add feedback to (and more detail below in our responses to
Response. Randomized surveillance is be combined with) this surveillance the comments on these aspects of our
an important aspect of an ONC–ACB’s process. For example, we will explore proposal.
overall approach to in-the-field other kinds of tools, such as those that We have finalized these revisions at
surveillance. In addition to exposing may be able to be used directly by § 170.556(c)–(e).
problems that may not surface through health care providers to test and report Comments. A number of commenters
complaints and other forms of how their products performed. Overall, suggested that we specify additional
surveillance, randomized surveillance and over the long-term, we believe that details regarding the random sampling
will encourage developers to proactively other approaches can and should be approach that ONC–ACBs must follow
address issues and will also encourage included to complement the when selecting certified Complete EHRs
providers to participate in and become randomized in-the-field surveillance and certified Health IT Modules for
familiar with in-the-field surveillance of performed by ONC–ACBs. randomized surveillance and,
certified health IT. However, we Second, while an ONC–ACB must separately, when selecting the locations
acknowledge that the proposed perform surveillance of randomly at which the technology will be
randomized surveillance requirements selected certified Complete EHRs and surveilled in the field. Commenters
could place a significant burden on certified Health IT Modules in the field, noted that under a purely random
ONC–ACBs and divert resources and we no longer specify a minimum sampling approach, an ONC–ACB
energy away from other equally number of locations at which the ONC– would be equally likely to select a
important aspects of our proposal, ACB will be required to conduct such Complete EHR or Health IT Module
including more rigorous in-the-field surveillance. This revision reflects with relatively few installations or users
surveillance of certified health IT based commenters’ insight that requiring an as one with many installations or users.
To maximize the value of randomized product is excluded from selection to ensure that the surveillance
surveillance for providers and other because it was already selected for approaches used by ONC–ACBs,
stakeholders, commenters suggested randomized surveillance within the last including the selection processes and
that we require ONC–ACBs to weigh the 12 months). This prospect, that any methodologies for randomized
selection of products based on the product and location may be selected at surveillance discussed above, include
number of installed locations, users, or random, is the essence of a ‘‘random the use of consistent, objective, valid,
other factors. sampling’’ approach and is a central and reliable methods. (§ 170.503(e)(2)).
Commenters also suggested we clarify feature of randomized surveillance We intend to work closely with the
or specify additional requirements because it ensures that all health IT ONC–AA and the ONC–ACBs to ensure
related to the number and types of developers’ products and that such methods are in place and to
locations at which an ONC–ACB must implementations are potential identify and incorporate appropriate
surveil certified Complete EHRs and candidates for in-the-field surveillance. best practices and elements that serve
certified Health IT Modules that it has The possibility that any product may be the policies of this final rule.
randomly selected for in-the-field surveilled at any provider location will Comments. Commenters pointed out
surveillance. One commenter stressed encourage developers to proactively that while ONC–ACBs may be able to
the importance of ensuring random address issues and improve the real- randomly select locations at which to
selection of and diversity in the world performance and reliability of conduct in-the-field surveillance, they
providers and locations selected for health IT capabilities across all cannot compel a provider to grant
surveillance. Another commenter customers. access to its health care facility or to
suggested that an ONC–ACB’s approach Consistent with these principles, we cooperate in the surveillance of its
to selecting locations would need to clarify that an ONC–ACB’s selection of certified health IT. At the same time,
vary depending on the type of products and locations need not be providers may be reluctant to allow
implementation (e.g., local versus random in the absolute sense of ONC–ACBs to perform in-the-field
hosted systems). assigning an equal probability of surveillance because of concerns about
Response. We thank commenters for selection to every product or location in granting access to PHI. One ONC–ACB
their feedback on potential random the pool. Indeed, for the reasons stated stated that it had experienced
sampling and other considerations for by commenters, there may be strong difficulties securing cooperation from
randomized surveillance. While we do justifications for assigning different providers in connection with its existing
not explicitly adopt any additional probabilities or ‘‘weights’’ to products or surveillance activities and therefore
sampling or methodological constraints locations based on a variety of factors questioned whether providers would be
beyond those we proposed, we agree that are relevant to maximizing the willing to participate in additional
with many of the commenters’ value and impact of randomized surveillance, especially when
suggestions and intend to work with surveillance activities for providers and
conducted at random rather than in
ONC–ACBs and the ONC–AA to other stakeholders. For example, when
response to a complaint or identified
incorporate these and other elements in selecting products for randomized
their approaches to randomized issue.
surveillance, the ONC–ACB could
surveillance, consistent with the basic assign greater weight to products that Given these concerns, some
parameters established by this final rule are more widely adopted and used so as commenters suggested that ONC–ACBs
and discussed in more detail below. to increase the likelihood that the should not be required to conduct
In consideration of the comments products surveilled will include at least randomized surveillance unless
provided, we have determined that an some products with a large number of providers are also required to
ONC–ACB’s selection process under installations and users. This would participate in such surveillance as a
randomized surveillance will adhere to increase the overall impact of the ONC– condition of participation in the EHR
the following requirements. On an ACB’s surveillance activities by Incentive Programs or other programs.
annual basis the ONC–ACB must ensure increasing the likelihood of discovering Alternatively, other commenters
that it meets the threshold sample size, and addressing non-conformities that suggested that we provide exceptions
which is initially being established at affect a large number of providers and and other flexibility for ONC–ACBs in
2% of all of the Complete EHRs and users. As another example, when the event that a provider is selected for
Health IT Modules to which the ONC– randomly selecting locations at which to but does not cooperate with an ONC–
ACB has issued a certification. The perform in-the-field surveillance for any ACB’s in-the-field surveillance of the
ONC–ACB must randomly select particular product, an ONC–ACB might provider’s certified health IT. Several
products from those to which it has ensure that no two locations selected are commenters requested clarity on our
issued a certification, but is permitted to under the common ownership or control expectations for providers’ role as
implement appropriate weighting and of a single person or entity, thereby participants in in-the-field surveillance,
sampling considerations. After an ONC– addressing the concerns raised by especially randomized surveillance.
ACB has randomly selected a product commenters regarding the diversity of Response. We appreciate commenters’
for surveillance, for each product providers and locations selected for concerns and acknowledge that
selected, the ONC–ACB must select a randomized surveillance. randomized surveillance presents
random sample of one or more locations To avoid any misinterpretation of the unique challenges. In particular, we
at which the ONC–ACB will initiate in- phrases ‘‘randomly select’’ and recognize that some providers who are
the-field surveillance of the certified ‘‘selected at random,’’ we have clarified selected for randomized surveillance
Complete EHR or certified Health IT the regulation text at § 170.556(c)(2) and may not cooperate with an ONC–ACB’s
Module’s prioritized capabilities. At § 170.556(c)(4)(ii) to allow for efforts. Moreover, depending on the
both stages of the selection process, an appropriate weighting and sampling number of locations at which a
ONC–ACB must ensure that every considerations in the random selection particular product is in use, a lack of
product selected and every provider of products and locations, respectively. cooperation from providers or end-users
location at which the product is in use Finally, we note that under the ONC could prevent the ONC–ACB from
has a chance of being randomly selected Health IT Certification Program, it is an conducting in-the-field surveillance of
for in-the-field surveillance (unless a ongoing responsibility of the ONC–AA that product altogether.
Because we agree that an ONC–ACB of production systems. We also note the open data CHPL. Specifically, the
should not be penalized in such that, in consultation with the Office for ONC–ACB would have to contact the
situations, we clarify that where an Civil Rights, we have clarified that developer of the certified Complete EHR
ONC–ACB makes a good faith effort but under the ‘‘health oversight agency’’ or certified Health IT Module and
is nevertheless unable to complete in- exception of the HIPAA Privacy Rule, a require the developer to submit a
the-field surveillance at a particular healthcare provider is permitted to proposed corrective action plan to the
location for reasons beyond its control, disclose PHI to an ONC–ACB during the ONC–ACB within 30 days of the date
the ONC–ACB may exclude the location course of authorized in-the-field that the developer was notified by the
and substitute another location that surveillance activities, without patient ONC–ACB of the ‘‘deficient’’ finding.
meets the random selection authorization and without a business The ONC–ACB would be responsible for
requirements described above. associate agreement.173 prescribing the form and content of
Similarly, in the event that the ONC– Comment. One commenter, an ONC– corrective action plans and for
ACB exhausts all available locations for ACB, stated that some health IT developing specific procedures for
a particular certified Complete EHR or developers have resisted providing the submission and approval, with guidance
certified Health IT Module, the ONC– ONC–ACB with a complete list of the from ONC to promote consistency
ACB may exclude that Complete EHR or health IT developers’ users. The across ONC–ACBs.
Health IT Module and substitute commenter asked us to clarify that Comments. Many commenters
another randomly selected Complete health IT developers have an obligation supported our proposal to specify
EHR or Health IT Module. In the case of to abide by and support an ONC–ACB’s certain required elements and
exhaustion, we clarify that the excluded surveillance requirements, including procedures for corrective action. Several
certified Complete EHR or Health IT furnishing complete and up-to-date user commenters asked us to clarify whether
Module would be counted towards the lists upon request. these requirements would apply to non-
minimum number of products an ONC– Response. We expect an ONC–ACB to conformities confirmed through reactive
ACB is required to randomly surveil require, as a condition of certification, and other forms of surveillance and, if
during the calendar year surveillance that health IT developers furnish to the not, what if any corrective action would
period. We emphasize, however, that an ONC–ACB upon request, accurate and be required for those non-conformities.
ONC–ACB must carefully and complete customer lists, user lists, and Several commenters urged us to apply
accurately document its efforts to other information that the ONC–ACB the same standards for corrective action
complete in-the-field surveillance for determines is necessary to enable it to to all types of surveillance and non-
each product and at each location. The carry out its surveillance conformities. Commenters pointed out
ONC–AA would be expected to review responsibilities. We note that even that the reasons for imposing such
this documentation to ensure that ONC– under ONC–ACB’s existing annual requirements apply with equal force to
ACBs have met the required random surveillance plans, access to accurate all confirmed non-conformities, not
selection requirement and have made a customer and user lists is essential to an only those identified through
good faith effort to perform in-the-field ONC–ACB’s ability to contact users for randomized surveillance and meeting
surveillance prior to excluding any reactive surveillance and to conduct the proposed 20% threshold. In
product or location from randomized surveys and other activities necessary to particular, requiring corrective action
surveillance. We believe that these obtain and synthesize information about plans and related public reporting for
the performance of certified health IT. only some non-conformities and not
revisions—combined with the reduced
Therefore, if a health IT developer others would be difficult to square with
minimum sample size for in-the-field
refuses to provide this information to an our stated goals of improving
surveillance and the clarifications noted
ONC–ACB, the ONC–ACB may regard transparency and accountability for
above regarding the number of locations
the refusal as a refusal to participate in health IT developers and ONC–ACBs.
at which an ONC–ACB must observe
surveillance under the ONC Health IT Commenters also questioned whether
capabilities in the field—will mitigate
Certification Program and institute the proposed approach would best
the concerns raised by commenters and
appropriate procedures, consistent with achieve our patient safety goals. When
make randomized surveillance more
the ONC–ACB’s accreditation to ISO an ONC–ACB confirms a non-
manageable for ONC–ACBs, providers,
17065, to suspend or terminate the conformity in the context of reactive
and developers.
health IT developer’s certification. surveillance, it may not know whether
It is our expectation that providers the problem is widespread unless and
will cooperate with an ONC–ACB’s Corrective Action Requirements; until it conducts more extensive
authorized surveillance activities, Reporting of Surveillance Results and randomized surveillance of a large
including the surveillance of certified Corrective Action Information sample of the potentially affected
health IT in the field. While we certified Complete EHR or certified
In the Proposed Rule, we stated that
understand that some providers may be Health IT Module. For reasons
if an ONC–ACB found a pattern of
reluctant to grant ONC–ACBs access to described earlier, ONC–ACBs may have
nonconformity—defined as a failure to
PHI, we point out that providers who difficulty at this time conducting
demonstrate conformity to any
commented on our proposal randomized surveillance on the
prioritized certification criterion at 20%
overwhelmingly supported and urged us necessary scale. Applying the corrective
or more of the locations surveilled—the
to finalize requirements for the action plan and related reporting
ONC–ACB would be required to treat
surveillance of certified health IT in the requirements to all types of surveillance
the certified Complete EHR or certified
field (i.e., in production environments and confirmed non-conformities would
Health IT Module as ‘‘deficient.’’ This

in which the technology is implemented alert users to these potential concerns.
finding would also trigger special
and used). Such surveillance will only Response. Our goal for these
requirements for corrective action plans
be successful if providers are actively requirements was to ensure that health
and the reporting of that information to
engaged and cooperate with ONC– IT users, implementers, and purchasers
ACBs’ surveillance activities, including 173 See ONC Regulation FAQ #45 [12–13–045–1]. would be alerted to potential non-
by granting access to and assisting available at http://www.healthit.gov/policy- conformities in a timely and effective
ONC–ACBs to observe the performance researchers-implementers/45-question-12-13-045. manner, consistent with the patient
safety, program integrity, and developers who are subjected to a enhancing transparency and
transparency objectives described in the corrective action plan should be accountability for health IT developers
Proposed Rule. But as the comments required to notify affected and and ONC–ACBs.
make clear, the proposed requirements potentially affected users of identified Some commenters, including several
would only partially serve those goals. non-conformities and deficiencies. We health IT developers, objected to the
As commenters pointed out, there is no already proposed to require developers reporting of corrective action plan
principled reason to apply the proposed to describe in their corrective action information to the publicly accessible
corrective action plan exclusively to plans both an assessment of how Open Data CHPL. Some commenters felt
non-conformities identified in the widespread an identified non- that information about non-conformities
context of the proposed randomized conformity might be and how the should not be made public unless and
surveillance approach. Moreover, the developer planned to address the non- until the developer of the certified
comments suggest that prescribing conformity both at the specific locations Complete EHR or certified Health IT
different corrective action plan at which surveillance occurred and Module at issue has been given a full
requirements in this context than for more generally at other potentially and fair opportunity to contest the
other types of non-conformities (which affected locations (80 FR 16879). ONC–ACB’s determination, including
would be governed by an ONC–ACB’s Requiring developers to describe how whether the developer was responsible
general responsibility to require they will notify affected and potentially or ‘‘at fault’’ for the non-conformity.
corrective action per its accreditation to affected users of the extent of the Other commenters stated that such
ISO 17065) would likely create problem and their plans to address it is information should never be made
significant and unnecessary confusion. a natural extension of these public because it is bound to lack
Particularly in light of the reduced requirements and will help alert important context, could be
emphasis on randomized surveillance in stakeholders to potential non- misinterpreted, or would not offer
comparison to the Proposed Rule, we conformities in a timely and effective substantial value to health IT customers
are persuaded that our policy objectives manner, which was one of the stated and users. Separately, some commenters
will be better served by requiring the purposes of these requirements (80 FR raised concerns regarding the reporting
same approach to corrective action 16884). of proprietary or competitively sensitive
across the board. Thus we have Accordingly, we have added as a information.
finalized the proposed requirements for requirement of all corrective action A few commenters suggested that to
corrective action plans for all certified plans approved by an ONC–ACB that reduce reporting burden or improve the
Complete EHRs and certified Health IT the developer identify a process for efficacy of the open data CHPL, we limit
Modules for which an ONC–ACB ensuring that all affected and potentially the types of information about
confirms a non-conformity, whether that affected customers and users are alerted corrective action that an ONC–ACB
non-conformity is confirmed through to identified non-conformities and would be required to submit. One
randomized, reactive, or any other form deficiencies, as applicable. This process commenter suggested that the reporting
of surveillance under the ONC Health IT must describe in detail: How the of corrective action plan information be
Certification Program. developer will assess the scope and limited to 2015 Edition certified health
For similar reasons, we have finalized impact of the problem, including IT and that reporting of surveillance
the proposed reporting requirements for identifying all potentially affected results be limited to twice a year instead
corrective action plans and extended customers; how the developer will of quarterly. The commenter stated that
these requirements to all cases in which promptly ensure that all potentially these changes would reduce burden and
an ONC–ACB confirms a non- affected customers are notified of the enable us to assess the costs of these
conformity and subsequently approves a problem and plan for resolution; how reporting requirements.
corrective action plan. Requiring the and when the developer will resolve Response. We agree with commenters
uniform submission of this information issues for individual affected customers; that requiring ONC–ACBs to report
will promote transparency and alert and how the developer will ensure that surveillance results to the National
health IT users, implementers, and all issues are in fact resolved. Coordinator on a quarterly basis will
purchasers to potential conformity To ensure adherence to these significantly improve our ability to
issues in a more timely and effective requirements for notification and respond to problems and provide timely
manner. These reporting requirements resolution across a developer’s customer and accurate information stakeholders.
are discussed further below in our base, and to the other requirements of With regard to the reporting of
response to the comments on this aspect the approved corrective action plan, we corrective action plan information to the
of our proposal and also in our have added as an additional open data CHPL, we understand the
discussion of the ‘‘Open Data CHPL’’ requirement of all corrective action concerns raised by some commenters
requirements found elsewhere in this plans approved by an ONC–ACB that but believe that it is both necessary and
preamble. the developer attest to having completed appropriate to require ONC–ACBs to
Comment. A commenter suggested all required elements of the plan, submit this information. The public
that in addition to making information including the requirements for alerting safety, transparency, and program
about corrective action plans available customers and users described above. integrity rationales for requiring timely
on the CHPL, we should require health Comments. Many commenters and public reporting of this information
IT developers to notify affected users of supported our proposals to improve the are compelling. In comparison, and
the corrective action, similar to the reporting and submission of contrary to the assertions of some
requirements for breach notification surveillance results. Several commenters, making this information
under the HIPAA Rules. The commenter commenters stated that requiring ONC– available is not likely to cause
stated that many providers do not ACBs to submit corrective action plan customers and users to draw inaccurate
regularly check the CHPL and therefore information to the publicly accessible or unfair conclusions about a health IT
may not be made aware of problems in open data CHPL would provide developer or its certified technology. By
a timely manner. customers and users with valuable definition, this information will only be
Response. We appreciate the information about the performance of required when an ONC–ACB has
commenter’s suggestion that health IT certified health IT while significantly confirmed a non-conformity and
required a health IT developer to take Coordinator and the submission of the issues and respond to the ONC–
corrective action. Thus the ONC–ACB corrective action plan information to the ACB’s preliminary findings.
will have completed its review of the open data CHPL to 2015 Edition Response. We agree with the
relevant facts and circumstances, certified health IT. The public safety, commenter that a developer should be
including those raised by the developer transparency, and program integrity able to complete an approved corrective
in the course of the surveillance of its reasons for requiring the reporting of action plan within a substantially
certified Complete EHR or certified this information apply to all, and not shorter timeframe than we proposed.
Health IT Module. ONC–ACBs are only 2015 Edition, certified health IT. We clarify that the 30 day period for
required to make such determinations in However, we do agree that the reporting submitting a proposed corrective action
accordance with their accreditation to of corrective action information should plan would begin to run only after an
ISO 17065 and with the Principles of be limited to the types of information ONC–ACB has issued a non-conformity
Proper Conduct for ONC–ACBs, subject that will be useful to customers and determination. In our experience, ONC–
to ongoing supervision by the ONC–AA. users, consistent with the goals of ACBs already work with health IT
Moreover, as stated in the Proposed reporting this information to the open developers and users to investigate
Rule, when the developer has provided data CHPL explained above. We have potential non-conformities prior to
an explanation of the deficiencies therefore revised § 170.523(f)(1)(xxii) issuing a final determination. Because
identified by the ONC–ACB as the basis and (f)(2)(xi) to limit reporting to the this back-and-forth will have occurred
for its determination, the ONC–ACB following subset of information: prior to the ONC–ACB’s non-conformity
must include the developer’s • The specific certification determination, we believe that a
explanation in its submission to the requirements to which the technology developer should be able to submit a
open data CHPL. Thus developers will failed to conform, as determined by the proposed corrective action plan within
be able to note any objections and ONC–ACB; 30 days of being notified of the ONC–
provide any additional context or • A summary of the deficiency or ACB’s non-conformity determination
information that may be relevant to deficiencies identified by the ONC–ACB under § 170.556(d)(1). Similarly, if after
interpreting the results of the as the basis for its determination of non- 90 days of notifying the developer of a
surveillance and the ONC–ACB’s conformity; non-conformity under § 170.556(d)(1),
findings and conclusions. • When available, the health IT the ONC–ACB cannot approve a
We are confident that the concerns of developer’s explanation of the corrective action plan because the
some commenters regarding disclosure deficiency or deficiencies; developer has not submitted a revised
of proprietary or sensitive information • The dates surveillance was initiated proposed corrective action plan in
will be adequately addressed through and completed; accordance with § 170.556(d)(4), the
appropriate safeguards implemented at • The results of randomized ONC–ACB must initiate suspension
the discretion of ONC–ACBs. ONC– surveillance, including pass rate for procedures. Finally, an ONC–ACB must
ACBs should not submit to the open each criterion in instances where the initiate suspension procedures when it
data CHPL any information that is in Health IT Module is evaluated at more has approved a corrective action plan
fact legally privileged or protected from than one location; but the developer fails to comply with
disclosure. ONC–ACBs may also • The number of sites that were used all of the requirements of the plan
implement other appropriate safeguards, in randomized surveillance; within the time specified therein. We
as necessary, to protect information they • The date of the ONC–ACB’s have revised § 170.556(d)–(e) to reflect
believe should not be reported to a determination of non-conformity; these requirements.
publicly available Web site. However, • The date on which the ONC–ACB Effective Date and Applicability of
we caution ONC–ACBs to ensure that approved a corrective action plan; Requirements
such safeguards are narrowly tailored • The date corrective action began
and consistent with our goal of (effective date of approved corrective At the time of this Proposed Rule,
promoting the greatest possible degree action plan); ONC–ACBs had submitted their annual
of transparency with respect to certified • The date by which corrective action surveillance plans for calendar year
health IT and the business practices of must be completed (as specified by the 2015, which include their existing
certified health IT developers. ONC– approved corrective action plan); approaches and methodologies for
ACBs are required to accurately report • The date corrective action was randomized surveillance. To minimize
the results of their surveillance and to completed; and disruption to ONC–ACBs’ current
explain in detail the facts and • A description of the resolution of surveillance activities, we proposed to
circumstances on which their the non-conformity or non-conformities. make the requirements for randomized
conclusions are based. Similarly, health Comments. We proposed that an surveillance effective beginning on
IT developers are required to cooperate ONC–ACB would have to require a January 1, 2016. We said this would
with these efforts and may not prevent health IT developer to submit a provide time for ONC–ACBs to
or seek to discourage an ONC–ACB from proposed corrective action plan within implement these requirements in their
reporting the results of its authorized 30 days of being notified of an ONC– annual surveillance plans and
surveillance activities. We note that ACB’s non-conformity determination incorporate additional guidance and
while the ONC Health IT Certification and to complete an approved corrective clarification from ONC and the ONC–
Program is a voluntary one, developers action plan within 6 months of such AA as necessary. All other proposed
who choose to participate agree to notice. One commenter stated that this surveillance requirements would be
comply with certification program timeline was much too long and that effective immediately. We requested
requirements, including reporting developers should not be able to market comment on whether this timeline and
requirements designed to ensure health IT as certified for 6 months while plan for implementation was
transparency and accountability for all they correct a non-conformity. Another appropriate and on ways to minimize
participants and stakeholders. commenter stated that the 30 day disruption and ensure that the
We decline to limit the requirements timeline was too short because it would requirements and purpose of this
for more frequent reporting of not allow sufficient time for the proposal are timely and effectively
surveillance results to the National developer to understand and investigate achieved.
Comments. Some commenters, IT certified under the ONC Health IT certified health IT that were not
including the ONC–AA and an ONC– Certification Program, not just disclosed or contemplated when the
ACB, suggested that we specify a single technology certified to the new 2015 technology was initially purchased or
January 1, 2016 effective date for all Edition. Thus, as proposed, we have licensed. (80 FR 16880–81). We said
proposed surveillance requirements in finalized the in-the-field surveillance that the failure of developers to disclose
order to allow ONC–ACBs to effectively and maintenance of certification ‘‘known material information’’ about
and consistently implement these requirements for all Health IT Modules limitations or additional types of costs
requirements in their annual certified to either the 2015 Edition or associated with the capabilities of
surveillance plans for the calendar year the 2014 Edition. With respect to certified health IT diminishes both the
2016 surveillance period. Another Complete EHRs, because we have reliability of certified health IT and of
commenter, also an ONC–ACB, stated discontinued Complete EHR certifications issued under the ONC
that it would have difficulty certification with the 2015 Edition, we Health IT Certification Program. In
implementing the randomized have finalized these requirements for all particular, the failure of developers to
surveillance requirements for calendar Complete EHRs certified to the 2014 disclose such information creates a
year 2016 and suggested that the Edition. We note that Complete EHR substantial risk that existing or
requirements be postponed until certification to the 2014 Edition has and prospective users of certified health IT
January 1, 2017. Yet another commenter will continue to occur as providers may will encounter problems implementing
felt that the timeline for implementing use health IT certified to the 2014 and using the health IT in a manner
the proposed requirements should be Edition to meet the CEHRT definition at consistent with its certification.
more aggressive. least through 2017 based on the EHR Moreover, inadequate or incomplete
One ONC–ACB suggested that the Incentive Programs Stage 3 and information about health IT products
proposed requirements for in-the-field Modifications final rule published and services distorts the marketplace by
surveillance be applied only to 2015 elsewhere in this issue of the Federal preventing customers from accurately
Edition certified health IT so that ONC– Register. assessing the costs and capabilities of
ACBs could implement the different technologies and selecting the
requirements prospectively in new 2. Transparency and Disclosure
most appropriate solutions to their
contracts with health IT developers. Requirements
needs, which increases the likelihood of
Response. We believe that the We proposed to revise the Principles downstream implementation problems
proposed timeline for implementation is of Proper Conduct for ONC–ACBs to and, ultimately, reduced opportunities
reasonable. Given the significantly require greater and more effective to use health IT to improve health and
reduced scope of randomized disclosure by health IT developers of health care. Finally, customers who
surveillance in comparison the certain types of limitations and purchase or license inappropriate or
Proposed Rule, we are confident that additional types of costs that could suboptimal technologies may find it
ONC–ACBs will be able to complete interfere with the ability to implement difficult to switch to superior
randomized surveillance requirements or use health IT in a manner consistent alternatives due to the often significant
over the course of the calendar year with its certification. We stated that financial and other ‘‘switching costs’’
2016 surveillance period. We also these additional disclosure associated with health IT.175 When
believe that ONC–ACBs will be able to requirements were necessary to ensure providers become ‘‘locked in’’ to
implement the other requirements that existing and potential customers, technologies or solutions that do not
established by this final rule during the implementers, and users of certified meet their needs or the needs of their
90 days between its publication and health IT are fully informed about these patients, health IT developers have
effective date. Accordingly, ONC–ACBs implementation considerations that fewer incentives to innovate and
must comply with all new requirements accompany capabilities certified under compete on those aspects of health IT
by the effective date of this final rule. the ONC Health IT Certification that providers and their patients most
We will provide guidance to ONC–ACBs Program. value and need.
regarding updates to their annual Our proposal expanded on health IT For all of these reasons, we proposed
surveillance plans for calendar year developers’ existing disclosure to revise and strengthen our existing
2016 and, as necessary, regarding other obligations at § 170.523(k)(1). Those transparency and disclosure
aspects of surveillance affected by this obligations were adopted in the 2014 requirements in three key respects.
final rule.174 Edition final rule to promote greater First, under our proposal, a health IT
We decline to adopt the commenter’s price transparency in certified health IT developer’s obligation to disclose
suggestion to limit the requirements for capabilities required to meet meaningful ‘‘additional types of costs’’ would no
in-the-field surveillance and use objectives and measures; to mitigate longer be confined to the use of
maintenance of certification to only confusion in the marketplace; and to capabilities to demonstrate a meaningful
2015 Edition certified health IT. The reduce the risk that EPs, eligible use objective or measure under the EHR
need to assure that certified health IT hospitals, and CAHs would encounter Incentive Programs. Instead, ONC–ACBs
conforms to the requirements of its unexpected difficulties in the would be required to ensure that
certification is applicable to all health implementation or use of certified developers disclose any additional types
health IT. of costs that a user may incur in order
174 In our annual surveillance guidance to ONC– As we explained in the Proposed to implement or use capabilities of
ACBs for the calendar year 2016 surveillance Rule, despite our initial efforts to
period, we stated that ONC–ACBs should be aware promote greater transparency and 175 The costs of switching to a new technology
of the proposals in the 2015 Edition proposed rule include not only the costs of purchasing or
that could affect their surveillance responsibilities
disclosure of information by health IT
licensing the technology itself but of installing and
and indicated that we would update our developers, many providers continue to integrating it with other administrative and clinical
surveillance guidance as necessary in the event that lack reliable up-front information about IT systems, migrating data, redesigning associated
such proposals were finalized. ONC, ONC Health IT health IT products and services. We workflows and processes, and retraining staff to use
Certification Program, Program Policy Guidance the new technology. The transition may also disrupt
#15–01 (July 16, 2015), http://healthit.gov/sites/
described reports from providers who normal health care and business operations, adding
default/files/policy/onc- have encountered unexpected costs and additional costs and strain on provider
acb_cy16annual_surveillance_guidance.pdf. limitations in connection with their organizations and staff.
certified health IT, whether to Proposed Rule. We proposed that in technologies, organizations, and
demonstrate meaningful use objectives addition to requiring health IT applications. Similarly, commenters
or measures or for any other purpose developers to disclose known material cited examples of providers
within the scope of the health IT’s information about their certified health encountering unanticipated contractual,
certification. IT, an ONC–ACB would be required to technical, or other limitations on their
Second, in addition to ‘‘additional obtain a public attestation from every ability to implement and use certified
types of costs,’’ we proposed that health health IT developer to which it issues or health IT capabilities in the manner
IT developers would be required to has issued a certification for any edition they anticipated when they purchased
disclose other factors that may similarly of certified health IT. The attestation or licensed the technology. Some
interfere with a user’s ability to would take the form of a written commenters stated that small providers
successfully implement certified health ‘‘pledge’’ by the health IT developer to are especially vulnerable to these
IT, including information about certain take the additional, voluntarily step of unexpected challenges because they
‘‘limitations’’ associated with its proactively providing information lack the resources and time to study and
certified health IT. We explained that (which it would already be required to understand the complexities associated
the failure to disclose information about disclose via its website and in marketing with developer contracts.
limitations—including contractual, and other materials) to all current and Many commenters stated that the
technical, and other restrictions or prospective customers as well as to any proposed transparency and disclosure
policies—associated with certified other persons who request such requirements would help ensure that
health IT creates a substantial risk that information. While adherence to the providers are informed of these and
current or prospective users will attestation would be strictly voluntary, other considerations and enable them
encounter problems implementing the we explained that requiring developers both to more reliably estimate the
health IT in a manner consistent with its to make the attestation could encourage resources needed to successfully
certification. Thus the disclosure of this a culture of greater transparency and implement certified health IT
information is no less important than accountability in the health IT capabilities and to arrive at a realistic
the disclosure of information about marketplace. For example, health IT expectation of how those capabilities
additional types of costs. purchasers, implementers, and users will perform in the field. Commenters
Third, with regard to both (and organizations that represent them) also noted that this increased ability of
‘‘limitations’’ and ‘‘additional types of would be invited to approach customers to assess and compare
costs,’’ we proposed to significantly developers directly and request certified health IT products and services
broaden the types of information and information most relevant to their could reduce the problems of ‘‘lock in’’
the level of detail that a health IT health IT decisions and needs. The and ‘‘unfair surprise’’ described in our
developer would be required to expectation that developers will provide proposal and put pressure on
disclose. In contrast with the price developers to compete to innovate and
this information in a way that is more
transparency requirements adopted in deliver better and more affordable
meaningful for stakeholders, consistent
the 2014 Edition final rule, which technologies and solutions based on
with the attestation, would create
required disclosure only of additional provider and consumer preferences.
greater competitive incentives for
types of costs that a user ‘‘would pay’’ Commenters also stated that greater
developers to do so. Developers would
to implement certain capabilities, we transparency in health IT products and
also receive important feedback about
proposed to require health IT services would help to expose and
the types of information that
developers to be more proactive in discourage information blocking and
stakeholders find important, which
identifying the kinds of limitations and other business practices that frustrate
would assist developers in meeting their
additional types of costs that a user interoperability and prevent the
‘‘may’’ pay or encounter in order to disclosure obligations under the ONC
effective sharing of electronic health
achieve any use of the health IT within Health IT Certification Program. For
information. A number of commenters
the scope of its certification. example, requests for information about
cited our discussion of these issues in
Specifically, developers would be a particular cost or capability may alert
our recent Report to Congress on Health
required to provide, in plain language, the developer to a material limitation or
Information Blocking.176
a detailed description of any ‘‘known additional type of cost that it is required Response. We thank commenters for
material information’’ about limitations to disclose. their detailed and thoughtful feedback
that a purchaser may encounter, and Comments. Most commenters strongly on this proposal. As that feedback
about additional types of costs that a supported our proposal to require the overwhelmingly demonstrates, the lack
user may be required to pay, in the disclosure of additional information of transparency and access to reliable
course of implementing or using the about certified health IT. Many of these information about health IT products
capabilities of health IT to achieve any commenters agreed with our assessment and services is a persistent and
use within the scope of its certification. that providers and other stakeholders pervasive problem that undermines the
We also provided an extensive often lack reliable information about reliability of certifications issued on
discussion of the types of information certified health IT products and services behalf of ONC and creates substantial
that would be deemed ‘‘material’’ and of and, as a result, may encounter risks that users will be unable to
the types of information that developers unexpected costs and limitations that successfully implement and derive the
would and would not be required to interfere with their ability to benefits of certified health IT. For this
disclose. Further, we described the successfully implement and use and the additional reasons discussed
manner in which the information would certified health IT capabilities. Several below in our responses to comments on
need to be disclosed as well as commenters cited examples of providers specific aspects of our proposal, we
safeguards to avoid the disclosure of encountering unexpected fees to license, have finalized the transparency and
intellectual property and trade secrets. implement, upgrade, or use health IT; to
Finally, in addition to these three exchange or export electronic health 176 ONC, Report to Congress on Health
aspects, we proposed one additional information stored in certified health IT; Information Blocking (April 2015), http://
www.healthit.gov/sites/default/files/reports/
element designed to complement the or to integrate certified health IT infolblockingl040915.pdf (hereinafter ‘‘Blocking
disclosure requirements set forth in the capabilities and data with other Report’’).
disclosure requirements at § 170.523(k). proposal from providers and other purchasing or licensing and
We have finalized these requirements as customers of certified health IT, whose implementation decisions.
proposed, except for the attestation comments and first-hand accounts of Finally, we disagree that the
requirement, which we have revised. To the health IT marketplace affirm our transparency and disclosure
complement these new requirements, assessment in the Proposed Rule. Those requirements will limit developers’
we have also finalized additional comments suggest that many customers flexibility to design and market their
reporting requirements to the open data lack access to reliable information about products and services in ways that their
CHPL, which we have added to certified health IT products and services customers value. To the contrary,
§§ 170.523(f)(1) and (f)(2). We discuss and, as a result, are more likely to greater transparency in health IT
these revisions below in our response to encounter unexpected costs and developers’ business practices will
the comments on this aspect of our limitations that interfere with their provide customers with the basic
proposal. ability to successfully implement and information they need to make informed
Comments. Several commenters use certified health IT capabilities. The decisions in the marketplace, which
specifically agreed with our proposal to comments also provide insight into will in turn encourage and enable
require health IT developers to disclose other deleterious consequences that developers to experiment, innovate, and
known material information about the flow from a lack of basic transparency compete to deliver products and
capabilities of certified health IT, in the marketplace, including the services that customers demand and on
including limitations and additional increased risk that developers will such prices and terms that meet their
types of costs. Many commenters also engage in information blocking and individual needs and requirements.
specifically endorsed our proposal to other business practices that undermine Comments. Several commenters
apply these requirements uniformly to the goals of certification and the ONC stated that ONC–ACBs and developers
all capabilities and uses within the Health IT Certification Program. may have difficulty complying with the
scope of a health IT’s certification—not Second, we disagree that the proposed disclosure requirements
just those required to meet a specific transparency and disclosure because we had not specified with
meaningful use objective or measure. requirements are burdensome or unfair sufficient clarity or detail the types of
Commenters stated that applying clear to health IT developers. We note that information that developers would be
and uniform standards for the developers are not required to disclose required to disclose. Two ONC–ACBs
disclosure of this information will be information of which they are not and indicated that additional guidance may
necessary to help customers understand could not reasonably be aware, nor to be needed to fully implement the
and use an increasing array of certified account for every conceivable cost or requirements. However, another ONC–
health IT products, services, and implementation hurdle that a customer ACB that commented extensively on the
capabilities. may encounter in order to successfully proposal did not raise these concerns. In
In contrast, some commenters, mostly implement and use the capabilities of a addition, the ONC–AA supported our
health IT developers, strongly opposed developer’s certified health IT. Indeed, approach and noted that the criteria and
all of the proposed disclosure we recognized in the Proposed Rule that examples described in the Proposed
requirements. These commenters stated, certified health IT often functions in Rule provided sufficient guidance to
among other objections, that requiring combination with many third party ONC–ACBs and developers. The ONC–
the disclosure of this information is technologies and services whose AA stated that while ONC–ACBs and
unnecessary; would be burdensome for specific costs and limitations may be developers would inevitably need to
developers; and could limit developers’ difficult for a health IT developer to exercise some degree of judgment
flexibility to design and market their precisely predict or ascertain. Local regarding the precise form and content
products and services in ways that their implementation factors and other of the required disclosures, comparisons
customers value. Several commenters individual circumstances also vary across developers’ disclosures would
stated that the proposed disclosure substantially among customers and promote consistency and provide
requirements would be unfair to impact the cost and complexity of additional clarity to ONC–ACBs,
developers because developers may not implementing certified health IT. In developers, and other stakeholders as to
be aware of capabilities or uses of their addition, the costs of upgrading health the types of information and level of
technology that are not specifically IT to meet new regulatory requirements detail that must be disclosed.
required to demonstrate the meaningful or compliance timelines, which are Response. We understand the desire
use of certified health IT under the EHR subject to change, may make some for clear and predictable rules governing
Incentive Programs. Some commenters particular types of additional costs these expanded disclosure requirements
also stated that developers should not especially difficult to forecast. under the ONC Health IT Certification
be expected to know about—or required Nevertheless, it is reasonable to Program. We note that our ability to
to disclose—limitations or additional assume that health IT developers are issue guidance is limited by the problem
types of costs that may apply to third- experts on their own products and we are trying to solve; that is, the lack
party components or that may flow from services and possess sophisticated of transparency in the marketplace
local implementation decisions. technical and market knowledge related means we lack detailed information
Response. While we appreciate the to the implementation and use of health about many types of limitations and
concerns raised by some commenters, IT in a variety of settings in which their additional types of costs that customers
we believe they are outweighed by the products are used. Through their and users may encounter in the course
need to promote greater and more accumulated experience developing and of implementing and using certified
meaningful disclosure of information by providing health IT solutions to their health IT and that developers would be
developers of health IT certified on customers, health IT developers should required to disclose.

behalf of ONC. be familiar with the types of costs and Nevertheless, based on the comments
First, we respectfully disagree with limitations that most users encounter, and in particular the feedback of the
the assertion that these transparency and therefore must describe these in ONC–AA, we believe that the principles
and disclosure requirements are sufficient detail so as to provide and examples provided in the Proposed
unnecessary. Our conclusion is based potential customers with the Rule provide a workable starting point
on the overwhelming support for this information they need to make informed for ONC–ACBs to apply, and developers
to comply with, the disclosure capabilities to which technology is costs imposed by third parties with
requirements. As stated by the ONC– certified; or that could prevent or limit whom they do not have a contractual
AA, while these principles inevitably the use, exchange, or portability of any relationship. In contrast, because
involve the exercise of some discretion, data generated in the course of using limitations include not only contractual
comparisons across developers’ any capability to which technology is restrictions but also technical and
disclosures over time will provide certified. practical limitations of a developer’s
consistency and additional clarity As already noted, developers are not technology, developers will often be
regarding the types of information and required to disclose information of aware of material limitations
level of detail that developers must which they are not and could not notwithstanding the existence of a
disclose. In addition, as our visibility reasonably be aware, nor to account for contractual relationship, and there is
into these practices improves, we stand every conceivable type of cost or therefore no reason to expressly qualify
ready to issue additional guidance. implementation hurdle that a customer the types of material limitations for
For the sake of additional clarity, we may encounter in order to successfully which a developer may, in appropriate
clarify that to comply with the implement and use the capabilities of circumstances, be presumed to have
disclosure requirements, a developer the developer’s certified health IT. knowledge.
must disclose in plain language—on its Developers are required, however, to Comments. Several commenters who
website and in all marketing materials, describe with particularity the nature, supported our proposal urged us to
communications statements, and other magnitude, and extent of the limitations require the disclosure of more specific
assertions related to its certified health or types of costs. A developer’s information about prices and cost
IT—a detailed description of all known disclosure possesses the requisite structures for health IT products and
material information concerning particularity if it contains sufficient services. Some of these commenters
limitations and additional types of costs information and detail from which a suggested that developers be required to
that a person may encounter or incur to reasonable person under the disclose specific prices for each service
implement or use certified health IT circumstances would, without special a user may need and provide guidance
capabilities, whether to meet effort, be able to reasonably identify the on how relevant factors—such as the
meaningful use objectives and measures specific limitations he may encounter volume of transmissions, geography,
or to achieve any other use within the and reasonably understand the potential interfaces, and exchange partner
scope of the health IT’s certification. costs he may incur in the course of technology—may impact the costs of
Such information is ‘‘material’’ (and its implementing and using capabilities for those services. One commenter stated
disclosure therefore required) if the any purpose within the scope of the that developers should be required to
failure to disclose it could substantially health IT’s certification. disclose more detailed and specific cost
interfere with the ability of a user or Comments. A commenter asked structures that include costs and fees
prospective user to implement certified whether a developer would be required not covered by the provider’s service
health IT in a manner consistent with its to disclose known material limitations contract. Another commenter stated that
certification. Certain kinds of of its certified health IT where the developers should be required to
limitations and additional types of costs limitations are due to the actions of a disclose costs that could arise from
will always be material and thus, if third-party from whom the developer common end-user customizations and
known, must be disclosed. These purchases, licenses, or obtains implementations of the developer’s
include but are not limited to: technology, products, or services in health IT. Commenters believed that
• Additional types of costs or fees connection with its own certified health requiring the disclosure of this
(whether fixed, recurring, transaction- IT. The commenter noted that in information would enable customers to
based, or otherwise) imposed by a describing certain kinds of more easily and accurately estimate
developer (or any third-party from presumptively material information that their likely total cost of ownership and
whom the developer purchases, a developer would be required to other costs.
licenses, or obtains any technology, disclose, we mentioned third parties In contrast, several health IT
products, or services in connection with only in connection with types of costs developers and a few other commenters
its certified health IT) to purchase, and not limitations. strongly objected to a requirement to
license, implement, maintain, upgrade, Response. We clarify that a developer disclose any additional information
use, or otherwise enable and support the must disclose known material about prices or costs. One commenter
use of capabilities to which health IT is limitations of its certified health IT, stated that this information and other
certified; or in connection with any data including limitations caused by a third ‘‘commercial terms and conditions’’ are
generated in the course of using any party that the developer should be too varied and complex to be disclosed
capability to which health IT is aware of under the circumstances. in a useful manner to customers. Other
certified. A developer’s disclosure obligations commenters worried that requiring
• Limitations, whether by contract or are limited to material information that disclosure of this information could
otherwise, on the use of any capability the developer knows or should know expose intellectual property, trade
to which technology is certified for any about under the circumstances. The secrets, or other sensitive information.
purpose within the scope of the reference to third parties at Response. We thank commenters for
technology’s certification; or in § 170.526(k)(1)(iv)(A) and above is their extensive input regarding the types
connection with any data generated in intended to limit the material types of of costs and price information health IT
the course of using any capability to costs a developer will be presumed to developers should be required to
which health IT is certified. know about to those that the developer disclose.
• Limitations, including but not itself imposes or that are imposed by a We understand the importance of
limited to technical or practical third party from whom the developer ensuring that health IT developers’
limitations of technology or its purchases, licenses, or obtains any disclosures provide meaningful
capabilities, that could prevent or technology, products, or services in information to customers and users of
impair the successful implementation, connection with its certified health IT. certified health IT. We believe it is
configuration, customization, This reflects the reality that developers important for developers to provide the
maintenance, support, or use of any are unlikely to know about types of kind of information and level of detail
that will enable ordinary purchasers, substantial flexibility as to the content be described with particularity. For
licensees, and users to understand and of their disclosures, including how they example, for additional types of costs
make informed health IT purchasing choose to describe the particular related to the volume of transactions,
and implementation decisions. limitations and additional types of costs the developer would need to explain
At the same time, we appreciate that associated with their certified health IT how the volume of transactions would
the disclosure of certain kinds of products and services. As such, be measured and if variations in volume
proprietary or confidential information developers should be able to comply or types of transactions may trigger
may not be necessary to achieve these with the disclosure requirements additional fees or variations in the
goals and may also lead to undesirable without publishing their prices or cost subscription fee.
consequences. Requiring developers to structures or unnecessarily disclosing Turning to the developer’s HISP
disclose trade secrets and other information that they deem confidential. policy, the developer must disclose this
confidential information, for example, The following scenario and material limitation and the additional
could dampen innovation by making it discussion further illustrate these types of costs a user may incur as a
difficult for developers to license and requirements. result. The developer must explain, for
make their technologies available on • Scenario: A Health IT Module is example, that as a result of its policy the
terms that protect their research and certified to the 2014 Edition transitions transitions of care capability is
investments.177 And requiring the of care certification criterion at restricted and users will be unable to
disclosure of detailed price information § 170.314(b)(1). The developer of the exchange transitions of care summaries
could lessen price competition or even Health IT Module charges a yearly with users of third-party HISPs with
lead to price coordination among ‘‘subscription fee’’ for the use of the whom the developer does not have a
competitors, at least for certain kinds of capability. In making the capability trust agreement. The developer must
products and services in highly available, the developer bundles it with describe, in plain terms, its current
concentrated markets. its own HISP. Because the developer is network of HISPs and how such
We believe the approach described in not a member of any trust network, network would enable a user to
the Proposed Rule accommodates these users can only exchange transitions of exchange transitions of care summaries
concerns by ensuring that developers’ care summaries with other users of the with users of other HISPs servicing a
disclosures are comprehensive, and thus developer’s own HISP and with users of provider’s local referral area, including
meaningful, while also providing third-party HISPs with which the HISPs that participate in trust networks.
certain safeguards against the developer has negotiated or is willing to Further, the disclosure needs to clearly
unnecessary disclosure of proprietary or negotiate a trust agreement. The identify any HISPs with whom the
confidential information. developer also charges a ‘‘transaction developer will not permit exchange or
Consistent with that approach, and to fee’’ for each transitions of care which the developer knows will not
comply with this final rule, a developer summary sent or received via a third- agree to a trust agreement with the
must make a comprehensive disclosure party HISP (the transaction fee does not developer (e.g., because the developer is
of all known material information apply for transitions of care summaries not a member of a particular trust
regarding its certified health IT— exchanged among users of the network). If the developer offers the
including limitations and additional developer’s own HISP). option to customers to connect to third-
types of costs. With respect to types of Under these facts, the developer must party HISPs with whom the developer
disclose the existence of the currently has no relationship, the
costs, the disclosure must identify and
subscription fee and the transaction developer must describe the process for
describe the types of costs with
fee—each of which is a known material customers to request such connectivity.
particularity, from which a potential
type of cost associated with the The developer must also describe any
customer or user would be able to
transitions of care capability. In additional types of costs that may apply
reasonably understand his potential
addition, the developer must disclose for this service, including a description
costs to implement and use the health
the known material limitation (and any of any factors (e.g., geographical
IT for any purpose within the scope of
associated additional types of costs) considerations or variability in HISP
the health IT’s certification. The
presented by its HISP policy. The technologies and trust policies) that
disclosure must also describe the factors
developer must describe each of these impact the amount a customer would
that impact additional types of costs, have to pay.
including but not limited to additional types of costs and limitations
with particularity to the extent they Finally, the developer would need to
geographical considerations, volume disclose the separate ‘‘transaction fee’’
and usage, costs associated with impact the implementation and use of
the transitions of care capability for any charged for exchanging transitions of
necessary interfaces or other licenses or care summaries with users of third-party
technology, and costs associated with purpose to which it is certified.
Beginning with the ‘‘subscription HISPs. Disclosure of all additional types
exchange partner technology and of costs based on volume, geography, or
characteristics, among other relevant fee,’’ the developer must disclose that
there is such a fee along with any factors exchange partner technology would be
factors. Since certified technical required. The developer would also be
capabilities may be bundled with non- that impact the amount a customer
would have to pay. Examples include required to provide additional
certified capabilities, any disclosure information to assist the customer in
would need to include an explanation of number of licenses or limitations on the
number of workstations where the realistically understanding additional
any limitations such other non-certified potential costs of sending and receiving
capabilities may have on the use or software is deployed, additional types of
transitions of care summaries via third-
implementation of the certified costs related to the volume of

transactions, or usage, or associated party HISPs.
capabilities.178 Developers have The scenario and discussion above
bandwidth costs for a customer’s
illustrate the substantial flexibility
177 See M. Jager, 1 Trade Secrets Law § 1.1; transactions. Such factors would need to
developers have in determining the
Restatement (Third) of Unfair Competition § 39,
cmt. a. intellectual property, upgrades, or packaged
content of their disclosures, including
178 Health IT includes ‘‘hardware, software, solutions sold as services. . . .’’ 42 U.S.C. how they choose to describe the
integrated technologies or related licenses, § 300jj(5). particular limitations and types of costs
associated with their certified health IT included and updated on the § 170.523(k)(1)(ii), developers must
products and services. We caution, developer’s website regardless of include in their disclosures only a
however, that developers are ultimately whether the website refers to the subset of this information that will be
responsible for effectuating a certification or certified status of the valuable to customers in making
comprehensive disclosure that satisfies developer’s health IT. The information informed decisions about their certified
the expanded requirements of this final must also be located in a place that is health IT.
rule. Because developers have accessible and obvious to viewers and Comments. Several commenters
substantial flexibility as to the form and contextually relevant to the certification supported our proposal to require
content of their disclosures, it is criteria to which the disclosures pertain. developers to attest to voluntarily
unlikely that they would have to For the reasons stated by the providing information about their
disclose proprietary or confidential commenters, we agree that requiring a required disclosures to additional
information in order to comply with comprehensive disclosure in all persons and in additional
these requirements. However, the marketing materials and other assertions circumstances. Other commenters
safeguards we have adopted are may be burdensome and questioned the value of this requirement
prophylactic and do not create a counterproductive to our goal of or stated that it was duplicative of the
substantive basis for a developer to providing this information to customers other requirements we proposed. Some
refuse to comply with the requirements. in a manner that is meaningful and commenters stated that requiring
Thus a developer cannot cure a likely to inform. Therefore, we clarify developers to provide such an
deficient disclosure or avoid a non- that a developer may satisfy the attestation as a condition of certification
conformity finding by asserting that the requirement to disclose the information would in effect make compliance with
disclosure of known material limitations required by § 170.523(k)(1) in its the attestation mandatory.
or types of costs would require it to marketing materials, communications Response. We appreciate the
disclose trade secrets or other statements, and other assertions related comments in support of the proposed
proprietary or confidential information. to a Complete EHR or Health IT attestation requirement, which we
We note that the ONC Health IT Module’s certification by providing an regard as a key feature of the
Certification Program is a voluntary abbreviated disclaimer, appropriate to transparency and disclosure
program. To the extent that developers the material and medium, provided the requirements adopted in this final rule.
choose to seek certification under the disclaimer is accompanied by a In response to the comments
Program and to market their products hyperlink to the complete disclosure on questioning the value of this additional
and services as certified health IT, they the developer’s website. Where a requirement, we clarify that the purpose
must comply with the transparency and hyperlink is not feasible (for example, in of the attestation is to create market
disclosure requirements in their non-visual media), the developer may incentives—independent of any
entirety. use another appropriate method to regulatory obligations—for health IT
Comments. An ONC–ACB stated that direct the recipient of the marketing developers to be more transparent about
some health IT developers have material, communication, or assertion to their health IT products, services, and
circumvented the requirement to the complete disclosure on its website. business practices. Although the
disclose required information on their Because of the challenges and attestation does not create any
websites by omitting discussion of the accommodations described above, and additional disclosure obligations under
certification or certified status of their the need to ensure that customers and the ONC Health IT Certification
health IT. The ONC–ACB asked us to users are able to easily locate Program, we believe it will encourage
clarify whether such conduct is information about certified health IT developers to make a good faith effort to
permissible or constitutes a violation of products and services, we believe that ensure that customers and other persons
the disclosure requirements under developers’ disclosures should be actually receive the information that
§ 170.523(k)(1). Relatedly, multiple accessible from a single, authoritative developers are required to disclose at
ONC–ACBs asked whether it would be source. Thus, we have included a such times and in such a manner as is
permissible for a developer to use an developer’s disclosures as part of the likely to be useful in informing their
abbreviated or alternative disclosure information that an ONC–ACBs must health IT purchasing or licensing,
more appropriate to the kind of submit to ONC for inclusion in the open implementation, and other decisions.
marketing material and medium at data CHPL. We have revised In the Proposed Rule, we explained
issue. One commenter noted that § 170.523(f)(1) and (f)(2) to reflect this that the attestation would take the form
requiring a detailed disclosure of requirement. of a written ‘‘pledge’’ by the developer
information in all marketing materials In keeping with the goal of making to take the additional, voluntarily step
or assertions about certified health IT is developers’ disclosures accessible and of proactively providing information
impracticable and not helpful to useful to customers and other (which it would already be required to
customers. It may also discourage stakeholders, we have also revised disclose via its Web site and in
developers from including such § 170.523(k)(1)(ii), which requires marketing and other materials) to all
assertions in marketing and promotional developers to include in their current and prospective customers as
materials or from using certain kinds of disclosures certain types of well as to any other persons who
materials or media. administrative and programmatic request such information. While we
Response. A health IT developer’s information they are required to report stated that the attestation would not
website is not only one of its most to ONC. While the reporting and broaden or change a health IT
powerful marketing tools but also, for availability of this information is developer’s disclosure obligations under
most people, among the most readily important and is still required by the ONC Health IT Certification
available sources of information about a § 170.523(f)(1) and (2), requiring Program, some commenters believed
developer’s health IT products and developers to insert all of this that in practice developers would be
services. It is therefore essential that a information in their disclosures could forced to comply with the attestation.
developer include the information add unnecessary clutter and detract Because that was and is not our intent,
specified by § 170.523(k)(1) on its from the overall accessibility and clarity we have revised the attestation
website. This information must be of those disclosures. Therefore, under requirement. Under the revised
approach, which we have codified at ONC–ACBs upon issuing a 2015 Edition CHPL. Multiple commenters agreed that
§ 170.523(k)(2), a developer must either (or any subsequent edition certification) information contained in the CHPL has
attest that it will voluntarily take the to report on the same data elements they previously been difficult to access and
actions described above, or, in the report to ONC under § 170.523(f), the use and supported our proposal and
alternative, attest that it will not take information contained in the publicly plans to make this information easier to
these actions. Further, an ONC–ACB available test report, and certain access. Commenters stated that this
will be required to include the additional data listed in the Proposed information and the open data CHPL
developer’s attestation in the Rule. We explained that the additional more generally would provide greater
information submitted to the open data data reported to the open data CHPL product transparency, with a focus on
CHPL so that persons can easily identify would include the information ONC– surveillance, user-centered design, and
which attestation the developer has ACBs would be required to report in testing results.
made. We have revised §§ 170.523(f)(1) connection with corrective action plans Response. We appreciate these
and (f)(2) accordingly. under the proposal ‘‘ ‘In-the-field’ comments in support of our proposal.
Surveillance and Maintenance of We have finalized this proposal in its
3. Open Data Certified Health IT entirety, subject to minor clarifications
Certification’’ in the Proposed Rule.
Product List (CHPL) and revisions discussed below.
Because this data would be required for
We proposed to require ONC–ACBs to all, and not only 2015 Edition, certified Comments. Commenters offered
report an expanded set of information to health IT, we also proposed to revise suggestions on operational details of the
ONC for inclusion in the CHPL upon its new § 170.523(f)(2) (former § 170.523(f)) conversion of the current CHPL to an
conversion from its present form to an accordingly. open data format and on how we should
open data file represented in both XML Consistent with ONC–ACBs’ current subsequently collect and organize
and JSON and with accompanying API reporting practice required by information via the open data CHPL.
functionality. We are converting the § 170.523(f), ONC–ACBs would be Response. We appreciate these
CHPL to this new ‘‘open data CHPL’’ in required to submit the additional data suggestions. While the conversion of the
response to feedback from stakeholders no less frequently than weekly. Because CHPL is already underway, we will
regarding the accessibility of this expanded list of data would largely consider these comments on operational
information on the CHPL, especially the subsume the data included in the test aspects of the open data CHPL as we
information contained in the publicly results summary, we would no longer continue to implement these efforts.
available test reports for certified health require for 2015 Edition and subsequent Comments. Some commenters stated
IT products.179 We estimated that the edition certifications that ONC–ACBs that this proposal was unnecessary or
conversion along with the future provide a publicly accessible hyperlink that its benefits would be outweighed by
additional data collection we have to the test results used to certify a associated costs and administrative
proposed for 2015 Edition certifications Health IT Module. burden of collecting and reporting an
would occur over the next 12 to 18 In submitting this data related to expanded set of information to ONC for
months from the date the Proposed Rule corrective action and surveillance, inclusion in the new open data CHPL.
was issued. ONC–ACBs would be required to Commenters asked us to review the
To complement this conversion, we exclude any information that would proposed reporting requirements to see
proposed to require ONC–ACBs to identify any user or location that if they might be clarified and simplified.
report an expanded set of information to participated in or was subject to Response. While we recognize that
ONC for inclusion in the open data surveillance (as currently required for the collection and reporting of
CHPL. Specifically, we proposed to ONC–ACBs’ annual surveillance results additional data to the open data CHPL
revise § 170.523(f) to move the current reported to the ONC). ONC–ACBs will place a new reporting burden on
(f) to (f)(2) and to create a new would not be required and should take ONC–ACBs, we believe that the benefit
paragraph (f)(1) that would require care not to submit proprietary to the public of having all of this data
information to ONC for inclusion in the about product certification in granular
179 As the ONC Health IT Certification Program
open data file. With respect to the detail far outweighs the administrative
has matured, ONC–ACBs have continued to report reporting of corrective action plan and burden it will take to report this
the products and information about the products
they have certified to ONC for listing on the CHPL. surveillance information for health IT, information.
As part of the 2014 Edition final rule (77 FR 54271), an ONC–ACB would be able to meet the Comments. A number of commenters,
we required additional transparency in the ONC requirement by summarizing the including several health IT developers,
Health IT Certification Program in the form of a deficiencies leading to its non- objected to the reporting of corrective
hyperlink that ONC–ACBs needed to maintain that
would enable the public to access the test results conformity determination without action plan information to the publicly
that the ONC–ACB used as the basis for issuing a disclosing information that the ONC– accessible open data CHPL. Some
certification. For all 2014 Edition products certified ACB believes could be proprietary or commenters felt that information about
under the ONC Health IT Certification Program, the non-conformities should not be made
test results are available in a standardized summary
expose it to liability.
accessible and from the product’s detailed Consistent with these proposals, we public unless and until the developer of
information page on the CHPL Web page. The test also proposed to make a conforming the certified Complete EHR or certified
result summary includes granular detail from ATLs modification to 45 CFR 170.523(k)(1)(ii) Health IT Module at issue has been
about the testing performed, including, among other given a full and fair opportunity to
information: The certification criteria tested; the
which currently cross references
test procedure, test data, and test tool versions used § 170.523(f) to cross reference proposed contest the ONC–ACB’s determination,
during testing for each certification criterion; paragraph (f)(2) for 2014 Edition including whether the developer was
instances where optional portions of certification certifications and an equivalent set of responsible or ‘‘at fault’’ for the non-
criteria were tested; and which standard was used conformity. Other commenters stated
for testing when a certification criterion allowed for
data (minus the test results summary) in
more than one standard to be used to meet the paragraph (f)(1) for 2015 Edition and that such information should never be
certification criterion. The test result summary also subsequent certifications. made public because it is bound to lack
includes the user-centered design information and Comments. Most commenters important context, could be
summative tests results applicable to a product in
cases where it was required to meet the ‘‘safety-
supported requiring ONC–ACBs to misinterpreted, or would not offer
enhanced design’’ certification criterion report an expanded set of information to substantial value to health IT customers
(§ 170.314(g)(3)) in order to ultimately be certified. ONC for inclusion in the open data and users. Separately, some commenters
raised concerns regarding the reporting two ways. We proposed to require that years, which may not be a sufficient
of proprietary or competitively sensitive ONC–ACBs retain all records related to period of time or too long a period of
information. the certification of Complete EHRs and/ time. It also provides consistency and
Response. We have addressed the or Health IT Module(s) (including EHR reduced burden for ONC–ACB record
concerns related to the submission of Modules) for a minimum of 6 years keeping. To illustrate this point,
corrective action plan and related instead of 5 years as was required by establishing a record keeping period
information to the open data CHPL in regulation. We stated that this proposal based on an event such as an instance
section IV.D.1 of this preamble (‘‘ ‘In- would make certification records of first certification or a surveillance
the-field’ Surveillance and Maintenance available for a longer time period, which activity would lead to variances in
of Certification Criteria’’). For the may be necessary for HHS programmatic ONC–ACB record keeping for certified
reasons stated there, we have finalized purposes such as evaluations or audits. health IT, while under our finalized
the requirement to submit a corrective We also proposed that records of approach all records would be retained
action plan and related information to certifications performed under the ONC until a regulatory certain date (at least
the open data CHPL. Further, we have Health IT Certification Program must be 3 years after an edition is removed from
revised the specific data elements that available to HHS upon request during the CFR). To note, the record would
must be submitted to accommodate the the proposed 6-year period that a record include all documents related to the
revised randomized in-the-field is retained. We stated that this would issued certification, such as test results
surveillance and corrective action plan help clarify the availability of and surveillance engagements and
and related reporting requirements certification records for agencies (e.g., results.
finalized at §§ 170.556(c)–(e). CMS) and authorities (e.g., the Office of
Comments. Some commenters 5. Complaints Reporting
Inspector General) within HHS.
expressed confusion as to why we Comments. A majority of commenters We proposed that ONC–ACBs provide
proposed to require the submission of expressed support for the proposed 6- ONC (the National Coordinator) with a
corrective action and related year records retention requirement list of complaints received on a
information only for randomized without additional comment. One quarterly basis. We proposed that ONC–
surveillance and not for other commenter suggested a 10-year ACB indicate in their submission the
surveillance activities. Commenters also requirement. Another commenter number of complaints received, the
suggested several technical recommended record retention nature or substance of each complaint,
clarifications to our proposed regulation requirements for the life of the edition and the type of complainant for each
text to ensure alignment between our of certification criteria. A commenter complaint (e.g., type of provider, health
‘‘Open Data CHPL’’ and ‘‘ ‘In-the-field’ requested clarification on the start date IT developer, etc.). We stated that this
Surveillance and Maintenance of of the retention period, asking whether information would provide further
Certification’’ proposals. the start date was from the first instance insight into potential concerns with
Response. We have responded to of certification for a product or from the certified health IT and/or the ONC
these concerns in section IV.D.1 of this last documented date of an activity Health IT Certification Program and give
preamble (‘‘ ‘In-the-field’ Surveillance related to the certification such as ONC a better ability to identify trends or
and Maintenance of Certification surveillance. issues that may require action including
Criteria’’) and refer commenters to that Response. We thank commenters for notification of the public.
section for a more detailed treatment of their feedback. We have adopted a Comments. A majority of commenters
these issues. For the reasons stated records retention provision that requires expressed support for the proposed
there, we agree with commenters that ONC–ACBs to retain all records related quarterly complaints reporting
the requirement to submit corrective to the certification of Complete EHRs requirement. Some commenters,
action and related information to the and/or Health IT Module(s) (including however, expressed opposition or
open data CHPL should be applied to all EHR Modules) for the ‘‘life of the concern with the proposed requirement.
forms of surveillance and all confirmed edition’’ plus an additional 3 years. We These commenters stated that the
non-conformities. We have also refined have also adopted our proposal to make proposed requirement would add
the data elements required to be these records available to HHS upon certification cost without value. A few
reported for reasons also set forth in request during this period of time for commenters recommended a more
section IV.D.1 of this preamble. To the reasons specified above and in the robust reporting requirement than
implement these changes we have Proposed Rule. We define the ‘‘life of proposed, suggesting we require a more
revised the randomized in-the-field the edition’’ as beginning with the comprehensive list of complaint data as
surveillance and corrective action plan codification of an edition of certification well as aggregated and analyzed data.
reporting requirements at §§ 170.556(c)– criteria in regulation and ending when One commenter requested clarification
(e) and have made conforming revisions the edition is removed from regulation. on whether the proposed requirement
to § 170.523(k)(1) and § 170.523(k)(2) to This means that certification records for would apply to any complaint received
accommodate the revised data elements. a Complete EHR and/or Health IT by an ONC–ACB, such as complaints
As discussed in section IV.D.2 of this Module(s) (including EHR Modules) about an ONC–ACB’s services and
preamble (‘‘Transparency and certified to a specific edition (e.g., the complaints about certified Health IT
Disclosure Requirements’’), we have 2015 Edition) must be kept for a Modules.
also added developers’ disclosures minimum of 3 years after the effective Response. We have adopted this
required by § 170.523(k)(1) and their date of the removal of that edition from requirement as proposed with
attestations required by § 170.523(k)(2) the Code of Federal Regulations (CFR). clarifications in response to comments.
to the data that must be submitted to This approach is responsive to We continue to believe that this
ONC for inclusion in the open data commenters and addresses the goal of requirement will provide us with
CHPL. ensuring records are available for HHS insight and situational awareness of
programs, including evaluations and issues related to the ONC Health IT
4. Records Retention audits, during a relevant period of time. Certification Program. We further
We proposed to change the records It provides more clarity and certainty believe these benefits outweigh the
retention requirement in § 170.523(g) in than establishing a term such as 6 or 10 limited reporting burden we have
specified, which does not adopt any not result in risks to the certified health or certified Health IT Module, including
new reporting requirements as IT and that the burden to collect a list EHR Modules. Second, the CHPL does
suggested by a few commenters. We of these updates would not be worth the not list updates to products unless they
clarify that this requirement applies to effort. Some commenters noted that are presented for separate certification.
all complaints received by the ONC– health IT developers time their major This policy allows a health IT developer
ACB. This includes, but is not limited updates with certification to reflect a to update a product for routine
to, complaints regarding ONC–ACB new product listing on the CHPL maintenance or to include new or
services, certified health IT, and the whereas others do not. These modified capabilities without the need
ONC Health IT Certification Program in commenters suggested there is for recertification. However, in these
general. To provide ONC–ACBs inconsistency in the industry in the instances, the product name and version
sufficient time to meet this new versioning of certified products. One on the CHPL would remain unchanged.
requirement, this provision will become commenter recommended that we We established an attestation process for
effective on April 1, 2016. This means provide guidance on consistently a product to be approved for inherited
that we expect ONC–ACBs to first distinguishing major from minor certified status to provide a more
provide ONC with a list of complaints updates for products listed on the efficient pathway for certification for a
received on July 1, 2016. CHPL. new version of a previously certified
We intend to provide, as necessary, Response. In response to comments product in the Permanent Certification
more specific guidance to ONC–ACBs and to balance the ONC–ACBs’ burden, Program final rule (76 FR 1306). As part
through the annual ONC Health IT we have adopted a more limited of this policy, we noted that we do not
Certification Program surveillance requirement than proposed. We agree presume the version numbering schema
guidance on reporting complaints with commenters that many updates to that a health IT developer may choose
received regarding certified Health IT certified health IT products would not to utilize. For compliance with this
Modules. normally pose a risk to certified requirement, the focus on ‘‘updates’’ is
6. Adaptations and Updates of Certified capabilities or patient safety. As such, for all updates to certified Health IT that
Health IT we have limited the requirement to only affect the capabilities included in
adaptations (all adaptations); and all certification criteria to which the
We proposed to require that ONC– ‘‘safety-enhanced design’’ criteria apply.
updates that affect the capabilities
ACBs obtain monthly reports from Comments. A commenter requested
included in certification criteria to
health IT developers regarding their that we clarify the definition of an
which the ‘‘safety-enhanced design’’
certified health IT. Specifically, we ‘‘adaptation.’’ Another commenter
certification criteria apply.180 These
proposed to require that ONC–ACBs suggested that ONC–ACBs should only
obtain a record of all adaptations and types of updates, particularly changes to
the user-interface, pose the greatest risk be required to monitor adaptations
updates, including changes to user- made by the health IT developer as it
facing aspects, made to certified health to patient safety. The adoption of this
requirement will provide ONC–ACBs would be impractical for an ONC–ACB
IT (i.e., Complete EHRs and certified to monitor all customer-initiated
Health IT Modules), on a monthly basis with more insight and transparency into
these kinds of updates and adaptations, adaptations. A commenter requested
each calendar year, and we requested clarification as to whether an ONC–ACB
comment on whether we should require which should improve ONC–ACBs’
situational awareness and surveillance. is expected to review each report from
even more frequent reporting. We stated a health IT developer, which the
that this new PoPC would apply for all We thank the commenter for the
commenter contended could be time-
certified Complete EHRs and certified feedback on distinguishing major and
consuming and costly. Another
Health IT Modules (which includes minor updates. We first note that, as
commenter requested clarification as to
‘‘EHR Modules’’) to the 2014 Edition stated in the 2014 Edition final rule (77
whether an ONC–ACB has the
and all certified Health IT Modules to FR 54268), unless adaptations are
authorization to suspend or withdraw a
the 2015 Edition. presented for separate certification, the
certification if the health IT developer
We proposed that the PoPC would CHPL would not independently list the
does not provide a report of adaptations
become effective with this final rule and adaptation because it is considered part
and updates within the specified
we would expect ONC–ACBs to begin of a previously certified Complete EHR
timeframe.
complying with the PoPC at the 180 2014 Edition certification criteria: CPOE
Response. We maintain our
beginning of the first full calendar (§ 170.314(a)(1)); drug-drug, drug-allergy interaction previously adopted definition of an
month that is at least 30 days after the checks (§ 170.314(a)(2)); medication list ‘‘adaptation’’ as a software application
effective date of the final rule. We (§ 170.314(a)(6)); medication allergy list designed to run on a different medium
explained that we would not expect the (§ 170.314(a)(7)); clinical decision support that includes the full and exact same
(§ 170.314(a)(8)); electronic medication
information in these records to be administration record (§ 170.314(a)(16)); CPOE—
capabilities included in the Complete
reported to ONC and listed on the medications (§ 170.314(a)(18)); CPOE— laboratory EHR or certified Health IT Module,
CHPL. Rather, we stated that the best (§ 170.314(a)(19)); CPOE—diagnostic imaging including EHR Modules (77 FR 54267).
course of action would be for ONC– (§ 170.314(a)(20)); electronic prescribing We refer readers to the discussion in the
(§ 170.314(b)(3)); clinical information reconciliation
ACBs to retain this information to (§ 170.314(b)(4)); and clinical information
2014 Edition final rule preamble for
provide awareness to the ONC–ACB on reconciliation and incorporation (§ 170.314(b)(9)). more detailed examples of adaptations
adaptations and updates made to 2015 Edition certification criteria: CPOE— (77 FR 54267). We also previously
technologies they certified. medications (§ 170.315(a)(1)); CPOE— laboratory stated in the 2014 Edition final rule (77
Comments. We received mixed (§ 170.315(a)(2)); CPOE—diagnostic imaging FR 54268) that a health IT developer can
(§ 170.315(a)(3)); drug-drug, drug allergy interaction

comments in response to the proposal. checks (§ 170.315(a)(4)); demographics
choose to seek certification for
A number of commenters supported the (§ 170.315(a)(5)); problem list (§ 170.315(a)(6)); adaptations which would lead to it
proposal, but expressed concerns with medication list (§ 170.315(a)(7)); medication allergy being separately listed on the CHPL and
the volume and frequency of updates to list (§ 170.315(a)(8)); clinical decision support permit the health IT developer to openly
(§ 170.315(a)(9)); implantable device list
certified health IT. Commenters stated (§ 170.315(a)(14)); clinical information
sell the adaptation to all potential
that updates could arise from relatively reconciliation and incorporation (§ 170.315(b)(2)); purchasers as a separate certified
small changes to software code that do and electronic prescribing (§ 170.315(b)(3)). product.
We would expect that ONC–ACBs In the Proposed Rule, we stated that consideration as we determine whether
obtain a record of adaptations of additional rulemaking would be a new regulatory ‘‘decertification’’
certified health IT made by the health IT necessary to implement any approach process for health IT is necessary or
developer as those are the adaptations that would include ONC appropriating whether other steps could better support
covered by the issued certification. An an ONC–ACB’s delegated authority to the continued compliance of certified
ONC–ACB has the discretion in issue and terminate a certification, health IT with certification
determining how much time and including establishing new program requirements, the unencumbered access
resources should be devoted to requirements and processes by which and use of certified capabilities of
reviewing the lists provided by health ONC or an ONC–ACB would have the health IT, the unrestricted exchange of
IT developers. As previously noted, we grounds to terminate an issued health information, and overall
expect this information to inform ONC– certification. We requested comment on interoperability.
ACBs surveillance activities for certified the circumstances, due process,
V. Incorporation by Reference
health IT. In terms of non-compliance remedies, and other factors that we
by a health IT developer in providing should consider regarding the • The Office of the Federal Register
the requisite list, we note that an ONC– termination of a certification. To assist has established new requirements for
ACB retains its authority and oversight commenters, we provided a brief materials (e.g., standards and
over the certifications it issues and has background of the ONC Health IT implementation specifications) that
the discretion to implement that Certification Program and examples of agencies incorporate by reference in the
authority and oversight in a manner that the complexities and potential impacts Federal Register (79 FR 66267; 1 CFR
supports its role and responsibilities as associated with terminating a 51.5). Specifically, § 51.5(b) requires
well as the integrity of the ONC Health certification. We asked commenters to agencies to discuss, in the preamble of
IT Certification Program. account for the potentially profound a final rule, the ways that the materials
asymmetric impacts revoking a they incorporate by reference are
Comments. We received a number of
certification could create, especially if reasonably available to interested
comments on the proposed frequency in
based on the business practices (by parties and how interested parties can
which an ONC–ACB would have to
health IT developers or their customers) obtain the materials; and summarize, in
obtain a record of all adaptations and
associated with the health IT’s use and the preamble of the final rule, the
applicable updates, with many
not necessarily the health IT’s material they incorporates by reference.
commenters suggesting quarterly To make the materials we have
reporting. Another commenter performance according to certification
requirements. incorporated by reference reasonably
suggested that the reports should be available, we provide a uniform
Comments. Commenters
required only when adaptations and resource locator (URL) for the standards
overwhelmingly expressed support for
updates occur, or alternately weekly. and implementation specifications. In
the decertification of health IT products
Response. We have finalized a that did not continue to meet many cases, these standards and
calendar quarter reporting frequency for certification requirements or proactively implementation specifications are
this requirement. This approach blocked the sharing of health directly accessible through the URL
addresses commenters’ concerns about information. Of these commenters, the provided. In instances where they are
burden, but also ensures that ONC– majority supported a clear and not directly available, we note the steps
ACBs receive timely notifications about structured approach to and requirements necessary to gain
new adaptations and updates that could ‘‘decertification,’’ with some access to the standard or
affect the safety of certified health IT. In commenters specifically recommending implementation specification. In most of
order to provide ONC–ACBs and health a regulatory approach that could be these instances, access to the standard
IT developers sufficient time to plan implemented as soon as possible. or implementation specification can be
and implement this new requirement, However, other commenters opposed gained through no-cost (monetary)
this PoPC will not become effective changing the current approach or, at a participation, subscription, or
until April 1, 2016. For clarity, we minimum, urged caution in membership with the applicable
reiterate that this PoPC applies to all implementing a new ‘‘decertification’’ standards developing organization
certifications issued to the 2014 Edition, process. In this regard, commenters (SDO) or custodial organization. In
2015 Edition, and future editions of recommended clear parameters be certain instances, where noted, access
certification criteria. We expect all established that would lead to requires a fee or paid membership.
ONC–ACBs to receive lists from health decertification; appropriate due The National Technology Transfer
IT developers on July 1, 2016, and then processes, including sufficient and Advancement Act (NTTAA) of 1995
every calendar quarter thereafter (e.g., opportunities to correct deficiencies and (15 U.S.C. 3701 et seq.) and the Office
October 1, 2016, January 1, 2017, and so non-compliance; and safeguards for of Management and Budget (OMB)
on). non-culpable parties, such as ‘‘hold Circular A–119 181 require the use of,
E. ‘‘Decertification’’ of Health IT— harmless’’ provisions, hardship wherever practical, technical standards
Request for Comments exemptions, and ‘‘safe harbors’’ when that are developed or adopted by
applicable. A few commenters also voluntary consensus standards bodies to
The Proposed Rule proposed and the suggested that further stakeholder input carry out policy objectives or activities,
final rule take certain steps to support was needed before considering with certain exceptions. The NTTAA
the certification of health IT that meets regulations, particularly to fully and OMB Circular A–119 provide
relevant program standards and permits understand the ‘‘downstream’’
exceptions to selecting only standards

the unrestricted use of certified implications of ‘‘decertification.’’ developed or adopted by voluntary
capabilities that facilitate health Response. We thank commenters for consensus standards bodies, namely
information exchange (see the ‘‘In-The- their feedback. As noted in the Proposed when doing so would be inconsistent
Field Surveillance and Maintenance of Rule, additional rulemaking would be with applicable law or otherwise
Certification’’ and ‘‘Transparency and necessary to implement any new
Disclosure Requirements’’ proposals in ‘‘decertification’’ process. We will take 181 http://www.whitehouse.gov/omb/
section IV.D of this preamble). the comments received under circulars_a119.
impractical. As discussed in section Summary: This document provides information systems help deliver
III.A.2 of this preamble, we have implementation guidance enabling clinical knowledge to the point of care
followed the NTTAA and OMB Circular Security/Trust Agents (STAs) to provide as well as patient-tailored education
A–119 in adopting standards and a high level of assurance that a message material. This implementation guide
implementation specifications, has arrived at its destination. It also provides a standard mechanism for EHR
including describing any exceptions in outlines the various exception flows systems to submit knowledge requests
the adoption of standards and that result in a compromised message over the HTTP protocol through a
implementation specifications. Over the delivery and the mitigation actions that standard using a URL format.
years of adopting standards and should be taken by STAs to provide Content Exchange Standards and
implementation specifications for success and failure notifications to the Implementation Specifications for
certification, we have worked with sending system. Exchanging Electronic Health
SDOs, such as HL7, to make the
Functional Standards—45 CFR 170.204 Information—45 CFR 170.205
standards we adopt and incorporate by
reference in the Federal Register • HL7 Version 3 Standard: Context • HL7 CDA® R2 Implementation
available to interested stakeholders. As Aware Knowledge Retrieval Application Guide: Quality Reporting Document
described above, this includes making (‘‘Infobutton’’), Knowledge Request, Architecture—Category I (QRDA I);
the standards and implementation Release 2. Release 1, Draft Standard for Trial Use
specifications available through no-cost URL: http://www.hl7.org/implement/ (DSTU) Release 3 (US Realm), Volumes
memberships and no-cost subscriptions. standards/product_brief.cfm?product_ 1 (Introductory Material) and 2
As required by § 51.5(b), we provide id=208. Access requires a ‘‘user (Templates and Supporting Material).
summaries of the standards and account’’ and a license agreement. There URL: http://www.hl7.org/implement/
implementation specifications we have is no monetary cost for a user account standards/product_brief.cfm?product_
adopted and incorporated by reference and license agreement. id=35. Access requires a ‘‘user account’’
in the Federal Register. We also provide Summary: The Context-aware and a license agreement. There is no
relevant information about these knowledge retrieval specifications monetary cost for a user account and
standards and implementation (Infobutton) provide a standard license agreement.
specifications throughout section III.3 of mechanism for clinical information Summary: The Quality Reporting
the preamble. In particular, in relevant systems to request context-specific Document Architecture (QRDA) is an
instances, we identify differences clinical knowledge from online electronic document format that
between previously adopted versions of resources. Based on the clinical context, provides a standard structure with
standards and implementation which includes characteristics of the which to report quality measure data to
specifications and 2015 Edition adopted patient, provider, care setting, and organizations that will analyze and
versions of standards and clinical task, Infobutton(s) anticipates interpret the data. The Release 3 IG is
implementation specifications. clinicians’ and patients’ questions and consistent with the CDA, and Category
We have organized the following provides automated links to resources I is an individual-patient-level quality
standards and implementation that may answer those questions. report. The Release 3 IG includes
specifications that we have adopted • HL7 Implementation Guide: updates to align with the Quality Data
through this final rule according to the Service-Oriented Architecture Model version 4.1.2; incorporates
sections of the Code of Federal Implementations of the Context-aware appropriate QRDA Category I Release 2
Regulation (CFR) in which they are Knowledge Retrieval (Infobutton) (R2) DSTU comments that were
codified and cross-referenced for Domain, Release 1. considered as New Feature Requests;
associated certification criteria that we URL: http://www.hl7.org/implement/ and updates of the QRDA I R1 DSTU
have adopted in 45 CFR 170.315. standards/product_brief.cfm?product_ Release 3 templates to align with the C–
id=283. Access requires a ‘‘user CDA R2 templates where applicable.
Transport and Other Protocol account’’ and a license agreement. There • Errata to the HL7 Implementation
Standards—45 CFR 170.202 is no monetary cost for a user account Guide for CDA® Release 2: Quality
• Applicability Statement for Secure and license agreement. Reporting Document Architecture—
Health Transport, Version 1.2. Summary: Context-aware knowledge Category III, DSTU Release 1 (US
URL: http://wiki.directproject.org/file/ retrieval (Infobutton) into clinical Realm), September 2014.
view/Applicability+Statement+for+ information systems help deliver URL: http://www.hl7.org/implement/
Secure+Health+Transport+v1.2.pdf. clinical knowledge to the point of care standards/product_brief.cfm?product_
This is a direct access link. as well as patient-tailored education id=286. Access requires a ‘‘user
Summary: This document is intended material. This specification enables the account’’ and a license agreement. There
as an applicability statement providing implementation of context-aware is no monetary cost for a user account
constrained conformance guidance on knowledge retrieval applications and license agreement. The DSTU
the interoperable use of a set of Requests through a Service Oriented Architecture package must be downloaded in order to
for Comments (RFCs) describing based on the RESTful software access the errata.
methods for achieving security, privacy, architectural style. Summary: The September 2014 Errata
data integrity, authentication of sender • HL7 Version 3 Implementation reflects updates for the implementation
and receiver, and confirmation of Guide: Context-Aware Knowledge of QRDA Category I consistent with the
delivery consistent with the data Retrieval (Infobutton), Release 4. Quality Data Model-based Health
transport needs for health information URL: http://www.hl7.org/implement/ Quality Measures Format Release 2.1, an
exchange. standards/product_brief.cfm?product_ incremental version of harmonized

• Implementation Guide for Delivery id=22. Access requires a ‘‘user account’’ clinical quality measure and CDS
Notification in Direct, Version 1.0. and a license agreement. There is no standards.
URL: http://wiki.directproject.org/file/ monetary cost for a user account and • HL7 Implementation Guide for
view/Implementation+Guide+for+ license agreement. CDA® Release 2: Consolidated CDA
Delivery+Notification+in+Direct+ Summary: Context-aware knowledge Templates for Clinical Notes (US
v1.0.pdf. This is a direct access link. retrieval (Infobutton) in clinical Realm), Draft Standard for Trial Use,
Release 2.1, Volumes 1 (Introductory facilitate exchange of immunization (Introductory Material) and 2
Material) and 2 (Templates and records between different systems. (Templates and Supporting Material).
Supporting Material). • HL7 Version 2.5.1 Implementation URL: http://www.hl7.org/implement/
URL: http://www.hl7.org/ Guide for Immunization Messaging standards/product_brief.cfm?product_
documentcenter/public/standards/dstu/ (Release 1.5)—Addendum, July 2015. id=398. Access requires a ‘‘user
CDAR2_IG_CCDA_CLINNOTES_R1_ URL: http://www.cdc.gov/vaccines/ account’’ and a license agreement. There
DSTUR2.1_2015AUG.zip. Access programs/iis/technical-guidance/ is no monetary cost for a user account
requires a ‘‘user account’’ and a license hl7.html. and license agreement.
agreement. There is no monetary cost Summary: This addendum Summary: As ambulatory health care
for a user account and license consolidates the HL7 Version 2.5.1 providers adopt modern EHR systems,
agreement. Implementation Guide for the opportunity to automate cancer
Summary: The Consolidated CDA (C– Immunization Messaging, Release 1.5 registry reporting from ambulatory
CDA) IG contains a library of CDA information that clarifies the health care provider settings is also
templates, incorporating and conformance requirements. This increasing and becoming more feasible.
harmonizing previous efforts from HL7, supplement does not specify additional This document provides clear and
IHE, and the Health Information requirements; it just clarifies existing concise specifications for electronic
Technology Standards Panel (HITSP). It ones. Value set requirements, general reporting form ambulatory health care
represents harmonization of the HL7 clarifications, and Immunization IG provider EHR systems to public health
Health Story guides, HITSP C32, related errata are also provided in this central cancer registries using the HL7
components of IHE Patient Care addendum. CDA based standards. This document is
Coordination (IHE PCC), and Continuity • PHIN Messaging Guide for designed to guide EHR vendors and
of Care (CCD). The C–CDA Release 2.1 Syndromic Surveillance: Emergency public health central cancer registries in
IG, in conjunction with the HL7 CDA Department, Urgent Care, Inpatient and the implementation of standardized
Release 2 (CDA R2) standard, is to be Ambulatory Settings, Release 2.0, April electronic reporting.
used for implementing the following 21, 2015. • IHE IT Infrastructure Technical
URL: http://www.cdc.gov/nssp/ Framework Volume 2b (ITI TF–2b).
CDA documents and header constraints
documents/guides/ URL: http://www.ihe.net/Technical_
for clinical notes: Care Plan including
syndrsurvmessagguide2_ Framework/upload/IHE_ITI_TF_Rev7-
Home Health Plan of Care, Consultation
messagingguide_phn.pdf. This is a 0_Vol2b_FT_2010-08-10.pdf. This is a
Note, CCD, Diagnostic Imaging Reports,
direct access link. direct access link.
Discharge Summary, History and
Summary: This document represents Summary: This document defines
Physical, Operative Note, Procedure
the collaborative effort of the specific implementations of established
Note, Progress Note, Referral Note,
International Society for Disease standards to achieve integration goals
Transfer Summary, Unstructured
Surveillance, CDC, and NIST to specify that promote appropriate sharing of
Document, and Patient Generated
a national electronic messaging standard medical information to support ongoing
Document (US Realm Header). The
that enables disparate health care patient care. The IHE IT Infrastructure
Consolidated CDA (C–CDA) Release 2.1
applications to submit or transmit Technical Framework identifies a subset
IG provides compatibility between
administrative and clinical data for of functional components of the health
Releases 2.0 and 1.1 by applying
public health surveillance and response. care enterprise, called ‘‘IHE actors,’’ and
industry agreed-upon compatibility
The scope of the guide is to provide specified their interactions in terms of a
principles.
guidelines for sending HL7 v.2.5.1 set of coordinated, standards-based
• HL7 Implementation Guide: Data compliant messages from emergency transactions. Volume 2b corresponds to
Segmentation for Privacy (DS4P), department, urgent and ambulatory transactions [ITI–29] through [ITI–57].
Release 1, Part 1: CDA R2 and Privacy care, and inpatient settings to public • HL7 Implementation Guide for
Metadata Reusable Content Profile. health authorities. CDA® Release 2—Level 3: Healthcare
URL: http://www.hl7.org/implement/ • Erratum to the CDC PHIN 2.0 Associated Infection Reports, Release 1,
standards/product_brief.cfm?product_ Implementation Guide, August 2015; U.S. Realm.
id=354. Access requires a ‘‘user Erratum to the CDC PHIN 2.0 Messaging URL: http://www.hl7.org/implement/
account’’ and a license agreement. There Guide, April 2015 Release for standards/product_brief.cfm?product_
is no monetary cost for a user account Syndromic Surveillance: Emergency id=20. Access requires a ‘‘user account’’
and license agreement. Department, Urgent Care, Inpatient and and a license agreement. There is no
Summary: This guide supports Ambulatory Care Settings. monetary cost for a user account and
segmenting clinical records so that URL: http://www.cdc.gov/nssp/ license agreement.
protected health information (PHI) can documents/guides/erratum-to-the-cdc- Summary: This document specifies a
be appropriately shared as may be phin-2.0-implementation-guide-august- standard for electronic submission of
permitted by privacy policies or 2015.pdf. This is a direct access link. health care associated infection reports
regulations. Summary: This document contains (HAI) to the National Healthcare Safety
• HL7 2.5.1 Implementation Guide for erratum and conformance clarifications Network of the CDC. This document
Immunization Messaging, Release 1.5. for the PHIN Messaging Guide for defines the overall approach and
URL: http://www.cdc.gov/vaccines/ Syndromic Surveillance: Emergency method of electronic submission and
programs/iis/technical-guidance/ Department, Urgent Care, Inpatient and develops constraints defining specific
downloads/hl7guide-1-5-2014-11.pdf. Ambulatory Setting, Release 2.0. Value HAI report types.
This is a direct access link. set requirements and errata are also • HL7 Implementation Guide for
Summary: This document represents provided in the addendum. CDA® Release 2: National Health Care
the collaborative effort of the American • HL7 CDA© Release 2 Surveys (NHCS), Release 1—US Realm,
Immunization Registry Association and Implementation Guide: Reporting to HL7 Draft Standard for Trial Use,
CDC to improve inter-system Public Health Cancer Registries from Volumes 1 (Introductory Material) and 2
communication of immunization Ambulatory Healthcare Providers, (Templates and Supporting Material),
records. The guide is intended to DSTU Release 1.1, Volumes 1 December 2014.
URL: http://www.hl7.org/implement/ clinical data from laboratories that identified and reported using a unique,
standards/product_brief.cfm?product_ produce the data to hospitals, provider’s three-segment number, called the
id=385. Access requires a ‘‘user offices, and payers who use the data for National Drug Code (NDC), which
account’’ and license agreement. There clinical care and management purposes. services as the universal product
is no monetary cost for a user account The scope of the LOINC® effort includes identifier for drugs. This standard is
and license agreement. laboratory and other clinical limited to the NDC vaccine codes
Summary: The HL7 Implementation observations. The LOINC® database identified by CDC at the URL provided.
Guide for CDA Release 2: National facilitates the exchange and pooling of • CDC Race and Ethnicity Code Set
Health Care Surveys (NHCS), Release results for clinical care, outcomes Version 1.0.
1—US Realm provides a standardized management, and research. URL: http://www.cdc.gov/phin/
format for implementers to submit data • RxNorm, a standardized resources/vocabulary/index.html. The
to fulfill requirements of the Centers for nomenclature for clinical drugs code set can be accessed through this
Disease Control and Prevention/ produced by the United States National link.
National Center for Health Statistics/ Library of Medicine, September 8, 2015 Summary: The CDC has prepared a
National Health Care Surveys. This IG Release. code set for use in coding race and
supports automatic extraction of the URL: http://www.nlm.nih.gov/ ethnicity data. This code set is based on
data from a provider’s EHR system or research/umls/rxnorm/docs/ current federal standards for classifying
data repository. The data are collected rxnormfiles.html. Access requires a user data on race and ethnicity, specifically
through three surveys of ambulatory account and license agreement. There is the minimum race and ethnicity
care services in the United States: The no monetary cost for a user account and categories defined by the U.S. Office of
National Ambulatory Medical Care license agreement. Management and Budget (OMB) and a
Survey with information from Summary: RxNorm provides more detailed set of race and ethnicity
physicians and two national hospital normalized names for clinical drugs and categories maintained by the U.S.
care surveys: the National Hospital links its names to many of the drug Bureau of the Census (BC). The main
Ambulatory Medical Care Surveys and vocabularies commonly used in purpose of the code set is to facilitate
the National Hospital Care Survey with pharmacy management and drug use of federal standards for classifying
data from hospital emergency and interaction software. By providing links data on race and ethnicity when these
outpatient departments. between vocabularies commonly used data are exchanged, stored, retrieved, or
in pharmacy management and drug analyzed in electronic form. At the same
Vocabulary Standards for Representing interaction software, RxNorm can
Electronic Health Information—45 CFR time, the code set can be applied to
mediate messages between systems not paper-based record systems to the extent
170.207 using the same software and vocabulary. that these systems are used to collect,
• IHTSDO SNOMED CT®, U.S. RxNorm now includes the National maintain, and report data on race and
Edition, September 2015 Release. Drug File—Reference Terminology ethnicity in accordance with current
URL: http://www.nlm.nih.gov/ (NDF–RT) from the Veterans Health federal standards.
research/umls/Snomed/us_edition.html. Administration, which is used to code
Access requires a user account and • Request for Comments (RFC) 5646,
clinical drug properties, including ‘‘Tags for Identifying Languages.’’
license agreement. There is no monetary mechanism of action, physiologic effect,
cost for a user account and license URL: http://www.rfc-editor.org/info/
and therapeutic category. rfc5646. This is a direct access link.
agreement. • HL7 Standard Code Set CVX—
Summary: Systemized Nomenclature Summary: RFC 5646 describes the
Vaccines Administered, updates
of Medicine—Clinical Terms (SNOMED structure, content, construction, and
through August 17, 2015.
CT®) is a comprehensive clinical URL: http://www2a.cdc.gov/vaccines/ semantics of language tags for use in
terminology, originally created by the iis/iisstandards/vaccines.asp?rpt=cvx. cases where it is desirable to indicate
College of American Pathologists and, as This is a direct access link. the language used in an information
of April 2007, owned, maintained, and Summary: CDC’s National Center of object. It also describes how to register
distributed by the International Health Immunization and Respiratory Diseases values for use in language tags and the
Terminology Standards Development developed and maintains HL7 Table creation of user-defined extensions for
Organisation. SNOMED CT® improves 0292, Vaccine Administered (CVX). private interchange.
the recording of information in an EHR CVX includes both active and inactive • International Telecommunication
system and facilitates better vaccines available in the U.S. CVX Union E.123: Notation for national and
communication, leading to codes for inactive vaccines allow international telephone numbers, email
improvements in the quality of care. transmission of historical immunization addresses and Web addresses.
• Logical Observation Identifiers records; when paired with a URL: http://www.itu.int/rec/T-REC-
Names and Codes (LOINC®) Database manufacturer (MVX) code, the specific E.123-200102-I/e. This is a direct access
version 2.52, a universal code system for trade named vaccine may be indicated. link.
identifying laboratory and clinical • National Drug Code Directory Summary: This standard applies
observations produced by the (NDC)—Vaccine NDC Linker, updates specifically to the printing of national
Regenstrief Institute, Inc. through August 17, 2015. and international telephone numbers,
URL: http://loinc.org/downloads. URL: http://www2a.cdc.gov/vaccines/ electronic mail addresses and Web
Access requires registration, a user iis/iisstandards/ndc_tableaccess.asp. addresses on letterheads, business
account, and license agreement. There is This is a direct access link. cards, bills, etc. Regard has been given
no monetary cost for registration, a user Summary: The Drug Listing Act of to the printing of existing telephone
account, and license agreement. 1972 requires registered drug directories. The standard notation for
Summary: LOINC® was initiated in establishments to provide the FDA with printing telephone numbers, Email
1994 by the Regenstrief Institute and a current list of all drugs manufactured, addresses and Web addresses helps to
developed by Regenstrief and the prepared, propagated, compounded, or reduce difficulties and errors, since this
LOINC® committee as a response to the processed by it by commercial address information must be entered
demand for electronic movement of distribution. Drug products are exactly to be effective.
• International Telecommunication contemporarily used in international hash algorithms are typically used with
Union E.164: The international public science, engineering, and business. The other cryptographic algorithms, such as
telecommunication numbering plan. purpose is to facilitate unambiguous digital signature algorithms and keyed-
URL: http://www.itu.int/rec/T-REC- electronic communication of quantities hash message authentication codes, or
E.164-201011-I/en. This is a direct together with units. in the generation of random numbers
access link. • HL7 Version 3 (V3) Normative (bits).
Summary: Recommendation ITU–T Edition, 2015, AdminstrativeGender • ASTM E2147–01 (Reapproved 2013)
E.164 provides the number structure Value Set and NullFlavor. Standard Specification for Audit and
and functionality for the five categories URL: http://www.hl7.org/ Disclosure Logs for Use in Health
of numbers used for international public documentcenter/public_temp_ Information Systems, approved March
telecommunication: Geographic areas, 369DCAB9-1C23-BA17- 1, 2013.
global services, Networks, groups of 0CAF31D63E2D1A3E/standards/ URL: http://www.astm.org/Standards/
countries (GoC) and resources for trials. vocabulary/vocabulary_tables/ E2147.htm. This is a direct access link.
For each of the categories, it details the infrastructure/vocabulary/vs_ However, a fee is required to obtain a
components of the numbering structure AdministrativeGender.html; and http:// copy of the standard.
and the digit analysis required to www.hl7.org/documentcenter/public_ Summary: This specification
successfully route the calls. temp_369DCAB9-1C23-BA17- describes the security requirements
• Crosswalk: Medicare Provider/ 0CAF31D63E2D1A3E/standards/ involved in the development and
Supplier to Healthcare Provider vocabulary/vocabulary_tables/ implementation of audit and disclosure
Taxonomy (updated April 2, 2015). infrastructure/vocabulary/vs_ logs used in health information systems.
URL: https://www.cms.gov/Medicare/ NullFlavor.html. These are direct access It specifies how to design an access
Provider-Enrollment-and-Certification/ links. Compliance with a license audit log to record all access to patient
MedicareProviderSupEnroll/ agreement is required. identifiable information maintained in
Downloads/TaxonomyCrosswalk.pdf. Summary: These HL7 Version 3 (V3) computer systems, and includes
This is a direct access link. Standard Value Sets for principles for developing policies,
Summary: This crosswalk links the administrativegender and NullFlavor procedures, and functions of health
types of providers and suppliers who provide means for coding birth sex and information logs to document all
are eligible to apply for enrollment in nullFlavors. disclosure of confidential health care
the Medicare program with the
Standards for Health Information information to external users for use in
appropriate Healthcare Provider
Taxonomy Codes. This crosswalk Technology to Protect Electronic Health manual and computer systems. This
Information Created, Maintained, and specification provides for two main
includes the Medicare Specialty Codes
Exchanged—45 CFR 170.210 purposes, namely: To define the nature,
for those provider/supplier types who
role, and function of system access audit
have Medicare Specialty Codes. The • Any encryption algorithm identified
logs and their use in health information
Healthcare Provider Taxonomy Code Set by the National Institute of Standards
systems as a technical and procedural
is available from the Washington and Technology (NIST) as an approved
tool to help provide security oversight;
Publishing Company (www.wpc- security function in Annex A of the
and to identify principles for
edi.com) and is maintained by the Federal Information Processing
establishing a permanent record of
National Uniform Claim Committee Standards (FIPS) Publication 140–2,
disclosure of health information to
(www.nucc.org). October 8, 2014.
• Public Health Data Standards URL: http://csrc.nist.gov/publications/ external users and the data to be
Consortium Source of Payment fips/fips140-2/fips1402annexa.pdf. This recorded in maintaining it.
Typology Code Set, Version 5.0. is a direct access link. VI. Collection of Information
URL: http://www.phdsc.org/ Summary: Federal Information Requirements
standards/pdfs/SourceofPayment Processing Standards Publication (FIPS
TypologyVersion5.0.pdf. This is a direct PUB) 140–2, Security Requirements for Under the Paperwork Reduction Act
access link. Cryptographic Modules, specifies the of 1995 (PRA), agencies are required to
Summary: The Source of Payment security requirements that are to be provide 60-day notice in the Federal
Typology was developed to create a satisfied by the cryptographic module Register and solicit public comment on
standard for reporting payer type data utilized within a security system a proposed collection of information
that will enhance the payer data protecting sensitive information within before it is submitted to the Office of
classification; it is also intended for use computer and telecommunications Management and Budget for review and
by those collecting data, or analyzing systems. The standard provides four approval. In order to fairly evaluate
healthcare claims information. The increasing qualitative levels of security whether an information collection
Payment Typology can be used by any that are intended to cover the wide should be approved by the Office of
analyst who wishes to code source of range of potential applications and Management and Budget, section
payment data, including analysts who environments in which cryptographic 3506(c)(2)(A) of the PRA requires that
code administrative or claims data, modules may be employed. we solicit comment on the following
survey data, clinical trials data, or any • FIPS PUB 180–4, Secure Hash issues:
other dataset containing this type of Standard, 180–4 (August 2015). 1. Whether the information collection
data element. URL: http://nvlpubs.nist.gov/ is necessary and useful to carry out the
• The Unified Code of Units of nistpubs/FIPS/NIST.FIPS.180-4.pdf. proper functions of the agency;
Measure, Revision 1.9. This is a direct access link. 2. The accuracy of the agency’s
URL: http://unitsofmeasure.org/trac/. Summary: This standard specifies estimate of the information collection
This is a direct access link. The codes secure hash algorithms—SHA–1, SHA– burden;
can be viewed in html or xml. 224, SHA–256, SHA–384, SHA–512, 3. The quality, utility, and clarity of
Summary: The Unified Code of Units SHA–512/224 and SHA–512/256—for the information to be collected; and
of Measure is a code system intended to computing a condensed representation 4. Recommendations to minimize the
include all units of measures being of electronic data (message). Secure information collection burden on the
affected public, including automated participating in the ONC Health IT beyond the scope of the EHR Incentive
collection techniques. Certification Program as this is the Programs.
Under the PRA, the time, effort, and current number of ONC–ACBs. Further, The adoption and implementation of
financial resources necessary to meet since the establishment of the ONC health IT certified to the 2015 Edition
the information collection requirements Health IT Certification Program in 2010, promotes interoperability in support of
referenced in this section are to be ONC has never had more than six a nationwide health information
considered. We sought comment on applicants for ONC–ACB or ONC–ATCB infrastructure and improves health care
proposed PRA requirements in the status or selected more than six ONC– quality, safety and efficiency consistent
Proposed Rule (80 FR 16893–16895). ACBs or ONC–ATCBs.182 with the goals of the HITECH Act.
Abstract We concluded that the regulatory B. Overall Impact
‘‘collection of information’’
Under the ONC Health IT requirements under the ONC Health IT We have examined the impact of this
Certification Program, accreditation Certification Program described above final rule as required by Executive
organizations that wish to become the are not subject to the PRA under 5 CFR Order 12866 on Regulatory Planning
ONC-Approved Accreditor (ONC–AA) 1320.3(c). We welcomed comments on and Review (September 30, 1993),
must submit certain information, this conclusion and the supporting Executive Order 13563 on Improving
organizations that wish to become an rationale on which it was based. Regulation and Regulatory Review
ONC–ACB must submit the information Comments. We received one comment (February 2, 2011), the Regulatory
specified by the application suggesting that the time we estimated Flexibility Act (5 U.S.C. 601 et seq.),
requirements, and ONC–ACBs must for proposed ONC–ACB surveillance section 202 of the Unfunded Mandates
comply with collection and reporting activities may be underestimated in Reform Act of 1995 (2 U.S.C. 1532), and
requirements, records retention terms of reviewing surveillance Executive Order 13132 on Federalism
requirements, and submit annual guidance, developing plans, and (August 4, 1999).
surveillance plans and annually report finalizing surveillance results for
surveillance results. 1. Executive Orders 12866 and 13563—
submission. Regulatory Planning and Review
In the Permanent Certification Response. We agree with the
Program final rule (76 FR 1312–14), we Analysis
commenter that our time estimate for
solicited public comment on each of the Executive Orders 12866 and 13563
surveillance-related activities was an
information collections associated with direct agencies to assess all costs and
underestimation. We have provided a
the requirements described above (and benefits of available regulatory
new estimate as part of the regulatory
included in regulation at 45 CFR alternatives and, if regulation is
impact statement.
170.503(b), 170.520, and 170.523(f), (g), We continue to estimate fewer than 10 necessary, to select regulatory
and (i), respectively). In the 2014 approaches that maximize net benefits
respondents for all of the regulatory
Edition final rule (77 FR 54275–76), we (including potential economic,
‘‘collection of information’’
sought comment on these collection environmental, public health and safety
requirements under Part 170 of Title 45.
requirements again and finalized an effects, distributive impacts, and
Accordingly, the ‘‘collection of
additional requirement at § 170.523(f)(8) equity). A regulatory impact analysis
information’’ requirements/burden that
for ONC–ACBs to report to ONC a (RIA) must be prepared for major rules
are associated with this final rule are
hyperlink with each EHR technology with economically significant effects
not subject to the PRA under 5 CFR
they certify that provides the public ($100 million or more in any 1 year).
1320.3(c).
with the ability to access the test results OMB has determined that this final rule
used to certify the EHR technology. VII. Regulatory Impact Statement is an economically significant rule as we
These collections of information were have estimated the costs to develop and
A. Statement of Need
approved under OMB control number prepare health IT to be tested and
0955–0013 (previous OMB control This final rule is being published to certified may be greater than $100
number 0990–0378). adopt the 2015 Edition. Certification million per year.
In the Proposed Rule, we estimated criteria and associated standards and
less than 10 annual respondents for all implementation specifications would be a. Costs
of the regulatory ‘‘collection of used to test and certify health IT in This final rule adopts standards,
information’’ requirements under Part order to make it possible for EPs, implementation specifications, and
170 of Title 45, including those eligible hospitals, and CAHs to adopt certification criteria that establish the
previously approved by OMB and and implement health IT that can be capabilities that health IT would need to
proposed in the Proposed Rule (80 FR used to meet the CEHRT definition. EPs, demonstrate to be certified to the 2015
16894). The ‘‘collection of information’’ eligible hospitals, and CAHs who Edition. Our analysis focuses on the
requirements that apply to the ONC- participate in the EHR Incentive direct effects of the provisions of this
Approved Accreditor (ONC–AA) are Programs are required by statute to use final rule—the costs incurred by health
found in § 170.503(b). The ‘‘collection of CEHRT.183 IT developers to develop and prepare
information’’ requirements that apply to The certification criteria and health IT to be tested and certified in
the ONC–ACBs are found in § 170.520; associated standards and accordance with the certification criteria
§ 170.523(f)(1) and (2), (g), (i), and (o); implementation specifications would (and the standards and implementation
and § 170.540(c). As stated in the also support the certification of more specifications they include) adopted by
Proposed Rule, we estimated the types of health IT and health IT that the Secretary. That is, we focus on the
number of respondents for § 170.503(b) supports care and practice settings technological development and
(applicants for ONC–AA status) at two preparation costs necessary for health IT
based on past selection processes for the 182 See also: http://www.healthit.gov/policy-
already certified to the 2014 Edition to
ONC–AA, which have included no more researchers-implementers/authorized-testing-and- upgrade to the proposed 2015 Edition
certifications-bodies and http://www.healthit.gov/
than two applicants. As also stated in policy-researchers-implementers/certification- and for, in limited cases, developing
the Proposed Rule, we anticipate that bodies-testing-laboratories. and preparing a new Health IT Module
there will be three ONC–ACBs 183 Section 1848(o) of the Social Security Act. to meet the 2015 Edition. The costs for
the testing and certification of health IT significantly underestimated. However, certain e-prescribing and C–CDA
to the 2015 Edition were captured in the one commenter stated the average cost conformance.
regulatory impact analysis of the estimate for patient health information
Certification Criteria
Permanent Certification Program final capture was significantly overestimated.
rule as we discuss in more detail below One commenter stated that the We have divided the certification
(VIII.B.1.a.iii ‘‘Testing and Certification developer hour estimates do not appear criteria into three categories, each with
Costs for the 2015 Edition’’). In this final to be derived from data reported by its own table below. Table 11 is for the
rule, we have also included estimated health IT developers or consulting new and revised certification criteria
costs for complying with new and companies and recommends a total associated with the EHR Incentive
revised Principles of Proper Conduct for economic impact assessment by a 3rd Programs Stage 3 CEHRT definition and
ONC–ACBs. party is needed. objectives and measures. Table 12 is for
Because the costs that EPs, eligible Response. As noted in the Proposed the unchanged certification criteria
hospitals, and CAHs would incur in Rule, we are not aware of an available associated with the EHR Incentive
adopting and implementing (including independent study (e.g., a study Programs Stage 3 CEHRT definition and
training, maintenance, and any other capturing the preparation efforts and objectives and measures. These tables
ongoing costs) health IT certified to the costs to develop and Health IT Modules also include certification criteria that
2015 Edition is overwhelmingly to meet the requirements of the 2014 are mandatory and conditional
attributable to the EHR Incentive Edition) that we could rely upon as a certification requirements, such as
Programs Stage 3 and Modifications basis for estimating the efforts and costs ‘‘safety-enhanced design,’’ and ‘‘quality
final rule (published elsewhere in this required to develop and prepare health management system,’’ ‘‘accessibility-
issue of the Federal Register), and IT to meet the 2015 Edition. We based centered design,’’ and privacy and
would not be incurred in the absence of our cost estimates in the Proposed Rule security certification criteria as certified
such rulemaking, such costs are not in part on burden hour estimates Health IT Modules certified to these
within the scope of the analysis of this provided by the Electronic Health criteria would be used to meet the
final rule; similarly, any benefits that Record Association (EHRA) (a health IT
CEHRT definition under the EHR
are contingent upon adoption and developer association) as well as
Incentive Programs.185 Table 13 is for all
implementation would be attributable to internal estimates. For this final rule, we
other certification criteria
CMS’s rulemaking.184 We also note that have once again relied on burden hour
(‘‘Independent Criteria’’). We have taken
this final rule does not impose the costs estimates provided by the EHRA in
this approach because, based on
cited as compliance costs, but rather as response to the Proposed Rule and
available data, we can more accurately
investments which health IT developers internal estimates.
We have also once again generally estimate the number of health IT
voluntarily take on and may expect to developers that may develop and
used the EHRA estimates as a basis for
recover with an appropriate rate of prepare Health IT Modules for
our high estimates. We have used the
return. certification to certification criteria
EHRA estimates in this manner because
i. Development and Preparation Costs of the uncertain reliability of the associated with the EHR Incentive
for the 2015 Edition information. It is our understanding that Programs.
The development and preparation these estimates were based on a survey Health IT Developers and Number of
costs we estimate are derived through a of EHRA’s members. It is unclear how Health IT Modules
health IT developer per criterion cost. In many of EHRA’s members responded
and how each member arrived at their New and Revised Stage 3 Criteria
simple terms, we estimate: (1) How
estimates. Further, we cannot rely on We derive our estimates for the
many health developers will prepare
these estimates as being generated from number of health IT developers by
and develop products against the
an independent, unbiased source beginning with the number of Health IT
certification criteria; (2) how many
because EHRA members must, in some developers certified to each of the 2014
products they will develop; and (3)
respects, substantiate the costs and fees Edition certification criteria as
what it will likely cost them to develop
they charge providers for their certified identified in CHPL data from November
and prepare those products to meet the
health IT. We do note, however, that we 10, 2014. For the new and revised Stage
certification criteria.
have also used the EHRA estimates to 3 Criteria that correspond to 2014
Comments. Several commenters
significantly increase our low estimates. Edition certification criteria, we have
expressed concern with the estimated Based on the estimates provided by
costs and developer hours in the reduced the number of Health IT
the EHRA, by not adopting the 14 developers by 30% from the number
Proposed Rule, stating they were proposed certification criteria identified that certified against the 2014 Edition.
184 ONC administers a voluntary certification
in Table 2 of this final rule and certain We have done this because we have
other functionality and standards, we
program that provides no incentives for found a 22% drop in the number of
certification. Therefore, to the extent that providers’ have reduced the estimated burden of
health IT developers that certified
implementation and adoption costs are attributable the 2015 Edition by over 40,000 burden
to CMS’s rulemaking, health IT developers’ technology against the 2014 Edition
hours per health IT developer. The 14
preparation and development costs would also be versus the 2011 Edition. We believe that
criteria that were not adopted saved
attributable to that rulemaking (because all of the as both interoperability requirements
costly activities are, directly or indirectly, over 25,000 burden hours. An
increase by edition and certain health IT
incentivized by CMS’s payment structure). additional 15,000 burden hours were
However, a professional organization or other such developers gain more market share
saved through not adopting certain
entity could also require or promote certification, through competition and acquisition of
functionality and standards such as user
thus generating costs and benefits that are other health IT developers, there will be
attributable to this final rule. To avoid giving the response ‘‘tracking’’ for clinical decision
an even greater drop in the number of
misleading impression that such effects equal zero, support and drug-drug, drug-allergy
we present in this RIA a subset of the relevant interaction checks, a formulary benefit
impacts—a quantification of costs that are incurred 185 Please see section III.A for explanation of the
by health IT developers and a qualitative discussion

standard, a standard for recording terms ‘‘mandatory’’ and ‘‘conditional’’ as they apply
of benefits. (The missing portion of the subset is smoking status, a standard for CPOE to certification criteria and the certification of a
providers’ implementation and adoption costs). laboratory orders, and proposals for Health IT Module.
health IT developers that seek Independent Criteria content exchange standard can
certification to the 2015 Edition. For the Independent Criteria, we have significantly reduce a health IT
We estimate 2.5 products per health only estimated the development and developer’s burden when certifying to
IT developer for each new and revised preparation of one Health IT Module to multiple certification criteria that
‘‘Stage 3’’ criterion. We reached this meet these criteria. The Independent reference the same vocabulary or
estimate based both on the number of Criteria are not currently associated content exchange standard. For
unique 186 certified products listed on with the EHR Incentive Programs or example, the ‘‘transitions of care,’’
the CHPL as of November 10, 2014 another HHS payment program. ‘‘clinical information reconciliation and
divided by the number of health IT Therefore, we continue to have no incorporation,’’ ‘‘data export,’’ ‘‘view,
developers certified and stakeholder reliable basis on which to estimate how download, and transmit to 3rd party,’’
feedback on our Voluntary Edition many developers and products will be ‘‘application access—data category
proposed rule (79 FR 54474). certified to these criteria. We do not request,’’ and ‘‘application access—all
include these estimated costs in our data request’’ certification criteria
We note that these estimates included
overall cost estimate for this final rule. included the same content exchange
any new health IT developers.
standard and many, if not all, the same
Unchanged Stage 3 Criteria Average Development and Preparation
vocabulary standards. Based on health
Hours
IT products certified to the 2014
For unchanged ‘‘Stage 3’’ criteria, we Our estimated average development Edition, we expect health IT developers
estimate 5 new health IT developers, hours are based on feedback we to certify their products to many or all
each with 1 product. We have attempted received in response to the RIA we of these criteria. This will create
to establish a burden estimate for each completed for the Proposed Rule and developmental efficiencies and reduced
criterion assuming a health IT developer internal estimates for criteria where burden. Similarly, a health IT developer
would be in the same position as a there is no external data to validly rely preparing a product for certification to
health IT developer that sought upon. As noted above, we have the ‘‘social, psychological, and
certification to the 2011 or 2014 Edition generally used estimates from the behavioral data’’ criterion would find
as these 2015 certification criteria are Electronic Health Record Association as synergies in meeting all the measures
unchanged as compared to those same a basis for our high estimates, where now included in the criterion as they all
2011 and 2014 Edition certification applicable. We have accounted for the rely on LOINC®. We note that our
criteria. We do not anticipate more than reduced burden hours related to estimates also take into account added
5 new health IT developers to certify to functionality and standards not adopted burden such as with the Direct criteria,
these criteria for the market attrition (e.g., ‘‘CPOE—laboratory,’’ ‘‘clinical which is a result of adoption of a newer
reasons mentioned above. We note for decision support,’’ and ‘‘smoking version of the standard and other
health IT developers that have had status,’’ certification criteria). included interoperability requirements.
products previously certified to the We have also attempted to capture
2014 Edition version of these criteria, developmental synergies where Estimated Health IT Developers and
we estimate no new costs. development to a vocabulary and/or Development Hours Per Criterion
TABLE 11—ESTIMATED HEALTH IT DEVELOPERS AND DEVELOPMENT AND PREPARATION HOURS FOR THE 2015 EDITION—
NEW AND REVISED CRITERIA ASSOCIATED WITH THE EHR INCENTIVE PROGRAMS STAGE 3
[‘‘Stage 3 Criteria’’]
Number of Hourly development effort by

health IT health IT developer
developers
Item No. CFR text Certification criterion name who develop
product(s) for Low avg. High avg.
certification
to criterion
1 .................. § 170.315(a)(5) .................... Demographics ............................................ 268.8 1,200 2,000

2 .................. § 170.315(a)(6) .................... Problem List ............................................... 256.9 50 100
3 .................. § 170.315(a)(9) .................... Clinical Decision Support ........................... 235.2 300 400
4 .................. § 170.315(a)(12) .................. Family Health History ................................. 250 50 100
5 .................. § 170.315(a)(13) .................. Patient-specific Education Resources ....... 249.2 300 400
6 .................. § 170.315(a)(14) .................. Implantable Device List .............................. 90 700 2,200
7 .................. § 170.315(b)(1) .................... Transitions of Care ..................................... 242.9 3,000 4,000
8 .................. § 170.315(b)(2) .................... Clinical Information Reconciliation and In- 224 500 600
corporation.
9 .................. § 170.315(b)(3) .................... Electronic Prescribing ................................ 224.7 1,600 2,300
10 ................ § 170.315(b)(6) .................... Data Export ................................................ 228.9 600 1,600
11 ................ § 170.315(c)(1) .................... CQMs—record and export ......................... 246.4 600 800
12 ................ § 170.315(c)(2) .................... CQMs—import and calculate ..................... 246.4 600 800
13 ................ § 170.315(c)(3) .................... CQMs—report ............................................ 246.4 600 800
14 ................ § 170.315(d)(2) .................... Auditable Events and Tamper-resistance .. 272.3 50 100
15 ................ § 170.315(d)(8) .................... Integrity ....................................................... 312.2 50 100

16 ................ § 170.315(d)(9) .................... Trusted Connection .................................... 242 100 200
17 ................ § 170.315(d)(10) .................. Auditing Actions on Health Information ..... 242 100 200
18 ................ § 170.315(e)(1) .................... View, Download, and Transmit to 3rd 256.2 1,300 2,000
party.
186 We attempted to discern how many Complete not constitute a newer version of the same
EHRs and Health IT Modules were used that would technology.
TABLE 11—ESTIMATED HEALTH IT DEVELOPERS AND DEVELOPMENT AND PREPARATION HOURS FOR THE 2015 EDITION—
NEW AND REVISED CRITERIA ASSOCIATED WITH THE EHR INCENTIVE PROGRAMS STAGE 3—Continued

developers
certification
to criterion
19 ................ § 170.315(e)(2) .................... Secure Messaging ..................................... 246.4 100 200

20 ................ § 170.315(e)(3) .................... Patient Health Information Capture ........... 88.9 500 800
21 ................ § 170.315(f)(1) ..................... Transmission to Immunization Registries .. 220.5 1,000 1,600
22 ................ § 170.315(f)(2) ..................... Transmission to Public Health Agencies— 100 600 800
syndromic surveillance.
23 ................ § 170.315(f)(4) ..................... Transmission to Cancer Registries ............ 22.4 800 1,000
24 ................ § 170.315(f)(5) ..................... Transmission to Public Health Agencies— 21 600 800
electronic case reporting.
25 ................ § 170.315(f)(6) ..................... Transmission to Public Health Agencies— 21 1,000 1,400
antimicrobial use and resistance report-
ing.
26 ................ § 170.315(f)(7) ..................... Transmission to Public Health Agencies— 21 1,000 1,400
health care surveys.
27 ................ § 170.315(g)(1) .................... Automated Numerator Recording .............. 113.4 800 1,200
28 ................ § 170.315(g)(2) .................... Automated Measure Calculation ................ 264.6 1,000 1,600
29 ................ § 170.315(g)(3) .................... Safety-enhanced Design ............................ 266 300 400
30 ................ § 170.315(g)(4) .................... Quality Management System ..................... 401.8 50 160
31 ................ § 170.315(g)(5) .................... Accessibility-Centered Design ................... 401.8 50 100
32 ................ § 170.315(g)(6) .................... Consolidated CDA Creation Performance 242 400 900
33 ................ § 170.315(g)(7) .................... Application Access—Patient Selection ...... 242 300 400
34 ................ § 170.315(g)(8) .................... Application Access—Data Category Re- 242 300 400
quest.
35 ................ § 170.315(g)(9) .................... Application Access—All Data Request ...... 242 300 400
36 ................ § 170.315(h)(1) .................... Direct Project .............................................. 140 800 1,100
37 ................ § 170.315(h)(2) .................... Direct Project, Edge Protocol, and XDR/ 70 800 1,100
XDM.
TABLE 12—ESTIMATED HEALTH IT DEVELOPERS AND DEVELOPMENT AND PREPARATION HOURS FOR PROPOSED
UNCHANGED CERTIFICATION CRITERIA—CRITERIA ASSOCIATED WITH THE EHR INCENTIVE PROGRAMS STAGE 3

developers
certification
to criterion
1 .................. § 170.315(a)(1) ..................... CPOE—medications .................................... 5 50 100

2 .................. § 170.315(a)(2) ..................... CPOE—laboratory ....................................... 5 50 100
3 .................. § 170.315(a)(3) ..................... CPOE—diagnostic imaging ......................... 5 50 100
4 .................. § 170.315(a)(4) ..................... DD/DAI Checks for CPOE .......................... 5 50 100
5 .................. § 170.315(a)(8) ..................... Medication List ............................................ 5 50 100
6 .................. § 170.315(a)(9) ..................... Medication Allergy List ................................ 5 50 100
7 .................. § 170.315(a)(10) ................... Drug-formulary and Preferred Drug List 5 50 100
Checks.
8 .................. § 170.315(a)(11) ................... Smoking Status ........................................... 5 50 100
9 .................. § 170.315(d)(1) ..................... Authentication, Access Control, Authoriza- 5 50 100
tion.
10 ................ § 170.315(d)(3) ..................... Audit Report(s) ............................................ 5 50 100
11 ................ § 170.315(d)(4) ..................... Amendments ............................................... 5 50 100
12 ................ § 170.315(d)(5) ..................... Automatic Access Time-out ........................ 5 50 100

13 ................ § 170.315(d)(6) ..................... Emergency Access ...................................... 5 50 100
14 ................ § 170.315(d)(7) ..................... End-User Device Encryption ....................... 5 50 100
15 ................ § 170.315(f)(3) ...................... Transmission to Public Health Agencies— 5 400 600
reportable laboratory tests and values/re-
sults.
TABLE 13—ESTIMATED DEVELOPMENT AND PREPARATION HOURS FOR THE 2015 EDITION—CRITERIA NOT ASSOCIATED
WITH THE EHR INCENTIVE PROGRAMS STAGE 3
[‘‘Independent Criteria’’]
Hourly development effort by

health IT developer
Item No. CFR text Certification criterion name
Low avg. High avg.
1 ................... § 170.315(a)(15) ............................... Social, Psychological, and Behavioral Data .................. 800 1,000
2 ................... § 170.315(b)(4) ................................. Common Clinical Data Set Summary Record—Create 1,600 2,200
3 ................... § 170.315(b)(5) ................................. Common Clinical Data Set Summary Record—Receive 1,600 2,200
4 ................... § 170.315(b)(7) ................................. Data Segmentation for Privacy—send ........................... 800 1,300
5 ................... § 170.315(b)(8) ................................. Data Segmentation for Privacy—receive ....................... 800 1,300
6 ................... § 170.315(b)(9) ................................. Care Plan ....................................................................... 700 1,000
7 ................... § 170.315(c)(4) .................................. CQMs—filter ................................................................... 1,000 1,500
8 ................... § 170.315(d)(9) ................................. Accounting of Disclosures .............................................. 400 600
Health IT Developer Hourly Cost and calculated the costs of an employee’s To calculate our cost estimates for
Cost Range benefits by assuming that an employer each certification criterion in the tables
expends thirty-six percent (36%) of an below, we have multiplied both the
We have based the effort levels on the employee’s hourly wage on benefits for average low and average high number of
hours necessary for a software developer the employee. We have concluded that development and preparation hours in
to develop and prepare the health IT for a 36% expenditure on benefits is an Tables 11–13 by $63. For tables 14, 15,
testing and certification. These hours appropriate estimate because it is the and 16, dollar amounts are expressed in
are identified in Tables 11–13 above. routine percentage used by HHS for 2014 dollars.
The U.S. Department of Labor, Bureau contract cost estimates. We have
of Labor Statistics estimates that the rounded up the average software Estimated Cost Per Criterion for Health
median hourly wage for a software developer’s wage with benefits to $63 IT Developers
developer is $45.92.187 We have also per hour.
TABLE 14—TOTAL DEVELOPMENT AND PREPARATION COSTS PER CRITERION FOR HEALTH IT DEVELOPERS —2015
EDITION NEW AND REVISED CRITERIA ASSOCIATED WITH THE EHR INCENTIVE PROGRAMS STAGE 3
Average cost estimates ($)

Item No. CFR text Certification criterion name Average low Average high
($) ($)
1 ................... § 170.315(a)(5) ................................. Demographics ................................................................ 20,321,280 33,868,800

2 ................... § 170.315(a)(6) ................................. Problem List ................................................................... 809,235 1,618,470
3 ................... § 170.315(a)(9) ................................. Clinical Decision Support ............................................... 4,445,280 5,927,040
4 ................... § 170.315(a)(12) ............................... Family Health History ..................................................... 787,500 1,575,000
5 ................... § 170.315(a)(13) ............................... Patient-specific Education Resources ............................ 4,709,880 6,279,840
6 ................... § 170.315(a)(14) ............................... Implantable Device List .................................................. 3,969,000 12,474,000
7 ................... § 170.315(b)(1) ................................. Transitions of Care ......................................................... 45,908,100 61,210,800
8 ................... § 170.315(b)(2) ................................. Clinical Information Reconciliation and Incorporation .... 7,056,000 8,467,200
9 ................... § 170.315(b)(3) ................................. Electronic Prescribing ..................................................... 22,649,760 32,559,030
10 ................. § 170.315(b)(6) ................................. Data Export .................................................................... 8,652,420 23,073,120
11 ................. § 170.315(c)(1) .................................. CQMs—record and export ............................................. 9,313,920 12,418,560
12 ................. § 170.315(c)(2) .................................. CQMs—import and calculate ......................................... 9,313,920 12,418,560
13 ................. § 170.315(c)(3) .................................. CQMs—report ................................................................ 9,313,920 12,418,560
14 ................. § 170.315(d)(2) ................................. Auditable Events and Tamper-resistance ...................... 857,745 1,715,490
15 ................. § 170.315(d)(8) ................................. Integrity ........................................................................... 983,430 1,966,860
16 ................. § 170.315(d)(9) ................................. Trusted Connection ........................................................ 1,524,600 3,049,200
17 ................. § 170.315(d)(10) ............................... Auditing Actions on Health Information .......................... 1,524,600 3,049,200
18 ................. § 170.315(e)(1) ................................. View, Download, and Transmit to 3rd party .................. 20,982,780 32,281,200
19 ................. § 170.315(e)(2) ................................. Secure Messaging .......................................................... 1,552,320 3,104,640
20 ................. § 170.315(e)(3) ................................. Patient Health Information Capture ................................ 2,800,350 4,480,560
21 ................. § 170.315(f)(1) .................................. Transmission to Immunization Registries ...................... 13,891,500 22,226,400
22 ................. § 170.315(f)(2) .................................. Transmission to Public Health Agencies—syndromic 3,780,000 5,040,000
surveillance.
23 ................. § 170.315(f)(4) .................................. Transmission to Cancer Registries ................................ 1,128,960 1,411,200

24 ................. § 170.315(f)(5) .................................. Transmission to Public Health Agencies—electronic 793,800 1,058,400
case reporting.
25 ................. § 170.315(f)(6) .................................. Transmission to Public Health Agencies—antimicrobial 1,323,000 1,852,200
use and resistance reporting.
187 http://www.bls.gov/oes/current/
oes151132.htm.
TABLE 14—TOTAL DEVELOPMENT AND PREPARATION COSTS PER CRITERION FOR HEALTH IT DEVELOPERS —2015
EDITION NEW AND REVISED CRITERIA ASSOCIATED WITH THE EHR INCENTIVE PROGRAMS STAGE 3—Continued
Average cost estimates ($)

Item No. CFR text Certification criterion name Average low Average high
($) ($)
26 ................. § 170.315(f)(7) .................................. Transmission to Public Health Agencies—health care 1,323,000 1,852,200
surveys.
27 ................. § 170.315(g)(1) ................................. Automated Numerator Recording .................................. 5,715,360 8,573,040
28 ................. § 170.315(g)(2) ................................. Automated Measure Calculation .................................... 16,669,800 26,671,680
29 ................. § 170.315(g)(3) ................................. Safety-enhanced Design ................................................ 5,027,400 6,703,200
30 ................. § 170.315(g)(4) ................................. Quality Management System ......................................... 1,265,670 4,050,144
31 ................. § 170.315(g)(5) ................................. Accessibility-Centered Design ........................................ 1,265,670 2,531,340
32 ................. § 170.315(g)(6) ................................. Consolidated CDA Creation Performance ..................... 6,098,400 13,721,400
33 ................. § 170.315(g)(7) ................................. Application Access—Patient Selection .......................... 4,573,800 6,098,400
34 ................. § 170.315(g)(8) ................................. Application Access—Data Category Request ................ 4,573,800 6,098,400
35 ................. § 170.315(g)(9) ................................. Application Access—All Data Request .......................... 4,573,800 6,098,400
36 ................. § 170.315(h)(1) ................................. Direct Project .................................................................. 7,056,000 9,702,000
37 ................. § 170.315(h)(2) ................................. Direct Project, Edge Protocol, and XDR/XDM ............... 3,528,000 4,851,000
TABLE 15—TOTAL DEVELOPMENT AND PREPARATION COSTS PER CRITERION FOR HEALTH IT DEVELOPERS—2015
EDITION UNCHANGED CRITERIA ASSOCIATED WITH THE EHR INCENTIVE PROGRAMS STAGE 3
Average cost estimates

($)
Item No. CFR text Certification criterion name Average Average
low high
($) ($)
1 ................... § 170.315(a)(1) ................................. CPOE—medications ....................................................... 15,750 31,500

2 ................... § 170.315(a)(2) ................................. CPOE—laboratory .......................................................... 15,750 31,500
3 ................... § 170.315(a)(3) ................................. CPOE—diagnostic imaging ............................................ 15,750 31,500
4 ................... § 170.315(a)(4) ................................. DD/DAI Checks for CPOE ............................................. 15,750 31,500
5 ................... § 170.315(a)(8) ................................. Medication List ............................................................... 15,750 31,500
6 ................... § 170.315(a)(9) ................................. Medication Allergy List ................................................... 15,750 31,500
7 ................... § 170.315(a)(10) ............................... Drug-Formulary and Preferred Drug List Checks .......... 15,750 31,500
8 ................... § 170.315(a)(11) ............................... Smoking Status .............................................................. 15,750 31,500
9 ................... § 170.315(d)(1) ................................. Authentication, Access Control, Authorization ............... 15,750 31,500
10 ................. § 170.315(d)(3) ................................. Audit Report(s) ............................................................... 15,750 31,500
11 ................. § 170.315(d)(4) ................................. Amendments .................................................................. 15,750 31,500
12 ................. § 170.315(d)(5) ................................. Automatic Access Time-Out ........................................... 15,750 31,500
13 ................. § 170.315(d)(6) ................................. Emergency Access ......................................................... 15,750 31,500
14 ................. § 170.315(d)(7) ................................. End-User Device Encryption .......................................... 15,750 31,500
15 ................. § 170.315(f)(3) .................................. Transmission to Public Health Agencies—reportable 126,000 189,000
laboratory tests and values/results.
TABLE 16—TOTAL DEVELOPMENT AND PREPARATION COSTS PER CRITERION —2015 EDITION CRITERIA NOT ASSOCIATED
WITH THE EHR INCENTIVE PROGRAMS STAGE 3
[‘‘Independent Criteria’’]
Average cost estimates

($)
Item CFR text Certification criterion name
No. Average low Average high
($) ($)
1 ................... § 170.315(a)(15) ............................... Social, Psychological, and Behavioral Data .................. 50,400 63,000
2 ................... § 170.315(b)(4) ................................. Common Clinical Data Set Summary Record—Create 100,800 138,600
3 ................... § 170.315(b)(5) ................................. Common Clinical Data Set Summary Record—Receive 100,800 138,600
4 ................... § 170.315(b)(7) ................................. Data Segmentation for Privacy—send ........................... 50,400 81,900
5 ................... § 170.315(b)(8) ................................. Data Segmentation for Privacy—receive ....................... 50,400 81,900
6 ................... § 170.315(b)(9) ................................. Care Plan ....................................................................... 44,100 63,000
7 ................... § 170.315(c)(4) .................................. CQMs—filter ................................................................... 63,000 94,500
8 ................... § 170.315(d)(9) ................................. Accounting of Disclosures .............................................. 25,200 37,800
ii. Overall Development and Preparation calendar years 2015 through 2018, the prepare and develop their health IT to
Costs Over a Four-Year Period cost range would be $65.11 million to meet the 2015 Edition as the compliance
$100.79 million per year with an annual date for the EHR Incentive Programs
We estimate the development and cost mid-point of approximately $82.95 CEHRT definition draws near (i.e., 2018)
preparation costs over a four-year period million. However, we project these costs and because health IT certified to the
because a four-year period aligns with to be unevenly distributed. We estimate 2015 Edition could be used in 2017
our estimated publication date for a the distribution as follows: 2015 (15%); under the EHR Incentive Programs
subsequent final rule (2015) and the 2016 (35%); 2017 (35%); and 2018 CEHRT definition finalized in the EHR
year in which CMS proposes that (15%). We reached this distribution Incentive Programs Stage 3 and
participants in the EHR Incentive based on these assumptions and Modifications final rule (published
Programs must use health IT certified to information: elsewhere in this issue of the Federal
the 2015 Edition (2018) (see the EHR • We expect for health IT developers Register).
Incentive Programs Stage 3 and to spend the rest of the year preparing
Modifications final rule published and developing their health IT to meet • We expect health IT developers to
elsewhere in this issue of the Federal the 2015 Edition. We note that we continue to prepare and develop health
Register). lowered the percentage to 15% for 2015 IT to the 2015 Edition in 2018 based on
In total, we estimate the overall costs from 25% in the Proposed Rule due to their approach to the 2014 Edition.
to develop and prepare health IT for the later-than-anticipated publication Table 17 below represents the costs
certification over a four-year period to date of this final rule. We redistributed attributable to this proposed rule
be $260.44 million to $403.19 million, the 10% over 2016 and 2017. distributed as discussed above. The
with a cost mid-point of approximately • We expect health IT developers to dollar amounts expressed in Table 17
$331.82 million. Evenly distributed over aggressively work in 2016 and 2017 to are expressed in 2014 dollars.
TABLE 17—DISTRIBUTED TOTAL 2015 EDITION DEVELOPMENT AND PREPARATION COSTS FOR HEALTH IT DEVELOPERS (4-
YEAR PERIOD)—TOTALS ROUNDED
Total low Total high Total average
Ratio
Year cost estimate cost estimate cost estimate
(%) ($M) ($M) ($M)
2015 ................................................................................................................. 15 39.07 60.48 49.77

2016 ................................................................................................................. 35 91.15 141.12 116.14
2017 ................................................................................................................. 35 91.15 141.12 116.14
2018 ................................................................................................................. 15 39.07 60.48 49.77
4-Year Totals ............................................................................................ ........................ 260.44 403.19 331.82
iii. Testing and Certification Costs for included costs for surveillance of CFR 170.523(g), compile and submit
the 2015 Edition technologies and also estimated the surveillance results quarterly per 45
In the RIA of the Permanent costs for testing and certification above CFR 170.523(i), collect adaptations/
Certification Program final rule, we what we understand are the cost ranges updates quarterly per 45 CFR
estimated the costs for testing and charged by ONC–ACBs today. 170.523(m), and compile and submit
certification of technologies that would iv. New and Revised Principles of complaints per 45 CFR 170.523(n). We
be used for providers to attempt to Proper Conduct Estimated Costs believe that an employee equivalent to
achieve EHR Incentive Programs Stages the Federal Classification of GS–14 Step
1–3.188 These costs were based on the Costs to ONC–ACB
1 could verify health IT developers’
requirements of the certification We have estimated the costs compliance with 45 CFR 170.523(k). We
program and a two-year rulemaking associated with new and revised PoPC have utilized the corresponding
cycle for the CEHRT definition and each finalized in this final rule. For reporting employee hourly rates for the locality
EHR Incentive Programs stage. We requirements under 45 CFR 170.523(f), pay area of Washington, D.C., as
believe the costs we attributed to testing (m), and (n), we have used burden hour published by OPM, to calculate our cost
and certification of technologies in estimates provided in the Proposed Rule estimates. We have also calculated the
support of EHR Incentive Programs (80 FR 16893). For 45 CFR 170.523(i), costs of the employee’s benefits while
Stage 2 in the Permanent Certification we have increased the burden hours
completing the specified tasks. We have
Program final rule would encompass the based on the quarterly reporting
calculated these costs by assuming that
actual testing and certification of requirements and the nature of what
technologies to both the 2014 and 2015 an ONC–ACB expends thirty-six percent
must be reported. For 45 CFR 170.523(g)
Editions. This assessment is based on and (k), we have established burden (36%) of an employee’s hourly wage on
the number of technologies currently hour estimates based on the number of benefits for the employee. We have
certified to the 2014 Edition and our certifications performed per year by concluded that a 36% expenditure on
projections in this proposed rule for the ONC–ACBs. benefits is an appropriate estimate
number of technologies that would We believe that an employee because it is the routine percentage used
likely be tested and certified to the 2015 equivalent to the Federal Classification by HHS for contract cost estimates. Our
Edition. Further, we note that the of GS–12 Step 1 could report the cost estimates are expressed in Table 18
estimated costs in the Permanent required information for 45 CFR below and are expressed in 2015 dollars
Certification Program final rule 170.523(f), retain the records under 45 (rounded).
188 76 FR 1318.
TABLE 18—ANNUAL COSTS FOR AN ONC–ACB TO COMPLY WITH NEW AND REVISED POPC
Employee Employee
Annual burden Total cost
hourly benefits
Program requirement Employee equivalent hours per per ONC–ACB
wage rate hourly cost
ONC–ACB ($)
($) ($)
45 CFR 170.523(f) ............................ GS–12, Step 1 ................................. 230 36.60 $13.18 $11,449.40
45 CFR 170.523(g) ........................... GS–12, Step 1 ................................. 1,000 36.60 13.18 49,780
45 CFR 170.523(i) ............................ GS–12, Step 1 ................................. 80 36.60 13.18 3,982.40
45 CFR 170.523(k) ........................... GS–14, Step 1 ................................. 1,000 51.43 18.51 69,940
45 CFR 170.523(m) .......................... GS–12, Step 1 ................................. 4 36.60 13.18 199.12
45 CFR 170.523(n) ........................... GS–12, Step 1 ................................. 4 36.60 13.18 199.12
Total ........................................... ........................................................... ........................ ........................ ........................ 135,550.04
We estimate the total annual costs to which we have attempted to estimate in highest estimated number of health IT
be $406,650.12 based on three ONC– this final rule below. We have estimated developers we expect to be certified to
ACBs. the burden hours to the extent possible. a 2015 Edition certification criterion
Costs to Health IT Developers We have used the same cost factors as (see Table 11 above). Our cost estimates
discussed above. We have estimated 402 are expressed in Table 19 below and are
Certain new and revised PoPC create health IT developers based on the expressed in 2015 dollars (rounded).
indirect costs on health IT developers,
TABLE 19—ANNUAL COSTS FOR HEALTH IT DEVELOPERS TO COMPLY WITH TRANSPARENCY AND REPORTING
REQUIREMENTS
Annual burden Employee Employee Total number
hours per Total cost
Program requirement Employee equivalent hourly benefits of health IT
health IT ($M)
wage rate hourly cost developers
developer
45 CFR 170.523(k) ............. GS–14, Step 1 .................... 100 $51.43 $18.51 402 2.81
45 CFR 170.523(m) ............ GS–12, Step 1 .................... 8 36.60 13.18 402 .16
Total Costs .................. ............................................. ........................ ........................ ........................ ........................ 2.97
addition, 2015 Edition certification overwhelmingly attributable to CMS’s

b. Benefits criteria that support the collection of final rule.
As noted above, we expect that health patient data that could be used to
IT developers will recover an address health disparities would not 2. Regulatory Flexibility Act (RFA)
appropriate rate of return for their only benefit patients, but the entire The RFA requires agencies to analyze
investments in developing and health care delivery system through options for regulatory relief of small
preparing their health IT for improved quality of care. The 2015 businesses if a rule has a significant
certification to the 2015 Edition Edition also supports usability and
certification criteria adopted in this impact on a substantial number of small
patient safety through new and entities.
final rule. However, we do not have data enhanced certification requirements for
available to quantify these benefits or health IT. The Small Business Administration
other benefits that will likely arise from (SBA) establishes the size of small
This final rule also makes the ONC
health IT developers certifying their businesses for federal government
Health IT Certification Program open
health IT to the 2015 Edition. programs based on average annual
We believe that there will be several and accessible to more types of health
receipts or the average employment of a
significant benefits that may arise from IT and for health IT that supports a
variety of care and practice settings. firm. While health IT developers that
this final rule for patients, health care pursue certification under the ONC
providers, and health IT developers. This should benefit health IT
developers, providers practicing in Health IT Certification Program
The 2015 Edition continues to improve represent a small segment of the overall
health IT interoperability through the other care/practice settings, and
consumers through the availability and information technology industry, we
adoption of new and updated standards believe that the entities impacted by this
and implementation specifications. For use of certified health IT that includes
capabilities that promote proposed rule most likely fall under the
example, many adopted certification
interoperability and enhanced North American Industry Classification
criteria include standards and
functionality. System (NAICS) code 541511 ‘‘Custom
implementation specifications for
interoperability that directly support the We note that, in general, these Computer Programming Services’’
EHR Incentive Programs, which include benefits will be realized only if health specified in 13 CFR 121.201 where the
objectives and measures for the care providers actually adopt new SBA publishes ‘‘Small Business Size
interoperable exchange of health technology. As discussed elsewhere in Standards by NAICS Industry.’’ The
information and for providing patients this RIA, we believe that such SBA size standard associated with this
electronic access to their health adoption—and thus the benefits noted NAICS code is set at $27.5 million in
information in structured formats. In in this section—would be
annual receipts 189 which ‘‘indicates the will not have a significant impact on a ■ a. Removing the definitions for ‘‘Base
maximum allowed for a concern and its substantial number of small entities. EHR’’, ‘‘Certified EHR Technology’’,
affiliates to be considered small ‘‘Common MU Data Set’’, and ‘‘EHR
3. Executive Order 13132—Federalism
entities.’’ Module’’; and
Based on our analysis, we believe that Executive Order 13132 establishes ■ b. Adding in alphanumeric order the
there is enough data generally available certain requirements that an agency definitions for ‘‘2014 Edition Base
to establish that between 75% and 90% must meet when it promulgates a EHR’’, ‘‘2015 Edition Base EHR’’, ‘‘2015
of entities that are categorized under the proposed rule (and subsequent final Edition health IT certification criteria’’,
NAICS code 541511 are under the SBA rule) that imposes substantial direct ‘‘Common Clinical Data Set’’, ‘‘Device
size standard, but note that the available requirement costs on state and local identifier’’, ‘‘Global Unique Device
data does not show how many of these governments, preempts state law, or Identification Database (GUDID)’’,
entities will develop a health IT product otherwise has federalism implications. ‘‘Health IT Module’’, ‘‘Implantable
that will be certified to the 2015 Edition Nothing in this final rule imposes device’’, ‘‘Production identifier’’, and
substantial direct compliance costs on ‘‘Unique device identifier’’.
under the ONC Health IT Certification
state and local governments, preempts The revisions read as follows:
Program. We also note that with the
state law or otherwise has federalism
exception of aggregate business § 170.102 Definitions.
implications. We are not aware of any
information available through the U.S. 2014 Edition Base EHR means an
State laws or regulations that are
Census Bureau and the SBA related to electronic record of health-related
contradicted or impeded by any of the
NAICS code 541511, it appears that information on an individual that:
standards, implementation
many health IT developers that pursue (1) Includes patient demographic and
specifications, or certification criteria
certification under the ONC Health IT clinical health information, such as
that we have adopted.
Certification Program are privately held medical history and problem lists;
or owned and do not regularly, if at all, 4. Unfunded Mandates Reform Act of (2) Has the capacity:
make their specific annual receipts 1995 (i) To provide clinical decision
publicly available. As a result, it is Section 202 of the Unfunded support;
difficult to locate empirical data related Mandates Reform Act of 1995 requires (ii) To support physician order entry;
to many of these health IT developers to that agencies assess anticipated costs (iii) To capture and query information
correlate to the SBA size standard. and benefits before issuing any rule relevant to health care quality;
However, although not correlated to the whose mandates require spending in (iv) To exchange electronic health
size standard for NAICS code 541511, any one year of $100 million in 1995 information with, and integrate such
we do have information indicating that dollars, updated annually for inflation. information from other sources;
over 60% of health IT developers that The current inflation-adjusted statutory (v) To protect the confidentiality,
have had Complete EHRs and/or EHR threshold is approximately $144 integrity, and availability of health
Modules certified to the 2011 Edition million. This final rule will not impose information stored and exchanged; and
have less than 51 employees. (3) Has been certified to the
an unfunded mandate on State, local,
We estimate that this final rule would certification criteria adopted by the
and tribal governments or on the private
have effects on health IT developers that Secretary:
sector that will reach the threshold (i) For at least one of the four criteria
are likely to pursue certification under level. adopted at § 170.314(a)(1), (18), (19), or
the ONC Health IT Certification OMB reviewed this final rule.
(20);
Program, some of which may be small (ii) At § 170.314(a)(3);
List of Subjects in 45 CFR Part 170
entities. However, we believe that we (iii) At § 170.314(a)(5) through (8);
have adopted the minimum amount of Computer technology, Electronic
(iv) Both § 170.314(b)(1) and (2); or,
requirements necessary to accomplish health record, Electronic information
both § 170.314(b)(8) and (h)(1); or
our policy goals, including a reduction system, Electronic transactions, Health,
§ 170.314(b)(1) and (2) combined with
in regulatory burden and additional Health care, Health information
either § 170.314(b)(8) or (h)(1), or both
flexibility for the regulated community, technology, Health insurance, Health
§ 170.314(b)(8) and (h)(1);
and that no additional appropriate records, Hospitals, Incorporation by (v) At § 170.314(b)(7);
regulatory alternatives could be reference, Laboratories, Medicaid, (vi) At § 170.314(c)(1) through (3);
developed to lessen the compliance Medicare, Privacy, Reporting and (vii) At § 170.314(d)(1) through (8);
burden associated with this final rule. recordkeeping requirements, Public (4) Has been certified to the
We note that this final rule does not health, Security. certification criteria at § 170.314(c)(1)
impose the costs cited in the RIA as For the reasons set forth in the and (2):
compliance costs, but rather as preamble, 45 CFR subtitle A, subchapter (i) For no fewer than 9 clinical quality
investments which these health IT D, part 170, is amended as follows: measures covering at least 3 domains
developers voluntarily take on and may from the set selected by CMS for eligible
expect to recover with an appropriate PART 170—HEALTH INFORMATION professionals, including at least 6
rate of return. Accordingly, we do not TECHNOLOGY STANDARDS, clinical quality measures from the
believe that the final rule will create a IMPLEMENTATION SPECIFICATIONS, recommended core set identified by
significant impact on a substantial AND CERTIFICATION CRITERIA AND CMS; or
number of small entities. Additionally, CERTIFICATION PROGRAMS FOR (ii) For no fewer than 16 clinical
the Secretary certifies that this final rule HEALTH INFORMATION quality measures covering at least 3
TECHNOLOGY domains from the set selected by CMS

189 The SBA references that annual receipts for eligible hospitals and critical access
■ 1. The authority citation for part 170 hospitals.
means ‘‘total income’’ (or in the case of a sole
proprietorship, ‘‘gross income’’) plus ‘‘cost of goods continues to read as follows:
* * * * *
sold’’ as these terms are defined and reported on Authority: 42 U.S.C. 300jj–11; 42 U.S.C.
Internal Revenue Service tax return forms. http://
2015 Edition Base EHR means an
300jj–14; 5 U.S.C. 552. electronic record of health-related
www.sba.gov/sites/default/files/files/
Size_Standards_Table.pdf. ■ 2. Amend § 170.102 by: information on an individual that:
(1) Includes patient demographic and 2015 Edition Health IT certification with the standard specified in
clinical health information, such as criteria. § 170.207(c)(3) and with the associated
medical history and problem lists; (7) Smoking status. For certification to applicable unit of measure for the vital
(2) Has the capacity: both the 2014 Edition EHR certification sign measurement in the standard
(i) To provide clinical decision criteria and the 2015 Edition health IT specified in § 170.207(m)(1). For BMI
support; certification criteria: The standard percentile per age and sex for youth 2–
(ii) To support physician order entry; specified in § 170.207(h). 20 years of age and weight for age per
(iii) To capture and query information (8) Problems. (i) At a minimum, the length and sex for children less than 3
relevant to health care quality; standard specified in § 170.207(a)(3) for years of age, the reference range/scale or
(iv) To exchange electronic health certification to the 2014 Edition EHR growth curve should be included as
information with, and integrate such certification criteria. appropriate.
information from other sources; and (ii) At a minimum, the standard (14) Care plan field(s), including goals
(3) Has been certified to the specified in § 170.207(a)(4) for and instructions. For certification to the
certification criteria adopted by the certification to the 2015 Edition Health 2014 Edition EHR certification criteria.
Secretary in § 170.315(a)(1), (2), or (3); IT certification criteria. (15) Procedures—(i)(A) At a
(a)(5) through (9); (a)(11); (a)(15); (b)(1) (9) Medications. (i) At a minimum, the minimum, the version of the standard
and (6); (c)(1); (g)(7) through (9); and standard specified in § 170.207(d)(2) for specified in § 170.207(a)(3) for
(h)(1) or (2); certification to the 2014 Edition EHR certification to the 2014 Edition EHR
2015 Edition health IT certification certification criteria. certification criteria and § 170.207(a)(4)
criteria means the certification criteria (ii) At a minimum, the standard for certification to the 2015 Edition
in § 170.315. specified in § 170.207(d)(3) for health IT certification criteria, or
certification to the 2015 Edition Health § 170.207(b)(2); or
* * * * *
IT certification criteria. (B) For technology primarily
Common Clinical Data Set means the (10) Medication allergies. (i) At a
following data expressed, where developed to record dental procedures,
minimum, the standard specified in the standard specified in § 170.207(b)(3)
indicated, according to the specified § 170.207(d)(2) for certification to the
standard(s): for certification to both the 2014 Edition
2014 Edition EHR certification criteria. EHR certification criteria and the 2015
(1) Patient name. For certification to (ii) At a minimum, the standard
both the 2014 Edition EHR certification Edition health IT certification criteria.
specified in § 170.207(d)(3) for (ii) Optional. The standard specified
criteria and the 2015 Edition health IT certification to the 2015 Edition Health in § 170.207(b)(4) for certification to
certification criteria. IT certification criteria. both the 2014 Edition EHR certification
(2) Sex. (i) No required standard for (11) Laboratory test(s). (i) At a criteria and the 2015 Edition health IT
certification to the 2014 Edition EHR minimum, the standard specified in certification criteria.
certification criteria. § 170.207(c)(2) for certification to the (16) Care team member(s). For
(ii) The standard specified in 2014 Edition EHR certification criteria. certification to both the 2014 Edition
§ 170.207(n)(1) for certification to the (ii) At a minimum, the standard EHR certification criteria and the 2015
2015 Edition health IT certification specified in § 170.207(c)(3) for Edition health IT certification criteria.
criteria. certification to the 2015 Edition Health (17) Immunizations. In accordance
(3) Date of birth. For certification to IT certification criteria. with, at a minimum, the standards
both the 2014 Edition EHR certification (12) Laboratory value(s)/result(s). For specified in § 170.207(e)(3) and (4) for
criteria and the 2015 Edition health IT certification to both the 2014 Edition certification to the 2015 Edition health
certification criteria. EHR certification criteria and the 2015 IT certification criteria.
(4) Race. (i) The standard specified in Edition health IT certification criteria. (18) Unique device identifier(s) for a
§ 170.207(f)(1) for certification to the (13) Vital signs. (i) Height/length, patient’s implantable device(s). In
2014 Edition EHR certification criteria. weight, blood pressure, and BMI for accordance with the ‘‘Product Instance’’
(ii) For certification to the 2015 certification to the 2014 Edition EHR in the ‘‘Procedure Activity Procedure
Edition health IT certification criteria: certification criteria. Section’’ of the standard specified in
(A) The standard specified in (ii) For certification to the 2015 § 170.205(a)(4) for certification to the
§ 170.207(f)(2); Edition Health IT certification criteria: 2015 Edition health IT certification
(B) The standard specified in (A) The patient’s diastolic blood criteria.
§ 170.207(f)(1) for each race identified in pressure, systolic blood pressure, body (19) Assessment and plan of
accordance § 170.207(f)(2). height, body weight, heart rate, treatment. For certification to the 2015
(5) Ethnicity. (i) The standard respiratory rate, body temperature, Edition health IT certification criteria:
specified in § 170.207(f)(1) for pulse oximetry, and inhaled oxygen (i) In accordance with the
certification to the 2014 Edition EHR concentration must be exchanged in ‘‘Assessment and Plan Section (V2)’’ of
certification criteria. numerical values only; and the standard specified in § 170.205(a)(4);
(ii) For certification to the 2015 (B) In accordance with the standard or
Edition health IT certification criteria: specified in § 170.207(c)(3) and with the (ii) In accordance with the
(A) The standard specified in associated applicable unit of measure ‘‘Assessment Section (V2)’’ and ‘‘Plan of
§ 170.207(f)(2); for the vital sign measurement in the Treatment Section (V2)’’ of the standard
(B) The standard specified in standard specified in § 170.207(m)(1). specified in § 170.205(a)(4).
§ 170.207(f)(1) for each ethnicity (C) Optional. The patient’s BMI (20) Goals. In accordance with the
identified in accordance § 170.207(f)(2). percentile per age and sex for youth 2– ‘‘Goals Section’’ of the standard
(6) Preferred language. (i) The 20 years of age, weight for age per length specified in § 170.205(a)(4) for
standard specified in § 170.207(g)(1) for and sex for children less than 3 years of certification to the 2015 Edition health
certification to the 2014 Edition EHR age, and head occipital-frontal IT certification criteria.
certification criteria. circumference for children less than 3 (21) Health concerns. In accordance
(ii) The standard specified in years of age must be recorded in with the ‘‘Health Concerns Section’’ of
§ 170.207(g)(2) for certification to the numerical values only in accordance the standard specified in § 170.205(a)(4)
for certification to the 2015 Edition (b) * * * Erratum to the CDC PHIN 2.0 Messaging
health IT certification criteria. (2) Implementation specifications. Guide, April 2015 Release for
* * * * * HL7 Implementation Guide: Service- Syndromic Surveillance: Emergency
Device identifier is defined as it is in Oriented Architecture Implementations Department, Urgent Care, Inpatient and
21 CFR 801.3. of the Context-aware Knowledge Ambulatory Care Settings (incorporated
* * * * * Retrieval (Infobutton) Domain, Draft by reference in § 170.299).
Global Unique Device Identification Standard for Trial Use, Release 1 (e) * * *
Database (GUDID) is defined as it is in (incorporated by reference in § 170.299). (4) Standard. HL7 2.5.1 (incorporated
21 CFR 801.3. (3) Standard. HL7 Version 3 Standard: by reference in § 170.299).
Health IT Module means any service, Context Aware Knowledge Retrieval Implementation specifications. HL7
component, or combination thereof that Application. (‘‘Infobutton’’), Knowledge 2.5.1 Implementation Guide for
can meet the requirements of at least Request, Release 2 (incorporated by Immunization Messaging, Release 1.5
one certification criterion adopted by reference in § 170.299). Implementation (incorporated by reference in § 170.299)
the Secretary. specifications. HL7 Implementation and HL7 Version 2.5.1 Implementation
* * * * * Guide: Service-Oriented Architecture Guide for Immunization Messaging
Implantable device is defined as it is Implementations of the Context-aware (Release 1.5)—Addendum, July 2015
in 21 CFR 801.3. Knowledge Retrieval (Infobutton) (incorporated by reference in § 170.299).
Domain, Release 1 (incorporated by * * * * *
* * * * * reference in § 170.299).
Production identifier is defined as it is (h) Clinical quality measure data
(4) Standard. HL7 Version 3 Standard: import, export and reporting. (1)
in 21 CFR 801.3.
Context Aware Knowledge Retrieval Standard. HL7 Implementation Guide
* * * * * Application (‘‘Infobutton’’), Knowledge
Unique device identifier is defined as for CDA® Release 2: Quality Reporting
Request, Release 2 (incorporated by Document Architecture (incorporated by
it is in 21 CFR 801.3. reference in § 170.299). Implementation reference in § 170.299).
§ 170.200 [Amended] specifications. HL7 Version 3 (2) Standard. HL7 CDA® R2
Implementation Guide: Context-Aware Implementation Guide: Quality
■ 3. In § 170.200, remove the term ‘‘EHR Knowledge Retrieval (Infobutton),
Modules’’ and add in its place ‘‘Health Reporting Document Architecture—
Release 4 (incorporated by reference in Category I (QRDA I); Release 1, DSTU
IT Modules.’’ § 170.299).
■ 4. Amend § 170.202 by—
Release 3 (US Realm), Volume 1—
■ a. Revising the section heading;
■ 6. Amend § 170.205 by— Introductory Material and HL7 CDA® R2
■ a. Adding paragraphs (a)(4), (d)(4), Implementation Guide: Quality
■ b. Revising paragraph (a); and
■ c. Adding paragraph (e).
and (e)(4); Reporting Document Architecture—
The additions and revisions read as ■ b. Revising paragraphs (h), (i), and (k); Category I (QRDA I); Release 1, DSTU
■ c. Reserving paragraphs (1), (m), (n), Release 3 (US Realm), Volume 2—
follows:
and (q); and Templates and Supporting Material
§ 170.202 Transport standards and other ■ d. Adding paragraphs (o), (p), (r), and
(incorporated by reference in § 170.299).
protocols. (s). (i) Cancer information—(1) Standard.
* * * * * The additions and revisions read as HL7 Clinical Document Architecture
(a) Direct Project—(1) Standard. ONC follows: (CDA), Release 2.0, Normative Edition
Applicability Statement for Secure (incorporated by reference in § 170.299).
§ 170.205 Content exchange standards
Health Transport, Version 1.0 and implementation specifications for Implementation specifications.
(incorporated by reference in § 170.299). exchanging electronic health information. Implementation Guide for Ambulatory
(2) Standard. ONC Applicability Healthcare Provider Reporting to
Statement for Secure Health Transport, * * * * *
(a) * * * Central Cancer Registries, HL7 Clinical
Version 1.2 (incorporated by reference Document Architecture (CDA), Release
(4) Standard. HL7 Implementation
in § 170.299).
Guide for CDA® Release 2: Consolidated 1.0 (incorporated by reference in
* * * * * CDA Templates for Clinical Notes (US § 170.299).
(e) Delivery notification—(1) Realm), Draft Standard for Trial Use, (2) Standard. HL7 Clinical Document
Standard. ONC Implementation Guide Volume 1—Introductory Material, Architecture (CDA), Release 2.0,
for Delivery Notification in Direct Release 2.1 and HL7 Implementation Normative Edition (incorporated by
(incorporated by reference in § 170.299). Guide for CDA® Release 2: Consolidated reference in § 170.299). Implementation
(2) [Reserved] CDA Templates for Clinical Notes (US specifications. HL7 CDA© Release 2
■ 5. Amend § 170.204 by— Realm), Draft Standard for Trial Use, Implementation Guide: Reporting to
■ a. Revising paragraphs (a) and (b)(2); Public Health Cancer Registries from
Volume 2—Templates and Supporting
and Material, Release 2.1 (incorporated by Ambulatory Healthcare Providers,
■ b. Adding paragraphs (b)(3) and (4).
reference in § 170.299). Release 1; DSTU Release 1.1, Volume
The additions and revisions read as 1—Introductory Material and HL7
follows: * * * * *
(d) * * * CDA© Release 2 Implementation Guide:
§ 170.204 Functional standards. (4) Standard. HL7 2.5.1 (incorporated Reporting to Public Health Cancer
* * * * * by reference in § 170.299). Registries from Ambulatory Healthcare
(a) Accessibility—(1) Standard. Web Implementation specifications. PHIN Providers, Release 1; DSTU Release 1.1
Content Accessibility Guidelines Messaging Guide for Syndromic (US Realm), Volume 2—Templates and
(WCAG) 2.0, Level A Conformance Surveillance: Emergency Department, Supporting Material (incorporated by
(incorporated by reference in § 170.299). Urgent Care, Inpatient and Ambulatory reference in § 170.299).
(2) Standard. Web Content Care Settings, Release 2.0, April 21, * * * * *
Accessibility Guidelines (WCAG) 2.0, 2015 (incorporated by reference in (k) Clinical quality measure aggregate
Level AA Conformance (incorporated by § 170.299) and Erratum to the CDC PHIN reporting. (1) Standard. Quality
reference in § 170.299). 2.0 Implementation Guide, August 2015; Reporting Document Architecture
Category III, Implementation Guide for ■ c. Reserving paragraphs (k) and (l); Version 3 Standard, Value Sets for
CDA Release 2 (incorporated by and AdministrativeGender and NullFlavor
reference in § 170.299). ■ d. Adding paragraphs (m), (n), (o), (p), (incorporated by reference in § 170.299),
(2) Standard. Errata to the HL7 (q), (r), and (s). attributed as follows:
Implementation Guide for CDA® The additions and revisions read as (i) Male. M
Release 2: Quality Reporting Document follows: (ii) Female. F
Architecture—Category III, DSTU (iii) Unknown. nullFlavor UNK
§ 170.207 Vocabulary standards for (2) [Reserved]
Release 1 (US Realm), September 2014 representing electronic health information.
(incorporated by reference in § 170.299). (o) Sexual orientation and gender
(l) [Reserved] * * * * * identity—(1) Standard. Sexual
(m) [Reserved] (a) * * * orientation must be coded in accordance
(4) Standard. IHTSDO SNOMED CT®, with, at a minimum, the version of
(n) [Reserved]
U.S. Edition, September 2015 Release SNOMED CTsupreg; codes specified in
(o) Data segmentation for privacy—(1)
(incorporated by reference in § 170.299). paragraph (a)(4) of this section for
Standard. HL7 Implementation Guide:
Data Segmentation for Privacy (DS4P), * * * * * paragraphs (o)(1)(i) through (iii) of this
Release 1 (incorporated by reference in (c) * * * section and HL7 Version 3 Standard,
§ 170.299). (3) Standard. Logical Observation Value Sets for AdministrativeGender
(2) [Reserved] Identifiers Names and Codes (LOINC®) and NullFlavor (incorporated by
(p) XDM package processing—(1) Database version 2.52, a universal code reference in § 170.299), for paragraphs
Standard. IHE IT Infrastructure system for identifying laboratory and (o)(1)(iv) through (vi) of this section,
Technical Framework Volume 2b (ITI clinical observations produced by the attributed as follows:
TF–2b) (incorporated by reference in Regenstrief Institute, Inc. (incorporated (i) Lesbian, gay or homosexual.
§ 170.299). by reference in § 170.299). 38628009
(2) [Reserved] (d) * * * (ii) Straight or heterosexual. 20730005
(3) Standard. RxNorm, a standardized (iii) Bisexual. 42035005
(q) [Reserved]
nomenclature for clinical drugs (iv) Something else, please describe.
(r) Public health—antimicrobial use
produced by the United States National nullFlavor OTH
and resistance information—(1)
Library of Medicine, September 8, 2015 (v) Don’t know. nullFlavor UNK
Standard. The following sections of HL7
Release (incorporated by reference in (vi) Choose not to disclose. nullFlavor
Implementation Guide for CDA®
§ 170.299). ASKU
Release 2—Level 3: Healthcare
(e) * * * (2) Standard. Gender identity must be
Associated Infection Reports, Release 1, (3) Standard. HL7 Standard Code Set coded in accordance with, at a
U.S. Realm (incorporated by reference CVX—Vaccines Administered, updates minimum, the version of SNOMED CT®
in § 170.299). Technology is only through August 17, 2015 (incorporated codes specified in paragraph (a)(4) of
required to conform to the following by reference in § 170.299). this section for paragraphs (o)(2)(i)
sections of the implementation guide: (4) Standard. National Drug Code through (v) of this section and HL7
(i) HAI Antimicrobial Use and Directory (NDC)—Vaccine NDC Linker, Version 3 Standard, Value Sets for
Resistance (AUR) Antimicrobial updates through August 17, 2015 AdministrativeGender and NullFlavor
Resistance Option (ARO) Report (incorporated by reference in § 170.299). (incorporated by reference in § 170.299),
(Numerator) specific document template (f) Race and Ethnicity—(1) Standard. for paragraphs (o)(2)(vi) and (vii) of this
in Section 2.1.2.1 (pages 69–72); The Office of Management and Budget section, attributed as follows:
(ii) Antimicrobial Resistance Option Standards for Maintaining, Collecting, (i) Male. 446151000124109
(ARO) Summary Report (Denominator) and Presenting Federal Data on Race (ii) Female. 446141000124107
specific document template in Section and Ethnicity, Statistical Policy (iii) Female-to-Male (FTM)/
2.1.1.1 (pages 54–56); and Directive No. 15, as revised, October 30, Transgender Male/Trans Man.
(iii) Antimicrobial Use (AUP) 1997 (incorporated by reference in 407377005
Summary Report (Numerator and § 170.299). (iv) Male-to-Female (MTF)/
Denominator) specific document (2) Standard. CDC Race and Ethnicity Transgender Female/Trans Woman.
template in Section 2.1.1.2 (pages 56– Code Set Version 1.0 (March 2000) 407376001
58). (incorporated by reference in § 170.299). (v) Genderqueer, neither exclusively
(2) [Reserved] (g) Preferred language—(1) Standard. male nor female. 446131000124102
(s) Public health—health care survey As specified by the Library of Congress, (vi) Additional gender category or
information—(1) Standard. HL7 ISO 639–2 alpha-3 codes limited to other, please specify. nullFlavor OTH
Implementation Guide for CDA® those that also have a corresponding (vii) Choose not to disclose.
Release 2: National Health Care Surveys alpha-2 code in ISO 639–1 (incorporated nullFlavor ASKU
(NHCS), Release 1—US Realm, HL7 by reference in § 170.299). (p) Social, psychological, and
Draft Standard for Trial Use, Volume (2) Standard. Request for Comments behavioral data—(1) Financial resource
1—Introductory Material and HL7 (RFC) 5646 (incorporated by reference strain. Financial resource strain must be
Implementation Guide for CDA® in § 170.299). coded in accordance with, at a
Release 2: National Health Care Surveys * * * * * minimum, the version of LOINC® codes
(NHCS), Release 1—US Realm, HL7 (k) [Reserved] specified in paragraph (c)(3) of this
Draft Standard for Trial Use, Volume (l) [Reserved] section and attributed with the LOINC®
2—Templates and Supporting Material (m) Numerical references—(1) code 76513–1 and LOINC® answer list
(incorporated by reference in § 170.299). Standard. The Unified Code of Units of ID LL3266–5.
(2) [Reserved] Measure, Revision 1.9 (incorporated by (2) Education. Education must be
■ 7. Amend § 170.207 by— reference in § 170.299). coded in accordance with, at a
■ a. Adding paragraphs (a)(4), (c)(3), (2) [Reserved] minimum, the version of LOINC® codes
(d)(3), (e)(3) and (4); (n) Sex—(1) Standard. Birth sex must specified in paragraph (c)(3) of this
■ b. Revising paragraphs (f) and (g); and be coded in accordance with HL7 section and attributed with LOINC®
code 63504–5 and LOINC® answer list 76499–3, 76500–8 (with LOINC® answer to or greater than SHA–1 (Secure Hash
ID LL1069–5. list ID LL963–0), 76501–6 (with LOINC® Algorithm (SHA–1)) as s specified by
(3) Stress. Stress must be coded in answer list ID LL963–0), 76502–4 (with the National Institute of Standards and
accordance with, at a minimum, the LOINC® answer list ID LL963–0), Technology (NIST) in FIPS PUB 180–4
version of LOINC® codes specified in 76503–2 (with LOINC® answer list ID (March 2012)).
paragraph (c)(3) of this section and LL963–0), and 76504–0 (with the (2) Standard. A hashing algorithm
attributed with the LOINC® code associated applicable unit of measure in with a security strength equal to or
76542–0 and LOINC® answer list the standard specified in greater than SHA–2 as specified by
LL3267–3. § 170.207(m)(1)). NIST in FIPS Publication 180–4 (August
(4) Depression. Depression must be (q) Patient matching. (1) Phone 2015) (incorporated by reference in
coded in accordance with, at a number standard. ITU–T E.123, Series § 170.299).
minimum, the version of LOINC® codes E: Overall Network Operation, * * * * *
specified in paragraph (c)(3) of this Telephone Service, Service Operation (e) * * *
section and attributed with LOINC® and Human Factors, International (1)(i) The audit log must record the
codes 55757–9, 44250–9 (with LOINC® operation—General provisions information specified in sections 7.2
answer list ID LL358–3), 44255–8 (with concerning users: Notation for national through 7.4, 7.6, and 7.7 of the standard
LOINC® answer list ID LL358–3), and and international telephone numbers, specified in § 170.210(h) and changes to
55758–7 (with the answer coded with email addresses and web addresses user privileges when health IT is in use.
the associated applicable unit of (incorporated by reference in § 170.299);
measure in the standard specified in * * * * *
and ITU–T E.164, Series E: Overall (h) Audit log content. ASTM E2147–
§ 170.207(m)(1)). Network Operation, Telephone Service,
(5) Physical activity. Physical activity 01 (Reapproved 2013), (incorporated by
Service Operation and Human Factors, reference in § 170.299).
must be coded in accordance with, at a International operation—Numbering
minimum, the version of LOINC® codes plan of the international telephone
■ 9. In § 170.299:
specified in paragraph (c)(3) of this ■ a. Revise paragraph (c)(1).
service: The international public
section and attributed with LOINC® telecommunication numbering plan
■ b. Add paragraphs (d)(10) through
codes 68515–6 and 68516–4. The (16), (e)(3) and (f)(15) through (29).
(incorporated by reference in § 170.299).
answers must be coded with the ■ c. Redesignate paragraphs (g), (h), (i),
(2) [Reserved]
associated applicable unit of measure in (r) Provider type. (1) Standard. (j), (k), (l), (m), and (n) as paragraphs (h),
the standard specified in Crosswalk: Medicare Provider/Supplier (j), (k), (l), (m), (o), (q), and (r),
§ 170.207(m)(1). to Healthcare Provider Taxonomy, April respectively.
(6) Alcohol use. Alcohol use must be ■ d. Add new paragraphs (g), (i), (n),
2, 2015 (incorporated by reference in
coded in accordance with, at a § 170.299). and (p).
minimum, the version of LOINC® codes (2) [Reserved] ■ e. Amend newly redesignated
specified in paragraph (c)(3) of this (s) Patient insurance. (1) Standard. paragraph (h) by revising paragraph (h)
section and attributed with LOINC® Public Health Data Standards introductory text and adding paragraph
codes 72109–2, 68518–0 (with LOINC® Consortium Source of Payment (h)(3).
answer list ID LL2179–1), 68519–8 (with Typology Code Set Version 5.0 (October ■ f. Amend newly redesignated
LOINC® answer list ID LL2180–9), 2011) (incorporated by reference in paragraph (l) by adding paragraphs (l)(3)
68520–6 (with LOINC® answer list ID § 170.299). and (4).
LL2181–7), and 75626–2. ■ g. Amend newly redesignated
(2) [Reserved]
(7) Social connection and isolation. paragraph (m) by revising paragraph (m)
■ 8. In § 170.210:
Social connection and isolation must be introductory text.
■ a. Add paragraph (a)(2)
coded in accordance with, at a ■ h. Amend newly redesignated
■ b. Revise paragraphs (c) and (e)(1)(i);
minimum, the version of LOINC® codes ■ c. Amend paragraphs (e)(3) by
paragraph (o) by revising paragraph (o)
specified in paragraph (c)(3) of this removing the term ‘‘EHR technology’’ introductory text and adding paragraphs
section and attributed with the LOINC® and adding in its place ‘‘health IT’’; and (o)(3) and (4).
codes 76506–5, 63503–7 (with LOINC ■ d. Revise paragraph (h).
■ i. Amend newly redesignated
answer list ID LL1068–7), 76508–1 (with The addition and revisions read as paragraph (q) by adding paragraphs
the associated applicable unit of follows: (q)(6) and (7).
measure in the standard specified in The additions and revisions read as
§ 170.207(m)(1)), 76509–9 (with the § 170.210 Standards for health information follows:
associated applicable unit of measure in technology to protect electronic health
the standard specified in information created, maintained, and § 170.299 Incorporation by reference.
§ 170.207(m)(1)), 76510–7 (with the exchanged. * * * * *
associated applicable unit of measure in * * * * * (c) * * *
the standard specified in (a) * * * (1) ASTM E2147–01 (Reapproved
§ 170.207(m)(1)), 76511–5 (with LOINC (2) General. Any encryption algorithm 2013) Standard Specification for Audit
answer list ID LL963–0), and 76512–3 identified by the National Institute of and Disclosure Logs for Use in Health
(with the associated applicable unit of Standards and Technology (NIST) as an Information Systems, approved March
measure in the standard specified in approved security function in Annex A 1, 2013, IBR approved for § 170.210(h).
§ 170.207(m)(1)). of the Federal Information Processing * * * * *
(8) Exposure to violence (intimate Standards (FIPS) Publication 140–2, (d) * * *

partner violence). Exposure to violence: October 8, 2014 (incorporated by (10) PHIN Messaging Guide for
Intimate partner violence must be coded reference in § 170.299). Syndromic Surveillance: Emergency
in accordance with, at a minimum, the * * * * * Department, Urgent Care, Inpatient and
version of LOINC® codes specified in (c) Hashing of electronic health Ambulatory Care Settings, Release 2.0,
paragraph (c)(3) of this section and information. (1) Standard. A hashing April 21, 2015, IBR approved for
attributed with the LOINC® code algorithm with a security strength equal § 170.205(d).
(11) Erratum to the CDC PHIN 2.0 (21) HL7 CDA® R2 Implementation (h) Internet Engineering Task Force
Implementation Guide, August 2015; Guide: Quality Reporting Document (IETF) Secretariat, c/o Association
Erratum to the CDC PHIN 2.0 Messaging Architecture—Category I (QRDA I); Management Solutions, LLC (AMS),
Guide, April 2015 Release for Release 1, DSTU Release 3 (US Realm), 48377 Fremont Blvd., Suite 117,
Syndromic Surveillance: Emergency Volume 2—Templates and Supporting Fremont, CA, 94538, Telephone (510)
Department, Urgent Care, Inpatient and Material, June 2015, IBR approved for 492–4080, http://www.ietf.org/rfc.html.
Ambulatory Care Settings, IBR approved § 170.205(h). * * * * *
for § 170.205(d). (22) HL7 CDA© Release 2 (3) Request for Comment (RFC) 5646,
(12) HL7 2.5.1 Implementation Guide Implementation Guide: Reporting to ‘‘Tags for Identifying Languages,
for Immunization Messaging, Release Public Health Cancer Registries from September 2009,’’ copyright 2009, IBR
1.5, October 1, 2014, IBR approved for Ambulatory Healthcare Providers, approved for § 170.207(g).
§ 170.205(e). Release 1; DSTU Release 1.1 (US (i) International Telecommunication
(13) HL7 Version 2.5.1 Realm), Volume 1—Introductory Union (ITU), Place des Nations, 1211
Implementation Guide for Material, April 2015, IBR approved for Geneva 20 Switzerland, Telephone (41)
Immunization Messaging (Release 1.5)— § 170.205(i). 22 730 511, http://www.itu.int/en/
Addendum, July 2015, IBR approved for (23) HL7 CDA© Release 2 pages/default.aspx.
§ 170.205(e). Implementation Guide: Reporting to (1) ITU–T E.123, Series E: Overall
(14) HL7 Standard Code Set CVX— Public Health Cancer Registries from Network Operation, Telephone Service,
Vaccines Administered, updates Ambulatory Healthcare Providers, Service Operation and Human Factors,
through August 17, 2015, IBR approved Release 1; DSTU Release 1.1 (US International operation—General
for § 170.207(e). Realm), Volume 2—Templates and provisions concerning users: Notation
(15) National Drug Code Directory Supporting Material, April 2015, IBR for national and international telephone
(NDC)—Vaccine NDC Linker, updates approved for § 170.205(i). numbers, e-mail addresses and web
through August 17, 2015, IBR approved (24) Errata to the HL7 Implementation addresses, February 2001, IBR approved
for § 170.207(e). Guide for CDA® Release 2: Quality for § 170.207(q).
(16) CDC Race and Ethnicity Code Set Reporting Document Architecture— (2) ITU–T E.164, Series E: Overall
Version 1.0 (March 2000), IBR approved Category III, DSTU Release 1 (US Network Operation, Telephone Service,
for § 170.207(f). Realm), September 2014, IBR approved Service Operation and Human Factors,
(e) * * * for § 170.205(k). International operation—Numbering
(3) Crosswalk: Medicare Provider/ (25) HL7 Version 3 Implementation plan of the international telephone
Supplier to Healthcare Provider Guide: Data Segmentation for Privacy service, The international public
Taxonomy, April 2, 2015, IBR approved (DS4P), Release 1, Part 1: CDA R2 and telecommunication numbering plan,
for § 170.207(r). Privacy Metadata Reusable Content November 2010, IBR approved for
(f) * * * Profile, May 16, 2014, IBR approved for § 170.207(q).
(15) HL7 Version 3 Standard: Context § 170.205(o).
Aware Retrieval Application (26) HL7 Implementation Guide for * * * * *
(‘‘Infobutton’’), Knowledge Request, (l) * * *
CDA® Release 2—Level 3: Healthcare
Release 2, 2014 Release, IBR approved (3) Annex A: Federal Information
Associated Infection Reports, Release 1
for § 170.204(b). Processing Standards (FIPS) Publication
(U.S. Realm), August 9, 2013, IBR
(16) HL7 Implementation Guide: 140–2, Security Requirements for
approved for § 170.205(r).
Service-Oriented Architecture Cryptographic Modules, October 8,
(27) HL7 Implementation Guide for
Implementations of the Context-aware 2014, IBR approved for § 170.210(a).
CDA® Release 2: National Health Care
Knowledge Retrieval (Infobutton) (4) FIPS PUB 180–4, Secure Hash
Surveys (NHCS), Release 1—US Realm,
Domain, Release 1, August 9, 2013, IBR Standard (August 2015), IBR approved
HL7 Draft Standard for Trial Use,
approved for § 170.204(b). for § 170.210(c).
Volume 1—Introductory Material, (m) Office of the National Coordinator
(17) HL7 Version 3 Implementation December 2014, IBR approved for
Guide: Context-Aware Knowledge for Health Information Technology
§ 170.205(s). (ONC), 330 C Street SW., Washington,
Retrieval (Infobutton), Release 4, June (28) HL7 Implementation Guide for
DC 20201, http://healthit.hhs.gov.
13, 2014, IBR approved for § 170.204(b). CDA® Release 2: National Health Care
(18) HL7 Implementation Guide for Surveys (NHCS), Release 1—US Realm, * * * * *
CDA® Release 2: Consolidated CDA HL7 Draft Standard for Trial Use, (n) Public Health Data Standards
Templates for Clinical Notes (US Volume 2—Templates and Supporting Consortium, 111 South Calvert Street,
Realm), Draft Standard for Trial Use, Material, December 2014, IBR approved Suite 2700, Baltimore, MD 21202,
Volume 1—Introductory Material, for § 170.205(s). http://www.phdsc.org/.
Release 2.1, August 2015, IBR approved (29) HL7 Version 3 (V3) Standard, (1) Public Health Data Standards
for § 170.205(a). Value Sets for AdministrativeGender Consortium Source of Payment
(19) HL7 Implementation Guide for and NullFlavor, published August 1, Typology Code Set Version 5.0 (October
CDA® Release 2: Consolidated CDA 2013, IBR approved for § 170.207(n) and 2011), IBR approved for § 170.207(s).
Templates for Clinical Notes (US (o). (2) [Reserved]
Realm), Draft Standard for Trial Use, (g) Integrating the Healthcare (o) Regenstrief Institute, Inc., LOINC®
Volume 2—Templates and Supporting Enterprise (IHE), 820 Jorie Boulevard, c/o Regenstrief Center for Biomedical
Material, Release 2.1, August 2015, IBR Oak Brook, IL, Telephone (630) 481– Informatics, Inc., 410 West 10th Street,
approved for § 170.205(a). 1004, http://http://www.ihe.net/. Suite 2000, Indianapolis, IN 46202–

(20) HL7 CDA® R2 Implementation (1) IHE IT Infrastructure Technical 3012, http://loinc.org/.
Guide: Quality Reporting Document Framework Volume 2b (ITI TF–2b), * * * * *
Architecture—Category I (QRDA I); Transactions Part B—Sections 3.29— (3) Logical Observation Identifiers
Release 1, DSTU Release 3 (US Realm), 2.43, Revision 7.0, August 10, 2010, IBR Names and Codes (LOINC®) Database
Volume 1—Introductory Material, June approved for § 170.205(p). version 2.52, Released June 2015, IBR
2015, IBR approved for § 170.205(h). (2) [Reserved] approved for § 170.207(c).
(4) The Unified Code of Units for ■ f. In paragraph (c)(2)(i), remove (1) To a specific set of identified
Measure, Revision 1.9, October 23, ‘‘§ 170.205(h)’’ and add in its place users.
2013, IBR approved for § 170.207. ‘‘§ 170.205(h)(1)’’; (2) As a system administrative
(p) The Direct Project, c/o the Office ■ g. In paragraph (c)(3)(i), remove function.
of the National Coordinator for Health ‘‘§ 170.205(h)’’ and add in its place (5) Demographics. (i) Enable a user to
Information Technology (ONC), 330 C ‘‘§ 170.205(h)(1)’’; record, change, and access patient
Street SW., Washington, DC 20201, ■ h. In paragraph (c)(3)(i), remove ‘‘(k)’’ demographic data including race,
http://healthit.hhs.gov. and add in its place ‘‘§ (k)(1)’’; ethnicity, preferred language, sex,
(1) Applicability Statement for Secure ■ i. In paragraphs (d)(8)(i) and (ii), sexual orientation, gender identity, and
Health Transport, Version 1.2, August remove ‘‘§ 170.210(c)’’ and add in its date of birth.
2015, IBR approved for § 170.202(a). place ‘‘170.210(c)(1)’’; (A) Race and ethnicity. (1) Enable
(2) Implementation Guide for Delivery ■ j. In paragraph (e)(1)(i)(A) each one of a patient’s races to be
Notification in Direct, Version 1.0, June introductory text, remove ‘‘§ 170.204(a)’’ recorded in accordance with, at a
29, 2012, IBR approved for § 170.202(e). and add in its place ‘‘§ 170.204(a)(1)’’; minimum, the standard specified in
(q) * * * ■ k. In paragraph (f)(6)(i), remove § 170.207(f)(2) and whether a patient
(6) International Health Terminology ‘‘§ 170.205(i)’’ and add in its place ’’ declines to specify race.
Standards Development Organization § 170.205(i)(1)’’; (2) Enable each one of a patient’s
(IHTSDO) Systematized Nomenclature ■ l. In paragraphs (b)(1)(i)(A) and (B), ethnicities to be recorded in accordance
of Medicine Clinical Terms (SNOMED (b)(2)(ii)(A) and (B), (b)(8)(i)(A) and (B), with, at a minimum, the standard
CT®) U.S. Edition, September 2015 (e)(1)(i)(C)(1)(i) and (ii), (e)(1)(i)(C)(2)(i) specified in § 170.207(f)(2) and whether
Release, IBR approved for § 170.207(a). and (ii), and (h)(1) and (2), remove a patient declines to specify ethnicity.
(7) RxNorm, September 8, 2015 Full ‘‘§ 170.202(a)’’ and add in its place (3) Aggregate each one of the patient’s
Release Update, IBR approved for ‘‘§ 170.202(a)(1)’’. races and ethnicities recorded in
§ 170.207(d). ■ 12. Add § 170.315 to subpart C to read accordance with paragraphs
as follows: (a)(5)(i)(A)(1) and (2) of this section to
■ 10. In § 170.300, revise paragraph (d)
the categories in the standard specified
to read as follows: § 170.315 2015 Edition health IT in § 170.207(f)(1).
certification criteria. (B) Preferred language. Enable
§ 170.300 Applicability.
The Secretary adopts the following preferred language to be recorded in
* * * * * certification criteria for health IT.
(d) In §§ 170.314 and 170.315, all accordance with the standard specified
Health IT must be able to electronically in § 170.207(g)(2) and whether a patient
certification criteria and all capabilities perform the following capabilities in
specified within a certification criterion declines to specify a preferred language.
accordance with all applicable (C) Sex. Enable sex to be recorded in
have general applicability (i.e., apply to standards and implementation accordance with the standard specified
any health care setting) unless specifications adopted in this part: in § 170.207(n)(1).
designated as ‘‘inpatient setting only’’ or (a) Clinical—(1) Computerized (D) Sexual orientation. Enable sexual
‘‘ambulatory setting only.’’ provider order entry—medications. (i) orientation to be recorded in accordance
(1) Inpatient setting only means that Enable a user to record, change, and with the standard specified in
the criterion or capability within the access medication orders. § 170.207(o)(1) and whether a patient
criterion is only required for (ii) Optional. Include a ‘‘reason for declines to specify sexual orientation.
certification of health IT designed for order’’ field. (E) Gender identity. Enable gender
use in an inpatient setting. (2) Computerized provider order identity to be recorded in accordance
(2) Ambulatory setting only means entry—laboratory. (i) Enable a user to with the standard specified in
that the criterion or capability within record, change, and access laboratory § 170.207(o)(2) and whether a patient
the criterion is only required for orders. declines to specify gender identity.
certification of health IT designed for (ii) Optional. Include a ‘‘reason for (ii) Inpatient setting only. Enable a
use in an ambulatory setting. order’’ field. user to record, change, and access the
§ 170.314 [Amended] (3) Computerized provider order preliminary cause of death and date of
entry—diagnostic imaging. (i) Enable a death in the event of mortality.
■ 11. In § 170.314: user to record, change, and access (6) Problem list. Enable a user to
■ a. In paragraph (a)(3)(i)(A), remove diagnostic imaging orders. record, change, and access a patient’s
‘‘§ 170.207(f)’’ and add in its place (ii) Optional. Include a ‘‘reason for active problem list:
‘‘§ 170.207(f)(1)’’; order’’ field. (i) Ambulatory setting only. Over
■ b. In paragraph (a)(3)(i)(B), remove (4) Drug-drug, drug-allergy interaction multiple encounters in accordance with,
‘‘§ 170.207(g)’’ and add in its place checks for CPOE—(i) Interventions. at a minimum, the version of the
‘‘§ 170.207(g)(1)’’; Before a medication order is completed standard specified in § 170.207(a)(4).
■ c. In paragraph (a)(8)(iii)(B)(2), remove and acted upon during computerized (ii) Inpatient setting only. For the
‘‘paragraph (b)(1)(iii)’’ and add in its provider order entry (CPOE), duration of an entire hospitalization in
place ‘‘paragraph (b)(1)(iii)(B) or interventions must automatically accordance with, at a minimum, the
(b)(9)(ii)(D)’’; indicate to a user drug-drug and drug- version of the standard specified in
■ d. In paragraphs (b)(2)(i) introductory allergy contraindications based on a § 170.207(a)(4).
text, (b)(7) introductory text, (b)(8)(iii) patient’s medication list and medication (7) Medication list. Enable a user to
introductory text, (e)(1)(i)(A)(1), and allergy list. record, change, and access a patient’s
(e)(2)(iii)(A), remove the term ‘‘Common (ii) Adjustments. (A) Enable the active medication list as well as
MU Data Set’’ and add in its place severity level of interventions provided medication history:
‘‘Common Clinical Data Set’’; for drug-drug interaction checks to be (i) Ambulatory setting only. Over
■ e. In paragraph (c)(1)(ii), remove adjusted. multiple encounters.
‘‘§ 170.205(h)’’ and add in its place (B) Limit the ability to adjust severity (ii) Inpatient setting only. For the
‘‘§ 170.205(h)(1)’’; levels in at least one of these two ways: duration of an entire hospitalization.
(8) Medication allergy list. Enable a (A) For evidence-based decision (A) Device Identifier;
user to record, change, and access a support interventions under paragraph (B) The following identifiers that
patient’s active medication allergy list (a)(9)(iii) of this section: compose the Production Identifier:
as well as medication allergy history: (1) Bibliographic citation of the (1) The lot or batch within which a
(i) Ambulatory setting only. Over intervention (clinical research/ device was manufactured;
multiple encounters. guideline); (2) The serial number of a specific
(ii) Inpatient setting only. For the (2) Developer of the intervention device;
duration of an entire hospitalization. (translation from clinical research/ (3) The expiration date of a specific
(9) Clinical decision support (CDS)— guideline); device;
(i) CDS intervention interaction. (3) Funding source of the intervention (4) The date a specific device was
Interventions provided to a user must development technical implementation; manufactured; and
and (5) For an HCT/P regulated as a
occur when a user is interacting with
(4) Release and, if applicable, revision device, the distinct identification code
technology.
date(s) of the intervention or reference required by 21 CFR 1271.290(c).
(ii) CDS configuration. (A) Enable
source. (iii) Obtain and associate with each
interventions and reference resources (B) For linked referential CDS in Unique Device Identifier:
specified in paragraphs (a)(9)(iii) and paragraph (a)(9)(iv) of this section and (A) A description of the implantable
(iv) of this section to be configured by drug-drug, drug-allergy interaction device referenced by at least one of the
a limited set of identified users (e.g., checks in paragraph (a)(4) of this following:
system administrator) based on a user’s section, the developer of the (1) The ‘‘GMDN PT Name’’ attribute
role. intervention, and where clinically associated with the Device Identifier in
(B) Enable interventions: indicated, the bibliographic citation of the Global Unique Device Identification
(1) Based on the following data: the intervention (clinical research/ Database.
(i) Problem list; guideline). (2) The ‘‘SNOMED CT® Description’’
(ii) Medication list; (10) Drug-formulary and preferred mapped to the attribute referenced in in
(iii) Medication allergy list; drug list checks. The requirements paragraph (a)(14)(iii)(A)(1) of this
(iv) At least one demographic specified in one of the following section.
specified in paragraph (a)(5)(i) of this paragraphs (that is, paragraphs (a)(10)(i) (B) The following Global Unique
section; and (a)(10)(ii) of this section) must be Device Identification Database
(v) Laboratory tests; and met to satisfy this certification criterion: attributes:
(vi) Vital signs. (i) Drug formulary checks. (1) ‘‘Brand Name’’;
(2) When a patient’s medications, Automatically check whether a drug (2) ‘‘Version or Model’’;
medication allergies, and problems are formulary exists for a given patient and (3) ‘‘Company Name’’;
incorporated from a transition of care/ medication. (4) ‘‘What MRI safety information
referral summary received and pursuant (ii) Preferred drug list checks. does the labeling contain?’’; and
to paragraph (b)(2)(iii)(D) of this section. Automatically check whether a (5) ‘‘Device required to be labeled as
(iii) Evidence-based decision support preferred drug list exists for a given containing natural rubber latex or dry
interventions. Enable a limited set of patient and medication. natural rubber (21 CFR 801.437).’’
identified users to select (i.e., activate) (11) Smoking status. Enable a user to (iv) Display to a user an implantable
electronic CDS interventions (in record, change, and access the smoking device list consisting of:
addition to drug-drug and drug-allergy status of a patient. (A) The active Unique Device
contraindication checking) based on (12) Family health history. Enable a Identifiers recorded for a patient; and
user to record, change, and access a (B) For each active Unique Device
each one and at least one combination
patient’s family health history in Identifier recorded for a patient, the
of the data referenced in paragraphs
accordance with the familial concepts or description of the implantable device
(a)(9)(ii)(B)(1)(i) through (vi) of this
expressions included in, at a minimum, specified by paragraph (a)(14)(iii)(A) of
section.
the version of the standard in this section.
(iv) Linked referential CDS. (A)
§ 170.207(a)(4). (C) A method to access all Unique
Identify for a user diagnostic and
(13) Patient-specific education Device Identifiers recorded for a patient.
therapeutic reference information in (v) For each Unique Device Identifier
accordance at least one of the following resources. (i) Identify patient-specific
education resources based on data recorded for a patient, enable a user to
standards and implementation access:
specifications: included in the patient’s problem list
and medication list in accordance with (A) The Unique Device Identifier;
(1) The standard and implementation (B) The description of the implantable
at least one of the following standards
specifications specified in device specified by paragraph
and implementation specifications:
§ 170.204(b)(3). (A) The standard and implementation (a)(14)(iii)(A) of this section;
(2) The standard and implementation specifications specified in (C) The identifiers associated with the
specifications specified in § 170.204(b)(3). Unique Device Identifier, as specified by
§ 170.204(b)(4). (B) The standard and implementation paragraph (a)(14)(ii) of this section;
(B) For paragraph (a)(9)(iv)(A) of this specifications specified in (D) The attributes associated with the
section, technology must be able to § 170.204(b)(4). Unique Device Identifier, as specified by
identify for a user diagnostic or (ii) Optional. Request that patient- paragraph (a)(14)(iii)(B) of this section.
therapeutic reference information based specific education resources be (vi) Enable a user to change the status
on each one and at least one identified in accordance with the of a Unique Device Identifier recorded
combination of the data referenced in standard in § 170.207(g)(2). for a patient.
paragraphs (a)(9)(ii)(B)(1)(i), (ii), and (iv) (14) Implantable device list. (i) Record (15) Social, psychological, and
of this section. Unique Device Identifiers associated behavioral data. Enable a user to record,
(v) Source attributes. Enable a user to with a patient’s Implantable Devices. change, and access the following patient
review the attributes as indicated for all (ii) Parse the following identifiers social, psychological, and behavioral
CDS resources: from a Unique Device Identifier: data:
(i) Financial resource strain. Enable performance. Demonstrate the ability to (D) Functional status.
financial resource strain to be recorded detect valid and invalid transition of (E) Ambulatory setting only. The
in accordance with the standard care/referral summaries received and reason for referral; and referring or
specified in § 170.207(p)(1) and whether formatted in accordance with the transitioning provider’s name and office
a patient declines to specify financial standards specified in § 170.205(a)(3) contact information.
resource strain. and § 170.205(a)(4) for the Continuity of (F) Inpatient setting only. Discharge
(ii) Education. Enable education to be Care Document, Referral Note, and instructions.
recorded in accordance with the (inpatient setting only) Discharge (G) Patient matching data. First name,
standard specified in § 170.207(p)(2) Summary document templates. This last name, previous name, middle name
and whether a patient declines to includes the ability to: (including middle initial), suffix, date of
specify education. (1) Parse each of the document types. birth, address, phone number, and sex.
(iii) Stress. Enable stress to be (2) Detect errors in corresponding The following constraints apply:
recorded in accordance with the ‘‘document-templates,’’ ‘‘section-
standard specified in § 170.207(p)(3) (1) Date of birth constraint—(i) The
templates,’’ and ‘‘entry-templates,’’
and whether a patient declines to year, month and day of birth must be
including invalid vocabulary standards
specify stress. present for a date of birth. The
and codes not specified in the standards
(iv) Depression. Enable depression to technology must include a null value
adopted in § 170.205(a)(3) and
be recorded in accordance with the when the date of birth is unknown.
§ 170.205(a)(4).
standard specified in § 170.207(p)(4) (3) Identify valid document-templates (ii) Optional. When the hour, minute,
and whether a patient declines to and process the data elements required and second are associated with a date of
specify depression. in the corresponding section-templates birth the technology must demonstrate
(v) Physical activity. Enable physical and entry-templates from the standards that the correct time zone offset is
activity to be recorded in accordance adopted in § 170.205(a)(3) and included.
with the standard specified in § 170.205(a)(4). (2) Phone number constraint.
§ 170.207(p)(5) and whether a patient (4) Correctly interpret empty sections Represent phone number (home,
declines to specify physical activity. and null combinations. business, cell) in accordance with the
(vi) Alcohol use. Enable alcohol use to (5) Record errors encountered and standards adopted in § 170.207(q)(1).
be recorded in accordance with the allow a user through at least one of the All phone numbers must be included
standard specified in § 170.207(p)(6) following ways to: when multiple phone numbers are
and whether a patient declines to (i) Be notified of the errors produced. present.
specify alcohol use. (ii) Review the errors produced. (3) Sex constraint. Represent sex in
(vii) Social connection and isolation. (B) Display. Display in human accordance with the standard adopted
Enable social connection and isolation readable format the data included in in § 170.207(n)(1).
to be recorded in accordance the transition of care/referral summaries (2) Clinical information reconciliation
standard specified in § 170.207(p)(7) received and formatted according to the and incorporation—(i) General
and whether a patient declines to standards specified in § 170.205(a)(3) requirements. Paragraphs (b)(2)(ii) and
specify social connection and isolation. and § 170.205(a)(4). (iii) of this section must be completed
(viii) Exposure to violence (intimate (C) Display section views. Allow for based on the receipt of a transition of
partner violence). Enable exposure to the individual display of each section care/referral summary formatted in
violence (intimate partner violence) to (and the accompanying document accordance with the standards adopted
be recorded in accordance with the header information) that is included in in § 170.205(a)(3) and § 170.205(a)(4)
standard specified in § 170.207(p)(8) a transition of care/referral summary using the Continuity of Care Document,
and whether a patient declines to received and formatted in accordance Referral Note, and (inpatient setting
specify exposure to violence (intimate with the standards adopted in only) Discharge Summary document
partner violence). § 170.205(a)(3) and § 170.205(a)(4) in a templates.
(b) Care coordination—(1) Transitions manner that enables the user to: (ii) Correct patient. Upon receipt of a
of care—(i) Send and receive via edge (1) Directly display only the data transition of care/referral summary
protocol—(A) Send transition of care/ within a particular section; formatted according to the standards
referral summaries through a method (2) Set a preference for the display adopted § 170.205(a)(3) and
that conforms to the standard specified order of specific sections; and § 170.205(a)(4), technology must be able
in § 170.202(d) and that leads to such (3) Set the initial quantity of sections
to demonstrate that the transition of
summaries being processed by a service to be displayed.
care/referral summary received can be
that has implemented the standard (iii) Create. Enable a user to create a
properly matched to the correct patient.
specified in § 170.202(a)(2); and transition of care/referral summary
(B) Receive transition of care/referral formatted in accordance with the (iii) Reconciliation. Enable a user to
summaries through a method that standard specified in § 170.205(a)(4) reconcile the data that represent a
conforms to the standard specified in using the Continuity of Care Document, patient’s active medication list,
§ 170.202(d) from a service that has Referral Note, and (inpatient setting medication allergy list, and problem list
implemented the standard specified in only) Discharge Summary document as follows. For each list type:
§ 170.202(a)(2). templates that includes, at a minimum: (A) Simultaneously display (i.e., in a
(C) XDM processing. Receive and (A) The Common Clinical Data Set. single view) the data from at least two
make available the contents of a XDM (B) Encounter diagnoses. Formatted sources in a manner that allows a user
package formatted in accordance with according to at least one of the following to view the data and their attributes,
the standard adopted in § 170.205(p)(1) standards: which must include, at a minimum, the
when the technology is also being (1) The standard specified in source and last modification date.
certified using an SMTP-based edge § 170.207(i). (B) Enable a user to create a single
protocol. (2) At a minimum, the version of the reconciled list of each of the following:
(ii) Validate and display—(A) standard specified in § 170.207(a)(4). Medications; medication allergies; and
Validate C–CDA conformance—system (C) Cognitive status. problems.
(C) Enable a user to review and the standard specified in § 170.205(a)(4) transitioning provider’s name and office
validate the accuracy of a final set of using the Continuity of Care Document, contact information.
data. Referral Note, and (inpatient setting (F) Inpatient setting only. Discharge
(D) Upon a user’s confirmation, only) Discharge Summary document instructions.
automatically update the list, and templates that includes, at a minimum: (ii) Validate and display. Demonstrate
incorporate the following data (i) The Common Clinical Data Set. the following functionalities for the
expressed according to the specified (ii) Encounter diagnoses. Formatted document received in accordance with
standard(s): according to at least one of the following paragraph (b)(5)(i) of this section:
(1) Medications. At a minimum, the standards: (A) Validate C–CDA conformance—
version of the standard specified in (A) The standard specified in system performance. Detect valid and
§ 170.207(d)(3); § 170.207(i). invalid transition of care/referral
(2) Medication allergies. At a (B) At a minimum, the version of the summaries including the ability to:
minimum, the version of the standard standard specified in § 170.207(a)(4). (1) Parse each of the document types
specified in § 170.207(d)(3); and (iii) Cognitive status. formatted according to the following
(3) Problems. At a minimum, the (iv) Functional status. document templates: Continuity of Care
version of the standard specified in (v) Ambulatory setting only. The Document, Referral Note, and (inpatient
§ 170.207(a)(4). reason for referral; and referring or setting only) Discharge Summary.
(iv) System verification. Based on the transitioning provider’s name and office (2) Detect errors in corresponding
data reconciled and incorporated, the contact information. ‘‘document-templates,’’ ‘‘section-
technology must be able to create a file (vi) Inpatient setting only. Discharge templates,’’ and ‘‘entry-templates,’’
formatted according to the standard instructions. including invalid vocabulary standards
specified in § 170.205(a)(4) using the (vii) Patient matching data. First and codes not specified in the standards
Continuity of Care Document document name, last name, previous name, middle adopted in § 170.205(a)(3) and
template. name (including middle initial), suffix, § 170.205(a)(4).
(3) Electronic prescribing. (i) Enable a date of birth, address, phone number, (3) Identify valid document-templates
user to perform all of the following and sex. The following constraints and process the data elements required
prescription-related electronic apply: in the corresponding section-templates
transactions in accordance with the (A) Date of birth constraint—(1) The and entry-templates from the standards
standard specified in § 170.205(b)(2) year, month and day of birth must be adopted in § 170.205(a)(3) and
and, at a minimum, the version of the present for a date of birth. The § 170.205(a)(4).
standard specified in § 170.207(d)(3) as technology must include a null value (4) Correctly interpret empty sections
follows: when the date of birth is unknown. and null combinations.
(A) Create new prescriptions (2) Optional. When the hour, minute, (5) Record errors encountered and
(NEWRX). and second are associated with a date of allow a user through at least one of the
(B) Change prescriptions (RXCHG, birth the technology must demonstrate following ways to:
CHGRES). that the correct time zone offset is (i) Be notified of the errors produced.
(C) Cancel prescriptions (CANRX, included. (ii) Review the errors produced.
CANRES). (B) Phone number constraint. (B) Display. Display in human
(D) Refill prescriptions (REFREQ, Represent phone number (home, readable format the data included in
REFRES). business, cell) in accordance with the transition of care/referral summaries
(E) Receive fill status notifications standards adopted in § 170.207(q)(1). received and formatted according to the
(RXFILL). All phone numbers must be included standards specified in § 170.205(a)(3)
(F) Request and receive medication when multiple phone numbers are and § 170.205(a)(4).
history information (RXHREQ, present. (C) Display section views. Allow for
RXHRES). (C) Sex constraint. Represent sex in the individual display of each section
(ii) For each transaction listed in accordance with the standard adopted (and the accompanying document
paragraph (b)(3)(i) of this section, the in § 170.207(n)(1). header information) that is included in
technology must be able to receive and (5) Common Clinical Data Set a transition of care/referral summary
transmit the reason for the prescription summary record—receive—(i) Enable a received and formatted in accordance
using the diagnosis elements in DRU user to receive a transition of care/ with the standards adopted in
Segment. referral summary formatted in § 170.205(a)(3) and § 170.205(a)(4) in a
(iii) Optional. For each transaction accordance with the standards adopted manner that enables the user to:
listed in paragraph (b)(3)(i) of this in § 170.205(a)(3) and § 170.205(a)(4) (1) Directly display only the data
section, the technology must be able to using the Continuity of Care Document, within a particular section;
receive and transmit the reason for the Referral Note, and (inpatient setting (2) Set a preference for the display
prescription using the indication only) Discharge Summary document order of specific sections; and
elements in the SIG Segment. templates that includes, at a minimum: (3) Set the initial quantity of sections
(iv) Limit a user’s ability to prescribe (A) The Common Clinical Data Set. to be displayed.
all oral liquid medications in only (B) Encounter diagnoses. Formatted (6) Data export—(i) General
metric standard units of mL (i.e., not cc). according to at least one of the following requirements for export summary
(v) Always insert leading zeroes standards: configuration. (A) Enable a user to set
before the decimal point for amounts (1) The standard specified in the configuration options specified in
less than one and must not allow § 170.207(i). paragraph (b)(6)(ii) through (v) of this
trailing zeroes after a decimal point (2) At a minimum, the standard section when creating an export
when a user prescribes medications. specified in § 170.207(a)(4). summary as well as a set of export
(4) Common Clinical Data Set (C) Cognitive status. summaries for patients whose
summary record—create. Enable a user (D) Functional status. information is stored in the technology.
to create a transition of care/referral (E) Ambulatory setting only. The A user must be able to execute these
summary formatted in accordance with reason for referral; and referring or capabilities at any time the user chooses
and without subsequent developer disclosure according to the standard with the identified standards, where
assistance to operate. adopted in § 170.205(o)(1); specified.
(B) Limit the ability of users who can (ii) Sequester the document-level (ii) Filter CQM results at the patient
create export summaries in at least one tagged document from other documents and aggregate levels by each one and
of these two ways: received; and any combination of the data listed in
(1) To a specific set of identified (iii) View the restricted document paragraph (c)(4)(iii) of this section and
users. without incorporating any of the data be able to:
(2) As a system administrative from the document. (A) Create a data file of the filtered
function. (9) Care plan. Enable a user to record, data in accordance with the standards
(ii) Creation configuration. Enable a change, access, create, and receive care adopted in § 170.205(h)(2) and
user to configure the technology to plan information in accordance with the § 170.205(k)(1) and (2); and
create export summaries formatted in Care Plan document template, including (B) Display the filtered data results in
accordance with the standard specified the Health Status Evaluations and human readable format.
in § 170.205(a)(4) using the Continuity Outcomes Section and Interventions (iii) Data.
of Care Document document template Section (V2), in the standard specified (A) Taxpayer Identification Number.
that includes, at a minimum: in § 170.205(a)(4). (B) National Provider Identifier.
(A) The Common Clinical Data Set. (c) Clinical quality measures—(1) (C) Provider type in accordance with,
(B) Encounter diagnoses. Formatted Clinical quality measures—record and at a minimum, the standard specified in
according to at least one of the following export—(i) Record. For each and every § 170.207(r)(1).
standards: CQM for which the technology is (D) Practice site address.
(1) The standard specified in presented for certification, the (E) Patient insurance in accordance
§ 170.207(i). technology must be able to record all of with, at a minimum, the standard
(2) At a minimum, the version of the the data that would be necessary to specified in § 170.207(s)(1).
standard specified in § 170.207(a)(4). calculate each CQM. Data required for (F) Patient age.
(C) Cognitive status. CQM exclusions or exceptions must be (G) Patient sex in accordance with, at
(D) Functional status. codified entries, which may include a minimum, the version of the standard
(E) Ambulatory setting only. The specific terms as defined by each CQM, specified in § 170.207(n)(1).
reason for referral; and referring or or may include codified expressions of (H) Patient race and ethnicity in
transitioning provider’s name and office ‘‘patient reason,’’ ‘‘system reason,’’ or accordance with, at a minimum, the
contact information. ‘‘medical reason.’’ version of the standard specified in
(F) Inpatient setting only. Discharge (ii) Export. A user must be able to § 170.207(f)(2).
instructions. export a data file at any time the user (I) Patient problem list data in
(iii) Timeframe configuration. (A) chooses and without subsequent accordance with, at a minimum, the
Enable a user to set the date and time developer assistance to operate: version of the standard specified in
period within which data would be (A) Formatted in accordance with the § 170.207(a)(4).
used to create the export summaries. standard specified in § 170.205(h)(2); (d) Privacy and security—(1)
This must include the ability to enter in (B) Ranging from one to multiple Authentication, access control, and
a start and end date and time range. patients; and authorization. (i) Verify against a unique
(B) Consistent with the date and time (C) That includes all of the data identifier(s) (e.g., username or number)
period specified in paragraph captured for each and every CQM to that a user seeking access to electronic
(b)(6)(iii)(A) of this section, enable a which technology was certified under health information is the one claimed;
user to do each of the following: paragraph (c)(1)(i) of this section. and
(1) Create export summaries in real- (2) Clinical quality measures—import (ii) Establish the type of access to
time; and calculate—(i) Import. Enable a user electronic health information a user is
(2) Create export summaries based on to import a data file in accordance with permitted based on the unique
a relative date and time (e.g., the first of the standard specified in § 170.205(h)(2) identifier(s) provided in paragraph
every month at 1:00 a.m.); and for one or multiple patients and use (d)(1)(i) of this section, and the actions
(3) Create export summaries based on such data to perform the capability the user is permitted to perform with
a specific date and time (e.g., on 10/24/ specified in paragraph (c)(2)(ii) of this the technology.
2015 at 1:00 a.m.). section. A user must be able to execute (2) Auditable events and tamper-
(iv) Location configuration. Enable a this capability at any time the user resistance—(i) Record actions.
user to set the storage location to which chooses and without subsequent Technology must be able to:
the export summary or export developer assistance to operate. (A) Record actions related to
summaries are intended to be saved. (ii) Calculate each and every clinical electronic health information in
(7) Data segmentation for privacy— quality measure for which it is accordance with the standard specified
send. Enable a user to create a summary presented for certification. in § 170.210(e)(1);
record formatted in accordance with the (3) Clinical quality measures—report. (B) Record the audit log status
standard adopted in § 170.205(a)(4) that Enable a user to electronically create a (enabled or disabled) in accordance
is document-level tagged as restricted data file for transmission of clinical with the standard specified in
and subject to restrictions on re- quality measurement data: § 170.210(e)(2) unless it cannot be
disclosure according to the standard (i) At a minimum, in accordance with disabled by any user; and
adopted in § 170.205(o)(1). the standards specified in (C) Record the encryption status
(8) Data segmentation for privacy— § 170.205(h)(2) and § 170.205(k)(1) and (enabled or disabled) of electronic
receive. Enable a user to: (2). health information locally stored on
(i) Receive a summary record that is (ii) Optional. That can be end-user devices by technology in
formatted in accordance with the electronically accepted by CMS. accordance with the standard specified
standard adopted in § 170.205(a)(4) that (4) Clinical quality measures—filter. in § 170.210(e)(3) unless the technology
is document-level tagged as restricted (i) Record the data listed in paragraph prevents electronic health information
and subject to restrictions on re- (c)(4)(iii) of this section in accordance from being locally stored on end-user
devices (see paragraph (d)(7) of this use of the technology on those devices accordance with the standard specified
section). stops. in § 170.204(a)(2).
(ii) Default setting. Technology must (A) Electronic health information that (A) View. Patients (and their
be set by default to perform the is stored must be encrypted in authorized representatives) must be able
capabilities specified in paragraph accordance with the standard specified to use health IT to view, at a minimum,
(d)(2)(i)(A) of this section and, where in § 170.210(a)(2). the following data:
applicable, paragraphs (d)(2)(i)(B) and (B) Default setting. Technology must (1) The Common Clinical Data Set
(d)(2)(i)(C) of this section. be set by default to perform this (which should be in their English (i.e.,
(iii) When disabling the audit log is capability and, unless this configuration non-coded) representation if they
permitted. For each capability specified cannot be disabled by any user, the associate with a vocabulary/code set).
in paragraphs (d)(2)(i)(A) through (C) of ability to change the configuration must (2) Ambulatory setting only.
this section that technology permits to be restricted to a limited set of Provider’s name and office contact
be disabled, the ability to do so must be identified users. information.
restricted to a limited set of users. (ii) Technology is designed to prevent (3) Inpatient setting only. Admission
(iv) Audit log protection. Actions and electronic health information from being and discharge dates and locations;
statuses recorded in accordance with locally stored on end-user devices after discharge instructions; and reason(s) for
paragraph (d)(2)(i) of this section must use of the technology on those devices hospitalization.
not be capable of being changed, stops. (4) Laboratory test report(s).
overwritten, or deleted by the (8) Integrity. (i) Create a message Laboratory test report(s), including:
technology. digest in accordance with the standard (i) The information for a test report as
(v) Detection. Technology must be specified in § 170.210(c)(2). specified all the data specified in 42
able to detect whether the audit log has (ii) Verify in accordance with the CFR 493.1291(c)(1) through (7);
been altered. standard specified in § 170.210(c)(2) (ii) The information related to
(3) Audit report(s). Enable a user to upon receipt of electronically reference intervals or normal values as
create an audit report for a specific time exchanged health information that such specified in 42 CFR 493.1291(d); and
(iii) The information for corrected
period and to sort entries in the audit information has not been altered.
reports as specified in 42 CFR
log according to each of the data (9) Trusted connection. Establish a
493.1291(k)(2).
specified in the standards in trusted connection using one of the (5) Diagnostic image report(s).
§ 170.210(e). following methods: (B) Download. (1) Patients (and their
(4) Amendments. Enable a user to (i) Message-level. Encrypt and authorized representatives) must be able
select the record affected by a patient’s integrity protect message contents in to use technology to download an
request for amendment and perform the accordance with the standards specified ambulatory summary or inpatient
capabilities specified in paragraph in § 170.210(a)(2) and (c)(2). summary (as applicable to the health IT
(d)(4)(i) or (ii) of this section. (ii) Transport-level. Use a trusted setting for which certification is
(i) Accepted amendment. For an connection in accordance with the requested) in the following formats:
accepted amendment, append the standards specified in § 170.210(a)(2) (i) Human readable format; and
amendment to the affected record or and (c)(2). (ii) The format specified in
include a link that indicates the (10) Auditing actions on health accordance to the standard specified in
amendment’s location. information. (i) By default, be set to § 170.205(a)(4) following the CCD
(ii) Denied amendment. For a denied record actions related to electronic document template.
amendment, at a minimum, append the health information in accordance with (2) When downloaded according to
request and denial of the request in at the standard specified in § 170.210(e)(1). the standard specified in § 170.205(a)(4)
least one of the following ways: (ii) If technology permits auditing to following the CCD document template,
(A) To the affected record. be disabled, the ability to do so must be the ambulatory summary or inpatient
(B) Include a link that indicates this restricted to a limited set of users. summary must include, at a minimum,
information’s location. (iii) Actions recorded related to the following data (which, for the
(5) Automatic access time-out. (i) electronic health information must not human readable version, should be in
Automatically stop user access to health be capable of being changed, their English representation if they
information after a predetermined overwritten, or deleted by the associate with a vocabulary/code set):
period of inactivity. technology. (i) Ambulatory setting only. All of the
(ii) Require user authentication in (iv) Technology must be able to detect data specified in paragraph
order to resume or regain the access that whether the audit log has been altered. (e)(1)(i)(A)(1), (2), (4), and (5) of this
was stopped. (11) Accounting of disclosures. section.
(6) Emergency access. Permit an Record disclosures made for treatment, (ii) Inpatient setting only. All of the
identified set of users to access payment, and health care operations in data specified in paragraphs
electronic health information during an accordance with the standard specified (e)(1)(i)(A)(1), and (3) through (5) of this
emergency. in § 170.210(d). section.
(7) End-user device encryption. The (e) Patient engagement—(1) View, (3) Inpatient setting only. Patients
requirements specified in one of the download, and transmit to 3rd party. (i) (and their authorized representatives)
following paragraphs (that is, Patients (and their authorized must be able to download transition of
paragraphs (d)(7)(i) and (d)(7)(ii) of this representatives) must be able to use care/referral summaries that were
section) must be met to satisfy this internet-based technology to view, created as a result of a transition of care
certification criterion. download, and transmit their health (pursuant to the capability expressed in
(i) Technology that is designed to information to a 3rd party in the manner the certification criterion specified in
locally store electronic health specified below. Such access must be paragraph (b)(1) of this section).
information on end-user devices must consistent and in accordance with the (C) Transmit to third party. Patients
encrypt the electronic health standard adopted in § 170.204(a)(1) and (and their authorized representatives)
information stored on such devices after may alternatively be demonstrated in must be able to:
(1) Transmit the ambulatory summary (A) The standard and applicable (4) An identifier representing the row
or inpatient summary (as applicable to implementation specifications specified and version of the trigger table that
the health IT setting for which in § 170.205(e)(4). triggered the case report.
certification is requested) created in (B) At a minimum, the version of the (6) Transmission to public health
paragraph (e)(1)(i)(B)(2) of this section standard specified in § 170.207(e)(3) for agencies—antimicrobial use and
in accordance with both of the following historical vaccines. resistance reporting. Create
ways: (C) At a minimum, the version of the antimicrobial use and resistance
(i) Email transmission to any email standard specified in § 170.207(e)(4) for reporting information for electronic
address; and administered vaccines. transmission in accordance with the
(ii) An encrypted method of electronic (ii) Enable a user to request, access, standard specified in § 170.205(r)(1).
transmission. and display a patient’s evaluated (7) Transmission to public health
(2) Inpatient setting only. Transmit immunization history and the agencies—health care surveys. Create
transition of care/referral summaries (as immunization forecast from an health care survey information for
a result of a transition of care/referral as immunization registry in accordance electronic transmission in accordance
referenced by (e)(1)(i)(B)(3)) of this with the standard at § 170.205(e)(4). with the standard specified in
section selected by the patient (or their (2) Transmission to public health § 170.205(s)(1).
authorized representative) in both of the agencies—syndromic surveillance. (g) Design and performance—(1)
ways referenced (e)(1)(i)(C)(1)(i) and (ii) Create syndrome-based public health Automated numerator recording. For
of this section). surveillance information for electronic each EHR Incentive Programs
(D) Timeframe selection. With respect transmission in accordance with the percentage-based measure, technology
to the data available to view, download, standard (and applicable must be able to create a report or file
and transmit as referenced paragraphs implementation specifications) that enables a user to review the
(e)(1)(i)(A), (B), and (C) of this section, specified in § 170.205(d)(4). patients or actions that would make the
patients (and their authorized (3) Transmission to public health patient or action eligible to be included
representatives) must be able to: agencies—reportable laboratory tests in the measure’s numerator. The
(1) Select data associated with a and values/results. Create reportable information in the report or file created
specific date (to be viewed, laboratory tests and values/results for must be of sufficient detail such that it
downloaded, or transmitted); and electronic transmission in accordance enables a user to match those patients
(2) Select data within an identified
with: or actions to meet the measure’s
date range (to be viewed, downloaded,
(i) The standard (and applicable denominator limitations when
or transmitted).
(ii) Activity history log. (A) When any implementation specifications) necessary to generate an accurate
of the capabilities included in specified in § 170.205(g). percentage.
(ii) At a minimum, the versions of the (2) Automated measure calculation.
paragraphs (e)(1)(i)(A) through (C) of
standards specified in § 170.207(a)(3) For each EHR Incentive Programs
this section are used, the following
and (c)(2). percentage-based measure that is
information must be recorded and made
(4) Transmission to cancer registries. supported by a capability included in a
accessible to the patient:
(1) The action(s) (i.e., view, Create cancer case information for technology, record the numerator and
download, transmission) that occurred; electronic transmission in accordance denominator and create a report
(2) The date and time each action with: including the numerator, denominator,
occurred in accordance with the (i) The standard (and applicable and resulting percentage associated with
standard specified in § 170.210(g); implementation specifications) each applicable measure.
(3) The user who took the action; and specified in § 170.205(i)(2). (3) Safety-enhanced design. (i) User-
(4) Where applicable, the addressee to (ii) At a minimum, the versions of the centered design processes must be
whom an ambulatory summary or standards specified in § 170.207(a)(4) applied to each capability technology
inpatient summary was transmitted. and (c)(3). includes that is specified in the
(B) Technology presented for (5) Transmission to public health following certification criteria:
certification may demonstrate agencies—electronic case reporting. (i) Paragraphs (a)(1) through (9) and (14),
compliance with paragraph (e)(1)(ii)(A) Consume and maintain a table of trigger (b)(2) and (3) of this section.
of this section if it is also certified to the codes to determine which encounters (ii) Number of test participants. A
certification criterion specified in may be reportable. minimum of 10 test participants must be
§ 170.315(d)(2) and the information (ii) Match a patient visit or encounter used for the testing of each capability
required to be recorded in paragraph to the trigger code based on the identified in paragraph (g)(3)(i) of this
(e)(1)(ii)(A) of this section is accessible parameters of the trigger code table. section.
by the patient. (iii) Case report creation. Create a case (iii) One of the following must be
(2) Secure messaging. Enable a user to report for electronic transmission: submitted on the user-centered design
send messages to, and receive messages (A) Based on a matched trigger from processed used:
from, a patient in a secure manner. paragraph (f)(5)(ii). (A) Name, description and citation
(3) Patient health information (B) That includes, at a minimum: (URL and/or publication citation) for an
capture. Enable a user to: (1) The Common Clinical Data Set. industry or federal government
(i) Identify, record, and access (2) Encounter diagnoses. Formatted standard.
information directly and electronically according to at least one of the following (B) Name the process(es), provide an
shared by a patient (or authorized standards: outline of the process(es), a short
representative). (i) The standard specified in description of the process(es), and an

(ii) Reference and link to patient § 170.207(i). explanation of the reason(s) why use of
health information documents. (ii) At a minimum, the version of the any of the existing user-centered design
(f) Public health—(1) Transmission to standard specified in § 170.207(a)(4). standards was impractical.
immunization registries. (i) Create (3) The provider’s name, office (iv) The following information/
immunization information for electronic contact information, and reason for sections from NISTIR 7742 must be
transmission in accordance with: visit. submitted for each capability to which
user-centered design processes were used for applicable capabilities, it an ID or other token that can be used by
applied: would only need to be identified once. an application to subsequently execute
(A) Name and product version; date (ii) When different accessibility- requests for that patient’s data.
and location of the test; test centered design standards and laws (ii) Documentation—(A) The API
environment; description of the were applied to specific capabilities, must include accompanying
intended users; and total number of each accessibility-centered design documentation that contains, at a
participants; standard or law applied would need to minimum:
(B) Description of participants, be identified. This would include the (1) API syntax, function names,
including: Sex; age; education; application of an accessibility-centered required and optional parameters and
occupation/role; professional design standard or law to some their data types, return variables and
experience; computer experience; and capabilities and none to others. their types/structures, exceptions and
product experience; (iii) When no accessibility-centered exception handling methods and their
(C) Description of the user tasks that design standard or law was applied to returns.
were tested and association of each task all applicable capabilities such a (2) The software components and
to corresponding certification criteria; response is acceptable to satisfy this configurations that would be necessary
(D) The specific metrics captured certification criterion. for an application to implement in order
during the testing of each user task (6) Consolidated CDA creation to be able to successfully interact with
performed in (g)(3)(iv)(C) of this section, performance. The following technical the API and process its response(s).
which must include: Task success (%); and performance outcomes must be (3) Terms of use. The terms of use for
task failures (%); task standard demonstrated related to Consolidated the API must be provided, including, at
deviations (%); task performance time; CDA creation. The capabilities required a minimum, any associated developer
and user satisfaction rating (based on a under paragraphs (g)(6)(i) through (iv) of policies and required developer
scale with 1 as very difficult and 5 as this section can be demonstrated in agreements.
very easy) or an alternative acceptable tandem and do not need to be (B) The documentation used to meet
user satisfaction measure; individually addressed in isolation or paragraph (g)(7)(ii)(A) of this section
(E) Test results for each task using the sequentially. This certification must be available via a publicly
metrics identified above in paragraph criterion’s scope includes only data accessible hyperlink.
expressed within the Common Clinical (8) Application access—data category
(g)(3)(iv)(D) of this section; and
Data Set definition. request. The following technical
(F) Results and data analysis
(i) Reference C–CDA match. Create a outcome and conditions must be met
narrative, including: Major test finding;
data file formatted in accordance with through the demonstration of an
effectiveness; efficiency; satisfaction;
the standard adopted in § 170.205(a)(4) application programming interface.
and areas for improvement. (i) Functional requirements. (A)
that matches a gold-standard, reference
(v) Submit test scenarios used in Respond to requests for patient data
data file.
summative usability testing. (ii) Document-template conformance. (based on an ID or other token) for each
(4) Quality management system. (i) Create a data file formatted in of the individual data categories
For each capability that a technology accordance with the standard adopted specified in the Common Clinical Data
includes and for which that capability’s in § 170.205(a)(4) that demonstrates a Set and return the full set of data for that
certification is sought, the use of a valid implementation of each document data category (according to the specified
Quality Management System (QMS) in template applicable to the certification standards, where applicable) in a
the development, testing, criterion or criteria within the scope of computable format.
implementation, and maintenance of the certificate sought. The scope of this (B) Respond to requests for patient
that capability must be identified that certification criterion will not exceed data associated with a specific date as
satisfies one of the following ways: the evaluation of the CCD, Referral Note, well as requests for patient data within
(A) The QMS used is established by and Discharge Summary document a specified date range.
the Federal government or a standards templates. (ii) Documentation—(A) The API
developing organization. (iii) Vocabulary conformance. Create must include accompanying
(B) The QMS used is mapped to one a data file formatted in accordance with documentation that contains, at a
or more QMS established by the Federal the standard adopted in § 170.205(a)(4) minimum:
government or standards developing that demonstrates the required (1) API syntax, function names,
organization(s). vocabulary standards (and value sets) required and optional parameters and
(ii) When a single QMS was used for are properly implemented. their data types, return variables and
applicable capabilities, it would only (iv) Completeness verification. Create their types/structures, exceptions and
need to be identified once. a data file for each of the applicable exception handling methods and their
(iii) When different QMS were document templates referenced in returns.
applied to specific capabilities, each paragraph (g)(6)(ii) of this section (2) The software components and
QMS applied would need to be without the omission of any of the data configurations that would be necessary
identified. included in the Common Clinical Data for an application to implement in order
(5) Accessibility-centered design. For Set definition. to be able to successfully interact with
each capability that a Health IT Module (7) Application access—patient the API and process its response(s).
includes and for which that capability’s selection. The following technical (3) Terms of use. The terms of use for
certification is sought, the use of a outcome and conditions must be met the API must be provided, including, at
health IT accessibility-centered design through the demonstration of an a minimum, any associated developer
standard or law in the development, application programming interface policies and required developer
testing, implementation and (API). agreements.
maintenance of that capability must be (i) Functional requirement. The (B) The documentation used to meet
identified. technology must be able to receive a paragraph (g)(8)(ii)(A) of this section
(i) When a single accessibility- request with sufficient information to must be available via a publicly
centered design standard or law was uniquely identify a patient and return accessible hyperlink.
(9) Application access—all data (C) Both edge protocol methods email, phone number, and contact
request. The following technical specified by the standard in name;
outcome and conditions must be met § 170.202(d). (ii) The ONC–ACB Web site, physical
through the demonstration of an (ii) Applicability Statement for Secure address, email, phone number, and
application programming interface. Health Transport and Delivery contact name, contact function/title;
(i) Functional requirements. (A) Notification in Direct. Able to send and (iii) The ATL Web site, physical
Respond to requests for patient data receive health information in address, email, phone number, and
(based on an ID or other token) for all accordance with the standard specified contact name, contact function/title;
of the data categories specified in the in § 170.202(e)(1). (iv) Location and means by which the
Common Clinical Data Set at one time testing was conducted (e.g., remotely
§ § 170.500, 170.501, 170.502, 170.503,
and return such data (according to the with health IT developer at its
170.504, 170.505, 170.510, 170.520, 170.523,
specified standards, where applicable) 170.525, 170.530, 170.535, 170.540, 170.545, headquarters location);
in a summary record formatted 170.550, 170.553, 170.555, 170.557, 170.560, (v) The date(s) the Health IT Module
according to the standard specified in 170.565, 170.570, 170.575, and 170.599 was tested;
§ 170.205(a)(4) following the CCD [Amended] (vi) The date the Health IT Module
document template. ■ 13. In subpart E, consisting of was certified;
(B) Respond to requests for patient §§ 170.500 through 170.599: (vii) The unique certification number
data associated with a specific date as ■ a. Remove the term ‘‘ONC HIT
or other specific product identification;
well as requests for patient data within Certification Program’’ and add in its (viii) The certification criterion or
a specified date range. place ‘‘ONC Health IT Certification criteria to which the Health IT Module
(ii) Documentation—(A) The API Program’’ wherever it may appear; has been certified, including the test
must include accompanying ■ b. Remove the acronym ‘‘HIT’’ and procedure and test data versions used,
documentation that contains, at a add in its place ‘‘health IT’’ wherever it test tool version used, and whether any
minimum: may appear; test data was altered (i.e., a yes/no) and
(1) API syntax, function names, ■ c. Remove the term ‘‘EHR Module’’ for what purpose;
required and optional parameters and and add in its place ‘‘Health IT Module’’ (ix) The way in which each privacy
their data types, return variables and wherever it may appear; and security criterion was addressed for
their types/structures, exceptions and ■ d. Remove the term ‘‘EHR Modules’’ the purposes of certification;
exception handling methods and their and add in its place ‘‘Health IT (x) The standard or mapping used to
returns. Modules’’ wherever it may appear; and meet the quality management system
(2) The software components and ■ e. Remove the term ‘‘EHR Module(s)’’ certification criterion;
configurations that would be necessary and add in its place ‘‘Health IT (xi) The standard(s) or lack thereof
for an application to implement in order Module(s)’’ wherever it may appear. used to meet the accessibility-centered
to be able to successfully interact with ■ 14. In § 170.503, revise paragraph
design certification criterion;
the API and process its response(s). (e)(4) to read as follows: (xii) Where applicable, the hyperlink
(3) Terms of use. The terms of use for to access an application programming
the API must be provided, including, at § 170.503 Requests for ONC–AA status interface (API)’s documentation and
a minimum, any associated developer and ONC–AA ongoing responsibilities. terms of use;
policies and required developer * * * * * (xiii) Where applicable, which
agreements. (e) * * * certification criteria were gap certified;
(B) The documentation used to meet (4) Verify that ONC–ACBs are (xiv) Where applicable, if a
paragraph (g)(9)(ii)(A) of this section performing surveillance as required by certification issued was a result of an
must be available via a publicly and in accordance with § 170.556, inherited certified status request;
accessible hyperlink. § 170.523(k), and their respective annual (xv) Where applicable, the clinical
(h) Transport methods and other plans; and quality measures to which the Health IT
protocols—(1) Direct Project—(i) * * * * * Module has been certified;
Applicability Statement for Secure ■ 15. Amend § 170.523 by—
(xvi) Where applicable, any additional
Health Transport. Able to send and ■ a. Revising paragraphs (f), (g), (i), and
software a Health IT Module relied
receive health information in (k); and upon to demonstrate its compliance
accordance with the standard specified ■ b. Adding paragraphs (m) and (n).
with a certification criterion or criteria
in § 170.202(a)(2), including formatted The additions and revisions read as adopted by the Secretary;
only as a ‘‘wrapped’’ message. follows: (xvii) Where applicable, the
(ii) Applicability Statement for Secure standard(s) used to meet a certification
Health Transport and Delivery § 170.523 Principles of proper conduct for criterion where more than one is
Notification in Direct. Able to send and ONC–ACBs. permitted;
receive health information in * * * * * (xviii) Where applicable, any optional
accordance with the standard specified (f) Provide ONC, no less frequently capabilities within a certification
in § 170.202(e)(1). than weekly, a current list of Health IT criterion to which the Health IT Module
(2) Direct Project, Edge Protocol, and Modules, Complete EHRs, and/or EHR was tested and certified;
XDR/XDM—(i) Able to send and receive Modules that have been certified that (xix) Where applicable, and for each
health information in accordance with: includes, at a minimum: applicable certification criterion, all of
(A) The standard specified in (1) For the 2015 Edition health IT the information required to be
§ 170.202(a)(2), including formatted certification criteria and subsequent submitted by Health IT Module
only as a ‘‘wrapped’’ message; editions of health IT certification developers to meet the safety-enhanced
(B) The standard specified in criteria: design certification criterion. Each user-
§ 170.202(b), including support for both (i) The Health IT Module developer centered design element required to be
limited and full XDS metadata profiles; name; product name; product version; reported must be at a granular level
and developer Web site, physical address, (e.g., task success/failure));
(xx) A hyperlink to the disclosures (ix) A hyperlink to the disclosures (2) Report, at a minimum, on a
required by § 170.523(k)(1) for the required by § 170.523(k)(1) for the quarterly basis to the National
Health IT Module; Complete EHRs and/or EHR Modules; Coordinator the results of its
(xxi) The attestation required by and surveillance.
§ 170.523(k)(2); (x) The attestation required by * * * * *
(xxii) When applicable, for each § 170.523(k)(2); and (k) Ensure adherence to the following
instance in which a Health IT Module (xi) When applicable, for each requirements when issuing any
failed to conform to its certification and instance in which a Complete EHR or certification and during surveillance of
for which corrective action was EHR Module failed to conform to its Complete EHRs and Health IT Modules
instituted under § 170.556 (provided no certification and for which corrective the ONC–ACB has certified.
provider or practice site is identified): action was instituted under § 170.556 (1) Mandatory disclosures. A Health
(A) The specific certification (provided no provider or practice site is IT developer must conspicuously
requirements to which the technology identified): include the following on its Web site
failed to conform, as determined by the (A) The specific certification and in all marketing materials,
ONC–ACB; requirements to which the technology communications statements, and other
(B) A summary of the deficiency or failed to conform, as determined by the assertions related to the Complete EHR
deficiencies identified by the ONC–ACB ONC–ACB; or Health IT Module’s certification:
as the basis for its determination of non- (B) A summary of the deficiency or (i) The disclaimer ‘‘This [Complete
conformity; deficiencies identified by the ONC–ACB EHR or Health IT Module] is [specify
(C) When available, the health IT as the basis for its determination of non- Edition of EHR certification criteria]
developer’s explanation of the conformity; compliant and has been certified by an
deficiency or deficiencies; (C) When available, the health IT ONC–ACB in accordance with the
(D) The dates surveillance was developer’s explanation of the applicable certification criteria adopted
initiated and completed; deficiency or deficiencies; by the Secretary of Health and Human
(E) The results of randomized (D) The dates surveillance was Services. This certification does not
surveillance, including pass rate for initiated and completed; represent an endorsement by the U.S.
each criterion in instances where the (E) The results of randomized Department of Health and Human
Health IT Module is evaluated at more surveillance, including pass rate for Services.’’
than one location; each criterion in instances where the (ii) The following information an
(F) The number of sites that were used Complete EHR or EHR Module is ONC–ACB is required to report to the
in randomized surveillance; evaluated at more than one location;
(G) The date of the ONC–ACB’s National Coordinator:
(F) The number of sites that were used (A) For a Health IT Module certified
determination of non-conformity; in randomized surveillance;
(H) The date on which the ONC–ACB to 2015 Edition health IT certification
(G) The date of the ONC–ACB’s criteria, the information specified by
approved a corrective action plan; determination of non-conformity;
(I) The date corrective action began paragraphs (f)(1)(i), (vi), (vii), (viii),
(H) The date on which the ONC–ACB (xvi), and (xvii) of this section as
(effective date of approved corrective approved a corrective action plan;
action plan); applicable for the specific Health IT
(I) The date corrective action began Module.
(J) The date by which corrective
(effective date of approved corrective (B) For a Complete EHR or EHR
action must be completed (as specified
action plan); Module certified to 2014 Edition health
by the approved corrective action plan);
(J) The date by which corrective IT certification criteria, the information
(K) The date corrective action was
action must be completed (as specified specified by paragraphs (f)(2)(i), (ii),
completed; and
by the approved corrective action plan); (iv)–(v), and (vii) of this section as
(L) A description of the resolution of
(K) The date corrective action was applicable for the specific Complete
the non-conformity or non-conformities.
(2) For the 2014 Edition EHR completed; and EHR or EHR Module.
certification criteria: (L) A description of the resolution of (iii) In plain language, a detailed
(i) The Complete EHR or EHR Module the non-conformity or non-conformities. description of all known material
developer name (if applicable); (g) Records retention. (1) Retain all information concerning:
(ii) The date certified; records related to the certification of (A) Additional types of costs that a
(iii) The product version; Complete EHRs and Health IT Modules user may be required to pay to
(iv) The unique certification number to an edition of certification criteria for implement or use the Complete EHR or
or other specific product identification; a minimum of 3 years from the effective Health IT Module’s capabilities,
(v) The clinical quality measures to date that removes the applicable edition whether to meet meaningful use
which a Complete EHR or EHR Module from the Code of Federal Regulations; objectives and measures or to achieve
has been certified; and any other use within the scope of the
(vi) Where applicable, any additional (2) Make the records available to HHS health IT’s certification.
software a Complete EHR or EHR upon request during the retention (B) Limitations that a user may
Module relied upon to demonstrate its period described in paragraph (g)(1) of encounter in the course of
compliance with a certification criterion this section; implementing and using the Complete
or criteria adopted by the Secretary; * * * * * EHR or Health IT Module’s capabilities,
(vii) Where applicable, the (i) Surveillance plan. Submit an whether to meet meaningful use
certification criterion or criteria to annual surveillance plan to the National objectives and measures or to achieve
which each EHR Module has been Coordinator and, in accordance with its any other use within the scope of the
certified; and surveillance plan, its accreditation, and health IT’s certification.
(viii) A hyperlink to the test results § 170.556: (iv) The types of information required
used to certify the Complete EHRs and/ (1) Conduct surveillance of certified to be disclosed under paragraph (k)(iii)
or EHR Modules that can be accessed by Complete EHRs and Health IT Modules; of this section include but are not
the public. and limited to:
(A) Additional types of costs or fees (ii) An attestation by the developer its scope. If the scope of certification
(whether fixed, recurring, transaction- that it has been asked to make the sought includes multiple certification
based, or otherwise) imposed by a voluntary transparency attestation criteria that require C–CDA creation,
health IT developer (or any third-party described by paragraph (k)(2)(i) of this § 170.315(g)(6) need only be tested in
from whom the developer purchases, section and has elected not to make association with one of those
licenses, or obtains any technology, such attestation. certification criteria and would not be
products, or services in connection with (3) A certification issued to a pre- expected or required to be tested for
its certified health IT) to purchase, coordinated, integrated bundle of Health each. If the scope of certification sought
license, implement, maintain, upgrade, IT Modules shall be treated the same as includes multiple certification criteria
use, or otherwise enable and support the a certification issued to a Complete EHR that require C–CDA creation,
use of capabilities to which health IT is for the purposes of paragraph (k)(1) of § 170.315(g)(6) need only be tested in
certified; or in connection with any data this section, except that the certification association with one of those
generated in the course of using any must also indicate each Health IT certification criteria and would not be
capability to which health IT is Module that is included in the bundle; expected or required to be tested for
certified. and each so long as all applicable C–CDA
(B) Limitations, whether by contract (4) A certification issued to a document templates have been
or otherwise, on the use of any Complete EHR or Health IT Module evaluated as part of § 170.315(g)(6) for
capability to which technology is based solely on the applicable the scope of the certification sought.
certified for any purpose within the certification criteria adopted by the (h) Privacy and security certification
scope of the technology’s certification; Secretary at subpart C of this part must framework—(1) General rule. When
or in connection with any data be separate and distinct from any other certifying a Health IT Module to the
generated in the course of using any certification(s) based on other criteria or 2015 Edition health IT certification
capability to which health IT is requirements. criteria, an ONC–ACB can only issue a
certified. * * * * * certification to a Health IT Module if the
(C) Limitations, including but not (m) Adaptations and updates. On a privacy and security certification
limited to technical or practical quarterly basis each calendar year, criteria in paragraphs (h)(3)(i) through
limitations of technology or its obtain a record of: (viii) of this section have also been met
capabilities, that could prevent or (1) All adaptations of certified (and are included within the scope of
impair the successful implementation, Complete EHRs and certified Health IT the certification).
configuration, customization, Modules; and (2) In order to be issued a
maintenance, support, or use of any (2) All updates made to certified certification, a Health IT Module would
capabilities to which technology is Complete EHRs and certified Health IT only need to be tested once to each
certified; or that could prevent or limit Modules affecting the capabilities in applicable privacy and security criterion
the use, exchange, or portability of any certification criteria to which the in paragraphs (h)(3)(i) through (viii) of
data generated in the course of using ‘‘safety-enhanced design’’ criteria apply. this section so long as the health IT
any capability to which technology is (n) Complaints reporting. Submit a developer attests that such privacy and
certified. list of complaints received to the security capabilities apply to the full
(v) Health IT self-developers are National Coordinator on a quarterly scope of capabilities included in the
excluded from the requirements of basis each calendar year that includes requested certification, except for the
paragraph (k)(1)(iii) of this section. the number of complaints received, the following:
(2) Transparency attestation. As a nature/substance of each complaint, and (i) A Health IT Module presented for
condition of a Complete EHR or Health the type of complainant for each certification to § 170.315(e)(1) must be
IT Module’s certification to any complaint. separately tested to § 170.315(d)(9); and
certification criterion, a health IT (ii) A Health IT Module presented for
■ 16. Amend § 170.550 by— certification to § 170.315(e)(2) must be
developer must make one of the ■ a. Redesignating paragraph (g) as
following attestations: separately tested to § 170.315(d)(9).
paragraph (k); (3) Applicability. (i) Section
(i) An attestation that it will ■ b. Adding paragraphs (g), (h) and (j); 170.315(a) is also certified to the
voluntarily and timely provide, in plain and certification criteria specified in
writing and in a manner calculated to ■ c. Adding reserved paragraph (i). § 170.315(d)(1) through (7);
inform, any part (including all of) the The additions read as follows: (ii) Section 170.315(b) is also certified
information required to be disclosed to the certification criteria specified in
under paragraph (k)(1) of this section, § 170.550 Health IT Module certification.
§ 170.315(d)(1) through (3) and (d)(5)
(A) to all customers, prior to * * * * * through (8);
providing or entering into any (g) When certifying a Health IT (iii) Section 170.315(c) is also
agreement to provide any certified Module to the 2015 Edition health IT certified to the certification criteria
health IT or related product or service certification criteria, an ONC–ACB must specified in § 170.315(d)(1) through (3),
(including subsequent updates, add-ons, certify the Health IT Module in and (5);
or additional products or services accordance with the certification criteria (iv) Section 170.315(e)(1) is also
during the course of an on-going at: certified to the certification criteria
agreement); (1) Section 170.315(g)(3) if the Health specified in § 170.315(d)(1) through (3),
(B) to any person who requests or IT Module is presented for certification (5), (7), and (9);
receives a quotation, estimate, to one or more listed certification (v) Section 170.315(e)(2) and (3) is
description of services, or other criteria in § 170.315(g)(3); also certified to the certification criteria
assertion or information from the (2) Section 170.315(g)(4); specified in § 170.315(d)(1) through (3),
developer in connection with any (3) Section 170.315(g)(5); and (5), and (9);
certified health IT or any capabilities (4) Section 170.315(g)(6) if the Health (vi) Section 170.315(f) is also certified
thereof; and IT Module is presented for certification to the certification criteria specified in
(C) to any person, upon request. with C–CDA creation capabilities within § 170.315(d)(1) through (3) and (7);
(vii) Section 170.315(g)(7), (8) and (9) (b) Reactive surveillance. An ONC– to complete in-the-field surveillance of
is also certified to the certification ACB must initiate surveillance a certified Complete EHR or certified
criteria specified in § 170.315(d)(1) and (including, as necessary, in-the-field Health IT Module at each location
(9); and (d)(2) or (10); surveillance required by paragraph (a) of selected under paragraph (c)(3) of this
(viii) Section 170.315(h) is also this section) whenever it becomes aware section. If the ONC–ACB is unable to
certified to the certification criteria of facts or circumstances that would complete surveillance at a location due
specified in § 170.315(d)(1) through (3); cause a reasonable person to question a to circumstances beyond its control, the
and certified Complete EHR or certified ONC–ACB may substitute a different
(4) Methods to demonstrate Health IT Module’s continued location that meets the requirements of
compliance with each privacy and conformity to the requirements of its paragraph (c)(3) of this section. If no
security criterion. One of the following certification. such location exists, the ONC–ACB may
methods must be used to meet each (1) Review of required disclosures. exclude the certified Complete EHR or
applicable privacy and security criterion When an ONC–ACB performs reactive certified Health IT Module and
listed in paragraph (h)(3) of this section: surveillance under this paragraph, it substitute a different randomly selected
(i) Directly, by demonstrating a must verify that the requirements of Complete EHR or Health IT Module to
technical capability to satisfy the § 170.523(k)(1) have been followed as which it has issued a certification.
applicable certification criterion or applicable to the issued certification. (6) Prohibition on consecutive
certification criteria; or (2) [Reserved] selection for randomized surveillance.
(ii) Demonstrate, through system (c) Randomized surveillance. During An ONC–ACB is prohibited from
documentation sufficiently detailed to each calendar year surveillance period, selecting a certified Complete EHR or
enable integration, that the Health IT an ONC–ACB must conduct in-the-field certified Health IT Module for
Module has implemented service surveillance for certain randomly randomized surveillance under this
interfaces for each applicable privacy selected Complete EHRs and Health IT paragraph more than once during any
and security certification criterion that Modules to which it has issued a consecutive 12 month period. This
enable the Health IT Module to access certification. limitation does not apply to reactive and
external services necessary to meet the (1) Scope. When an ONC–ACB selects other forms of surveillance required
privacy and security certification a certified Complete EHR or certified under this subpart and the ONC–ACB’s
criterion. Health IT Module for randomized accreditation.
(i) [Reserved] surveillance under this paragraph, its (d) Corrective action plan and
(j) Direct Project transport method. An evaluation of the certified Complete procedures. (1) When an ONC–ACB
ONC–ACB can only issue a certification EHR or certified Health IT Module must determines, through surveillance under
to a Health IT Module for include all certification criteria this section or otherwise, that a
§ 170.315(h)(1) if the Health IT Module’s prioritized by the National Coordinator Complete EHR or Health IT Module
certification also includes that are part of the scope of the does not conform to the requirements of
§ 170.315(b)(1). certification issued to the Complete EHR its certification, the ONC–ACB must
* * * * * or Health IT Module. notify the developer of its findings and
(2) Minimum number of products require the developer to submit a
§ 170.553 [Removed and Reserved] selected per year. 2% of the Complete proposed corrective action plan for the
■ 17. Remove and reserve § 170.553. EHRs and Health IT Modules to which applicable certification criterion,
■ 18. Add § 170.556 to read as follows: an ONC–ACB has issued a certification certification criteria, or certification
must be subject to randomized requirement.
§ 170.556 In-the-field surveillance and surveillance. (2) The ONC–ACB shall provide
maintenance of certification for Health IT. (3) Selection method. An ONC–ACB direction to the developer as to the
(a) In-the-field surveillance. must randomly select (subject to required elements of the corrective
Consistent with its accreditation to ISO/ appropriate weighting and sampling action plan.
IEC 17065 and the requirements of this considerations) certified Complete EHRs (3) The ONC–ACB shall verify the
subpart, an ONC–ACB must initiate and certified Health IT Modules for required elements of the corrective
surveillance ‘‘in the field’’ as necessary surveillance under this paragraph. action plan, consistent with its
to assess whether a certified Complete (4) Number and types of locations for accreditation and any elements
EHR or certified Health IT Module in-the-field surveillance. For each specified by the National Coordinator.
continues to conform to the certified Compete EHR or certified At a minimum, any corrective action
requirements of its certification once the Health IT Module selected for plan submitted by a developer to an
certified Complete EHR or certified randomized surveillance under this ONC–ACB must include:
Health IT Module has been paragraph, an ONC–ACB must: (i) A description of the identified non-
implemented and is in use in a (i) Evaluate the certified Complete conformities or deficiencies;
production environment. EHR or certified Health IT Module’s (ii) An assessment of how widespread
(1) Production environment. An capabilities at one or more locations or isolated the identified non-
ONC–ACB’s assessment of a certified where the certified Complete EHR or conformities or deficiencies may be
capability in the field must be based on certified Health IT Module is across all of the developer’s customers
the use of the capability in a production implemented and in use in the field. and users of the certified Complete EHR
environment, which means a live (ii) Ensure that the locations are or certified Health IT Module;
environment in which the capability has selected at random (subject to (iii) How the developer will address
been implemented and is in use. appropriate weighting and sampling the identified non-conformities or
(2) Production data. An ONC–ACB’s considerations) from among all deficiencies, both at the locations under
assessment of a certified capability in locations where the certified Complete which surveillance occurred and for all
the field must be based on the use of the EHR or certified Health IT Module is other potentially affected customers and
capability with production data unless implemented and in use in the field. users;
the use of test data is specifically (5) Exclusion and exhaustion. An (iv) How the developer will ensure
approved by the National Coordinator. ONC–ACB must make a good faith effort that all affected and potentially affected
customers and users are alerted to the (i) 30 days after notifying the National Coordinator on an ongoing
identified non-conformities or developer of a non-conformity pursuant basis throughout the calendar year.
deficiencies, including a detailed to paragraph (d)(1) of this section, if the (2) Confidentiality of locations
description of how the developer will developer has not submitted a proposed evaluated. The contents of an ONC–
assess the scope and impact of the corrective action plan; ACB’s surveillance results submitted to
problem, including identifying all (ii) 90 days after notifying the the National Coordinator must not
potentially affected customers; how the developer of a non-conformity pursuant include any information that would
developer will promptly ensure that all to paragraph (d)(1) of this section, if the identify any user or location that
potentially affected customers are ONC–ACB cannot approve a corrective participated in or was subject to
notified of the problem and plan for action plan because the developer has surveillance.
resolution; how and when the developer not submitted a revised proposed
corrective action plan in accordance (3) Reporting of corrective action
will resolve issues for individual plans. When a corrective action plan is
affected customers; and how the with paragraph (d)(4) of this section;
and initiated for a Complete EHR or Health
developer will ensure that all issues are IT Module, an ONC–ACB must report
in fact resolved. (iii) Immediately, if the developer has
not completed the corrective actions the Complete EHR or Health IT Module
(v) The timeframe under which and associated product and corrective
corrective action will be completed. specified by an approved corrective
action plan within the time specified action information to the National
(vi) An attestation by the developer Coordinator in accordance with
therein.
that it has completed all elements of the (6) Termination. If a certified § 170.523(f)(1)(xxii) or (f)(2)(xi), as
approved corrective action plan. Complete EHR or certified Health IT applicable.
(4) When the ONC–ACB receives a Module’s certification has been (f) Relationship to other surveillance
proposed corrective action plan (or a suspended in the context of randomized requirements. Nothing in this section
revised proposed corrective action surveillance under this paragraph, an shall be construed to limit or constrain
plan), the ONC–ACB shall either ONC–ACB is permitted to initiate an ONC–ACB’s duty or ability to
approve the corrective action plan or, if certification termination procedures for perform surveillance, including in-the-
the plan does not adequately address the Complete EHR or Health IT Module field surveillance, or to suspend or
the elements described by paragraph (consistent with its accreditation to ISO/ terminate the certification, of any
(d)(3) of this section and other elements IEC 17065 and procedures for certified Complete EHR or certified
required by the ONC–ACB, instruct the terminating a certification) when the Health IT Module as required or
developer to submit a revised proposed developer has not completed the actions permitted by this subpart and the ONC–
corrective action plan. necessary to reinstate the suspended ACB’s accreditation to ISO/IEC 17065.
(5) Suspension. Consistent with its certification.
accreditation to ISO/IEC 17065 and Dated: September 25, 2015.
(e) Reporting of surveillance results
procedures for suspending a requirements—(1) Rolling submission of Sylvia M. Burwell,
certification, an ONC–ACB shall initiate in-the-field surveillance results. The Secretary.
suspension procedures for a Complete results of in-the-field surveillance under [FR Doc. 2015–25597 Filed 10–6–15; 4:15 pm]
EHR or Health IT Module: this section must be submitted to the BILLING CODE 4150–45–P

2015 25597 2 Federal Register

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

2015 25597 2 Federal Register

Încărcat de

Drepturi de autor:

Formate disponibile

Vol.

Department of Health and Human Services

Total low cost Total high cost Total average

2015 ................................................................................................................. 15 39.07 60.48 49.77

4-Year Totals ............................................................................................ ........................ 260.44 403.19 331.82

with representatives of other relevant of the comments received on the 2014

TABLE 2—2015 EDITION HEALTH IT CERTIFICATION CRITERIA

Computerized Provider Order Entry (CPOE)—Medications

Revised Criteria as Compared to the 2014 Edition (25)

Clinical Quality Measures—Import and Calculate

TABLE 2—2015 EDITION HEALTH IT CERTIFICATION CRITERIA—Continued

New Criteria as Compared to the 2014 Edition (19)

Implantable Device List

TABLE 3—CODE SYSTEM OBJECT IDENTIFIERS (OIDS)

2.16.840.1.113883.6.96 .............................. IHTSDO SNOMED CT®.

9 Copyright© 1998–2013, Regenstrief Institute,

Inc. and the UCUM Organization. All rights

CFR Relationship to the Health IT

Specifically included in the

(a)(2) CPOE- Laboratory 13

(a)(3) CPOE- Diagnostic Imaging 14

(b)(l) Transitions of Care

Specifically included in the

(f)(2) Associated with Objective 8

(f)(6) Associated with Objective 8

(f)(7) Associated with Objective 8

• Computerized Provider Order terion

terion appropriate user interface

commenters recommended the product_brief.cfm?product_id=208.

we encourage the use of the

exchangeable documents. We clarify implantable devices by September 2015.

together provide a more comprehensive

HL7 Version 3 that gender identity be 34 http://www.nih.gov/precisionmedicine/. federalhealthitstratplanfinal_0.pdf.

However, a number of commenters were

end-to-end prescriber-to-receiver which is embedded within NCPDP

version of RxNorm in this criterion as

elements in the DRU Segment. This DosingDesignations-OralLiquid-

‘‘ToC’’ criterion and will provide

have determined that we could not

U.S. Department of Veterans Affairs

Coordination of Care Initiative.75

section III.B.3 of this preamble. product_brief.cfm?product_id=35.

whether it is a duplicate. Commenters submit data). this end, some commenters

method. criterion in the 2016 IPPS/LTCH PPS accessed at http://www.cms.gov/Regulations-and-

05/07/policy-certification-hearing. electronically create a data file for Clinical+Quality+Framework+Initiative.

CMS updates the measure specifications

Enrollment-and-Certification/MedicareProviderSup pub28.pdf. 91 http://www.phdsc.org/standards/pdfs/

Enroll/Downloads/TaxonomyCrosswalk.pdf. 90 http://projectcypress.org/. Cypress is the testing SourceofPaymentTypologyVersion5.0.pdf.

Welcome.do. the ONC Health IT Certification Program. typology.asp.

access was being audited and is already

partially addresses the amendment of the 2014 Edition ‘‘automatic log-off’’

securing encryption keys. health IT developers to get their

fips1402annexa.pdf. 111/SP800-111.pdf. 57/sp800-57_part1_rev3_general.pdf.

disclosures (76 FR 31426).102 Other

when compared to the OMB standards. iisstandards/ndc_tableaccess.asp. iisstandards/vaccines.asp?rpt=mvx.

terion a detailed view of these changes). The

2015 Edition SED criterion are as completed, including ‘‘major findings’’

implementers/2015-edition-draft-test-procedures. provider order entry—laboratory search.cfm?pub_id=907312.

Commenters mentioned that user establishing a minimum number of

sp800_163_draft.pdf; FTC, Careful Connections:

125 ONC Security Risk Assessment Tool: http://

Regulation section Regulation section

Regulation section Regulation section

We agree with commenters’ concerns