21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program, 25642-25961 [2020-07419]
Download as PDF
25642
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
DEPARTMENT OF HEALTH AND
HUMAN SERVICES
Office of the Secretary
45 CFR Parts 170 and 171
RIN 0955–AA01
21st Century Cures Act:
Interoperability, Information Blocking,
and the ONC Health IT Certification
Program
Office of the National
Coordinator for Health Information
Technology (ONC), Department of
Health and Human Services (HHS).
ACTION: Final rule.
AGENCY:
This final rule implements
certain provisions of the 21st Century
Cures Act, including Conditions and
Maintenance of Certification
requirements for health information
technology (health IT) developers under
the ONC Health IT Certification Program
(Program), the voluntary certification of
health IT for use by pediatric health care
providers, and reasonable and necessary
activities that do not constitute
information blocking. The
implementation of these provisions will
advance interoperability and support
the access, exchange, and use of
electronic health information. The rule
also finalizes certain modifications to
the 2015 Edition health IT certification
criteria and Program in additional ways
to advance interoperability, enhance
health IT certification, and reduce
burden and costs.
DATES:
Effective date: This final rule is
effective on June 30, 2020.
Incorporation by reference: The
incorporation by reference of certain
publications listed in the rule was
approved by the Director of the Federal
Register as of June 30, 2020.
Compliance date: Compliance with 45
CFR 170.401, 170.402(a)(1), and 45 CFR
part 171 is required by November 2,
2020.
FOR FURTHER INFORMATION CONTACT:
Michael Lipinski, Office of Policy,
Office of the National Coordinator for
Health Information Technology, 202–
690–7151.
SUPPLEMENTARY INFORMATION:
SUMMARY:
Table of Contents
I. Executive Summary
A. Purpose of Regulatory Action
B. Summary of Major Provisions and
Clarifications
1. Deregulatory Actions for Previous
Rulemakings
2. Updates to the 2015 Edition Certification
Criteria
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
a. Adoption of the United States Core Data
for Interoperability (USCDI) as a
Standard
b. Electronic Prescribing
c. Clinical Quality Measures—Report
d. Electronic Health Information (EHI)
Export
e. Application Programming Interfaces
f. Privacy and Security Transparency
Attestations
g. Security Tags and Consent Management
3. Modifications To the ONC Health IT
Certification Program
4. Health IT for the Care Continuum
5. Conditions and Maintenance of
Certification Requirements
6. Information Blocking
C. Costs and Benefits
II. Background
A. Statutory Basis
1. Standards, Implementation
Specifications, and Certification Criteria
2. Health IT Certification Program(s)
B. Regulatory History
C. General Comments on the Proposed
Rule
III. Deregulatory Actions for Previous
Rulemakings
A. Background
1. History of Burden Reduction and
Regulatory Flexibility
2. Executive Orders 13771 and 13777
B. Deregulatory Actions
1. Removal of Randomized Surveillance
Requirements
2. Removal of the 2014 Edition From the
Code of Federal Regulations
3. Removal of the ONC-Approved
Accreditor From the Program
4. Removal of Certain 2015 Edition
Certification Criteria and Standards
a. 2015 Edition Base EHR Definition
Certification Criteria
b. Drug-Formulary and Preferred Drug Lists
c. Patient-Specific Education Resources
d. Common Clinical Data Set Summary
Record—Create; and Common Clinical
Data Set Summary Record—Receive
e. Secure Messaging
5. Removal of Certain ONC Health IT
Certification Program Requirements
a. Limitations Disclosures
b. Transparency and Mandatory
Disclosures Requirements
6. Recognition of Food and Drug
Administration Processes
a. FDA Software Precertification Pilot
Program
b. Development of Similar Independent
Program Processes—Request for
Information
IV. Updates To the 2015 Edition Certification
Criteria
A. Standards and Implementation
Specifications
1. National Technology Transfer and
Advancement Act
2. Compliance With Adopted Standards
and Implementation Specifications
3. ‘‘Reasonably Available’’ to Interested
Parties
B. Revised and New 2015 Edition Criteria
1. The United States Core Data for
Interoperability Standard (USCDI)
a. USCDI 2015 Edition Certification
Criteria
PO 00000
Frm 00002
Fmt 4701
Sfmt 4700
b. USCDI Standard—Data Classes Included
c. USCDI Standard—Relationship to
Content Exchange Standards and
Implementation Specifications
2. Clinical Notes C-CDA Implementation
Specification
3. Unique Device Identifier(s) for a
Patient’s Implantable Device(s) C-CDA
Implementation Specification
4. Electronic Prescribing Criterion
a. Electronic Prescribing Standard and
Certification Criterion
b. Electronic Prescribing Transactions
5. Clinical Quality Measures—Report
Criterion
6. Electronic Health Information (EHI)
Export Criterion
a. Single Patient Export To Support Patient
Access
b. Patient Population Export to Support
Transitions Between Health IT Systems
c. Scope of Data Export
d. Export Format
e. Initial Step Towards Real-Time Access
f. Timeframes
g. 2015 Edition ‘‘Data Export’’ Criterion in
§ 170.315(b)(6)
7. Standardized API for Patient and
Population Services Criterion
8. Privacy and Security Transparency
Attestations Criteria
a. Encrypt Authentication Credentials
b. Multi-Factor Authentication
9. Security Tags and Consent Management
Criteria
a. Implementation With the Consolidated
CDA Release 2.1
b. Implementation With the Fast
Healthcare Interoperability Resources
(FHIRr) Standard
10. Auditable Events and TamperResistance, Audit Reports, and Auditing
Actions on Health Information
C. Unchanged 2015 Edition Criteria—
Promoting Interoperability Programs
Reference Alignment
V. Modifications To the ONC Health IT
Certification Program
A. Corrections
1. Auditable Events and Tamper Resistance
2. Amendments
3. View, Download, and Transmit to 3rd
Party
4. Integrating Revised and New
Certification Criteria Into the 2015
Edition Privacy and Security
Certification Framework
B. Principles of Proper Conduct for ONCACBs
1. Records Retention
2. Conformance Methods for Certification
Criteria
3. ONC-ACBs To Accept Test Results From
Any ONC-ATL in Good Standing
4. Mandatory Disclosures and
Certifications
C. Principles of Proper Conduct for ONCATLs—Records Retention
VI. Health IT for the Care Continuum
A. Health IT for Pediatric Setting
1. Background and Stakeholder Convening
2. Recommendations for the Voluntary
Certification of Health IT for Use in
Pediatric Care
a. 2015 Edition Certification Criteria
b. New or Revised Certification Criteria
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
B. Health IT and Opioid Use Disorder
Prevention and Treatment—Request for
Information
VII. Conditions and Maintenance of
Certification Requirements for Health IT
Developers
A. Implementation
B. Provisions
1. Information Blocking
2. Assurances
a. Full Compliance and Unrestricted
Implementation of Certification Criteria
Capabilities
b. Certification to the ‘‘Electronic Health
Information Export’’ Criterion
c. Records and Information Retention
d. Trusted Exchange Framework and the
Common Agreement—Request for
Information
3. Communications
a. Background and Purpose
b. Condition of Certification Requirements
c. Maintenance of Certification
Requirements
4. Application Programming Interfaces
a. Statutory Interpretation and API Policy
Principles
b. API Standards and Implementation
Specifications
c. Standardized API for Patient and
Population Services
d. API Condition of Certification
Requirements
e. API Maintenance of Certification
Requirements
5. Real World Testing
a. Unit of Analysis at which Testing
Requirements Apply
b. Applicability of Real World Testing
Condition and Maintenance of
Certification Requirements
c. Testing Plans, Methods, and Results
Reporting
d. Submission Dates
e. Real World Testing Pilot Year
f. Health IT Modules Certified But Not Yet
Deployed
g. Standards Version Advancement Process
(SVAP)
h. Updating Already Certified Health IT
Leveraging SVAP Flexibility
i. Health IT Modules Presented for
Certification Leveraging SVAP
Flexibility
j. Requirements Associated With All
Health IT Modules Certified Leveraging
SVAP Flexibility
k. Advanced Version Approval for SVAP
l. Real World Testing Principles of Proper
Conduct for ONC-ACBs
m. Health IT Module Certification &
Certification to Newer Versions of
Certain Standards
6. Attestations
7. EHR Reporting Criteria Submission
C. Compliance
D. Enforcement
1. ONC Direct Review of the Conditions
and Maintenance of Certification
Requirements
2. Review and Enforcement Only by ONC
3. Review Processes
a. Initiating Review and Health IT
Developer Notice
b. Relationship With ONC-ACBs and ONCATLs
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
c. Records Access
d. Corrective Action
e. Certification Ban and Termination
f. Appeal
g. Suspension
h. Proposed Termination
4. Public Listing of Certification Ban and
Terminations
5. Effect on Existing Program Requirements
and Processes
6. Coordination With the Office of
Inspector General
7. Applicability of Conditions and
Maintenance of Certification
Requirements for Self-Developers
VIII. Information Blocking
A. Statutory Basis
B. Legislative Background and Policy
Considerations
1. Purpose of the Information Blocking
Provision
2. Policy Considerations and Approach to
Information Blocking
3. General Comments Regarding
Information Blocking Exceptions
C. Relevant Statutory Terms and Provisions
1. ‘‘Required by Law’’
2. Health Care Providers, Health IT
Developers, Exchanges, and Networks
a. Health Care Providers
b. Health IT Developers of Certified Health
IT
c. Health Information Networks and Health
Information Exchanges
3. Electronic Health Information
4. Price Information—Request for
Information
5. Interests Promoted by the Information
Blocking Provision
a. Access, Exchange, and Use of EHI
b. Interoperability Elements
6. Practices That May Implicate the
Information Blocking Provision
a. Prevention, Material Discouragement,
and Other Interference
b. Likelihood of Interference
c. Examples of Practices Likely to Interfere
With Access, Exchange, or Use of EHI
7. Applicability of Exceptions
a. Reasonable and Necessary Activities
b. Treatment of Different Types of Actors
c. Establishing That Activities and
Practices Meet the Conditions of an
Exception
D. Exceptions to the Information Blocking
Definition
1. Exceptions That Involve not Fulfilling
Requests To Access, Exchange, or Use
EHI
a. Preventing Harm Exception—When will
an actor’s practice that is likely to
interfere with the access, exchange, or
use of EHI in order to prevent harm not
be considered information blocking?
b. Privacy Exception—When will an actor’s
practice of not fulfilling a request to
access, exchange, or use EHI in order to
protect an individual’s privacy not be
considered information blocking?
c. Security Exception—When will an
actor’s practice that is likely to interfere
with the access, exchange, or use of EHI
in order to protect the security of EHI not
be considered information blocking?
d. Infeasibility Exception—When will an
actor’s practice of not fulfilling a request
PO 00000
Frm 00003
Fmt 4701
Sfmt 4700
25643
to access, exchange, or use EHI due to
the infeasibility of the request not be
considered information blocking?
e. Health IT Performance Exception—
When will an actor’s practice that is
implemented to maintain or improve
health IT performance and that is likely
to interfere with the access, exchange, or
use of EHI not be considered information
blocking?
2. Exceptions That Involve Procedures for
Fulfilling Requests To Access, Exchange,
or Use EHI
a. Content and Manner Exception—When
will an actor’s practice of limiting the
content of its response to or the manner
in which it fulfills a request to access,
exchange, or use EHI not be considered
information blocking?
b. Fees Exception—When will an actor’s
practice of charging fees for accessing,
exchanging, or using EHI not be
considered information blocking?
c. Licensing Exception—When will an
actor’s practice to license
interoperability elements in order for
EHI to be accessed, exchanged, or used
not be considered information blocking?
E. Additional Exceptions—Request for
Information
1. Exception for Complying With Common
Agreement for Trusted Exchange
2. New Exceptions
F. Complaint Process
G. Disincentives for Health Care
Providers—Request for Information
IX. Registries Request for Information
X. Patient Matching Request for Information
XI. Incorporation by Reference
XII. Collection of Information Requirements
A. ONC–ACBs
B. Health IT Developers
XIII. Regulatory Impact Analysis
A. Statement of Need
B. Alternatives Considered
C. Overall Impact
1. Executive Orders 12866 and 13563—
Regulatory Planning and Review
Analysis
2. Executive Order 13771—Reducing
Regulation and Controlling Regulatory
Costs
a. Costs and Benefits
b. Accounting Statement and Table
3. Regulatory Flexibility Act
4. Executive Order 13132—Federalism
5. Unfunded Mandates Reform Act of 1995
Regulation Text
I. Executive Summary
A. Purpose of Regulatory Action
ONC is responsible for the
implementation of key provisions in
Title IV of the 21st Century Cures Act
(Cures Act) that are designed to advance
interoperability; support the access,
exchange, and use of electronic health
information (EHI); and address
occurrences of information blocking.
This final rule implements certain
provisions of the Cures Act, including
Conditions and Maintenance of
Certification requirements for health
information technology (health IT)
E:\FR\FM\01MYR3.SGM
01MYR3
25644
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
developers, the voluntary certification
of health IT for use by pediatric health
providers, and reasonable and necessary
activities that do not constitute
information blocking. The final rule also
implements parts of section 4006(a) of
the Cures Act to support patients’ access
to their EHI in a form convenient for
patients, such as making a patient’s EHI
more electronically accessible through
the adoption of standards and
certification criteria and the
implementation of information blocking
policies that support patient electronic
access to their health information at no
cost. Additionally, the final rule
modifies the 2015 Edition health IT
certification criteria and ONC Health IT
Certification Program (Program) in other
ways to advance interoperability,
enhance health IT certification, and
reduce burden and costs.
In addition to fulfilling the Cures
Act’s requirements, the final rule
contributes to fulfilling Executive Order
(E.O.) 13813. The President issued E.O.
13813 on October 12, 2017, to promote
health care choice and competition
across the United States. Section 1(c) of
the E.O., in relevant part, states that
government rules affecting the United
States health care system should reinject competition into health care
markets by lowering barriers to entry
and preventing abuses of market power.
Section 1(c) also states that government
rules should improve access to and the
quality of information that Americans
need to make informed health care
decisions. For example, as mentioned
above, the final rule establishes
application programming interface (API)
requirements, including for patients’
access to their health information
without special effort. The API
approach also supports health care
providers’ independence to choose the
‘‘provider-facing’’ third-party services
they want to use to interact with the
certified API technology they have
acquired. In addition, the final rule
provides the Secretary of Health and
Human Services’ (Secretary)
interpretation of the information
blocking definition as established in the
Cures Act and the application of the
information blocking provision by
identifying reasonable and necessary
activities that would not constitute
information blocking. Many of these
activities focus on improving patient
and health care provider access to EHI
and promoting competition.
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
B. Summary of Major Provisions and
Clarifications
1. Deregulatory Actions for Previous
Rulemakings
Since the inception of the Program,
we have aimed to implement and
administer the Program in the least
burdensome manner that supports our
policy goals. Throughout the years, we
have worked to improve the Program
with a focus on ways to reduce burden,
offer flexibility to both developers and
providers, and support innovation. This
approach has been consistent with the
principles of E.O. 13563 on Improving
Regulation and Regulatory Review
(February 2, 2011), which instructs
agencies to ‘‘periodically review its
existing significant regulations and
determine whether any such regulations
should be modified, streamlined,
expanded, or repealed so as to make the
agency’s regulatory program more
effective or less burdensome in
achieving the regulatory objectives.’’ To
that end, we have historically, where
feasible and appropriate, taken
measures to reduce burden within the
Program and make the Program more
effective, flexible, and streamlined.
We reviewed and evaluated existing
regulations and identified ways to
administratively reduce burden and
implement deregulatory actions through
guidance. In this final rule, we have
finalized new deregulatory actions that
will reduce burden for health IT
developers, providers, and other
stakeholders. We have finalized five
deregulatory actions in section III.B: (1)
Removal of a requirement to conduct
randomized surveillance on a set
percentage of certified products,
allowing ONC-Authorized Certification
Bodies (ONC–ACBs) more flexibility to
identify the right approach for
surveillance actions; (2) removal of the
2014 Edition from the Code of Federal
Regulations (CFR); (3) removal of the
ONC-Approved Accreditor (ONC–AA)
from the Program; (4) removal of certain
2015 Edition certification criteria; and
(5) removal of certain Program
requirements. We have not finalized a
sixth deregulatory action we proposed,
related to recognition of the Food and
Drug Administration (FDA) Software
Precertification Program, as comments
and the early stage of development of
the FDA program indicate finalization
would be premature at this time.
2. Updates to the 2015 Edition
Certification Criteria
This final rule updates the 2015
Edition to remove several certification
criteria. It also updates some
certification criteria to reflect standard
PO 00000
Frm 00004
Fmt 4701
Sfmt 4700
and implementation specification
updates. In consideration of public
comments, the final rule adds only two
new technical certification criteria and
two new attestation-structured privacy
and security certification criteria.
a. Adoption of the United States Core
Data for Interoperability (USCDI) as a
Standard
We noted in the Proposed Rule that,
as part of continued efforts to ensure the
availability of a minimum baseline of
data classes that could be commonly
available for interoperable exchange,
ONC adopted the 2015 Edition
‘‘Common Clinical Data Set’’ (CCDS)
definition and used the CCDS shorthand
in several certification criteria.
However, the CCDS definition also
began to be used colloquially for many
different purposes. As the CCDS
definition’s relevance grew outside of its
regulatory context, it was often viewed
as a ceiling to the industry’s collective
data set for access, exchange, and use.
In addition, we noted in the NPRM that
as we continue to move toward valuebased care, the inclusion of additional
data classes beyond the CCDS would be
necessary. In order to advance
interoperability, we proposed to remove
the CCDS definition and its references
from the 2015 Edition and replace it
with the ‘‘United States Core Data for
Interoperability 1’’ (USCDI). We
proposed to adopt the USCDI as a
standard, naming USCDI Version 1
(USCDI v1) in § 170.213 and
incorporating it by reference in
§ 170.299. The USCDI standard would
establish a set of data classes and
constituent data elements required to
support interoperability nationwide. To
achieve the goals set forth in the Cures
Act, we indicated that we intended to
establish and follow a predictable,
transparent, and collaborative process to
expand the USCDI, including providing
stakeholders with the opportunity to
comment on the USCDI’s expansion. We
also noted that once the USCDI is
adopted by the Secretary in regulation,
health IT developers would be allowed
to take advantage of a new proposed
flexibility we called the ‘‘Standards
Version Advancement Process’’ (SVAP)
(see 84 FR 7497 through 7500, see also
section VII.B.5 of this final rule). In
order to advance interoperability, we
have finalized the adoption of the
USCDI standard. Because the USCDI is
adopted as a standard and the SVAP is
finalized, the SVAP will allow a
developer to voluntarily have their
products certified to newer, National
Coordinator approved versions of the
1 https://www.healthit.gov/uscdi.
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
USCDI in the future without waiting for
rulemaking to update the version of the
USCDI listed in the regulations.
b. Electronic Prescribing
We have finalized an update to the
electronic prescribing National Council
for Prescription Drug Programs (NCPDP)
SCRIPT standard in 45 CFR 170.205(b)
from NCPDP SCRIPT standard version
10.6 to NCPDP SCRIPT standard version
2017071 for the electronic prescribing
certification criterion (§ 170.315(b)(3)).
ONC and the Centers for Medicare &
Medicaid Services (CMS) have
historically maintained aligned e-Rx
and medication history (MH) standards
to ensure that the current standard for
certification to the electronic
prescribing criterion supports use of the
current Part D e-Rx and MH standards.
This helps advance alignment with
CMS’ program standards.
In a final rule published April 16,
2018, CMS finalized its update of its
Part D standards to NCPDP SCRIPT
standard version 2017071 for e-Rx and
MH, effective January 1, 2020 (83 FR
16440). In addition to continuing to
reference the transactions previously
included in § 170.315(b)(3), and in
keeping with CMS’ final rule, we have
adopted all of the additional NCPDP
SCRIPT standard version 2017071
transactions that CMS adopted in 42
CFR 423.160(b)(2)(iv). Furthermore, we
have adopted the same electronic Prior
Authorization (ePA) request and
response transactions supported by
NCPDP SCRIPT standard 2017071
proposed by CMS in the Medicare
Program; Secure Electronic Prior
Authorization for Medicare Part D
proposed rule (84 FR 28450). Some
adopted transactions are required to
demonstrate conformance to the
updated § 170.315(b)(3) criterion, while
other transactions are optional.
c. Clinical Quality Measures—Report
In this final rule, we have removed
the Health Level 7 (HL7®) Quality
Reporting Document Architecture
(QRDA) standard requirements in the
2015 Edition ‘‘Clinical Quality
Measures—report’’ criterion in
§ 170.315(c)(3) and, in their place,
required Health IT Modules to support
the CMS QRDA Implementation Guide
(IGs).2 This will help reduce the burden
for health IT developers and remove
certification requirements that do not
support quality reporting for CMS
programs.
2 https://ecqi.healthit.gov/qrda-quality-reportingdocument-architecture.
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
d. Electronic Health Information (EHI)
Export
We proposed to adopt a new 2015
Edition certification criterion, referred
to as ‘‘EHI export’’ in § 170.315(b)(10) in
the Proposed Rule. The criterion’s
proposed conformance requirements
were intended to provide a means to
export the entire EHI a certified health
IT product produced and electronically
managed to support two contexts: (1)
Single patient EHI export and (2) for
patient EHI export when a health care
provider is switching health IT systems.
The proposals did not require the
exported data to be in a specific
standardized format. Rather, we
proposed to require that such an export
be in a computable, electronic format
made available via a publicly accessible
hyperlink. We noted that this
transparency would facilitate the
subsequent interpretation and use of the
exported information.
We have finalized the criterion with
modifications in response to public
comment. We have refined the scope of
data a Health IT Module certified to
§ 170.315(b)(10) must export, and
aligned the criterion to the definition of
EHI we finalized in § 170.102 and
§ 171.102. The finalized criterion
requires a certified Health IT Module to
electronically export all of the EHI, as
defined in § 171.102, that can be stored
at the time of certification by the
product, of which the Health IT Module
is a part. We finalized the 2015 Edition
Cures Update ‘‘EHI export’’ criterion in
§ 170.315(b)(10) but did not finalize its
inclusion in the 2015 Edition Base
Electronic Health Record (EHR)
definition, as proposed. Our intention
with this criterion, in combination with
other criteria set forth in this final rule,
is to advance the interoperability of
health IT as defined in section 4003 the
Cures Act, including the ‘‘complete
access, exchange, and use of all
electronically accessible health
information.’’
e. Application Programming Interfaces
(APIs)
We have adopted a new API
certification criterion in
§ 170.315(g)(10) to replace the
‘‘application access—data category
request’’ certification criterion
(§ 170.315(g)(8)), and added it to the
updated 2015 Edition Base EHR
definition. This new ‘‘standardized API
for patient and population services’’
certification criterion focuses on
supporting two types of API-enabled
services: (1) Services for which a single
patient’s data is the focus and (2)
services for which multiple patients’
PO 00000
Frm 00005
Fmt 4701
Sfmt 4700
25645
data are the focus. The API certification
criterion requires the use of the Health
Level 7 (HL7®) Fast Healthcare
Interoperability Resources (FHIR®)
standard Release 4 and references
several standards and implementation
specifications adopted in § 170.213 and
§ 170.215 to support standardization
and interoperability. This certification
criterion will align industry efforts
around FHIR Release 4 and advance
interoperability of API-enabled ‘‘read’’
services for single and multiple patients.
f. Privacy and Security Transparency
Attestations
We have adopted two new privacy
and security certification criteria
requiring transparency attestations from
developers of certified health IT as part
of the updated 2015 Edition privacy and
security certification framework. The
attestations will serve to identify
whether or not certified health IT
supports encrypting authentication
credentials and/or multi-factor
authentication (MFA). While these
criteria provide increased transparency,
they do not require new development or
implementation to take place. As part of
ONC’s ongoing commitment to advance
transparency about certified health IT
products, ONC will list the developers’
attestation responses on the Certified
Health IT Product List (CHPL).
g. Security Tags and Consent
Management
In the 2015 Edition final rule (80 FR
62646, Oct. 16, 2015), we adopted two
‘‘data segmentation for privacy’’ (DS4P)
certification criteria, one for creating a
summary record according to the DS4P
standard (§ 170.315(b)(7)) and one for
receiving a summary record according
to the DS4P standard (§ 170.315(b)(8)).
Certification to these 2015 Edition DS4P
criteria only required security tagging of
Consolidated-Clinical Document
Architecture (C–CDA) documents at the
document level. As noted in the 2015
Edition final rule (80 FR 62646),
certification to these criteria is not
linked to meeting the Certified EHR
Technology definition (CEHRT) used in
CMS programs.
Since the 2015 Edition final rule, the
health care industry has engaged in
additional field testing and
implementation of the DS4P standard.
Stakeholders also shared with ONC—
through public forums, listening
sessions, and correspondence—that
only tagging C–CDA documents at the
document level did not permit
providers the flexibility to address more
complex use cases for representing
patient privacy preferences. Based on
public comment, in this final rule, we
E:\FR\FM\01MYR3.SGM
01MYR3
25646
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
have changed the names of the two
current 2015 Edition DS4P criteria to
Security tags—Summary of Care (send)
and Security tags—Summary of Care
(receive). We also updated the
requirements for these criteria to
support security tagging at the
document, section, and entry levels.
This change better reflects the purpose
of these criteria and enables adopters to
support a more granular approach to
security tagging clinical documents for
exchange.
In finalizing this more granular
approach for security tagging
Consolidated Clinical Document
Architecture (C–CDA) documents, we
note that we do not specify rules or
requirements for the disposition of
tagged data or any requirements on
health care providers related to data
segmentation for privacy. The use cases
for which health IT certified to these
criteria might be implemented would be
driven by other applicable Federal,
State, local, or tribal law and are outside
the scope of the certification criteria. We
recognize that the tagging of documents
is not a fully automated segmentation of
the record but rather a first,
technological step or tool to support
health IT developers implementing
technology solutions for health care
providers to replace burdensome
manual processes for tagging sensitive
information.
We also proposed to adopt a new
2015 Edition certification criterion,
‘‘consent management for APIs’’ in
§ 170.315(g)(11), to support data
segmentation and consent management
through an API in accordance with the
Consent Implementation Guide (IG).
However, in response to comments, we
have chosen not to finalize our proposal
for this criterion at this time.
3. Modifications to the ONC Health IT
Certification Program
In this final rule, we have finalized
corrections to the 2015 Edition privacy
and security certification framework (80
FR 62705) and relevant regulatory
provisions. We also have finalized
corrections to the relevant current
Certification Companion Guides (CCGs).
We have adopted new and revised
Principles of Proper Conduct (PoPC) for
ONC–ACBs. We have finalized
clarification that the records retention
provision includes the ‘‘life of the
edition’’ as well as three years after the
retirement of an edition related to the
certification of Complete EHRs and
Health IT Modules. We also have
finalized revisions to the PoPC in
§ 170.523(h) to clarify the basis for
certification, including to permit a
certification decision to be based on an
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
evaluation conducted by the ONC–ACB
for Health IT Modules’ compliance with
certification criteria by use of
conformity methods approved by the
National Coordinator for Health
Information Technology (National
Coordinator). We also have finalized the
addition of § 170.523(r) to require ONC–
ACBs to accept test results from any
ONC-Authorized Testing Laboratory
(ONC–ATL) in good standing under the
Program and compliant with the ISO/
IEC 17025 accreditation requirements
consistent with the requirements set
forth in §§ 170.520(b)(3) and 170.524(a).
We believe these new and revised PoPC
provide necessary clarifications for
ONC–ACBs and promote stability
among the ONC–ACBs. We also have
finalized the update of § 170.523(k) to
broaden the requirements beyond just
the Medicare and Medicaid EHR
Incentive Programs (now renamed the
Promoting Interoperability (PI) Programs
and referenced as such hereafter) and
provided other necessary clarifications.
We have finalized a revised PoPC for
ONC–ATLs. The finalized revision
clarifies that the records retention
provision includes the ‘‘life of the
edition’’ as well as three years after the
retirement of an edition related to the
certification of Complete EHRs and
Health IT Modules.
4. Health IT for the Care Continuum
Section 4001(b) of the Cures Act
includes two provisions related to
supporting health IT across the care
continuum. The first instructs the
National Coordinator to encourage,
keep, or recognize through existing
authorities the voluntary certification of
health IT for use in medical specialties
and sites of service where more
technological advancement or
integration is needed. The second
outlines a provision related to the
voluntary certification of health IT for
use by pediatric health providers to
support the health care of children.
These provisions align closely with our
core purpose to promote interoperability
and to support care coordination,
patient engagement, and health care
quality improvement initiatives.
Advancing health IT that promotes and
supports patient care when and where
it is needed continues to be a primary
goal of the Program. This means health
IT should support patient populations,
specialized care, transitions of care, and
practice settings across the care
continuum.
We have explored how we might
work with the health IT industry and
with specialty organizations to
collaboratively develop and promote
health IT that supports medical
PO 00000
Frm 00006
Fmt 4701
Sfmt 4700
specialties and sites of service. Over
time, we have taken steps to make the
Program modular, more open and
accessible to different types of health IT,
and better able to advance functionality
that is generally applicable to a variety
of care and practice settings. We
considered a wide range of factors
specific to the provisions in the Cures
Act to support providers of health care
for children. These include: The
evolution of health IT across the care
continuum, the costs and benefits
associated with health IT, the potential
regulatory burden and compliance
timelines, and the need to help advance
health IT that benefits multiple medical
specialties and sites of service involved
in the care of children. In consideration
of these factors, and to advance
implementation of section 4001(b) of the
Cures Act specific to pediatric care, we
held a listening session where
stakeholders could share their clinical
knowledge and technical expertise in
pediatric care and pediatric sites of
service. Through the information
learned at this listening session and our
analysis of the health IT landscape for
pediatric settings, we identified existing
2015 Edition criteria, as well as new or
revised 2015 Edition criteria proposed
in the Proposed Rule, that could benefit
providers of pediatric care and pediatric
settings. In this final rule, we have
identified the already existing 2015
Edition certification criteria and the
new or revised 2015 Edition criteria
adopted in this final rule that support
the voluntary certification of health IT
for pediatric care and pediatric settings.
We also elaborate on our next steps to
support pediatric care and pediatric
settings through the development,
adoption, certification, and use of health
IT, including the continued support of
a pediatrics health IT web page on
www.healthit.gov/pediatrics and the
future development of informational
resources.
We also recognize the significance of
the opioid epidemic confronting our
nation and the importance of helping to
support the health IT needs of health
care providers committed to preventing
inappropriate access to prescription
opioids and to providing safe,
appropriate treatment. Therefore, we
requested public comment on how our
existing Program requirements and the
proposals in the Proposed Rule may
support use cases related to Opioid Use
Disorder (OUD) prevention and
treatment and if there were additional
areas that we should consider for
effective implementation of health IT to
help address OUD prevention and
treatment. We received over 100
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
comments in responses to this RFI,
which we are actively reviewing.
5. Conditions and Maintenance of
Certification Requirements
We have established in this final rule,
certain Conditions and Maintenance of
Certification requirements for health IT
developers based on the Conditions and
Maintenance of Certification
requirements outlined in section 4002 of
the Cures Act. The Program’s
Conditions and Maintenance of
Certification requirements express
initial requirements for health IT
developers and their certified Health IT
Module(s) as well as ongoing
requirements that must be met by both
health IT developers and their certified
Health IT Module(s) under the Program.
In this regard, we have implemented the
Cures Act Conditions of Certification
requirements with further specificity as
it applies to the Program and
implemented any accompanying
Maintenance of Certification
requirements as standalone
requirements to ensure that the
Conditions of Certification requirements
are not only met but continually being
met through the Maintenance of
Certification requirements. In this rule,
we capitalize ‘‘Conditions of
Certification’’ and ‘‘Maintenance of
Certification’’ when referring to
Conditions and Maintenance of
Certification requirements established
for the Program under section 4002 of
the Cures Act for ease of reference and
to distinguish from other conditions.
Information Blocking
Section 4002 of the Cures Act requires
that a health IT developer, as a
Condition and Maintenance of
Certification requirement under the
Program, not take any action that
constitutes information blocking as
defined in section 3022(a) of the Public
Health Service Act (PHSA). We have
adopted the information blocking
Condition of Certification requirement
in § 170.401 as proposed. As finalized,
the Condition of Certification
requirement prohibits any health IT
developer under the Program from
taking any action that constitutes
information blocking as defined by
section 3022(a) of the PHSA. We have
also finalized that definition in
§ 171.103.
Assurances
Section 4002 of the Cures Act also
requires that a health IT developer, as a
Condition of Certification requirement
under the Program, provide assurances
to the Secretary that, unless for
legitimate purpose(s) as specified by the
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
Secretary, the developer will not take
any action that constitutes information
blocking as defined in section 3022(a) of
the PHSA or any other action that may
inhibit the appropriate exchange,
access, and use of EHI. We have
finalized our proposed implementation
of this provision through several
Conditions of Certification and
accompanying Maintenance of
Certification requirements, which are
set forth in § 170.402. We have also
adopted more specific Conditions and
Maintenance of Certification
requirements, which are also set forth in
§ 170.402, for certified health IT
developers to provide assurances to the
Secretary that it does not take any other
action that may inhibit the appropriate
exchange, access, and use of EHI. These
requirements serve to provide further
clarity under the Program as to how
health IT developers must meet our
requirements as promulgated under the
Cures Act.
Communications
The Cures Act also requires as a
Condition and Maintenance of
Certification requirement under the
Program that health IT developers do
not prohibit or restrict communications
about certain aspects of the performance
of health IT and the developers’ related
business practices. We have finalized
(in § 170.403) provisions that permit
developers to impose certain types of
limited prohibitions and restrictions
that strike a balance between the need
to promote open communication about
health IT, and related developer
business practices, with the need to
protect the legitimate business interests
of health IT developers and others. The
provisions identify certain narrowlydefined types of communications, such
as communications required by law,
made to a government agency, or made
to a defined category of safety
organization, which will receive
‘‘unqualified protection’’ under our
Program. Under this policy, developers
will be prohibited from imposing any
prohibitions or restrictions on such
protected communications. Based on
public comment received, we have also
finalized provisions that allow health IT
developers certified under the Program
to place limitations on certain types of
communications, including screenshots
and video.
We have adopted Maintenance of
Certification requirements proposed in
§ 170.403(b) with modifications. A
health IT developer must not impose or
enforce any contractual requirement
that contravenes the requirements of
this Condition of Certification.
Furthermore, if a health IT developer
PO 00000
Frm 00007
Fmt 4701
Sfmt 4700
25647
has contracts/agreements in existence
that contravene the requirements of this
Condition of Certification, the developer
must notify all affected customers, other
persons, or entities that the prohibition
or restriction within the contract/
agreement will not be enforced by the
health IT developer. In response to
comments, we have finalized in
§ 170.403(b)(2)(ii) that health IT
developers are required to amend their
contracts/agreements to remove or make
void such provisions only when the
contracts/agreements are next modified
for other purposes and not within the
proposed period of time from the
effective date of this final rule.
Application Programming Interfaces
(APIs)
As a Condition of Certification
requirement in section 4002 of the Cures
Act requires health IT developers to
publish APIs that allow ‘‘health
information from such technology to be
accessed, exchanged, and used without
special effort through the use of APIs or
successor technology or standards, as
provided for under applicable law.’’ The
Cures Act’s API Condition of
Certification requirement also states that
a developer must, through an API,
‘‘provide access to all data elements of
a patient’s electronic health record to
the extent permissible under applicable
privacy laws.’’ The Cures Act’s API
Condition of Certification requirement
in section 4002 includes several key
phrases and requirements for health IT
developers that go beyond the technical
functionality of the Health IT Modules
they present for certification. This final
rule captures both the technical
functionality and behaviors necessary to
implement the Cures Act API Condition
of Certification requirement.
Specifically, we have adopted new
standards, new implementation
specifications, a new certification
criterion, and have modified the Base
EHR definition. In addition, we have
finalized detailed Condition and
Maintenance of Certification
requirements for health IT developers.
Real World Testing
The Cures Act also added a new
Condition and Maintenance of
Certification requirement that health IT
developers must successfully test the
real world use of health IT for
interoperability in the type(s) of
setting(s) in which such technology
would be marketed. This provision is
critical to advancing transparency
regarding Health IT Modules’
performance and to users having
information that could be crucial to
E:\FR\FM\01MYR3.SGM
01MYR3
25648
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
their decisions to acquire certified
health IT.
As discussed in section VII.B.5 of this
final rule, we have established in
§ 170.405 real world testing Condition
and Maintenance of Certification
requirements that include Maintenance
of Certification requirements to update
Health IT Modules certified to certain
certification criteria (see § 170.405(b)(3)
through (7) and section IV.B of this final
rule preamble) to ensure this certified
technology meets its users’ needs for
widespread and continued
interoperability.
As finalized, real world testing
Condition and Maintenance of
Certification requirements apply to
health IT developers with one or more
Health IT Module(s) certified to specific
certification criteria focused on
interoperability and data exchange that
are listed in § 170.405(a), as discussed
in section VII.B.5 of this final rule.
Under these Condition and Maintenance
of Certification requirements, health IT
developers must submit publicly
available annual real world testing plans
as well as annual real world testing
results for health IT certified to the
criteria identified in § 170.405(a). We
have also finalized a flexibility that we
have named the Standards Version
Advancement Process (SVAP). Under
this flexibility, health IT developers will
have the option to update their health
IT that is certified to the criteria
identified in § 170.405(a) to use more
advanced version(s) of the adopted
standard(s) or implementation
specification(s) included in the criteria,
provided such versions are approved by
the National Coordinator for use in
health IT certified under the Program.
Similarly, we have finalized our
proposal (84 FR 7497 through 7500) that
health IT developers presenting health
IT for initial certification to one of the
criteria listed in § 170.405(a) would
have the option to certify to National
Coordinator-approved newer version(s)
of one or more of the Secretary-adopted
standards or implementation
specifications applicable to the
criterion. All health IT developers
voluntarily opting to avail themselves of
the SVAP flexibility must ensure that
their annual real world testing plans
and real world testing results
submissions address all the versions of
all the standards and implementation
specifications to which each Health IT
Module is certified. In addition, we
have finalized in § 170.405(b)(8)(i) the
requirement that health IT developers
with existing certifications to criteria
listed in § 170.405(a) who wish to avail
themselves of the SVAP flexibility must
notify both their ONC–ACB and their
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
affected customers of their plans to
update their certified health IT, and the
update’s anticipated impact on their
existing certified health IT and
customers, specifically including but
not limited to whether, and if so for how
long, the health IT developer intends to
continue supporting the prior
version(s) 3 of the standard(s) to which
the Health IT Module has already been
certified, in addition to the National
Coordinator-approved newer version(s)
included in a planned update.
We have finalized our proposal (84 FR
7501) to establish in § 170.523(p) a new
PoPC for ONC–ACBs that requires
ONC–ACBs to review and confirm that
each health IT developer with one or
more Health IT Module(s) certified to
any one or more of the criteria listed in
§ 170.405(a) submits real world testing
plans and real world results on a
timeframe that allows for the ONC–ACB
to confirm completeness of all plans and
results by applicable annual due dates.
The specific annual due dates finalized
in § 170.523(p) differ from those
proposed as, and for the reasons,
discussed in section VII.B.5 of this final
rule preamble. Once completeness is
confirmed, ONC–ACBs must make the
plans available to ONC and the public
via the Certified Health IT Product List
(CHPL).4 We have also finalized, with
clarifying revisions, the PoPC proposed
in § 170.523(m) to require ONC–ACBs to
aggregate and report to ONC no less
than quarterly all updates successfully
made to support National Coordinatorapproved newer versions of Secretaryadopted standards in certified health IT
pursuant to the developers having
voluntarily opted to avail themselves of
the SVAP flexibility. We also finalize in
§ 170.523(t) the new PoPC for ONC–
ACBs that requires them to ensure that
developers seeking to take advantage of
the SVAP flexibility provide the
advance notice required in
§ 170.405(b)(8) to all affected customers
and its ONC–ACB, and comply with all
other applicable requirements.
Attestations
Section 4002(a) of the Cures Act
requires that a health IT developer, as
3 In the near term, many of these prior versions
are likely to be the same versions adopted by the
Secretary and incorporated by reference in subpart
B of 45 CFR part 170. Over time, however, we
anticipate increasing frequency of prior versions
certified including National Coordinator-approved
newer versions of these Secretary-adopted
standards.
4 Although real world testing plans and results
will not be immediately available upon publication
of this final rule, an overview of the CHPL is
available at https://chpl.healthit.gov/#/resources/
overview (last accessed 07/12/2019). For additional
information on how to navigate the CHPL, please
refer to the CHPL Public User Guide.
PO 00000
Frm 00008
Fmt 4701
Sfmt 4700
Condition and Maintenance of
Certification requirements under the
Program, provide to the Secretary an
attestation to all of the other Conditions
of Certification required in section
3001(c)(5)(D) of the PHSA, except for
the ‘‘EHR reporting criteria submission’’
Condition of Certification requirement
in § 3001(c)(5)(D)(vii). We have finalized
regulation text implementing the Cures
Act’s ‘‘attestations’’ Condition of
Certification requirement in § 170.406.
Under § 170.406 as finalized by this
rule, health IT developers will attest
twice a year to compliance with the
Conditions and Maintenance of
Certification requirements (except for
the EHR reporting criteria submission
requirement, which would be metrics
reporting requirements separately
implemented through a future
rulemaking). We believe requiring
attestations every six months under
§ 170.406(b) will properly balance the
need to support appropriate
enforcement with our desire to limit the
burden on health IT developers. In this
regard, we have also identified methods
to make the process as simple and
efficient for health IT developers as
possible (e.g., 30-day attestation
window, web-based form submissions,
and attestation alert reminders).
We have also finalized that
attestations will be submitted to ONC–
ACBs. We have finalized a new PoPC in
§ 170.523(q) that an ONC–ACB must
review these submissions for
completion and share the health IT
developers’ attestations with us. We
would then make the attestations
publicly available through the CHPL.
EHR Reporting Criteria Submission
The Cures Act specifies that health IT
developers be required, as Condition
and Maintenance of Certification
requirements under the Program, to
submit reporting criteria on certified
health IT in accordance with the EHR
Reporting Program established under
section 3009A of the PHSA, as added by
the Cures Act. We have not yet
established an EHR Reporting Program.
Once we establish such program, we
will undertake rulemaking to propose
and implement the associated Condition
and Maintenance of Certification
requirements for health IT developers.
Enforcement
Section 4002(a) of the Cures Act adds
(in section 3001(c)(5)(D) of the PHSA)
Program requirements aimed at
addressing health IT developers’ actions
and business practices through the
Conditions and Maintenance of
Certification requirements, which
expands the current focus of the
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
Program requirements beyond the
certified health IT itself. Equally
important, Cures Act section 4002(a)
also provides that the Secretary may
encourage compliance with the
Conditions and Maintenance of
Certification requirements and take
action to discourage noncompliance.
We, therefore, have finalized our
proposed enforcement framework for
the Conditions and Maintenance of
Certification requirements in §§ 170.580
and 170.581 to encourage consistent
compliance with the requirements.
More specifically, we have finalized our
proposed corrective action process in
§ 170.580 for ONC to review potential or
known instances where a Condition or
Maintenance of Certification
requirement under the Program has not
been met or is not being met by a health
IT developer. We have also finalized in
§§ 170.580 and 170.581 our proposal to
utilize, with minor modifications, the
processes previously established for
ONC direct review of certified health IT
in the enforcement of the Conditions
and Maintenance of Certification
requirements. Where we identify
noncompliance, our first priority will be
to work with the health IT developer to
remedy the matter through a corrective
action process. However, under certain
circumstances, ONC may ban a health
IT developer from the Program and/or
terminate the certification of one or
more of its Health IT Modules.
6. Information Blocking
Section 4004 of the Cures Act added
section 3022 of the PHSA (42 U.S.C.
300jj–52, ‘‘the information blocking
provision’’). Section 3022(a)(1) of the
PHSA defines practices that constitute
information blocking when engaged in
by a health care provider, or a health
information technology developer,
exchange, or network. Section
3022(a)(3) authorizes the Secretary to
identify, through notice and comment
rulemaking, reasonable and necessary
activities that do not constitute
information blocking for purposes of the
definition set forth in section 3022(a)(1).
We identify eight reasonable and
necessary activities as exceptions to the
information blocking definition, each of
which does not constitute information
blocking for purposes of section
3022(a)(1) of the PHSA. The exceptions
apply to certain activities that are likely
to interfere with, prevent, or materially
discourage the access, exchange, or use
of EHI, but that would be reasonable
and necessary if certain conditions are
met.
In developing and finalizing the final
exceptions, we were guided by three
overarching policy considerations. First,
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
the exceptions are limited to certain
activities that we believe are important
to the successful functioning of the U.S.
health care system, including promoting
public confidence in health IT
infrastructure by supporting the privacy
and security of EHI, and protecting
patient safety and promoting
competition and innovation in health IT
and its use to provide health care
services to consumers. Second, each
exception is intended to address a
significant risk that regulated
individuals and entities (i.e., health care
providers, health IT developers of
certified health IT, health information
networks, and health information
exchanges) will not engage in these
reasonable and necessary activities
because of potential uncertainty
regarding whether they would be
considered information blocking. Third,
and last, each exception is intended to
be tailored, through appropriate
conditions, so that it is limited to the
reasonable and necessary activities that
it is designed to exempt.
The eight exceptions are set forth in
section VIII.D of this final rule. The five
exceptions finalized in §§ 171.201–205,
and discussed in section VIII.D.1.a–e of
this final rule, involve not fulfilling
requests to access, exchange, or use EHI.
These exceptions are intended to
prevent harm and protect patient safety,
promote the privacy and security of EHI,
excuse an actor from responding to
requests that are infeasible, and address
activities that are reasonable and
necessary to promote the performance of
health IT. The three exceptions finalized
in §§ 171.301–303, and discussed in
section VIII.D.2.a–c of this final rule,
involve procedures for fulfilling
requests to access, exchange, or use EHI.
These exceptions describe when an
actor’s practice of limiting the content of
its response to or the manner in which
it responds to a request to access,
exchange, or use EHI will not be
considered information blocking; when
an actor’s practice of charging fees,
including fees that result in a reasonable
profit margin, for accessing, exchanging,
or using EHI will not be considered
information blocking; and when an
actor’s practice to license
interoperability elements for EHI to be
accessed, exchanged, or used will not be
considered information blocking.
An actor will not be subject to
enforcement actions under the
information blocking provision for civil
monetary penalties (CMP) or
appropriate disincentives if the actor’s
practice satisfies at least one exception.
In order to satisfy an exception, each
relevant practice by an actor at all
relevant times must meet all of the
PO 00000
Frm 00009
Fmt 4701
Sfmt 4700
25649
applicable conditions of the exception.
However, failure to meet the conditions
of an exception does not automatically
mean a practice constitutes information
blocking. A practice failing to meet all
conditions of an exception only means
that the practice would not have
guaranteed protection from CMPs or
appropriate disincentives. The practice
would instead be evaluated on a caseby-case basis to assess the specific facts
and circumstances (e.g., whether the
practice would be considered to rise to
the level of an interference, and whether
the actor acted with the requisite intent)
to determine whether information
blocking has occurred.
In addition to establishing the
exceptions, we have defined and
interpreted terms that are present in
section 3022 of the PHSA (such as the
types of individuals and entities
covered by the information blocking
provision). We have also finalized new
terms and definitions that are necessary
to implement the information blocking
provision. We have codified the
information blocking section in a new
part of title 45 of the Code of Federal
Regulations, part 171.
C. Costs and Benefits
Executive Orders 12866 on Regulatory
Planning and Review (September 30,
1993), and 13563 on Improving
Regulation and Regulatory Review
(February 2, 2011), direct agencies to
assess all costs and benefits of available
regulatory alternatives and, if regulation
is necessary, to select regulatory
approaches that maximize net benefits
(including potential economic,
environmental, public health and safety
effects, distributive impacts, and
equity). A regulatory impact analysis
(RIA) must be prepared for major rules
with economically significant effects
($100 million or more in any one year).
OMB has determined that this final rule
is an economically significant rule as
the costs associated with this final rule
could be greater than $100 million per
year. Accordingly, we have prepared an
RIA that to the best of our ability
presents the costs and benefits of this
final rule.
We have estimated the potential
monetary costs and benefits of this final
rule for health IT developers, health
care providers, patients, ONC–ACBs,
ONC–ATLs, and the Federal
Government (i.e., ONC), and have
broken those costs and benefits out into
the following categories: (1)
Deregulatory actions (no associated
costs); (2) updates to the 2015 Edition
health IT certification criteria; (3)
Conditions and Maintenance of
Certification requirements for a health
E:\FR\FM\01MYR3.SGM
01MYR3
25650
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
IT developer; (4) oversight for the
Conditions and Maintenance of
Certification requirements; and (5)
information blocking.
We note that we have rounded all
estimates to the nearest dollar and all
estimates are expressed in 2017 dollars
as it is the most recent data available to
address all cost and benefit estimates
consistently. We also note that we did
not have adequate data to quantify some
of the costs and benefits within this
RIA. In those situations, we have
described the non-quantified costs and
benefits of our provisions; however,
such costs and benefits have not been
accounted for in the monetary cost and
benefit totals below.
We estimated that the total cost for
this final rule for the first year after it
is finalized (including one-time costs),
based on the cost estimates outlined
above and throughout this RIA, would,
on average, range from $953 million to
$2.6 billion with an average annual cost
of $1.8 billion. We estimate that the
total perpetual cost for this final rule
(starting in year two), based on the cost
estimates outlined above, would, on
average, range from $366 million to $1.3
billion with an average annual cost of
$840 million.
We estimated the total annual benefit
for this final rule, based on the benefit
estimates outlined above, would range
from $1.2 billion to $5.0 billion with
primary estimated annual benefit of $3.1
billion.
II. Background
A. Statutory Basis
The Health Information Technology
for Economic and Clinical Health
(HITECH) Act, Title XIII of Division A
and Title IV of Division B of the
American Recovery and Reinvestment
Act of 2009 (the Recovery Act) (Pub. L.
111–5), was enacted on February 17,
2009. The HITECH Act amended the
Public Health Service Act (PHSA) and
created ‘‘Title XXX—Health Information
Technology and Quality’’ (Title XXX) to
improve health care quality, safety, and
efficiency through the promotion of
health IT and electronic health
information (EHI) exchange.
The 21st Century Cures Act
(hereinafter the ‘‘Cures Act’’) was
enacted on December 13, 2016, to
accelerate the discovery, development,
and delivery of 21st century cures, and
for other purposes. The Cures Act, Pub.
L. 114–255, included Title IV—Delivery,
which amended portions of the HITECH
Act (Title XIII of Division A of Pub. L.
111–5) by modifying or adding certain
provisions to the PHSA relating to
health IT.
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
1. Standards, Implementation
Specifications, and Certification Criteria
The HITECH Act established two new
Federal advisory committees, the HIT
Policy Committee (HITPC) and the HIT
Standards Committee (HITSC). Each
was responsible for advising the
National Coordinator for Health
Information Technology (National
Coordinator) on different aspects of
standards, implementation
specifications, and certification criteria.
Section 3002 of the PHSA, as
amended by section 4003(e) of the Cures
Act, replaced the HITPC and HITSC
with one committee, the Health
Information Technology Advisory
Committee (HIT Advisory Committee or
HITAC). After that change, section
3002(a) of the PHSA established that the
HITAC would advise and recommend to
the National Coordinator on different
aspects of standards, implementation
specifications, and certification criteria,
relating to the implementation of a
health IT infrastructure, nationally and
locally, that advances the electronic
access, exchange, and use of health
information. Further described in
section 3002(b)(1)(A) of the PHSA, this
included providing the National
Coordinator with recommendations on a
policy framework to advance
interoperable health IT infrastructure,
updating recommendations to the policy
framework, and making new
recommendations, as appropriate.
Section 3002(b)(2)(A) identified that in
general, the HITAC would recommend
to the National Coordinator, for
purposes of adoption under section
3004 of the PHSA, standards,
implementation specifications, and
certification criteria and an order of
priority for the development,
harmonization, and recognition of such
standards, specifications, and
certification criteria. Similar to the
process previously required of the
former HITPC and HITSC, the HITAC
will develop a schedule for the
assessment of policy recommendations
for the Secretary to publish in the
Federal Register.
Section 3004 of the PHSA identifies a
process for the adoption of health IT
standards, implementation
specifications, and certification criteria
and authorizes the Secretary to adopt
such standards, implementation
specifications, and certification criteria.
As specified in section 3004(a)(1), the
Secretary is required, in consultation
with representatives of other relevant
Federal agencies, to jointly review
standards, implementation
specifications, and certification criteria
endorsed by the National Coordinator
PO 00000
Frm 00010
Fmt 4701
Sfmt 4700
under section 3001(c), and subsequently
determine whether to propose the
adoption of any grouping of such
standards, implementation
specifications, or certification criteria.
The Secretary is required to publish all
determinations in the Federal Register.
Section 3004(b)(3) of the PHSA,
which is titled Subsequent Standards
Activity, provides that the Secretary
shall adopt additional standards,
implementation specifications, and
certification criteria as necessary and
consistent with the schedule published
by the HITAC. We consider this
provision in the broader context of the
HITECH Act and Cures Act to continue
to grant the Secretary the authority and
discretion to adopt standards,
implementation specifications, and
certification criteria that have been
recommended by the HITAC and
endorsed by the National Coordinator,
as well as other appropriate and
necessary health IT standards,
implementation specifications, and
certification criteria.
2. Health IT Certification Program(s)
Under the HITECH Act, section
3001(c)(5) of the PHSA provides the
National Coordinator with the authority
to establish a program or programs for
the voluntary certification of health IT.
Specifically, section 3001(c)(5)(A)
specifies that the National Coordinator,
in consultation with the Director of the
National Institute of Standards and
Technology (NIST), shall keep or
recognize a program or programs for the
voluntary certification of health IT that
is in compliance with applicable
certification criteria adopted under this
subtitle (i.e., certification criteria
adopted by the Secretary under section
3004 of the PHSA). The certification
program(s) must also include, as
appropriate, testing of the technology in
accordance with section 13201(b) of the
HITECH Act. Overall, section 13201(b)
of the HITECH Act requires that with
respect to the development of standards
and implementation specifications, the
Director of National Institute of
Standards and Technology (NIST) shall
support the establishment of a
conformance testing infrastructure,
including the development of technical
test beds. The same HITECH Act
provision (section 13201(b)) also
indicates that the development of this
conformance testing infrastructure may
include a program to accredit
independent, non-Federal laboratories
to perform testing.
Section 4001 of the Cures Act
amended section 3001(c)(5) of the PHSA
to instruct the National Coordinator to
encourage, keep, or recognize, through
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
existing authorities, the voluntary
certification of health IT under the
program for use in medical specialties
and sites of service for which no such
technology is available or where more
technological advancement or
integration is needed. Section
3001(c)(5)(C)(iii) in particular identifies
that the Secretary, in consultation with
relevant stakeholders, shall make
recommendations for the voluntary
certification of health IT for use by
pediatric health providers to support the
care of children, as well as adopt
certification criteria under section 3004
to support the voluntary certification of
health IT for use by pediatric health
providers. The Cures Act further
amended section 3001(c)(5) of the PHSA
by adding section 3001(c)(5)(D), which
provides the Secretary with the
authority to require, through notice and
comment rulemaking, Conditions and
Maintenance of Certification
requirements for the Program.
B. Regulatory History
The Secretary issued an interim final
rule with request for comments on
January 13, 2010, (75 FR 2014), which
adopted an initial set of standards,
implementation specifications, and
certification criteria. On March 10,
2010, we published a proposed rule (75
FR 11328) that proposed both a
temporary and permanent certification
program for the purposes of testing and
certifying health IT. A final rule
establishing the temporary certification
program was published on June 24,
2010, (75 FR 36158), and a final rule
establishing the permanent certification
program was published on January 7,
2011, (76 FR 1262). We have issued
multiple rulemakings since these initial
rulemakings to update standards,
implementation specifications,
certification criteria, and the
certification program, a history of which
can be found in the October 16, 2015
final rule titled, ‘‘2015 Edition Health
Information (Health IT) Certification
Criteria, 2015 Edition Base Electronic
Health Record (EHR) Definition, and
ONC Health IT Certification Program
Modifications’’ (80 FR 62602) (‘‘2015
Edition final rule’’). A final rule
corrections and clarifications notice was
published for the 2015 Edition final rule
on December 11, 2015, (80 FR 76868),
to correct preamble and regulatory text
errors and clarify requirements of the
Common Clinical Data Set (CCDS), the
2015 Edition privacy and security
certification framework, and the
mandatory disclosures for health IT
developers.
The 2015 Edition final rule
established a new edition of
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
certification criteria (‘‘2015 Edition
health IT certification criteria’’ or ‘‘2015
Edition’’) and a new 2015 Edition Base
EHR definition. The 2015 Edition
established the capabilities and
specified the related standards and
implementation specifications that
CEHRT would need to include to, at a
minimum, support the achievement of
‘‘meaningful use’’ by eligible clinicians,
eligible hospitals, and critical access
hospitals under the Medicare and
Medicaid EHR Incentive Programs (EHR
Incentive Programs) (now referred to as
the Promoting Interoperability (PI)
Programs) 5 when the 2015 Edition is
required for use under these and other
programs referencing the CEHRT
definition. The 2015 Edition final rule
also made changes to the ONC HIT
Certification Program. The final rule
adopted a proposal to change the
Program’s name to the ‘‘ONC Health IT
Certification Program’’ from the ONC
HIT Certification Program, modified the
Program to make it more accessible to
other types of health IT beyond EHR
technology and for health IT that
supports care and practice settings
beyond the ambulatory and inpatient
settings, and adopted new and revised
PoPC for ONC–ACBs.
After issuing a proposed rule on
March 2, 2016, (81 FR 11056), we
published a final rule titled, ‘‘ONC
Health IT Certification Program:
Enhanced Oversight and
Accountability’’ (81 FR 72404) (‘‘EOA
final rule’’) on October 19, 2016. The
EOA final rule finalized modifications
and new requirements under the
Program, including provisions related to
our role in the Program. The final rule
created a regulatory framework for our
direct review of health IT certified
under the Program, including, when
necessary, requiring the correction of
non-conformities found in health IT
certified under the Program and
suspending and terminating
certifications issued to Complete EHRs
and Health IT Modules. The final rule
also sets forth processes for us to
authorize and oversee accredited testing
laboratories under the Program. In
addition, it includes provisions for
expanded public availability of certified
health IT surveillance results.
On March 4, 2019, the Secretary
published a proposed rule titled, ‘‘21st
Century Cures Act: Interoperability,
Information Blocking, and the ONC
Health IT Certification Program’’ (84 FR
7424) (‘‘Proposed Rule’’). The Proposed
Rule proposed to implement certain
provisions of the Cures Act that would
5 https://www.federalregister.gov/d/2018-16766/
p-4.
PO 00000
Frm 00011
Fmt 4701
Sfmt 4700
25651
advance interoperability and support
the access, exchange, and use of
electronic health information and is the
subject of this final rule.
C. General Comments on the Proposed
Rule
Comments. Numerous commenters
expressed support for the overall
direction of the Proposed Rule.
Numerous commenters also expressed
support for the policy goals expressed in
the Proposed Rule, including: Reduced
health care costs; improved public
health surveillance; improved care
coordination, continuity of care, and
shared access of data between patient
and provider; improved quality and
patient safety; increased cost and
quality transparency; greater
efficiencies; and better health outcomes
for patients. A few commenters also
commended our interest in ways to use
health IT to address opioid use
disorders. Many commenters also
appreciated detailed context for the
provisions in the Proposed Rule. Many
commenters stated that the proposed
provisions and standards will provide
opportunities for innovation as well as
increase the ability of health care
providers to connect new tools and
services to their systems.
A number of commenters commended
our responsiveness to the health care
community, including patients, in
drafting the rule. A few commenters
suggested that the existing language in
the rule should remain mostly
unchanged as ONC drafts the final rule.
Many commenters commended us for
collaborating with public- and privatesector partners in developing the
Proposed Rule. Specifically, some
commenters expressed appreciation for
our work with CMS and their
companion Interoperability and Patient
Access Proposed Rule. A number of
commenters shared that they look
forward to working with us and CMS as
the health care industry progresses
toward an interoperable system, making
it easier for small independent practices
and providers to move to value-based
care.
Response. We appreciate the support
expressed by many commenters. This
final rule maintains the direction of the
Proposed Rule, and we too look forward
to ongoing collaboration with public
and private sector partners as we
implement the provisions of this final
rule.
Comments. A few commenters
recommended that the final rule include
additional resources to assist with
readability and ease of understanding.
Response. We thank commenters for
their feedback. As we did with the
E:\FR\FM\01MYR3.SGM
01MYR3
25652
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
Proposed Rule, we are providing
resources such as infographics, fact
sheets, webinars, and other forms of
educational materials and outreach.
Many of the education materials can be
found on www.HealthIT.gov/curesrule.
Comments. Several commenters
expressed the opinion that the use of
EHRs—and health IT, more generally—
has negatively affected the quality of
health care delivery and that the
Proposed Rule will exacerbate this
issue. Some of these commenters stated
that the need to input information into
EHRs during office visits has resulted in
clinicians spending less time
communicating with patients, and some
noted the impact of data entry on
clinician burnout. A few commenters
made a similar point that use of EHRs
has reduced productivity and, as a
result, increased health care spending.
Response. We thank commenters for
their feedback. We are aware of the
challenges stakeholders have
experienced in using EHRs and health
IT more broadly. In the Cures Act,
Congress identified the importance of
easing regulatory and administrative
burdens associated with the use of EHRs
and health IT. Specifically, through
section 4001(a) of the Cures Act,
Congress directed the Department of
Health and Human Services to establish
a goal, develop a strategy, and provide
recommendations to reduce EHR-related
burdens that affect care delivery.
To that end, on November 28, 2018,
we, in partnership with CMS, released
a draft Strategy on Reducing Regulatory
and Administrative Burden Relating to
the Use of Health IT and EHRs 6 for
public comment. This draft strategy
reflects input HHS received through
several wide-reaching listening sessions,
written input, and stakeholder outreach.
We released the final report on February
21, 2020. Reflective of public comment,
the final Strategy on Reducing
Regulatory and Administrative Burdens
Relating to the Use of Health IT and
EHRs 7 targets burdens tied to regulatory
and administrative requirements that
HHS can directly impact through the
rulemaking process. The report’s
strategies, recommendations, and policy
shifts aim to give clinicians more time
to focus on what matters—caring for
their patients. Based on stakeholder
input, the final strategy outlines three
overarching goals designed to reduce
clinician burden: (1) Reduce the effort
6 https://www.healthit.gov/sites/default/files/
page/2018–11/Draft%20Strategy
%20on%20Reducing%20Regulatory
%20and%20Administrative
%20Burden%20Relating.pdf.
7 https://www.healthit.gov/sites/default/files/
page/2020-02/BurdenReport_0.pdf.
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
and time required to record health
information in EHRs for clinicians; (2)
reduce the effort and time required to
meet regulatory reporting requirements
for clinicians, hospitals, and health care
organizations; and (3) improve the
functionality and intuitiveness (ease of
use) of EHRs.
In addition to the final strategy
mentioned above, we refer readers to
section III of this final rule, Deregulatory
Actions for Previous Rulemakings, for
more information on how we have
worked to improve the Program with a
focus on ways to reduce burden, offer
flexibility to both health IT developers
and providers, and support innovation.
Comments. We received several
comments from a variety of stakeholders
to extend the 60-day comment period
for the Proposed Rule, stating that due
to the depth and complexity of the
policies proposed, it would be critical
for the public to have extended time to
provide sufficient and thoughtful
comments to advance shared goals and
shape the interoperability landscape.
Response. In response to stakeholder
inquiries to extend the 60-day public
comment period and based on the stated
goals of the Proposed Rule to improve
interoperability and patient access to
health information for the purposes of
promoting competition and better care,
we extended the comment period for the
Proposed Rule for an additional 30 days
which ended on June 3, 2019.
Comments. A number of commenters
recommended delaying the final rule by
issuing an Interim Final Rule (IFR) with
comment. Commenters noted that many
organizations are providing comments
that include new information blocking
exceptions and that we will not be able
to incorporate such suggestions into the
final rule without an opportunity for
comment. Several commenters stated
that an IFR was appropriate due to the
significance and breadth of the
Proposed Rule, as well the magnitude of
changes proposed and that an IFR
would allow for additional opportunity
for stakeholder comment.
Several commenters recommended
that ONC consider issuing a
Supplemental Notice of Proposed
Rulemaking (SNPRM) to seek additional
comments on the information blocking
provisions. Some of these commenters
stated that new definitions and terms
introduced in the Proposed Rule need
additional clarification and an SNPRM
would enable ONC to propose such
clarifications and seek feedback on
modified proposals.
Response. We recognize the
importance of allowing enough time for
comment given the breadth of the
Proposed Rule and acknowledge the
PO 00000
Frm 00012
Fmt 4701
Sfmt 4700
comments requesting the issuance of an
IFR or a SNPRM. We believe that the
advance posting of the Proposed Rule
on the ONC website, the initial 60-day
comment period, and the 30-day
extension, provided adequate time for
comment, especially given the large
volume of comments received.
As discussed in the information
blocking section of the Proposed Rule
(84 FR 7508), after hearing from
stakeholders and based on our findings
from our 2015 Report to Congress,8 we
concluded that information blocking is
a serious problem and recommended
that Congress prohibit information
blocking and provide penalties and
enforcement mechanisms to deter these
harmful practices. Congress responded
by enacting the Cures Act on December
13, 2016, with many provisions
specifying a need for swift
implementation. It has been three years
since the Cures Act was enacted and
information blocking remains a serious
concern. This final rule includes
provisions that will address information
blocking and cannot be further delayed.
We have taken multiple actions to
address some expressed concerns
regarding the timing of the Conditions
and Maintenance of Certification
requirements as well as the
comprehensiveness of the information
blocking proposals. These actions
include some burden reduction by
removing certain certification criteria,
narrowing the scope of certain
certification criteria, and increasing the
compliance timeline with criteria. For
purposes of information blocking, we
have established compliance date for 45
CFR part 171 that is six months, rather
than sixty days, after the date this final
rule publishes in the Federal Register.
We have also focused the scope of EHI,
and provided new and revised
exceptions that are actionable and
reduce burden. One of these new
exceptions (see § 171.301(a) and section
VIII.D.2.a of this final rule) includes a
provision by which, until 24 months
after this rule is published in the
Federal Register, an actor’s conduct can
satisfy the conditions of the Content and
Manner Exception (§ 171.301) if they
provide at least the content that is
within the USCDI in response to a
request for access, exchange, or use of
EHI. Because of these reasons and those
noted above, we decline to issue an IFR
or SNPRM. Rather, we have issued this
final rule to support interoperability,
empower patient control of their health
care, and instill competition in health
care markets.
8 https://www.healthit.gov/sites/default/files/
reports/info_blocking_040915.pdf.
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
III. Deregulatory Actions for Previous
Rulemakings
A. Background
1. History of Burden Reduction and
Regulatory Flexibility
Since the inception of the ONC Health
IT Certification Program (Program), we
have aimed to implement and
administer the Program in the least
burdensome manner that supports our
policy goals. Through the years, we
have worked to improve the Program
with a focus on ways to reduce burden,
offer flexibility, and support innovation.
This approach has been consistent with
the principles of Executive Order (E.O.)
13563 on Improving Regulation and
Regulatory Review (February 2, 2011),
which instructs agencies to periodically
review its existing significant
regulations and ‘‘determine whether any
such regulations should be modified,
streamlined, expanded, or repealed so
as to make the agency’s regulatory
program more effective or less
burdensome in achieving the regulatory
objectives.’’ To that end, we have
historically taken measures where
feasible and appropriate to reduce
burden within the Program and make
the Program more effective, flexible, and
streamlined.
For example, in the 2014 Edition final
rule (77 FR 54164, Sept. 4, 2012), we
revised the certified electronic health
record technology (CEHRT) definition to
provide flexibility and create regulatory
efficiencies by narrowing required
functionality to a core set of capabilities
(i.e., the Base EHR definition) plus the
additional capabilities each eligible
clinician, eligible hospital, and critical
access hospital needed to successfully
achieve the applicable objective and
measures under the EHR Incentive
Programs (now referred to as the
Promoting Interoperability (PI)
Programs). ONC has also supported
more efficient testing and certification
methods and reduced regulatory burden
through the adoption of a gap
certification policy. As explained in the
2014 Edition final rule (77 FR 54254)
and the 2015 Edition final rule (80 FR
62681), as modified by the 2015 final
rule with corrections and clarifications
at 80 FR 76868, where applicable, gap
certification allows for the use of a
previously certified health IT product’s
test results for certification criteria
identified as unchanged. Developers
have been able to use gap certification
for more efficient certification of their
health IT when updating from the 2011
Edition to the 2014 Edition and from the
2014 Edition to the 2015 Edition.
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
ONC introduced further means to
reduce regulatory burden, increase
regulatory flexibility, and promote
innovation in the 2014 Edition Release
2 final rule (79 FR 54430) published on
September 11, 2014. The 2014 Edition
Release 2 final rule established a set of
optional 2014 Edition certification
criteria that provided flexibility and
alternative certification pathways for
health IT developers and providers
based on their specific circumstances.
The 2014 Edition Release 2 final rule
also simplified the Program by
discontinuing the use of the ‘‘Complete
EHR’’ certification concept beginning
with the 2015 Edition (79 FR 54443).
In the 2015 Edition final rule, we did
not ‘‘carry forward’’ certain 2014
Edition certification criteria into the
2015 Edition, such as the ‘‘image
results,’’ ‘‘patient list creation,’’ and
‘‘electronic medication administration
record’’ criteria. We determined that
these criteria did not advance
functionality or support interoperability
(80 FR 62682 through 62684). We also
did not require all health IT to be
certified to the ‘‘meaningful use
measurement’’ certification criteria for
‘‘automated numerator recording’’ and
‘‘automated measure calculation’’ (80
FR 62604 and 62605), which the 2014
Edition had previously required. Based
on stakeholder feedback and Program
administration observations, we also
permitted testing efficiencies for the
2015 Edition ‘‘automated numerator
recording’’ and ‘‘automated measure
calculation’’ criteria by removing the
live demonstration requirement of
recording data and generating reports
(80 FR 62703). Health IT developers
may now self-test their Health IT
Modules’ capabilities and submit the
resulting reports to the ONC-Authorized
Testing Laboratory (ONC–ATL) to verify
compliance with the ‘‘meaningful use
measurement’’ criterion.9 In order to
further reduce burden for health IT
developers, in our 2015 Edition final
rule, we adopted a more straightforward
approach to privacy and security
certification requirements and clarified
which requirements apply to each
criterion within the regulatory
functional areas (80 FR 62605).
2. Executive Orders 13771 and 13777
On January 30, 2017, the President
issued E.O. 13771 on Reducing
Regulation and Controlling Regulatory
Costs, which requires agencies to
identify deregulatory actions. This order
9 https://www.healthit.gov/test-method/
automated-numerator-recording and https://
www.healthit.gov/test-method/automated-measurecalculation.
PO 00000
Frm 00013
Fmt 4701
Sfmt 4700
25653
was followed by E.O. 13777, titled
‘‘Enforcing the Regulatory Reform
Agenda’’ (February 24, 2017). E.O.
13777 provides further direction on
implementing regulatory reform by
identifying a process by which agencies
must review and evaluate existing
regulations and make recommendations
for repeal or simplification.
In order to implement these
regulatory reform initiatives and
policies, ONC reviewed and evaluated
existing regulations in the year leading
to the issuance of the 21st Century
Cures Act: Interoperability, Information
Blocking, and the ONC Health IT
Certification Program Proposed Rule
(Proposed Rule) (84 FR 7424 through
7610). During our review, we sought to
identify ways to further reduce
administrative burden, to implement
deregulatory actions through guidance,
and to put forth deregulatory actions in
this final rule that will reduce burden
for health IT developer, providers, and
other stakeholders.
Prior to publishing the Proposed Rule,
on August 21, 2017, ONC issued Relied
Upon Software Program Guidance.10
Health IT developers are permitted to
use ‘‘relied upon software’’ 11 to
demonstrate compliance with
certification criteria adopted at 45 CFR
part 170, subpart C. Historically, in
cases where a Health IT Module is
paired with multiple ‘‘relied upon
software’’ products for the same
capability, health IT developers were
required to demonstrate compliance for
the same certification criterion with
each of those ‘‘relied upon software’’
products in order for the products to be
listed on the Certified Health IT Product
List (CHPL). With the guidance issued
on August 21, 2017, health IT
developers could demonstrate
compliance with only one ‘‘relied upon
software’’ product for a criterion/
capability. Once the health IT developer
demonstrates compliance with a
minimum of one ‘‘relied upon software’’
product, the developer can have
multiple, additional ‘‘relied upon
software’’ products for the same
criterion/capability listed on the CHPL
(https://chpl.healthit.gov/). This
approach reduces burden for health IT
developers, ONC–ATLs, and ONCAuthorized Certification Bodies (ONC–
ACBs).
On September 21, 2017, ONC
announced a deregulatory action to
reduce the overall burden for testing
10 https://www.healthit.gov/sites/default/files/
relieduponsoftwareguidance.pdf.
11 ‘‘Relied upon’’ software is defined in the 2011
final rule establishing the permanent certification
program (76 FR 1276).
E:\FR\FM\01MYR3.SGM
01MYR3
25654
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
health IT to the 2015 Edition
certification criteria.12 ONC reviewed
the 2015 Edition test procedures and
changed 30 of the 2015 Edition test
procedures from requiring ONC–ATL
evaluation to requiring only attestation
by health IT developers that their
product has capabilities conformant
with those specified in the associated
certification criterion/criteria.13 This
deregulatory action reduced burden and
costs program-wide, while still
maintaining the Program’s high level of
integrity and assurances. The total
testing cost savings for health IT
developers have been estimated
between $8.34 and $9.26 million. ONC–
ATLs also benefitted by having more
time and resources to focus on toolbased testing (for interoperabilityoriented criteria) and being responsive
to any retesting requirements that may
arise from ONC–ACB surveillance
activities. Health care providers and
other users of certified health IT did not
lose confidence in the Program because
health IT developers were still required
to meet certification criteria
requirements and maintain their
products’ conformance to the full scope
of the associated criteria, including
when implemented in the field and in
production use. ONC and ONC–ACBs
continue to conduct surveillance
activities and respond to end-user
complaints.
B. Deregulatory Actions
In the Proposed Rule, we proposed
(84 FR 7434 through 7439) and sought
comment on six specific deregulatory
actions. Having considered the
comments received on the proposals,
which are summarized below, we have
decided to finalize five of the six
proposed deregulatory actions and not
to finalize the proposal to recognize the
FDA Software Precertification Pilot
Program. We refer readers to section XIII
(Regulatory Impact Analysis) of this
final rule for a discussion of the
estimated cost savings from these
finalized deregulatory actions.
1. Removal of Randomized Surveillance
Requirements
ONC–ACBs are required under
§ 170.556 to conduct surveillance of
certified health IT to ensure that health
IT continues to conform with and
function as required by the full scope of
the certification requirements.
Surveillance is categorized as either
12 https://www.healthit.gov/buzz-blog/healthitcertification/certification-program-updates-supportefficiency-reduce-burden/.
13 https://www.healthit.gov/sites/default/files/
policy/selfdeclarationapproachprogramguidance1704.pdf.
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
reactive surveillance (for example,
complaint-based surveillance) or
randomized surveillance. Previously
finalized regulations in § 170.556(c)(2)
required ONC–ACBs to proactively
surveil two percent of the certificates
they issue annually. As discussed in the
Proposed Rule, in the time since the two
percent randomized surveillance
requirement was finalized, stakeholders
had expressed concern that the benefits
of in-the-field, randomized surveillance
may not outweigh the time commitment
required by providers, particularly if no
non-conformities are found (84 FR
7434). We noted in the Proposed Rule
that, in general, health care providers
had expressed that reactive surveillance
(e.g., surveillance based on user
complaints) is a more logical and
economical approach to surveillance.
Consistent with our September 21, 2017,
exercise of enforcement discretion on
implementation of randomized
surveillance by ONC–ACBs,14 we
proposed in the Proposed Rule to
eliminate certain regulatory randomized
surveillance requirements (84 FR 7434).
In the Proposed Rule, we specifically
proposed to revise § 170.556(c) by
changing the requirement that ONC–
ACBs must conduct in-the-field,
randomized surveillance to specify that
ONC–ACBs may conduct in-the-field,
randomized surveillance (84 FR 7434).
We further proposed to remove
§ 170.556(c)(2), which specified that
ONC–ACBs must conduct randomized
surveillance for a minimum of two
percent of certified health IT products
per year. We also proposed to remove
the requirements in § 170.556(c)(5)
regarding the exclusion and exhaustion
of selected locations for randomized
surveillance. Additionally, we proposed
to remove the requirements in
§ 170.556(c)(6) regarding the
consecutive selection of certified health
IT for randomized surveillance. As
noted in the Proposed Rule, without
these regulatory requirements, ONC–
ACBs would still be required to perform
reactive surveillance, and would be
permitted to conduct randomized
surveillance of their own accord, using
the methodology identified by ONC
with respect to scope (§ 170.556(c)(1)),
selection method (§ 170.556(c)(3)), and
the number and types of locations for
in-the-field surveillance
(§ 170.556(c)(4)).
Comments. A substantial number of
commenters supported removing the
requirements for randomized
surveillance. Many commenters
14 https://www.healthit.gov/sites/default/files/
ONC_Enforcement_Discretion_Randomized_
Surveillance_8-30-17.pdf.
PO 00000
Frm 00014
Fmt 4701
Sfmt 4700
supported the proposal to revise
§ 170.556(c) by changing the
requirement that ONC–ACBs must
conduct in-the-field, randomized
surveillance to specify that ONC–ACBs
may conduct in-the-field, randomized
surveillance, including the removal of
§ 170.556(c)(2). Commenters noted that
since ONC–ACBs would still be
required to perform reactive
surveillance, and would be permitted to
conduct randomized surveillance of
their own accord, the regulatory
requirement to conduct randomized
surveillance on a specified portion of
certified health IT would be
unnecessary. Commenters supporting
this proposal praised the deregulatory
action as allowing more flexibility for
ONC–ACBs. A number of commenters
were generally supportive of the
proposal and applied the caveat that if
an ONC–ACB did voluntarily conduct
randomized surveillance, they should
not do so repeatedly on the same Health
IT Module. These commenters indicated
a preference that the requirements in
§ 170.556(c)(6) regarding the
consecutive selection of certified health
IT for randomized surveillance remain.
Several commenters were supportive of
removing randomized surveillance
requirements and indicated they found
this appropriate in view of the
Conditions and Maintenance of
Certification enhancements to the
Program as directed by the Cures Act,
while others noted that reactive
surveillance may be more effective in
surfacing and correcting nonconformities. A number of commenters
did not support the proposal, with many
expressing concerns that this could be
or be perceived to be a reduction in
oversight of developers or could reduce
providers’ confidence that certified
Health IT Modules would meet their
needs. While a majority of commenters
speaking to surveillance burdens on
health care providers indicated the
removal of mandatory randomized
surveillance would, on the whole,
reduce burden on health care providers,
several expressed concerns about
whether providers can discern when a
product does not meet certification
requirements or know where and how to
report their concerns about their
certified health IT’s conformance to
Program requirements. A few
commenters suggested that the
increased emphasis on reactive
surveillance (particularly in some
commenters’ view because ONC is
removing randomized surveillance
requirements in advance of the full
implementation of the EHR Reporting
Program called for by section 4002 of
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
the Cures Act) indicates a need for
additional guidance to help providers
and particularly clinicians understand
how to recognize and report potential
non-conformities in the certified health
IT they use.
Response. We thank commenters for
their input and reiterate our continued
commitment to sustaining the integrity
of our Program, including ensuring
robust oversight of certified health IT
products while avoiding unnecessary
burdens on all program stakeholders.
Having considered all comments
received, in context of the totality of
updates we proposed to the Program, we
have concluded that the removal of the
regulatory requirements for ONC–ACBs
to conduct randomized surveillance is
consistent with enhancing Program
efficiency while maintaining its
efficacy. We leave ONC–ACBs the
option to conduct randomized
surveillance as they determine
necessary or appropriate to support
continued conformance to Program
requirements by Health IT Modules they
have certified. We also note that ONC–
ACBs that choose to conduct
randomized surveillance will still be
required to use the methodology
identified by ONC with respect to scope
(§ 170.556(c)(1)), selection method
(§ 170.556(c)(3)), and the number and
types of locations for in-the-field
surveillance (§ 170.556(c)(4)). While we
appreciate concerns that removal of
requirements in § 170.556(c)(6)
regarding the consecutive selection of
certified health IT creates a potential
that the same Health IT Module(s) could
be selected for randomized surveillance
in consecutive years, we are unaware of
evidence suggesting that ONC–ACBs
choosing to implement randomized
surveillance would do so in a manner
that would tend to erode its efficacy by
over-sampling some products at the
expense of under-sampling others.
Rather than retain a regulatory provision
intended to counterbalance a regulatory
requirement for randomized
surveillance of a required minimum
percent of certified products each year,
we believe it is more appropriate at this
time to remove the restriction on
consecutive selection of the same Health
IT Module(s) or location(s) for
randomized surveillance and monitor
the results of this and other Program
enhancements finalized in this rule for
any indication that we may need to
further adjust regulatory requirements
in the future.
We thank commenters for bringing to
our attention that health care providers
may be uncertain about how or where
they can engage the ONC Health IT
Certification Program for assistance
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
when the certified health IT they rely on
is not performing its certified functions
as they expect and their health IT
developer is unresponsive or fails to
resolve non-conformities with Program
requirements. Reactive surveillance by
ONC–ACBs, informed and focused by
end-user complaints, has always been
an essential component of the Program’s
oversight and assurance of continued
conformity of certified Health IT
Modules when deployed in the field.
While we encourage users to begin
seeking troubleshooting and issue
resolution support from the developer of
their health IT—because the developer
is often in the best position to act most
promptly to resolve problems with their
products’ performance—we also
encourage the user to share their
concerns with the ONC–ACB that
certified the health IT in question when
the developer has not addressed users’
concerns that their certified health IT is
not performing as it is certified to
perform. As we recognize that users may
in some circumstances need, or for
purposes potentially including but not
limited to their own preferences may
wish, to share their concerns about their
certified health IT’s performance or
other health IT matters directly with
ONC, we invite health IT users and all
other interested parties to share their
health IT-related feedback or concerns
with ONC through the Health IT
Feedback Form on our HealthIT.gov
website.15 Depending on the nature of a
specific feedback message, we may
contact the submitter for additional
information and, in some instances, may
share the information provided with
other appropriate entities—such as but
not limited to the ONC–ACBs who
certify the products about which we
receive feedback, as they are often in the
best position to assess and respond to
feedback expressing concerns about
conformance of specific certified criteria
used by Health IT Modules in
production environments. All
information submitted through the
Health IT Feedback Form is carefully
reviewed and helps us to improve our
awareness and ability to address health
IT-related issues and challenges. Also,
we note for clarity that persons sharing
health IT-related concerns with ONC via
the Health IT Feedback Form have the
option to remain anonymous and this
option has been chosen by some
submitters. However, we wish to note
that anonymous submissions will
prevent us from acquiring additional
information to fully follow up on a
matter if the submission does not
15 https://www.healthit.gov/form/healthitfeedback-form.
PO 00000
Frm 00015
Fmt 4701
Sfmt 4700
25655
include sufficient detail on which to act.
In general, submitters should provide as
much detail as possible about the
developer, product name, and version of
the certified health IT as well as their
specific concerns about the certified
health IT’s performance.
2. Removal of the 2014 Edition From the
Code of Federal Regulations
In the March 4, 2019 Proposed Rule,
we also proposed to remove the 2014
Edition from the Code of Federal
Regulations (CFR), which includes
standards and functionality now
significantly outmoded (84 FR 7434).
We noted that removal of the 2014
Edition would make the 2015 Edition
the new baseline for health IT
certification. The 2015 Edition,
including the additional certification
criteria, standards, and requirements
adopted in this final rule, will better
enable interoperability and the access,
exchange, and use of electronic health
information, as discussed in the
Proposed Rule (84 FR 7434), and its
adoption and implementation by
providers is expected to yield the
estimated costs savings described (84 FR
7563 and 7564) within the Regulatory
Impact Analysis (section XIV) of the
Proposed Rule and in the Regulatory
Impact Analysis section (section XIII) of
this final rule.
To implement the removal of the 2014
Edition from the CFR, we proposed (84
FR 7434 and 7435) to remove the 2014
Edition certification criteria (§ 170.314)
and related standards, terms, and
requirements from the CFR. In regard to
terms, we proposed to retire the 2014
Edition-related definitions found in
§ 170.102, including the ‘‘2014 Edition
Base EHR,’’ ‘‘2014 Edition EHR
certification criteria,’’ and ‘‘Complete
EHR, 2014 Edition.’’ As explained in the
2015 Edition final rule (80 FR 62719),
the ability to maintain Complete EHR
certification is only permitted with
health IT certified to the 2014 Edition
certification criteria. Because this
concept was discontinued for the 2015
Edition, we proposed (84 FR 7435) to
remove § 170.545 and any references to
Complete EHR from the regulation text
in conjunction with the removal of the
2014 Edition. We also proposed (84 FR
7435) to remove references to the 2014
Edition from the Common Clinical Data
Set (CCDS) definition and effectively
replace it with a new governmentunique standard, the United States Core
Data for Interoperability (USCDI). We
proposed (84 FR 7435) to remove the
standards and implementation
specifications found in §§ 170.200,
170.202, 170.204, 170.205, 170.207,
170.210, and 170.299 that are only
E:\FR\FM\01MYR3.SGM
01MYR3
25656
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
referenced in the 2014 Edition
certification criteria. Adopted standards
that are also referenced in the 2015
Edition would remain. Finally, we
proposed (84 FR 7435) to remove
requirements in § 170.550(f) and any
other requirements in subpart E,
§§ 170.500 through 170.599, which are
specific to the 2014 Edition and do not
apply to the 2015 Edition.
As discussed in the Proposed Rule (84
FR 7435), in order to avoid regulatory
conflicts, we took into consideration the
final rule released by CMS on November
16, 2017, titled ‘‘Medicare Program; CY
2018 Updates to the Quality Payment
Program; and Quality Payment Program:
Extreme and Uncontrollable
Circumstance Policy for the Transition
Year’’ (82 FR 53568). This Quality
Payment Program (QPP) final rule
permits eligible clinicians to use EHR
technology certified to either the 2014
or 2015 Edition certification criteria, or
a combination of the two for the CY
2018 performance period. This QPP
final rule also states that the 2015
Edition certified EHR technology
(CEHRT) will be required starting with
the CY 2019 QPP program year (82 FR
53671). Therefore, we proposed (84 FR
7435) the effective date of removal of
the 2014 Edition certification criteria
and related standards, terms, and
requirements from the CFR would be
the effective date of this final rule.
Comments. The majority of the
comments received supported removing
the 2014 Edition certification criteria
from the Code of Federal Regulations.
Commenters supporting the removal
noted that it will reduce confusion and
acknowledges that standards and
functionality in the 2014 Edition are
now significantly outmoded. Some
commenters requested the removal be
delayed until the end of CY 2019.
Response. We thank commenters for
their support. We have finalized the
removal of the 2014 Edition from the
CFR as proposed, including making the
removal effective as of the effective date
of this final rule (60 days after the rule
is published in the Federal Register).
The 2015 Edition was the sole edition
permitted to meet the CEHRT definition
beginning in the CY 2019 program year.
This final rule is published in CY 2020.
Therefore, the removal is not in conflict
with CMS’ regulatory requirements for
QPP.
To finalize removal of the 2014
Edition from the CFR, we have removed,
effective as of the effective date of this
final rule, the 2014 Edition certification
criteria in § 170.314. We also finalized
removal of terms and definitions
specific to the 2014 Edition from
§ 170.102, including the ‘‘2014 Edition
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
Base EHR,’’ ‘‘2014 Edition EHR
certification criteria,’’ and ‘‘Complete
EHR, 2014 Edition’’ definitions. As
explained in the 2015 Edition final rule
(80 FR 62719), the ‘‘Complete EHR’’
concept was discontinued for the 2015
Edition. Therefore, in conjunction with
the removal of the 2014 Edition, we also
remove in this final rule § 170.545 and
all other references to ‘‘Complete EHR’’
from the regulation text. Moreover, in
finalizing the removal of the 2014
Edition from the CFR, we also finalize
removal of the standards and
implementation specifications found in
§§ 170.200, 170.202, 170.204, 170.205,
170.207, 170.210, and 170.299 that are
referenced only in the 2014 Edition
certification criteria. Adopted standards
that are also referenced in the 2015
Edition, as modified by this final rule,
remain in the CFR. We also retained the
CCDS definition in § 170.102 but
removed the standards and
implementation specifications that
reference the 2014 Edition.
Additionally, we finalized the removal
of requirements in § 170.550(f) and any
other requirements in subpart E,
§§ 170.500 through 170.599, that are
specific to the 2014 Edition and do not
apply to the 2015 Edition.
3. Removal of the ONC-Approved
Accreditor From the Program
We proposed to remove the ONC–AA
from the Program (84 FR 7435). The
ONC–AA’s role is to accredit
certification bodies for the Program and
to oversee the ONC–ACBs. However,
years of experience and changes with
the Program have led ONC to conclude
that, in many respects, the role of the
ONC–AA to oversee ONC–ACBs is now
duplicative of ONC’s oversight. More
specifically, ONC’s experience with
administering the Principles of Proper
Conduct (PoPC) for ONC–ACBs as well
as issuing necessary regulatory changes
(e.g., ONC–ACB surveillance and
reporting requirements in the 2015
Edition final rule) has demonstrated that
ONC on its own has the capacity to
provide the appropriate oversight of
ONC–ACBs. Therefore, we believe
removal of the ONC–AA will reduce the
Program’s administrative complexity
and burden.
Comments. All but one commenter
specifically addressing this proposal
were in support of removing the ONC–
AA. The one commenter opposed to the
proposal stated concerns related to decoupling accreditation to ISO/IEC 17065
standards (an internationally recognized
standard for bodies certifying products,
processes, and services to provide
assurance of compliance with specified
requirements such as initial testing,
PO 00000
Frm 00016
Fmt 4701
Sfmt 4700
inspection, and quality management
systems) from specific assessment of a
certification body’s ability to apply their
accredited ISO/IEC 17065 capabilities to
the Program’s certification scheme
requirements. The commenter noted
that this might place a greater burden on
ONC staff than did the Program
structure that included an ONC–AA.
Finally, one of the commenters in
support of removing the ONC–AA from
the Program requested additional
clarification about criteria and processes
that will be used for accreditation of
certification bodies following removal of
the ONC–AA from the Program.
Response. We thank all commenters
for their thoughtful feedback. Upon
consideration of all comments received
on this proposal, we have finalized it as
proposed. As noted in the preamble to
the Proposed Rule (84 FR 7435), ONC’s
experience with administering the PoPC
for ONC–ACBs as well as issuing
necessary regulatory changes (e.g.,
ONC–ACB surveillance and reporting
requirements in the 2015 Edition final
rule) has demonstrated that ONC on its
own has the capacity to provide the
appropriate oversight of ONC–ACBs.
Therefore, we believe removal of the
ONC–AA will reduce the Program’s
administrative complexity and burden
while maintaining its effectiveness. We
anticipate providing updated
information about ONC’s updated
processes for approval and oversight of
certification bodies through familiar
mechanisms including but not
necessarily limited to the HealthIT.gov
website prior to the effective date of this
final rule, and on an ongoing basis as
needed or otherwise appropriate to
ensure effective transparency about this
aspect of the Program.
To finalize this deregulatory action,
we have removed the definition for
‘‘ONC-Approved Accreditor or ONC–
AA’’ from § 170.502. We also removed
§§ 170.501(c), 170.503, and 170.504
regarding requests for ONC–AA status,
ONC–AA ongoing responsibilities, and
reconsideration for requests for ONC–
AA status. Regarding correspondence
and communication with ONC, we have
revised § 170.505 to remove specific
references to the ‘‘ONC–AA’’ and
‘‘accreditation organizations requesting
ONC–AA status.’’ We also have
finalized our proposal to sunset the
policies reflected in the final rule titled
‘‘Permanent Certification Program for
Health Information Technology;
Revisions to ONC-Approved Accreditor
Processes’’ (76 FR 72636), and to
remove § 170.575, which established a
process for addressing instances where
the ONC–AA engages in improper
conduct or does not perform its
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
responsibilities under the Program.
Because the regulations promulgated in
this prior final rule relate solely to the
role of the ONC–AA, we have finalized
the removal of those requirements.
Accordingly, we also revised the
application process for ONC–ACB status
in § 170.520(a)(3) to require
documentation, with an appropriate
scope, that confirms that the applicant
has been accredited to ISO/IEC 17065 by
any accreditation body that is a
signatory to the Multilateral Recognition
Arrangement (MLA) with the
International Accreditation Forum
(IAF), in place of the ONC–AA
accreditation documentation
requirements. Similarly, instead of
requiring the ONC–AA to evaluate the
conformance of ONC–ACBs to ISO/IEC
17065, we revise § 170.523(a) to simply
require ONC–ACBs to maintain
accreditation in good standing to ISO/
IEC 17065. This means that ONC–ACBs
would need to continue to comply with
ISO/IEC 17065 and requirements
specific to the ONC Health IT
Certification Program scheme.
4. Removal of Certain 2015 Edition
Certification Criteria and Standards
Having reviewed and analyzed the
2015 Edition, we proposed to remove
certain certification criteria and
standards as discussed in the Proposed
Rule (84 FR 7435 through 7437) and
below. We stated (84 FR 7435) that we
believe the removal of these criteria and
standards will reduce burden and costs
for health IT developers and health care
providers by eliminating the need to:
Design and meet specific certification
functionalities; prepare, test, and certify
health IT in certain instances; adhere to
associated reporting and disclosure
requirements; maintain and update
certifications for certified
functionalities, and participate in
routine surveillance (84 FR 7435).
Although we did not expressly state it
in the Proposed Rule preamble, the
burdens and costs reduced by removal
of certain criteria from the 2015 Edition
would be those associated with the
needs we discussed in the preamble (84
FR 7435) specifically in connection to
the criteria we proposed to remove,
which are those that had been set forth
in § 170.315(a)(6), (7) and (8), (10) and
(11), and (13), (b)(4) and (5), and (e)(2)
(as the text of 45 CFR part 170 stood
prior to this final rule).
a. 2015 Edition Base EHR Definition
Certification Criteria
We proposed to remove certain
certification criteria from the 2015
Edition that had been included in the
2015 Edition Base EHR definition. As
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
discussed in the preamble to the
Proposed Rule (84 FR 7435), the
removal of these criteria supports
burden and cost reductions for health IT
developers and health care providers by
eliminating the need to: Design and
meet these specific certification
functionalities; prepare, test, and certify
health IT in certain instances; adhere to
associated reporting and disclosure
requirements; maintain and update
certifications for these specific certified
functionalities; and participate in
surveillance of health IT certified to
these criteria and standards.
i. Problem List
We proposed to remove the 2015
Edition ‘‘problem list’’ certification
criterion (§ 170.315(a)(6)) from the 2015
Edition (84 FR 7436). As we noted in
the Proposed Rule, the functionality in
this criterion was first adopted as a 2011
Edition certification criterion to support
the associated meaningful use Stage 1
objective and measure for recording
problem list information. This 2015
Edition ‘‘problem list’’ criterion
functionally remains relatively the same
as the 2011 Edition and has exactly the
same functionality as the 2014 Edition
‘‘problem list’’ criterion. We proposed to
remove this criterion because the
criterion no longer supports the
‘‘recording’’ objective and measure of
the CMS PI Programs as such objective
and measure no longer exist.16
Additionally, we stated the
functionality is sufficiently widespread
among health care providers since it has
been part of certification and the
Certified EHR Technology definition
since the 2011 Edition and has not
substantively changed with the 2015
Edition. Furthermore, we stated in the
Proposed Rule that the functionality is
essential to clinical care and would be
in EHR systems absent certification,
particularly considering the limited
certification requirements.
Comments. A number of commenters
expressed support for removing the
‘‘problem list’’ certification criterion
from the 2015 Edition and ‘‘Base EHR’’
definition. Several of those expressing
support for the removal of this criterion
specifically noted that the inclusion of
the same data elements in the USCDI
should suffice to ensure continued
ability of certified health IT to record
and facilitate access and exchange of
16 By stating in the NPRM that the objective and
measure no longer exist, we meant in the CMS PI
(formerly EHR Incentive) Programs. The authority
citation for this statement is the December 15, 2015
CMS Final Rule ‘‘Medicare and Medicaid Programs;
Electronic Health Record Incentive Program-Stage 3
and Modifications to Meaningful Use in 2015
Through 2017’’ (80 FR 62761 and 62785).
PO 00000
Frm 00017
Fmt 4701
Sfmt 4700
25657
these data. However, a few commenters
expressed concern that removing this
and other requirements would be a
disincentive to maintain the
functionality in the future, and some
commenters expressed concern about
ONC’s ability to continue to provide
effective oversight and require
correction if developers do not ensure
the functionalities perform safely and
effectively. Commenters stated that
while many developers will still
continue to support the functionalities
proposed for removal, eliminating the
certification requirement may allow for
developers to provide a ‘‘strippeddown’’ product at a lower price point
and, in absence of CEHRT definition to
guide the providers, mislead
independent and small providers into
unwittingly acquiring certified health IT
that does not fully meet their needs.
Response. As discussed in the
preamble to the Proposed Rule, a
criterion specific to the ‘‘problem list’’
functionality was first adopted in the
2011 Edition, specifically to ensure
support for the associated meaningful
use Stage 1 objective and the measure
for recording problem list information
under the CMS PI Programs. The
‘‘recording’’ objective and measure is no
longer a part of the CMS PI Programs.
However, the functionality remains
widespread among EHR systems used
by health care providers. While this
prevalence may be due in part to its
inclusion in the Certified EHR
Technology definition, without
substantive changes, since the 2011
Edition, we believe the more significant
reason that this functionality is widely
available is because it is essential to
clinical care, and therefore, that the
market will and should drive its
continued presence in EHR systems
regardless of certification requirements.
While we also appreciate the concerns
of commenters about the need for health
IT to support the accurate recording of
patients’ problems and the standardsbased exchange of that information, we
reiterate that the interoperabilityfocused criteria that will remain in the
Base EHR definition and reference the
USCDI will ensure that any system of
certified health IT meeting the Base EHR
definition is capable of using and
exchanging data on a patient’s problems
using content, format, and other
standards applicable to each mode of
exchange (e.g., standardized API and C–
CDA). Moreover, these interoperabilityfocused criteria will be subject not only
to the Program’s familiar initial
certification testing and in-the-field
reactive surveillance requirements but
also to the new Condition and
E:\FR\FM\01MYR3.SGM
01MYR3
25658
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
Maintenance of Certification
requirements for developers to test
annually their certified Health IT
Modules’ interoperability performance
in the types of real world settings for
which they are sold.
After consideration of all comments
received, and for the reasons noted in
the preamble to the Proposed Rule and
above, we have finalized the removal of
the ‘‘problem list’’ certification criterion
(§ 170.315(a)(6)). We further note that
upon the effective date of this final rule,
the ‘‘problem list’’ certification criterion
is removed from the 2015 Edition and
the criterion will no longer be included
in the 2015 Edition ‘‘safety-enhanced
design’’ criterion. This criterion, in
§ 170.315(g)(3), specifies the usercentered design testing that must be
applied to particular EHR functionality
submitted for certification. However, in
response to specific commenters’
concerns about the impact of removing
the functionally-based problem list
criterion on our ability to take action
where developers may retain the
functionality, but fail to ensure it does
not pose a danger to patient safety or
public health, we note that our
responsibility, pursuant to section
3001(b) of the PHSA, includes ensuring
certified health IT does not pose a risk
to patient safety or public health, and is
not limited to measuring the conformity
of the health IT to specific certification
criteria. As discussed in the ‘‘ONC
Health IT Certification Program:
Enhanced Oversight and
Accountability’’ (EOA) rule which was
proposed in 81 FR 11056, and finalized
in 81 FR 72404 in 2016, ONC has the
authority to address suspected or
confirmed non-conformities to the
requirements under the ONC Health IT
Certification Program if the certified
health IT is causing or contributing to
serious risks to public health or safety
(81 FR 72406). The EOA final rule
established in § 170.580 a regulatory
framework for ONC’s direct review of
health IT certified under the Program,
which expressly addresses the potential
for ONC to initiate direct review if we
have a reasonable belief that certified
health IT may not conform to the
requirements of the Program because the
certified health IT may be causing or
contributing to conditions that present a
serious risk to public health or safety.
With respect to health care providers’
selection of certified health IT products,
we would encourage all providers to
consider the Base EHR or Certified EHR
Technology (CEHRT) definition as a
useful starting point. Certain health care
payment programs, including the CMS
PI Programs, require the use of certified
health IT. CMS refers to the minimum
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
set of required certification
functionalities that the health IT used
by eligible clinicians must have in order
to qualify for the CMS incentive
programs as CEHRT.
Using certified health IT improves
care coordination through the electronic
exchange of clinical-care documents. It
provides a baseline assurance that the
technology will perform clinical-care
and data-exchange functions in
accordance with interoperability
standards and user-centered design.
ii. Medication List
We proposed to remove the 2015
Edition ‘‘medication list’’ certification
criterion (§ 170.315(a)(7)) (84 FR 7436).
As we noted in the Proposed Rule, the
2015 Edition ‘‘medication list’’ criterion
remains functionally the same as the
2011 Edition and 2014 Edition
‘‘medication list’’ criteria. As also
discussed in the Proposed Rule, a
functionally-based ‘‘medication list’’
criterion was first adopted as a 2011
Edition certification criterion to support
the associated meaningful use Stage 1
objective and measure for recording
medication list information. The
‘‘medication list’’ criterion that we
proposed to remove does not require use
of a specific vocabulary standard to
record medications.
Comments. Comments on the
proposal to remove the ‘‘medication
list’’ criterion were somewhat mixed.
While a number of comments expressed
support for the removal of the
‘‘medication list’’ criterion from the
2015 Edition as duplicative of
medication data included in the USCDI
a number of commenters expressed
concerns with, and a few commenters
indicated opposition to, the removal of
the ‘‘medication list’’ criterion. A few
commenters raised concerns specific to
elimination of the ‘‘medication list’’
criterion in view of the need to respond
to the opioids crisis. One commenter
expressed concern in the context of both
the medication list and the drugformulary and preferred drug lists
criteria as to whether the removal of
these criteria could potentially impact
patients’ drug costs. Several comments
also expressed the same concerns for
eliminating the ‘‘medication list’’ that
were expressed in regard to removal of
the ‘‘problem list’’ criterion, which are
summarized above, regarding whether
developers will continue to include the
functionality and maintain its safe
performance.
Response. We thank commenters for
their input. Upon consideration of all
comments received on this proposal, we
have finalized the removal of the
‘‘medication list’’ criterion
PO 00000
Frm 00018
Fmt 4701
Sfmt 4700
(§ 170.315(a)(7)). The ‘‘recording’’
objective and measure of the CMS PI
Programs that the ‘‘medication list’’
criterion was originally adopted to
support has since been retired from the
CMS Programs. However, the
functionality remains widespread
among EHR systems used by health care
providers. While this prevalence may be
due in part to its inclusion in the
Certified EHR Technology definition
since the 2011 Edition, we believe this
functionality is widely available and
used in more significant part because it
is essential to clinical care and,
therefore, the market will and should
drive its continued presence in EHR
systems regardless of certification
requirements. While we also appreciate
the concerns of commenters about the
need for health IT to support clinicians’
ability to access, maintain, use, and
exchange accurate and up-to-date
information on their patients’ current
medication lists and medication history,
we repeat for clarity and emphasis that
the interoperability-focused criteria that
will remain in the Base EHR definition,
and their inclusion of the USCDI, will
ensure that any system of certified
health IT meeting the Base EHR
definition is capable of using and
exchanging data on a patient’s
medications using content, format, and
other standards applicable to each mode
of exchange (e.g., standardized API
consistent with § 171.315(g)(10), or
exchange of C–CDA documents using
the transport standards and other
protocols in § 171.202). We recognize
the critical importance of providers’ and
patients’ ability to have, use, and
exchange medications information to
avoid harms that can arise from
interactions and duplications of
therapeutic effects amongst newly
prescribed drugs and those the patient
may already be taking. While the
clinical importance of maintaining and
referencing current, reconciled
medication lists is not limited to those
medications with significant risks of
misuse or dependency, we agree that it
is highlighted by the urgent need to
ensure opioids are prescribed and used
only with due care when clinically
necessary. We believe this clinical
importance supports the expectation
that the market will ensure this
functionality is maintained and will
drive innovations that improve its
usability for the clinicians who use it in
the course of caring for their patients.
Moreover, the inclusion of medication
information in interoperability-focused
criteria in § 170.405(a) will ensure
certified health IT can access, use, and
exchange medications data according to
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
applicable content and formatting
standards, which the ‘‘medication list’’
functionality did not ensure. This
interoperability of the data is critical to
reducing clinician burden related to
manually entering updated drug lists
and necessary to enable use of
medication information by clinical
decision support functionalities. The
interoperability-focused criteria will
also be subject not only to the Program’s
familiar initial certification testing and
in-the-field reactive surveillance
requirements but also to the new
Condition and Maintenance of
Certification requirements for
developers to test annually their
certified Health IT Modules’
interoperability performance in the
types of real world settings for which
they are marketed.
We note that once removed from the
2015 Edition, the criterion will no
longer be included in the 2015 Edition
‘‘safety-enhanced design’’ criterion in
§ 170.315(g)(3). However, as noted
above in context of the ‘‘problem list’’
criterion, ONC’s responsibility,
pursuant to section 3001(b) of the
PHSA, includes ensuring certified
health IT does not pose a risk to patient
safety or public health. Our
responsibility for certified health IT and
patient safety or public health is not
limited to measuring the conformity of
the health IT to specific certification
criteria. As discussed in the EOA rule,
ONC has the authority to address
suspected or confirmed nonconformities to the requirements under
the Health IT Certification Program if
the certified health IT is causing or
contributing to serious risks to public
health or safety (81 FR 72406). The EOA
final rule established in § 170.580 a
regulatory framework for ONC’s direct
review of health IT certified under the
Program, which expressly addresses the
potential for ONC to initiate direct
review if we have a reasonable belief
that certified health IT may not conform
to the requirements of the Program
because the certified health IT may be
causing or contributing to conditions
that present a serious risk to public
health or safety.
iii. Medication Allergy List
We proposed to remove the 2015
Edition ‘‘medication allergy list’’
certification criterion (§ 170.315(a)(8)).
The functionality in this criterion was
first adopted as a 2011 Edition
certification criterion to support the
associated meaningful use Stage 1
objective and measure for recording
medication allergies information. The
criterion does not require use of a
vocabulary standard to record
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
medication allergies, and does not
directly support interoperability as the
criterion does not require representation
of medication allergies in standardized
nomenclature. The criterion no longer
supports a ‘‘recording’’ objective and
measure of the CMS PI Programs as such
objective and measure no longer exist.
This 2015 Edition ‘‘medication allergy
list’’ criterion remains functionally the
same as the 2011 Edition and 2014
Edition ‘‘medication allergy list’’
criteria. The functionality is essential to
clinical care and would be in EHR
systems absent certification.
Comments. Comments on the
proposed removal of the ‘‘medication
allergy list’’ criterion were mixed, with
several commenters supportive of the
removal noting that the criterion would
be redundant now that medication
allergy data will be included in the
USCDI. Commenters expressed concern
with the removal of the criterion and
questioned the ubiquity of the
medication allergy list functionality and
whether health IT developers would
continue to support the functionality if
not required by ONC regulations.
Response. We thank commenters for
their input. Upon consideration of all
comments received on this proposal, we
have finalized the removal of the
‘‘medication allergy list’’ certification
criterion (§ 170.315(a)(8)). The
‘‘recording’’ objective and measure of
the CMS PI Programs that this criterion
was originally adopted to support has
since been retired from the CMS
Programs. However, the functionality
remains widespread among EHR
systems. While this prevalence may be
due in part to its inclusion in the
Certified EHR Technology definition
since the 2011 Edition, its importance to
clinical care suggests the market will
drive ongoing availability and
enhancement of this functionality over
time. Furthermore, because medication
allergies are included in the USCDI, all
systems of certified health IT meeting
the Base EHR definition will be required
to be able to exchange and use
medication allergy information
according to applicable content and
formatting standards, which the
‘‘medication allergies’’ criterion did not
ensure. This interoperability is critical
to reducing clinician burden related to
manually entering updated drug lists
and necessary to enable use of
medication information by clinical
decision support functionalities. We
believe that requiring the
interoperability of medication allergy
information will facilitate innovation
and improvement in health IT’s ability
to meet clinicians’ and patients’ needs
more than would the continuation of the
PO 00000
Frm 00019
Fmt 4701
Sfmt 4700
25659
‘‘medication allergies’’ functionallybased criterion.
We note that once removed from the
2015 Edition, the ‘‘medication allergy
list’’ criterion will also no longer be
included in the 2015 Edition ‘‘safetyenhanced design’’ criterion. However, as
noted in context of removed criteria
above, ONC’s responsibility, pursuant to
section 3001(b) of the PHSA includes
ensuring certified health IT does not
pose a risk to patient safety or public
health. Our responsibility for certified
health IT and patient safety or public
health is not limited to measuring the
conformity of the health IT to specific
certification criteria. As discussed in the
EOA rule, ONC has the authority to
address suspected or confirmed nonconformities to the requirements under
the Health IT Certification Program if
the certified health IT is causing or
contributing to serious risks to public
health or safety (81 FR 72406). The EOA
final rule established in § 170.580 a
regulatory framework for ONC’s direct
review of health IT certified under the
Program, which expressly addresses the
potential for ONC to initiate direct
review if we have a reasonable belief
that certified health IT may not conform
to the requirements of the Program
because the certified health IT may be
causing or contributing to conditions
that present a serious risk to public
health or safety.
iv. Smoking Status
We proposed to remove the 2015
Edition ‘‘smoking status’’ criterion
(§ 170.315(a)(11)), which would include
removing it from the 2015 Edition Base
EHR definition (84 FR 7436). We had
previously adopted a 2015 Edition
‘‘smoking status’’ certification criterion
that does not reference a standard.
However, the CCDS definition, which
we proposed to remove from regulation
in favor of adopting the new USCDI
standard, required smoking status to be
coded in accordance with a standard
value set of eight SNOMED CT® codes
defined in § 170.207(h). As with other
functionality that was included in 2014
Edition, we believe this functionality is
now widespread. Further, smoking
status data will continue to be required
to be available for access and exchange
via the USCDI.
Comments. Comments on this
proposal were mixed, with a number of
commenters expressing support for the
removal of ‘‘smoking status’’ criterion in
the Program and several noting that it is
not needed or duplicative in the context
of Program requirements to support the
USCDI. A few commenters stated
concerns that eliminating the
requirement would provide a
E:\FR\FM\01MYR3.SGM
01MYR3
25660
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
disincentive for developers to maintain
the function in the future. Several
commenters expressing concerns about
removal of this criterion noted its
importance to patient care and to public
health, raising points such as the use of
smoking status as a key determinant to
classify cases of some reportable
conditions, such as carbon monoxide
poisoning. Concerns raised by
commenters opposed to removing
smoking status data from providers’
EHR systems included potential for
additional provider burden, such as that
related to providing complete case
reporting data and responding to public
health requests for additional
information on patient smoking status
during case investigation processes.
Response. We thank commenters for
their input. Upon consideration of the
comments, we have finalized the
removal of the ‘‘smoking status’’
criterion (§ 170.315(a)(11)). While we
continue to believe that accurate, up-todate information on a patient’s smoking
status and history has significant
clinical value, we believe that its
importance to clinical care provides
adequate motivation for the market to
drive ongoing availability and
enhancement of this functionality over
time. Because smoking status
information is included in the USCDI,
all systems of certified health IT
meeting the Base EHR definition will
now be required to be able to exchange
and use smoking status information
according to applicable content and
formatting standards. The ‘‘smoking
status’’ recording functionality criterion
we have removed did not ensure
smoking status information was
captured in a structured, interoperable
manner and interoperability of this data
is critical to reducing clinician burden
related to maintaining complete, current
smoking status information. It is also
necessary to enable use of smoking
status information by clinical decision
support and public health reporting
functionalities. We believe that
interoperability and exchange of
smoking status information through the
interoperability-focused certification
criteria that reference the USCDI
standard will better facilitate innovation
and improvement in health IT’s ability
to meet clinicians’ and patients’ needs
than would continuation of the
‘‘smoking status’’ functionally-based
recording criterion.
Removal of Specific USCDI Smoking
Status Code Set
Along with the ‘‘smoking status’’
criterion, we proposed to remove the
requirement to code smoking status
according to the eight smoking status
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
SNOMED CT® codes referenced in the
value set adopted in § 170.207(h). These
eight codes reflected an attempt to
capture smoking status in a consistent
manner. Stakeholder feedback indicated
that these eight codes do not
appropriately and accurately capture all
clinically relevant patient smoking
statuses. Accordingly, we proposed to
no longer require use of only the
specific eight SNOMED CT® codes for
representing smoking status and remove
the value set standard by deleting and
reserving § 170.207(h).
Comments. Comments specifically
addressing this proposal were generally
supportive of removing the specific
value set of eight SNOMED CT® codes,
though many also noted the importance
of continuing to require health IT
certified under the Program to retain the
ability to include or access, exchange,
and use appropriately standardized
smoking status information. Several
comments made specific suggestions
related to broadening or revising the
vocabulary standard requirements for
smoking status information going
forward. Other commenters suggested
adding other forms of tobacco use,
including smokeless and second hand,
as well as e-cigarette (vaping) use.
Response. We appreciate all
commenters’ input and note that no
comments received raised concerns that
are not addressed by inclusion of
smoking status information in the
USCDI, which all interoperabilityfocused criteria within the 2015 Edition
Base EHR definition, as revised through
this final rule, reference. As is the case
with patient problems, medications, and
medication allergies, we believe having
smoking status information available for
standards-based exchange is an
important facilitator of better care and
more effective public health reporting
with less data-related burden on
clinicians and less need for follow-up
by public health professionals to
compensate for case reporting data that
is incomplete or is not fully
interoperable. As is the case with the
other removed criteria that were focused
on internal recording capabilities, we
believe the market can, will, and should
be the primary driver for the ongoing
maintenance and enhancement of
functionalities for end users to record or
modify these data. Furthermore, the
Program’s focus is more appropriately
spent on ensuring that certified health
IT supports interoperable access, use,
and exchange of these data as the key
facilitator for more coordinated patient
care and for ongoing innovation and
improvement in both provider- and
patient-facing functionalities. Because
comments on revisions or
PO 00000
Frm 00020
Fmt 4701
Sfmt 4700
enhancements to smoking status data
standardization moving forward are
outside the scope of this section, we
will not address them in specific detail
here. However, we note that the USCDI
v1 references as the standard for
smoking status information SNOMED
CT®, U.S. Edition.17
Having considered all comments
received on this proposal, we have
finalized the removal of the eight-code
value set standard and removed and
reserved § 170.207(h).
b. Drug-Formulary and Preferred Drug
List Checks
We proposed to remove the 2015
Edition ‘‘drug-formulary and preferred
drug list checks’’ criterion in
§ 170.315(a)(10).
Comments. Some commenters
expressed concern that this criterion’s
removal could negatively impact
prescribers’ ability to help their patients
manage their prescription drug
expenses. Although several commenters
supported the removal of this criterion
in principle, a number of comments
expressed concerns about the effect of
removal of the ‘‘drug-formulary and
preferred drug list checks’’ and other
criteria from the Program on health care
providers’ ability to comply with CMS
and State-specific regulatory
requirements for successful
participation in the Medicare Quality
Payment Program (QPP), or the
Medicare or Medicaid PI Programs. One
commenter, noting that the DrugFormulary and Preferred Drug List
Checks criterion is associated with the
CMS e-prescribing objective measures
that CMS has finalized for 2019 and
subsequent performance years
specifically, recommended coordination
with CMS to ensure alignment across
the policies maintained by these two
components of HHS.
Response. We thank commenters for
their input. As discussed in the
Proposed Rule (84 FR 7437), the 2015
Edition ‘‘drug-formulary and preferred
drug list checks’’ criterion does call for
functionality to check drug formulary
and preferred drug lists, but does not
require use of any specific
interoperability standards. The 2015
Edition ‘‘drug-formulary and preferred
drug list checks’’ criterion does not
include functionality or advance
interoperability beyond what was
required by the 2014 Edition ‘‘drugformulary checks’’ criterion. While we
17 For more information on finalized policy
regarding adoption of the USCDI standard, see
section IV.B.1 of this final rule. USCDI v1 can be
accessed freely and directly in its entirety at https://
www.healthit.gov/isa/sites/isa/files/inline-files/
USCDIv12019revised2.pdf.
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
believe this functionality is fairly
ubiquitous now due in part to the
widespread adoption of health IT
certified to the 2014 Edition, we do not
believe it is necessary to continue to
require certification to it under the
Program in order to ensure it remains
widely available. Instead, we believe,
prescribers’ and patients’ interest in
assuring patients can get the
medications they need at the best
available value will provide adequate
motivation for the market to drive
ongoing availability and enhancement
of this functionality over time,
including through increasing use of
relevant interoperability standards
essential to making this functionality
more affordable and seamlessly reliable
at scale than is feasible in the absence
of interoperability driven by ubiquitous
use of open standards. Because the
‘‘drug-formulary and preferred drug list
checks’’ criterion we proposed to
remove does not require use of
standards or directly drive
interoperability, we do not believe its
continued inclusion in the Program
would provide sufficient value to
providers or patients to justify the
burden on developers and providers of
meeting Program compliance
requirements specific to this criterion.
We also recognize the importance of
ensuring alignment between ONC
Health IT Certification Program
regulations and the CMS regulations
that reference them. We have been and
will continue to work in close
partnership with our CMS colleagues to
ensure that our regulations remain
aligned, and that we provide affected
stakeholders with the information they
need to understand how the rules work
together and how to succeed under
CMS’ PI Programs using health IT
certified under ONC’s Program. We,
therefore, permit ONC–ACBs to issue
certificates for this criterion up until
January 1, 2022 to align with the
requirements of the CMS Medicaid PI
Program, as this criterion is associated
with measures under the Medicaid
program that will continue through
2021; after 2021 there will be no further
incentives under the Medicaid
Promoting Interoperability Program (84
FR 42592). We have not finalized our
proposal to remove the criterion from
the CFR but included a provision in
§ 170.550(m)(1) to only allow ONC–
ACBs to issue certificates for this
criterion until January 1, 2022.
c. Patient-Specific Education Resources
We proposed to remove the 2015
Edition ‘‘patient-specific education
resources’’ certification criterion in
§ 170.315(a)(13) (84 FR 7437). We stated
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
that, based on the number of health IT
products that have been certified for this
functionality as part of 2014 Edition
certification and already for 2015
Edition, we believe that health IT’s
ability to identify appropriate patient
education materials is widespread now
among health IT developers and their
customers (e.g., health care providers).
We also noted that we have recently
seen innovative advancements in this
field, including the use of automation
and algorithms to provide appropriate
education materials to patients in a
timely manner. These advancements
help limit clinical workflow
interruptions and demonstrate the use
and promise of health IT to create
efficiencies and improve patient care.
As such, we stated that removal of this
criterion would prevent certification
from creating an unnecessary burden for
developers and providers and an
impediment to innovation.
Comments. Some commenters
expressed concern related to this
functionality not yet being consistently
used by all providers and to whether
removal of this criterion may create a
barrier to successful participation for
providers in the Medicaid PI Program.
One commenter noted that providers’
workflow changes to use this
functionality are substantial and
expressed concern related to providers
potentially not undertaking such
changes if the criteria were not required
to be included in health IT and used by
providers.
Response. While we continue to
recognize the importance of patient and
provider interaction to promote positive
health outcomes, we also believe that
this criterion, narrowly focused on a
specific functionality not connected to
interoperability, is no longer the best
way to encourage innovation and
advancement in health IT’s ability to
support clinician-patient interactions
and relationships.
Having reviewed all comments
received on this proposal, we have
decided not to remove the ‘‘patientspecific education resources’’ criterion
from the Program at this time. We
recognize the importance of ensuring
alignment between ONC Health IT
Certification Program regulations and
the CMS regulations that reference
them. We will continue to work in close
partnership with our CMS colleagues to
ensure that our regulations remain
aligned and that we provide affected
stakeholders with the information they
need to understand how the rules work
together and how to succeed under CMS
incentive programs using health IT
certified under ONC’s Program. CMS
has identified this criterion as
PO 00000
Frm 00021
Fmt 4701
Sfmt 4700
25661
supporting the patient electronic access
to health information objective and
measure, which is expected to remain
operational for Medicaid until January
1, 2022; after 2021, there will be no
further incentives under the Medicaid
Promoting Interoperability Program (84
FR 42592). We, therefore, will permit
ONC–ACBs to issue certificates for this
criterion up until January 1, 2022, to
align with the requirements of the CMS
Medicaid PI Program (84 FR 42592). We
have included a provision in
§ 170.550(m)(1) to only allow ONC–
ACBs to issue certificates for this
criterion until January 1, 2022.
d. Common Clinical Data Set Summary
Record—Create; and Common Clinical
Data Set Summary Record—Receive
As stated in the proposed rule (84 FR
7437), we assessed the number of
products certified to the 2015 Edition
‘‘Common Clinical Data Set summary
record—create’’ (§ 170.315(b)(4)) and
‘‘Common Clinical Data Set summary
record—receive’’ (§ 170.315(b)(5))
criteria that have not also been certified
to the 2015 Edition ‘‘transitions of care’’
criterion (§ 170.315(b)(1)) that also
requires health IT be capable of creating
and receiving Common Clinical Data Set
(CCDS) Summary Records using the
same interoperability standards. We
explained that, based on our findings of
only two unique products certified only
to these criteria and not to the
‘‘transitions of care’’ criterion at the
time of the drafting of the Proposed
Rule, there appears to be little market
demand for certification to 2015 Edition
‘‘Common Clinical Data Set summary
record—create’’ (§ 170.315(b)(4)) and
‘‘Common Clinical Data Set summary
record—receive’’ (§ 170.315(b)(5))
criteria alone. Therefore, we proposed to
remove these certification criteria from
the 2015 Edition.
Comments. The comments we
received on this proposal supported this
removal.
Response. We thank commenters for
their support and have finalized
removal of the 2015 Edition ‘‘Common
Clinical Data Set summary record—
create’’ (§ 170.315(b)(4)) and ‘‘Common
Clinical Data Set summary record—
receive’’ (§ 170.315(b)(5)) criteria.
e. Secure Messaging
We proposed to remove the 2015
Edition ‘‘secure messaging’’ criterion
(§ 170.315(e)(2)). As explained in the
Proposed Rule (84 FR 7437), ONC
strongly supports patient and provider
communication, as well as protecting
the privacy and security of patient
information, but no longer believes that
a separate certification criterion focused
E:\FR\FM\01MYR3.SGM
01MYR3
25662
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
on a health IT’s ability to send and
receive secure messages between health
care providers and patients is necessary.
This criterion would also no longer be
associated with an objective or measure
under the CMS PI Programs based on
proposals and determinations in recent
CMS rulemakings (83 FR 41664; 83 FR
35929).
Comments. Several comments
specifically referencing this proposal
were supportive of removing this
criterion. A number of commenters
expressed concern with the removal of
the ‘‘secure messaging’’ criterion,
including whether removal of this
criterion may create a barrier to
successful participation for providers in
the CMS PI Programs. Other
commenters expressed concerns about
continued availability of secure digital
endpoints for health care providers.
Some commenters noted that some
providers and patients might prefer to
continue using ‘‘secure messaging’’
functionality in lieu of other options for
a variety of purposes for which they
currently use it, while others expressed
concern that the separate ‘‘secure
messaging’’ functionality will disappear
from the market if no longer supported
by ONC requirements. Commenters
expressed that options for data access
and exchange, such as portals and APIs,
might satisfy providers’ and patients’
needs for interoperable communication.
However, commenters expressed a
concern that these options may not
ensure continued availability to new
market entrants’ health IT without
requiring the technology to interact with
developer- or system-specific interfaces.
Response. We thank commenters for
their input. Having reviewed all
comments received on this proposal, we
have decided not to remove the ‘‘secure
messaging’’ criterion from the Program
at this time. We recognize the
importance of ensuring alignment
between ONC Health IT Certification
Program regulations and the CMS
regulations that reference them. We will
continue to work in close partnership
with our CMS colleagues to ensure that
our regulations remain aligned and that
we provide affected stakeholders with
the information they need to understand
how the rules work together and how to
succeed under CMS incentive programs
using health IT certified under ONC’s
Program. CMS has identified this
criterion as supporting the coordination
of care through patient engagement
objective and measure, which is
expected to remain operational for
Medicaid until January 1, 2022; after
2021 there will be no further incentives
under the Medicaid Promoting
Interoperability Program (84 FR 42592).
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
We, therefore, will permit ONC–ACBs to
issue certificates for this criterion up
until January 1, 2022 to align with the
requirements of the CMS Medicaid PI
Program (84 FR 42592). We have
included a provision in § 170.550(m)(1)
to only allow ONC–ACBs to issue
certificates for this criterion until
January 1, 2022.
Limiting certificates to this criterion
for this period will help spur further
innovations in patient engagement
while helping to reduce regulatory
burdens and costs for health IT
developers and health care providers.
The other 2015 Edition certification
criteria that support patient engagement,
such as the 2015 Edition ‘‘view,
download, and transmit to 3rd party,’’
‘‘API,’’ and ‘‘patient health information
capture’’ certification criteria better
support interoperability and innovation
in patient engagement. We have seen
developers integrate secure messaging
functionality as part of other patient
engagement features, such as patient
portals, and integrate messaging with
access to and exchange of clinical and
administrative data. These integrated
technologies currently in use offer more
comprehensive options for providers
and patients to interact and share
information via a secure platform and
may render the separate ‘‘secure
messaging’’ criterion and functionality
redundant to robust integrated options.
We also believe removing the
standalone ‘‘secure messaging’’ criterion
will encourage the market to pursue
other innovative means of offering
patient engagement and interaction
functionalities that providers and
patients want, with the convenience and
efficiency they demand. Thus, we
believe that the removal of this criterion
will help reduce burden and costs
without negative impact on current or
future innovations in patient
engagement and secure information
exchange. In response to the concern
about new market entrants being able to
receive data needed to serve their
customers, we note that the ‘‘view,
download, and transmit to 3rd party’’
criterion remains available for patients
who wish to send their health
information to a third party of the
patient’s choice. Other remaining
interoperability-focused criteria, such as
‘‘transitions of care,’’ ensure that
systems of health IT certified to at least
those criteria remaining in the ‘‘Base
EHR’’ definition will remain capable of
supporting providers’ use of new
entrant and other third party health IT
of their choosing without requiring that
health IT to integrate or interface with
their certified health IT.
PO 00000
Frm 00022
Fmt 4701
Sfmt 4700
5. Removal of Certain ONC Health IT
Certification Program Requirements
We proposed to remove certain
mandatory disclosure requirements and
a related attestation requirement under
the Program. As discussed in the
Proposed Rule (84 FR 7437), we believe
removal of these requirements will
reduce costs and burden for Program
stakeholders, particularly for health IT
developers and ONC–ACBs.
a. Limitations Disclosures
We proposed to remove
§ 170.523(k)(1)(iii)(B), which requires
ONC–ACBs to ensure that certified
health IT includes a detailed description
of all known material information
concerning limitations that a user may
encounter in the course of
implementing and using the certified
health IT, whether to meet ‘‘meaningful
use’’ objectives and measures or to
achieve any other use within the scope
of the health IT’s certification. We
proposed to remove
§ 170.523(k)(1)(iv)(B) and (C), which
state that the types of information
required to be disclosed include, but are
not limited to: (B) Limitations, whether
by contract or otherwise, on the use of
any capability to which technology is
certified for any purpose within the
scope of the technology’s certification;
or in connection with any data
generated in the course of using any
capability to which health IT is
certified; (C) limitations, including but
not limited to technical or practical
limitations of technology or its
capabilities, that could prevent or
impair the successful implementation,
configuration, customization,
maintenance, support, or use of any
capabilities to which technology is
certified; or that could prevent or limit
the use, exchange, or portability of any
data generated in the course of using
any capability to which technology is
certified.
Comments. Most of the comments
specifically referencing this proposal
were supportive. A few commenters
raised concerns regarding the utility of
mandatory disclosures to health care
providers, their health information
exchange partners, and ONC, with some
commenters offering suggestions for
how ONC could use disclosures
information in the future. A few
commenters’ concerns specifically
referenced the disclosure of costs
information.
Response. We thank commenters for
their input. We have finalized removal
of § 170.523(k)(1)(iii)(B) and
§ 170.523(k)(1)(iv)(B) and (C), as
proposed (84 FR 7437 and 7438). As
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
discussed in the Proposed Rule (84 FR
7438), these specific disclosure
requirements are superseded by the
Cures Act information blocking
provision and Conditions of
Certification requirements, which we
proposed to implement in the same
Proposed Rule (84 FR 7424). As also
noted in the Proposed Rule (84 FR
7438), we proposed (84 FR 7465 and
7466) a complementary Condition of
Certification requirement that
developers would be prohibited from
taking any action that could interfere
with a user’s ability to access or use
certified capabilities for any purpose
within the scope of the technology’s
certification discussed further in section
VII.2.
We also note here to ensure clarity
that we did not propose, and have not
finalized, a complete removal of the
transparency requirements in
§ 170.523(k)(1). Requirements under
§ 170.523(k)(1) other than those
specifically proposed for removal will
remain in place. The transparency
requirements remaining in place
include: § 170.523(k)(1)(iii)(A), which
describes the plain language detailed
description of all known material
information concerning additional types
of costs that a user may be required to
pay to implement or use the Complete
EHR or Health IT Module’s capabilities,
whether to meet meaningful use
objectives and measures, or to achieve
any other use within the scope of the
health IT’s certification; and
§ 170.523(k)(1)(iv)(A) specification that
the types of information required by
§ 170.523(k)(1)(iii) include, but are not
limited to, additional types of costs or
fees (whether fixed, recurring,
transaction-based, or otherwise)
imposed by a health IT developer (or
any third party from whom the
developer purchases, licenses, or
obtains any technology, products, or
services in connection with its certified
health IT) to purchase, license,
implement, maintain, upgrade, use, or
otherwise enable and support the use of
capabilities to which health IT is
certified; or in connection with any data
generated in the course of using any
capability to which health IT is
certified.
b. Transparency and Mandatory
Disclosures Requirements
We proposed to remove the Principle
of Proper Conduct (PoPC) in
§ 170.523(k)(2), which requires ONC–
ACBs to ensure health IT developers’
adherence to a requirement that the
health IT developer submit an
attestation that it will disclose all of the
information in its mandatory
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
disclosures per § 170.523(k)(1) to
specified parties (e.g., potential
customers or anyone inquiring about a
product quote or description of
services). As discussed in the Proposed
Rule (84 FR 7438), we believe this
provision is no longer necessary and
that its removal is appropriate to further
reduce administrative burden for health
IT developers and ONC–ACBs.
Comments. The majority of
commenters specifically discussing this
proposal expressed support for the
removal of the PoPC in § 170.523(k)(2).
A few commenters expressed concern
that the high degree of transparency
ONC noted in the Proposed Rule might
not be maintained as they noted a
possibility that the PoPC requiring the
ONC–ACBs to ensure the developers
submitted an attestation, and, in turn,
the developers’ obligation to make the
attestation, may be driving the currently
observed levels of transparency.
Response. We thank commenters for
their input. We have decided to finalize
the removal of the PoPC in
§ 170.523(k)(2). We appreciate the
importance of holding health IT
developers accountable for meeting all
requirements of participation in the
Program, including meeting or
exceeding the minimum required
transparency disclosures. We believe
that the needed transparency and
accountability will be maintained and
enhanced by certain Condition and
Maintenance of Certification
requirements we have finalized in this
rule, which include the assurances and
attestations specifically discussed in
section VII.2 in relation to this proposed
removal of § 170.523(k)(2). We believe
that the removal of the PoPC
requirements in § 170.523(k)(2) will
likely aid in the avoidance of
unnecessary costs and burden for
Program stakeholders, particularly
health IT developers and ONC–ACBs.
6. Recognition of Food and Drug
Administration Processes
Section 618 of the Food and Drug
Administration Safety and Innovation
Act (FDASIA), Public Law 112–144,
required that the Food and Drug
Administration (FDA), in consultation
with ONC and the Federal
Communications Commission (FCC)
(collectively referred to as ‘‘the
Agencies’’ 18 for this final rule), develop
a report containing a proposed strategy
and recommendations on an
appropriate, risk-based regulatory
framework pertaining to health IT,
including mobile medical applications,
18 ONC is not an agency, but an office within the
Department of Health and Human Services.
PO 00000
Frm 00023
Fmt 4701
Sfmt 4700
25663
that promotes innovation, protects
patient safety, and avoids regulatory
duplication. The FDASIA Health IT
Report of April 2014,19 contained a
proposed strategy and recommendations
on an appropriate, risk-based regulatory
framework pertaining to health IT that
promotes innovation, protects patient
safety, and avoids regulatory
duplication. Public comments, received
prior to the report’s publication and
after,20 recommended that health IT
developers/manufacturers apply a single
process that satisfies the requirements of
all agencies, and existing safety and
quality-related processes, systems, and
standards should be leveraged for
patient safety in health IT. On July 27,
2017, FDA announced a voluntary
Software Precertification Pilot Program
as part of a broader Digital Health
Innovation Action Plan.21 It was
developed in order to create a tailored
approach toward recognizing the unique
characteristics of digital technology by
looking first at the firm, rather than
primarily at each product of the firm, as
is currently done for traditional medical
products. The FDA plans to explore
whether and how pre-certified
companies that have demonstrated a
culture of quality, patient safety, and
organizational excellence could bring
certain types of digital health products
to market either without FDA premarket
review or with a more streamlined FDA
premarket review.
a. FDA Software Precertification Pilot
Program
We proposed (84 FR 7438 and 7439)
to establish processes that would
provide health IT developers that can
document holding pre-certification
under the FDA Software Precertification
Pilot Program with exemptions to the
ONC Health IT Certification Program’s
requirements for testing and
certification of its health IT to the 2015
Edition ‘‘quality management systems’’
criterion (§ 170.315(g)(4)) and the 2015
Edition ‘‘safety-enhanced design’’
criterion (§ 170.315(g)(3)), as these
criteria are applicable to the health IT
developer’s health IT presented for
19 https://www.fda.gov/downloads/AboutFDA/
CentersOffices/
OfficeofMedicalProductsandTobacco/CDRH/
CDRHReports/UCM391521.pdf.
20 https://www.federalregister.gov/documents/
2013/05/30/2013-12817/food-and-drugadministration-safety-and-innovation-act-fdasiarequest-for-comments-on-the, https://blogs.fda.gov/
fdavoice/index.php/2014/04/fda-seeks-commenton-proposed-health-it-strategy-that-aims-topromote-innovation/ and https://
www.regulations.gov/document?D=FDA-2014-N0339-0001.
21 https://www.fda.gov/MedicalDevices/
DigitalHealth/DigitalHealthPreCertProgram/
Default.htm.
E:\FR\FM\01MYR3.SGM
01MYR3
25664
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
certification. We also stated that such a
‘‘recognition’’ could, depending on the
final framework of the FDA Software
Precertification Pilot Program, be
applicable to the functionally-based
2015 Edition ‘‘clinical’’ certification
criteria (§ 170.315(a)). We noted in the
Proposed Rule that the proposed
‘‘recognition’’ could also be appropriate
to address any or all of the following
functionally-based 2015 Edition criteria
in the event their proposed removal
were not finalized: ‘‘problem list’’
(§ 170.315(a)(6)), ‘‘medication list’’
(§ 170.315(a)(7)), ‘‘medication allergy
list’’ (§ 170.315(a)(8)), ‘‘drug-formulary
and preferred drug list checks’’
(§ 170.315(a)(10)),’’ and ‘‘smoking
status’’ (§ 170.315(a)(11)).
We noted (84 FR 7439) that despite
proffered benefits including alignment
with both EOs 13563 and 13771
regarding deregulatory, less
burdensome, and more effective
regulatory schemes and programs, and
serving as a regulatory relief for those
health IT developers qualifying as small
businesses under the Regulatory
Flexibility Act (84 FR 7587 and 7588),
there may be reasons not to adopt such
a ‘‘recognition’’ approach. We noted as
examples of such reasons that
stakeholders may not agree that the FDA
Software Precertification Program
sufficiently aligns with our Program,
and that stakeholders may have
operational concerns. Accordingly, we
welcomed comments on these and other
aspects of our proposed ‘‘recognition’’
approach, including the 2015 Edition
certification criteria that should be
eligible for ‘‘recognition.’’
Comments. The majority of
commenters commended ONC’s efforts
to recognize the FDA Software
Precertification Program. However, most
commenters expressed concerns that
FDA’s program was not yet mature
enough to assess the degree of alignment
to the ONC Health IT Certification
Program. Many commenters expressed
concerns that the FDA Software
Precertification Pilot Program focuses
on development and business practices,
with a potential for streamlining
requirements for pre-market clearance of
specific functionalities, while ONC’s
certification Program focuses less on
development practices and more on
certification of individual software
products as meeting Program-specified
requirements for functionality and
interoperability, including conformance
with specific interoperability standards.
Many of these commenters indicated
that until the FDA program is more fully
mature they would prefer to reserve
judgment on how recognition could or
should be structured to satisfy the needs
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
of ONC’s Program at lower burden on
those developers for whom dual
participation is a need or an appealing
option. Several commenters noted
potential for recognition of developers
who achieve precertification status
under the FDA’s program to streamline
or offer them a low-burden option for
satisfying certain requirements under
ONC’s Program. However, several
commenters urged that obtaining FDA
precertification status should not be the
only way a developer could satisfy any
requirement under ONC’s Program,
noting that a developer of one or more
certified Health IT Modules that is
newer to the market or simply smaller
and not engaged in development of
software subject to FDA regulation
could find the FDA Software
Precertification Program’s requirements
a higher hurdle to entering or remaining
in the ONC-certified health IT market
sector than the ONC requirements the
recognition might replace.
Response. Considering commenters’
concerns and the maturity of the FDA
Software Precertification Program—
which remains in a pilot phase at the
time this final rule is being drafted—we
have decided not to finalize recognition
of the FDA Software Precertification
Program at this time. However, we
anticipate continuing to consult and
coordinate with our colleagues at FDA
and to monitor the details and
experience of the FDA Software
Precertification Program as it continues
to mature. We continue to believe that
there may be potential for recognition of
the FDA Software Precertification
Program to contribute in the future to
our ongoing goals of reducing burden
and promoting innovation while
maintaining or enhancing the assurance
that the ONC Health IT Certification
Program provides, but we have not
finalized our proposal at this time.
b. Development of Similar Independent
Program Processes—Request for
Information
In the Proposed Rule (84 FR 7439), we
included a request for information (RFI)
related to the development of similar
independent processes to those of the
FDA Software Precertification Program
for purposes of our Program. We
received 21 comments on this RFI and
appreciate the input provided by
commenters. We will continue to
consider whether to develop similar
independent processes and whether this
should be included in future
rulemaking.
PO 00000
Frm 00024
Fmt 4701
Sfmt 4700
IV. Updates to the 2015 Edition
Certification Criteria
In order to capture and share patient
data efficiently, health care providers
need health IT that store data in
structured formats. Structured data
allows health care providers to easily
retrieve and transfer patient
information, and use health IT in ways
that can aid patient care. We proposed
to update the 2015 Edition by adopting
a limited set of revised and new 2015
Edition certification criteria, including
new standards, to support these
objectives. Some of these criteria and
standards are included in the Certified
EHR Technology (CEHRT) definition
used for participation in HHS Programs,
such as the Promoting Interoperability
(PI) Programs (formerly the EHR
Incentive Programs), some are required
to be met for participation in the ONC
Health IT Certification Program, and
some, though beneficial, are
unassociated with the CEHRT definition
and not required for participation in any
HHS program, including the ONC
Health IT Certification Program
(Program).
Comments. We received a few
comments in support of our approach to
modify the 2015 Edition health IT
certification criteria. One commenter
commended ONC for proposing logical
updates to the 2015 Edition certification
criteria, rather than overhauling the
Program or establishing a new edition of
certification, stating iterative changes
will provide stability and allow the
industry to adapt to new market forces.
Commenters stated that this incremental
approach best serves the health care
provider and health IT developer
community. One commenter applauded
ONC for proposing logical updates to
the 2015 Edition health IT certification
criteria and recommended that ONC
continue to seek to maximize the impact
of these certification changes and
pursue all opportunities to simplify
existing criteria.
However, a number of commenters
requested that ONC put forth a new
edition and suggested varied approaches
to a new edition. Commenters suggested
that ONC clearly delineate the
difference between the editions by
creating a new naming convention for
the updated criteria, such as a version
number. Others recommended a 2020
Edition or the corresponding year in
which this rule is effective. Still other
commenters recommended the
proposed updated 2015 Edition be
renamed to the 2021 Edition instead of
renamed with a Release 2 at end of the
existing name. Some commenters
identified the scope of the proposed
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
changes as the reason ONC should
establish the updates as a new edition
of certification criteria rather than
simply updating the 2015 Edition.
However, the majority of commenters
recommending a new edition based
their concern on the potential confusion
among providers who purchase and use
certified health IT resulting from
different products available under the
same label.
Response. We thank commenters for
their input on the tradeoffs associated
with modifying the current 2015 Edition
versus creating a new edition. We
considered a variety of factors when we
framed our proposals. First, we
reviewed the scope of each proposed
update and the cumulative scope of the
proposals overall for health IT
developers and sought to identify
whether it would be more appropriate to
require health IT developers
participating in the Program to
implement updates to Health IT
Modules certified to the 2015 Edition or
to test and certify health IT products to
an entirely new edition of certification
criteria. Second, we considered the
impact that either approach would have
on health care providers, including how
such updated Health IT Modules or
products certified to a new edition
would be implemented by providers
participating in CMS programs.
We have considered the impact on
health IT developers related to the scope
of the individual updates as well as the
cumulative scope of all updates to the
2015 Edition adopted in this final rule
(see also section XIII Regulatory Impact
Analysis). In this final rule, we have
only adopted two new technical
certification criteria in § 170.315(b)(10)
and § 170.315(g)(10) to which health IT
developers seeking to upgrade their
products will need to present Health IT
Modules for certification. Unlike the
new criteria introduced in prior
certification edition rulemakings, both
of these new criteria are an expansion
or modification of existing criteria
within the 2015 Edition which are
currently in use in certified health IT.
The new criteria in § 170.315(b)(10)
relates to the 2015 Edition criteria in
§ 170.315(b)(6) with an expansion of the
data and a removal of the specificity for
the standard requirement. The new
Standardized API criteria in
§ 170.315(g)(10) relates to the 2015
Edition API criteria with an expansion
of security requirements and the
addition of applicable standards. For the
remainder of the updated criteria, a
developer would not be required to
present a Health IT Module for
certification in order to update a
certified product in accordance with
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
this final rule. Instead, a health IT
developer would update their certified
Health IT Module, notify the ONC–ACB
that they have done so, and make the
update available their customers.
Additionally, unlike prior certification
edition rulemakings, the certification
criteria updated to address compliance
with the USCDI do not include new
functionality nor do they require a
complete redesign of Health IT Modules
certified to such certification criteria. As
noted in the Proposed Rule, the updates
to the CCDS to create the USCDI were
intentionally limited to a modest
expansion that most health IT
developers already supported, were
already working toward, or should be
capable of updating their health IT to
support in a timely manner. Please see
Table 1 for a list of all certification
criteria changes.
In consideration of the impact our
approach would have on health care
providers, we note that impact and
potential burden for providers is of
particular importance given that
CY2019 was the first performance year
where eligible clinicians (ECs), eligible
hospitals, dual-eligible hospitals, and
critical access hospitals (CAHs)
participating in CMS programs—
including the CMS Promoting
Interoperability Program and the
Quality Payment Program/Merit-based
Incentive Payment System—were
required to use health information
technology certified to the 2015 Edition
to meet the requirements of the CMS
CEHRT definition. If we were to adopt
a new edition of certification criteria,
CMS programs would have to consider
establishing a new CEHRT definition
and a subsequent requirement for
program participants who have only
recently completed a full edition update
to their technology used for program
participation. Historically, with a new
edition of certification criteria, health IT
developers have packaged Health IT
Modules certified to new, modified, and
unchanged criteria into a wholly new
certified product. Historical data
indicates that these complete updates to
the edition are particularly challenging
for both health IT developers seeking
certification and for health care
providers as they place deadlines for a
significant number of health IT
developers to support and implement
new products for a significant number
of health care providers simultaneously.
As a result, the burden of updating the
technology is compounded for both
health IT developers and health care
providers. While ONC does not itself
place any such requirements on health
care providers, we believe the risk of
PO 00000
Frm 00025
Fmt 4701
Sfmt 4700
25665
such significant burden must be
considered in health IT policy
decisions.
Further, we believe the scope of the
updates and the impact on health IT
developers and health care providers
must be considered in tandem—
meaning that an entirely new edition
should only be established when the
scope of the updates is significant
enough to warrant the impacts of
implementation. When the scope of
updates does not warrant
implementation of an entirely new
edition of certification criteria, we
believe it is appropriate to update the
existing criteria. For example the 2015
Edition included new criteria that were
neither built upon nor updated to
existing criteria in the 2014 Edition,
which was significantly different than
the 2011 Edition. In contrast, health IT
developers have been able to employ
regular or cyclical updates without
modifying all Health IT Modules
certified to unchanged criteria in order
to implement updates to existing
certification criteria such as the annual
updates to CMS eCQMs or for changes
made to public health reporting
standards. In such cases, the changes
may be implemented by health IT
developers in the manner most
appropriate for their product and their
customers, such as through routine
service and maintenance rather than a
completely new implementation.
In order to understand the impact
these updates would have on
participants in the CMS programs which
reference them for use by program
participants, we compare these updates
to the current definition of CEHRT
established by CMS at 42 CFR 495.4 for
eligible hospitals, CAHs and Medicaid
eligible professionals and at 42 CFR
414.1305 for eligible clinicians in MIPS.
For 2019 and subsequent years, the CMS
CEHRT definition specifies the use of
EHR technology certified to 2015
Edition including technology that meets
the 2015 Edition Base EHR definition in
§ 170.102, as well as other certified
technology necessary to be a meaningful
user. The updates finalized in this final
rule impact both certification criteria
included in the Base EHR definition as
well as criteria required for applicable
objectives and measures. Specifically,
this final rule updates several criteria
currently applicable for certified Health
IT Modules used by CMS program
participants for the CMS objectives and
measures necessary to be a meaningful
user, including:
• Revisions to the electronic
prescribing criterion in § 170.315(b)(3)
to reference an updated e-prescribing
standard;
E:\FR\FM\01MYR3.SGM
01MYR3
25666
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
• Revisions relating to the drugformulary and preferred drug list checks
criterion in § 170.315(a)(10) to include
at 170.550(m)(1) to only allow ONC–
ACBs to issue certificates for this
criterion until January 1, 2022;
• Replacement of the API criterion in
§ 170.315(g)(8) with a new API criterion
in § 170.315(g)(10) referencing an API
standard and related security standards;
• Revisions to several criteria to
reference the USCDI and implement
other standards updates (see Table 1 for
specifics); and
• Revisions to § 170.315(c)(3), to
update quality reporting standards.
In general, health IT developers have
24 months from the publication date of
the final rule to make technology
certified to these updated criteria
available to their customers, and during
this time developers may continue
supporting technology certified to the
prior version of certification criteria for
use by their customers. For providers
participating in CMS programs, this
means they can continue to use the
certified technology they have available
to them to support program
participation and can work with their
developers to implement any updates in
a manner that best meets their needs.
For the revisions to electronic
prescribing criterion in § 170.315(b)(3)
and to the quality reporting standards,
in § 170.315(c)(3), the updates adopted
for certified health IT align specifically
with changes already required by CMS
for use by health care providers. This
means health IT developers are already
implementing and supporting these
updates. The implementation of these
updates is driven by other requirements
and so repackaging such updates in a
new edition (or a new product) would
create a redundancy and could have
unintended cost burden on health care
providers. For the updates to the criteria
referencing the USCDI, as noted
previously, we based the USCDI on the
existing CCDS with modest expansion
that most health IT developers already
supported, were already working
toward, or should be capable of
updating their health IT to support in a
timely manner. Finally, for the removal
of the drug-formulary and preferred
drug list checks in § 170.315(a)(10), we
note that the removal from the Program
has negligible impact on health care
providers.
First, as discussed in past CMS
regulations related to the use of these
functionalities by participants in CMS
programs, health care providers have
noted that while formulary checks are a
promising approach, the utility of the
specific functionality that is certified is
not necessarily consistently applicable
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
for all prescriptions (80 FR 62833).
Second, as it does not remove the
product from the market, any providers
who are using the current functionality
may continue to use the technology for
their purposes. For the replacement of
the API criterion in § 170.315(g)(8) with
a new Standardized API criterion in
§ 170.315(g)(10) referencing an API
standard and related security standards,
we reiterate that health IT developers
have 24 months from the date of
publication of this final rule to update
their technology and make such
available to their customers. The 2015
Edition final rule adopted an API
criterion in § 170.315(g)(8) which was
implemented by many health IT
developers using the underlying
standard adopted in this final rule for
the Standardized API criterion in
§ 170.315(g)(10). This common use
impacted our decision to adopt the
standard in our update to the 2015
Edition (see also section VII.B.4.c
Standardized API for Patient and
Population Services). We, therefore,
believe that both the scope of the
updates and the potential impact on
health IT developers and health care
providers do not constitute sufficient
justification for the potential burden
associated with adopting an entirely
new edition of certification criteria.
Instead, we believe it is most reasonable
and effective for these updates to be part
of the existing 2015 Edition as modified
in this final rule.
We acknowledge the concerns of
commenters who expressed the
potential risk of confusion about the
updates among their customers and how
to best communicate that a product
meets the updated version of a given
certification criterion. We strongly
encourage health IT developers to work
with their customers to promote
understanding of these updates. In
addition, we have taken several
mitigating steps. First, we revisited our
proposed regulatory structure and
revised it so that the structure more
clearly reflects if a change is updating
the previously adopted standard, or a
more significant change to the criterion
such as adding a new standard. This
maintains the prior 2015 Edition
regulatory structure for the majority of
the updates except for § 170.315(b)(10)
and (g)(10) as discussed previously, and
establishes a more clear sense of scope.
Second, in order to support effective
communication of the updates, we are
implementing a practical approach to
facilitate transparency using the
Certified Health IT Product List
PO 00000
Frm 00026
Fmt 4701
Sfmt 4700
(CHPL),22 which is the tool that health
care providers and the general public
may use to identify the specific
certification status of a product at any
given time, to explore any certification
actions for a product, and to obtain a
CMS Certification ID for a product used
when participating in CMS programs.
While we retain the overall 2015 Edition
title, we will distinguish the 2015
Edition certification criteria from the
new or revised criteria adopted in this
final rule by referring to the new or
revised criteria as the 2015 Edition
Cures Update on the CHPL for products
that are certified. The CHPL will also
differentiate to what standards the
health IT will be certified and will allow
health care providers to identify if and
when a specific Health IT Module has
been updated. This will help to
eliminate some of the confusion among
providers who are seeking to
understand the certification and update
the status of the product they are
currently using. It can also be a resource
for providers who may be making a new
purchase of certified health IT to make
an informed decision about which
products support the most up to date
available standards and functionality.
We further note that, while in the past
ONC has largely relied on creating a
new edition to implement changes to
certification criteria, in each case, those
changes included some updates to
existing criteria, but also criteria
containing functionality and standards
that were entirely new and did not build
on the prior edition. In addition, the
Cures Act set in motion a shift for the
ONC Health IT Certification Program by
including Conditions and Maintenance
of Certification requirements which
allowed for processes such as the
Standards Version Advancement
Process (SVAP) flexibility within real
world testing, which allows better
alignment to industry efforts for
standards advancement while
maintaining accountability. These new
provisions help to remove barriers for
standards development and version
updates, which limit a health IT
developer’s ability to provide
individually relevant, timely, and
innovative solutions to their clients.
This change is consistent with our
approach to adopt incremental updates
in this final rule rather than to adopt a
complete new edition of certification
criteria. This final rule is the first time
we have executed on the concept of
Maintenance of Certification
requirements for existing certificates,
and we foresee the potential for future
22 ONC Certified Health IT Product List: https://
chpl.healthit.gov.
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
rulemakings to include incremental
updates to certification criteria when
such updates are appropriate.
25667
Please see Table 1 for a list of all
certification criteria changes.
TABLE 1—2015 EDITION CURES UPDATE
Certification criteria
Reference
New/revised/
removed/timelimited certification
Problem list ..................
§ 170.315(a)(6) .....
Removed ..............
Medication list ..............
§ 170.315(a)(7) .....
Removed ..............
Medication allergy list ..
§ 170.315(a)(8) .....
Removed ..............
Drug Formulary and
Preferred Drug List
Checks.
§ 170.315(a)(10) ...
Time-limited Certification.
Smoking status ............
§ 170.315(a)(11) ...
Removed ..............
Patient-specific Education Resource.
§ 170.315(a)(13) ...
Time-limited Certification.
Transitions of Care ......
§ 170.315(b)(1) .....
Revised ................
Update to USCDI/C–CDA companion guide
within 24 months after the publication date of
final rule.
Clinical information reconciliation and incorporation.
Electronic prescribing ..
§ 170.315(b)(2) .....
Revised ................
§ 170.315(b)(3) .....
Revised ................
§ 170.315(b)(4) .....
Removed ..............
Update to USCDI/C–CDA companion guide
within 24 months after the publication date of
final rule.
Update standard within 24 months after the
publication of final rule.
Effective date of final rule (60 days after publication).
§ 170.315(b)(5) .....
Removed ..............
Effective date of final rule (60 days after publication).
§ 170.315(b)(6) .....
Time-limited Certification.
Security tags—summary of care—send.
§ 170.315(b)(7) .....
Revised ................
Security tags—summary of care—receive.
Care plan .....................
§ 170.315(b)(8) .....
Revised ................
§ 170.315(b)(9) .....
Revised ................
EHI export ....................
§ 170.315(b)(10) ...
New ......................
Clinical quality measures (CQMs)—report.
Auditable events and
tamper-resistance.
Audit report(s) ..............
§ 170.315(c)(3) .....
Revised ................
§ 170.315(d)(2) .....
Revised ................
§ 170.315(d)(3) .....
Revised ................
Auditing actions on
health information.
Encrypt authentication
credentials.
§ 170.315(d)(10) ...
Revised ................
§ 170.315(d)(12) ...
New ......................
Multi-factor authentication (MFA).
§ 170.315(d)(13) ...
New ......................
View, Download, and
Transmit to 3rd Party.
§ 170.315(e)(1) .....
Revised ................
Secure Messaging .......
§ 170.315(e)(2) .....
Time-limited Certification.
ONC–ACBs may only issue certificates until 36
months after the publication date of the final
rule.
Document, section, and entry (data element)
level; or Document level for the period until
24 months after publication date of final rule.
Document, section, and entry (data element)
level; or Document level for the period until
24 months after publication date of final rule.
Update to C–CDA companion guide within 24
months after publication date of final rule.
Update within 36 months of publication date of
final rule.
Effective date of final rule (60 days after publication).
Update to new ASTM standard within 24
months after publication date of final rule.
Update to new ASTM standard within 24
months after publication date of final rule.
Update to new ASTM standard within 24
months after publication date of final rule.
Effective date of final rule (60 days after publication) (New and updated certifications
only).
Effective date of final rule (60 days after publication) (New and updated certifications
only).
Update to USCDI/C–CDA companion guide
within 24 months after publication date of
final rule.
ONC–ACBs only permitted to issue certificates
for this criterion until January 1, 2022.
Transmission to public
health agencies—
electronic case reporting.
Consolidated CDA creation performance.
§ 170.315(f)(5) ......
Revised ................
Update to USCDI/C–CDA companion guide
within 24 months after publication date of
final rule.
§ 170.315(g)(6) .....
Revised ................
Application Access—
Data Category Request.
§ 170.315(g)(8) .....
Time-limited Certification.
Update to USCDI/C–CDA companion guide
within 24 months after publication date of
final rule.
24 months after publication date of final rule ...
Common Clinical Data
Set summary
record—create.
Common Clinical Data
Set summary
record—receive.
Data Export ..................
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
PO 00000
2015 Edition cures update—timing
Impact on CMS promoting interoperability (PI)
programs
Effective date of final rule (60 days after publication).
Effective date of final rule (60 days after publication).
Effective date of final rule (60 days after publication).
ONC–ACBs only permitted to issue certificates
for this criterion until January 1, 2022.
Removed from 2015 Edition Base EHR definition.
Removed from 2015 Edition Base EHR definition.
Removed from 2015 Edition Base EHR definition.
PI Measures:
—e-Rx
—-Query of PDMP Operational for Medicaid
until January 1, 2022.
Removed from 2015 Edition Base EHR definition.
Operational for Medicaid until January 1, 2022
Supports Patient Electronic Access to Health
Information Objective Measure.
PI Measures:
—Support Electronic Referral Loops by
Sending Health Information
—Support Electronic Referral Loops by Receiving and Incorporating Health Information.
PI Measures:
—Support Electronic Referral Loops by Receiving and Incorporating Health Information.
PI Measures:
—e-Prescribing.
Effective date of final rule (60 days after publication).
ONC–ACBs only permitted to issue certificates
for this criterion until January 1, 2022.
Frm 00027
Fmt 4701
Sfmt 4700
Removed from 2015 Edition Base EHR definition effective date of the final rule (60 days
after publication).
PI Programs.
PI Measure:
—Provide Patients Electronic Access to
Their Health Information.
Operational for Medicaid until January 1, 2022
Supports the Coordination of Care through
Patient Engagement Objective.
PI Measure:
—Electronic Case Reporting.
PI Measure:
—Provide Patients Electronic Access to
Their Health Information.
E:\FR\FM\01MYR3.SGM
01MYR3
25668
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
TABLE 1—2015 EDITION CURES UPDATE—Continued
Certification criteria
Reference
New/revised/
removed/timelimited certification
Application Access—All
Data Request.
§ 170.315(g)(9) .....
Revised ................
Standardized API for
patient and population services.
§ 170.315(g)(10) ...
New ......................
2015 Edition cures update—timing
Impact on CMS promoting interoperability (PI)
programs
Update to USCDI/C–CDA companion guide
within 24 months after publication date of
final rule.
Update within 24 months of publication date of
final rule.
PI Measure:
—Provide Patients Electronic Access to
Their Health Information.
Added to the 2015 Edition Base EHR definition.
Note: The CHPL will be updated to indicate the standards utilized for new or revised certification criteria, as well as denote criteria removed from the Program.
A. Standards and Implementation
Specifications
1. National Technology Transfer and
Advancement Act
The National Technology Transfer
and Advancement Act (NTTAA) of 1995
(15 U.S.C. 3701 et. seq.) and the Office
of Management and Budget (OMB)
Circular A–119 23 require the use of,
wherever practical, technical standards
that are developed or adopted by
voluntary consensus standards bodies to
carry out policy objectives or activities,
with certain exceptions. The NTTAA
and OMB Circular A–119 provide
exceptions to electing only standards
developed or adopted by voluntary
consensus standards bodies, namely
when doing so would be inconsistent
with applicable law or otherwise
impractical. Agencies have the
discretion to decline the use of existing
voluntary consensus standards if
determined that such standards are
inconsistent with applicable law or
otherwise impractical, and instead use a
government-unique standard or other
standard. In addition to the
consideration of voluntary consensus
standards, the OMB Circular A–119
recognizes the contributions of
standardization activities that take place
outside of the voluntary consensus
standards process. Therefore, in
instances where use of voluntary
consensus standards would be
inconsistent with applicable law or
otherwise impracticable, other
standards should be considered that
meet the agency’s regulatory,
procurement or program needs, deliver
favorable technical and economic
outcomes, and are widely utilized in the
marketplace.
Comments. A couple of commenters
stated that they do not support Federal
programs’ use of the NTTAA voluntary
consensus standards exceptions, and
asked that the involved Federal
programs continue to utilize consensusbased standards developed through
23 https://www.whitehouse.gov/sites/
whitehouse.gov/files/omb/circulars/A119/revised_
circular_a-119_as_of_1_22.pdf.
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
work done by organizations such as
HL7®. They noted that such work
incorporates public health inputs, and
stated that it is critical for there to be
sufficient discussion and consideration
of all stakeholder concerns in adopting
such critical technologies such as
FHIR®.
Response. We thank commenters for
their feedback. We clarify that many of
the standards we adopt in this final rule
are developed and/or adopted by
voluntary consensus standards bodies,
except where we found that a
government unique standard is more
appropriate. We are aware of no
voluntary consensus standards that
could serve as an alternative for the
following purposes in this final rule.
In this final rule, we use voluntary
consensus standards except for:
• The standard adopted in § 170.213,
the United States Core Data for
Interoperability (USCDI), Version 1 (v1),
is a hybrid of government unique policy
(i.e., determining which data to include
in the USCDI) and voluntary consensus
standards (i.e., the vocabulary and code
set standards attributed to USCDI data
elements). We have placed time
limitations on the predecessor to this
standard, the Common Clinical Data Set
(CCDS) definition, under this rule, and
replaced it with the USCDI in all
applicable criteria except for the data
export criterion in § 170.315(b)(6), on
which we have also placed a time limit.
We refer readers to the ‘‘Revised and
New 2015 Edition Criteria’’ in section
IV.B of this preamble.
• The standards adopted in
§ 170.205(h)(3) and (k)(3). We replaced
the current HL7® QRDA standards with
government unique standards, the CMS
Implementation Guide for Quality
Reporting Document Architecture:
Category I; Hospital Quality Reporting;
Implementation Guide for 2019, and the
CMS Implementation Guide for Quality
Reporting Document Architecture:
Category III; Eligible Clinicians and
Eligible Professionals Programs;
Implementation Guide for 2019, that
will more effectively support the
associated certification criterion’s use
case, which is reporting electronic
PO 00000
Frm 00028
Fmt 4701
Sfmt 4700
clinical quality measure (eCQM) data to
CMS.
2. Compliance With Adopted Standards
and Implementation Specifications
In accordance with Office of the
Federal Register regulations related to
‘‘incorporation by reference,’’ 1 CFR
part 51, which we follow when we
adopt proposed standards and/or
implementation specifications in a final
rule, the entire standard or
implementation specification document
is deemed published in the Federal
Register when incorporated by reference
therein with the approval of the Director
of the Federal Register. Once published,
compliance with the standard and/or
implementation specification includes
the entire incorporated document,
unless we specify otherwise. For
example, for the HL7® FHIR U.S. Core
Implementation Guide (IG) STU 3.1.0
adopted in this final rule (see section
VII.B.4), health IT certified to
certification criteria referencing this IG
would need to demonstrate compliance
with all mandatory elements and
requirements of the IG. If an element of
the IG is optional or permissive in any
way, it would remain that way for
testing and certification unless we
specified otherwise in regulation. In
such cases, the regulatory text would
preempt the permissiveness of the IG.
3. ‘‘Reasonably Available’’ to Interested
Parties
The Office of the Federal Register has
established requirements for materials
(e.g., standards and implementation
specifications) that agencies propose to
incorporate by reference in the Code of
Federal Regulations (79 FR 66267; 1
CFR 51.5(b)). To comply with these
requirements, in section XI
(‘‘Incorporation by Reference’’) of this
preamble, we provide summaries of,
and uniform resource locators (URLs) to,
the standards and implementation
specifications we have adopted and
subsequently incorporate by reference
in the Code of Federal Regulations. To
note, we also provide relevant
information about these standards and
implementation specifications
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
throughout the relevant preamble policy
discussions and regulation text sections
of the final rule.
B. Revised and New 2015 Edition
Criteria
1. The United States Core Data for
Interoperability Standard (USCDI)
As we noted in the Proposed Rule, the
initial focus of the Program was to
support the Medicare and Medicaid
EHR Incentive Programs (76 FR 1294)
now referred to as the Promoting
Interoperability (PI) Programs. As such,
the 2014 Edition certification criteria
mirrored those functions specified by
the CMS PI Programs objectives and
measures for providers demonstrating
meaningful use (MU) of certified health
IT. In order to improve efficiency and
streamline the common data within our
Program’s certification criteria, we
created a single definition for all the
required data that could be referenced
for all applicable certification criteria.
We created the term ‘‘Common MU Data
Set’’ to encompass the common set of
MU data types/elements (and associated
vocabulary standards) for which
certification would be required across
several certification criteria (77 FR
54170).
The 2015 Edition final rule modified
the Program to make it open and
accessible to more types of health IT,
and health IT that supports various care
and practice settings beyond those
included in the CMS PI Programs (80 FR
62604). In comparison to the previous
editions, the 2015 Edition focused on
identifying health IT components
necessary to establish an interoperable
nationwide health information
infrastructure, fostering innovation and
opening new market opportunities, and
allowing for more health care provider
and patient choices in electronic health
information access and exchange. In
order to align with this approach, we
made changes in the 2015 Edition final
rule that resulted in updated vocabulary
and content standards to improve and
advance interoperability and health
information exchange (80 FR 62604).
The 2015 Edition final rule further
expanded accessibility and availability
of data exchanged by updating the
definition of Base EHR in the 2015
Edition to include enhanced data
export, transitions of care, and
application programming interface (API)
capabilities, all of which previously
required that, at a minimum, the CCDS
be available (80 FR 62602 through
62604).
We further noted in the Proposed
Rule (84 FR 7440) that the regulatory
approach to using and referencing a
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
‘‘definition’’ to identify electronic
health information, for access, exchange
and use, including associated
vocabulary codes, has had its
drawbacks. While ONC’s ‘‘CCDS’’
definition served its designed purpose
(to reduce repetitive text in each of the
certification criteria in which it is
referenced), the term CCDS, and the
data set it represents, also began to be
used by outside organizations such as
the Argonaut Project 24 for additional
use cases beyond the C–CDA and ONC’s
Health IT Certification Program. As
these organizations identified the need
to expand the content of the CCDS, the
CCDS definition in regulation became a
limitation to developing additional data
access, exchange, and uses outside of
ONC’s programs. As we move towards
value-based care and the inclusion of
Data Classes that go beyond clinical
data, and as part of ONC’s continued
efforts to evaluate the availability of a
minimum baseline of Data Classes that
must be commonly available for
interoperable exchange, we
acknowledge the need to change and
improve our regulatory approach to the
CCDS. Therefore, in order to advance
interoperability by adopting new data
and vocabulary codes sets that support
data exchange, we proposed to remove
the ‘‘Common Clinical Data Set’’ in
§ 170.315(b)(4) and § 170.315(b)(5), and
its references throughout the 2015
Edition and replace it with the ‘‘United
States Core Data for Interoperability’’
(USCDI) standard. This first version of
USCDI will be designated ‘‘version 1
(v1).’’ The USCDI standard aims to
achieve the goals set forth in the Cures
Act by specifying a common set of data
classes and elements that have been
designed to improve data usage and
interoperable data exchange.
We proposed to adopt the USCDI v1
as a standard defined in § 170.102. Here,
‘‘Standard’’ is defined as a ‘‘technical,
functional, or performance-based rule,
condition, requirement, or specification
that stipulates instructions, fields,
codes, data, materials, characteristics, or
actions.’’ The USCDI standard would be
composed of Data Classes, which may
be further delineated into groupings of
specific Data Element(s). For example,
‘‘patient demographics’’ is a Data Class,
and within that Data Class there is
‘‘patient name,’’ which is a Data
Element. As noted in section IV.B.1.b,
for the overall structure and
organization of the USCDI, please
consult www.healthIT.gov/USCDI.
We noted in the Proposed Rule (84 FR
7441) that ONC intended to establish
and follow a predictable, transparent,
24 https://argonautwiki.hl7.org/Main_Page.
PO 00000
Frm 00029
Fmt 4701
Sfmt 4700
25669
and collaborative process to expand the
USCDI, including providing
stakeholders with the opportunity to
comment on the USCDI’s expansion. We
indicated that once the Secretary adopts
the first version of the USCDI through
rulemaking, which we proposed in
§ 170.213 in the Proposed Rule, health
IT developers would be allowed to take
advantage of the ‘‘Standards Version
Advancement Process’’ (SVAP)
flexibility. The SVAP (which we
proposed in § 170.405(b) and which is
discussed in section VII.B.5, below)
would permit health IT developers to
voluntarily implement and use a newer
version of a Secretary-adopted standard
such as the USCDI, subject to certain
conditions including a requirement that
the newer version is approved for use by
the National Coordinator, and does not
conflict with requirements under other
applicable law. We received a number
of comments regarding these proposals,
which are outlined in the subsections
below.
Comments. We received broad
support for the adoption of version 1 of
the USCDI as a new standard defining
critical health care data to promote
interoperability. Some commenters from
health plans, while supportive of
patient and provider access to health
care data, voiced concerns about health
plans being required to make data
available in the USCDI standard. Other
commenters noted that USCDI v1 does
not include data classes and elements
that pertain to all health care settings,
including public health, and would
therefore not be broadly applicable to all
health care settings.
Response. We thank commenters for
their support of the adoption of USCDI
v1 as a standard. We wish to clarify that
the adoption of version 1 of the USCDI
as a standard for our Program is not
specific to a setting of care, a health care
specialty, or a specific category of health
IT user. Nor is the USCDI specific to a
particular content exchange standard
(e.g., HL7 C–CDA, HL7 FHIR, HL7 V2,
and NCPDP SCRIPT). Rather, it applies
to the certification of health IT and
certified health IT’s ability to send and
receive the Data Elements defined by
USCDI without requirements regarding
functionality, user interface, or the use
of those Data Elements in exchange.
While some users may find few
opportunities to exchange these Data
Elements, many will exchange these
Data Elements frequently, and we
believe that all health care providers
should have certified health IT that can
provide them with a means to
appropriately share and access the
USCDI data set when exchanging data
with other providers. Accordingly, we
E:\FR\FM\01MYR3.SGM
01MYR3
25670
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
seek to clarify a point with respect to
our proposal regarding the USCDI and
health IT certification. For the purposes
of the ONC Health IT Certification
Program, specific certification criteria
are the way the USCDI comes into
effect. For example, the USCDI is
referenced as part of the data
requirements in the updated
‘‘transitions of care’’ certification
criterion (§ 170.315(b)(1)), which also
specifies that for certification to that
criterion, the C–CDA must be used as
the syntax to hold all of the USCDI data.
As we explained, we believe that the
adoption of USCDI v1 for all certified
health IT will advance interoperability
by ensuring utilization of common data
and vocabulary code sets, and that
standardization will support both
electronic exchange and usability of the
data. Furthermore, because ONC will
establish and follow a predictable,
transparent, and collaborative process to
expand future versions of USCDI,
including providing stakeholders with
the opportunity to comment on draft
USCDI’s expansion, stakeholders will
have ample opportunities to advance
additional Data Classes and Data
Elements relevant to a wide range of
health care use cases. After
consideration of these comments and
the overall support of commenters, we
have adopted the USCDI v1 as a
standard in § 170.213.
We have also extended the
compliance timelines with which a
health IT developer needs to update to
the USCDI, therefore, we have not
removed the CCDS definition from
§ 170.102 as proposed but revised it to
remove references to 2014 Edition
standards and provided time limitations
for when health IT developers need to
update to the USCDI.
a. USCDI 2015 Edition Certification
Criteria
We proposed (84 FR 7441) to adopt
the USCDI Version 1 (USCDI v1) in
§ 170.213.25 The USCDI is a
standardized set of health Data Classes
and constituent Data Elements that
would be required to support
nationwide electronic health
25 We note that USCDI v1 is an updated version
and distinguished from the Draft United States Core
Data for Interoperability (USCDI) previously made
available for public review and comment in the
course of its development as a prospective standard.
The data classes and elements in the USCDI v1
were proposed in § 170.213 and defined in the
Proposed Rule, and an additional USCDI v1
document with technical standards information was
posted electronically concurrent with the
publication of the Proposed Rule in order to
provide the public adequate time to fully review
and comment on both the proposed regulation and
the USCDI v1 technical information.
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
information exchange. Once adopted in
this final rule, health IT developers
would be required to update their
certified health IT to support the USCDI
v1 for all certification criteria affected
by this proposed change. We also
proposed conforming changes in the
sections below to update the following
formerly CCDS-dependent 2015 Edition
certification criteria to incorporate the
USCDI standard:
• ‘‘transitions of care’’
(§ 170.315(b)(1));
• ‘‘view, download, and transmit to
3rd party’’ (§ 170.315(e)(1));
• ‘‘transmission to public health
agencies—electronic case reporting’’
(§ 170.315(f)(5));
• ‘‘consolidated CDA creation
performance’’ (§ 170.315(g)(6)); and
• ‘‘application access—all data
request’’ (§ 170.315(g)(9)).
We did not include the ‘‘data export’’
criterion (§ 170.315(b)(6)) in the
proposed list of criteria that would be
revised to include the USCDI standard
because we proposed to remove the
‘‘data export’’ criterion (§ 170.315(b)(6))
and instead proposed to adopt a
criterion that we referenced as ‘‘EHI
export’’ in the Proposed Rule
(§ 170.315(b)(10)). For similar reasons,
we did not include the ‘‘application
access—data category request’’ criterion
(§ 170.315(g)(8)) because we proposed to
replace it with the API certification
criterion (§ 170.315(g)(10)) that derives
its data requirements from the USCDI.
We also proposed, as a Maintenance
of Certification requirement
(§ 170.405(b)(3)) for the real world
testing Condition of Certification
requirement (§ 170.405(a)), that health
IT developers with health IT certified to
the five above-identified certification
criteria prior to the effective date of this
final rule would have to update such
certified health IT to the proposed
revised standards (84 FR 7441 and
7596). We further proposed, as a
Maintenance of Certification
requirement (§ 170.405(b)(3)) for the real
world testing Condition of Certification
requirement (§ 170.405(a)), that health
IT developers must provide the updated
certified health IT to all their customers
with health IT previously certified to
the identified criteria no later than 24
months after the effective date of this
final rule (84 FR 7441 and 84 FR 7596).
For the purposes of meeting this
compliance timeline, we noted that we
expected health IT developers to update
their certified health IT and notify their
ONC–ACB on the date at which they
have reached compliance. We noted that
developers would also need to factor
these updates into their next real world
PO 00000
Frm 00030
Fmt 4701
Sfmt 4700
testing plan as discussed in section
VII.B.5 of the Proposed Rule.26
Comments. The majority of
commenters supported the proposed
adoption of USCDI v1 and incorporation
of the USCDI into the revised and new
certification criteria. Some commenters
expressed concern that incorporation of
the USCDI into the ‘‘transmission to
public health agencies—electronic case
reporting’’ certification criteria could
have a negative impact on data received
by public health reporting programs.
Some commenters stressed the need for
reasonable adoption timelines. Some
suggested a longer adoption and
implementation timeline for
incorporation of the USCDI as part of
certified health IT.
Response. ONC acknowledges that
some entities, such as public health
agencies, may need to consider what the
expanded set of data the USCDI v1
offers may mean to their reporting
programs and requirements. To be clear,
the USCDI’s existence as a stand-alone
standard will not impact or change
public health reporting requirements.
However, certain data now included in
the USCDI, such as clinical notes,
would now become more readily
available for public health reporting and
a State’s public health program’s policy
may need to be revisited if a State seeks
to make use of the ‘‘new’’ data the
adoption of the USCDI stands to make
more easily available, and more usable
upon receipt. We also believe that the
proposed 24-month timeline for
updating certified health IT to comply
with the new USCDI standard in
§ 170.213 is an adequate
implementation timeline, based on
other adoption timelines with similar
technical complexities. We, therefore,
have finalized revisions for the five
above-identified formerly CCDSdependent 2015 Edition certification
criteria to incorporate the USCDI
standard.
We have finalized a modification to
the regulation text for these criteria
based on public comment related to
mitigating the risk of potential
confusion caused by updates to existing
criteria. As discussed earlier in this
preamble (section IV), we received
public comment requesting that all
revised criteria be included in a new
edition of certification criteria. At the
start of section IV, we discuss in
response to these comments that we do
not believe the creation of a new edition
is appropriate given that the scope of
the updates to the 2015 Edition is tied
26 The finalized real world testing Condition and
Maintenance of Certification requirements are
discussed in section VII.B.5 of this final rule.
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
to standards updates required to keep
pace with current industry practices.
However, we do plan to distinguish the
2015 Edition certification criteria from
the updated criteria in this final rule by
referring to them as the 2015 Edition
Cures Update on the CHPL.
However, as Health IT Modules are
updated to the new standards over time,
there is a need to define what is
required for certification and what is
required for compliance to prior
certification. Therefore, we have
finalized that for criteria being updated
from the CCDS to the USCDI, 24 months
after publication date of the final rule
shall be applicable for a transition from
the CCDS to the USCDI. We have
finalized that for the period until 24
months after the publication date of the
final rule, the CCDS remains applicable
for certified Health IT Modules until
such Health IT Modules are updated to
the USCDI. This means that upon the
effective date of the rule, for the
identified criteria the following apply
for certification and compliance:
• The USCDI, or
• The CCDS for the period up to 24
months after the publication date of the
final rule.
This allows for developers to plan the
transition for their products more
effectively and supports certification
continuity. We have finalized a
modification to the regulation text to
require the USCDI, or the CCDS for the
period lasting until 24 months after the
publication date of the final rule.
We have finalized this modification to
the regulation text for the following
criteria:
• ‘‘transitions of care’’
(§ 170.315(b)(1));
• ‘‘view, download, and transmit to
3rd party’’ (§ 170.315(e)(1));
• ‘‘transmission to public health
agencies—electronic case reporting’’
(§ 170.315(f)(5));
• ‘‘consolidated CDA creation
performance’’ (§ 170.315(g)(6)); and
• ‘‘application access—all data
request’’ (§ 170.315(g)(9)).
We have finalized in § 170.405(b)(3),
as a Maintenance of Certification
requirement under the real world testing
Condition of Certification requirement,
that health IT developers with health IT
certified to the five above-identified
certification criteria prior to the
effective date of this final rule, would
have to update such certified health IT
to the revisions within 24 months of the
publication date of this rule.
As of this final rule’s effective date,
the ‘‘data export’’ criterion in
§ 170.315(b)(6) is no longer required as
a part of the 2015 Edition Base EHR
definition. ONC–ACB’s will not be
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
permitted to issue certificates to this
certification criteria after 36 months
after the publication date of this final
rule. As discussed in the ‘‘EHI export’’
section below, we have retained
§ 170.315(b)(6) ‘‘as is,’’ without updates
to the USCDI. Thus, health IT
developers with health IT certified to
the prior certification criterion in
§ 170.315(b)(6) do not have to update
such certified health IT to the revisions
listed above, but are permitted to
maintain or seek new Health IT Module
certification to this criterion should they
desire this functionality.
b. USCDI Standard—Data Classes
Included
As we noted in the Proposed Rule (84
FR 7441), the USCDI Version 1 (USCDI
v1) and its constituent Data Elements
incorporated recommendations we had
accepted from public comments we had
previously received on our Draft USCDI
and Proposed Expansion Process,27
which we published January 5, 2018 as
well as initial feedback on that draft
from the Health IT Advisory Committee,
both of which occurred prior to the
publication of the Proposed Rule. The
standard we proposed to adopt in
§ 170.213 also reflected and
acknowledged the burden that rapidly
expanding the USCDI v1 beyond the
CCDS could cause. As a result, the
USCDI v1 that we proposed was a
modest expansion of the CCDS, which
we indicated that most health IT
developers already supported, were
already working toward, or should be
capable of updating their health IT to
support in a timely manner. Therefore,
in our Proposed Rule, we outlined only
the delta between the CCDS and the
USCDI v1. For the overall structure and
organization of the USCDI standard, we
urged stakeholders to consult
www.healthIT.gov/USCDI.
Comments. We received numerous
comments proposing new Data Classes,
Data Elements, and other changes
within the USCDI beyond those we
included in the Proposed Rule.
Comments recommended including new
Data Elements and/or classes within the
USCDI v1 related to encounter data,
financial transaction and insurance
data, and specialty-specific Data
Elements related to cancer treatment,
social determinants of health, and more.
Another commenter identified an error
in the Procedures Data Class citing the
wrong code set for dental procedures in
the USCDI v1.
Response. We thank the many
commenters for their input on the
27 https://www.healthit.gov/sites/default/files/
draft-uscdi.pdf (January 5, 2018).
PO 00000
Frm 00031
Fmt 4701
Sfmt 4700
25671
USCDI. We recognize that the USCDI v1
as proposed represents a modest change
over the current CCDS definition. As we
indicated in the Proposed Rule (84 FR
7441), we view this initial version of the
USCDI standard as a starting point to
support improved interoperability. We
are also sensitive to requirements
related to the development and
implementation of adopting the USCDI
standard. In the interests of maintaining
our proposed implementation timeline
of 24 months from the publication of
this final rule, and after consideration of
these comments and the overall support
of commenters, we have finalized the
adoption of the Data Classes and
elements of the USCDI standard as
proposed, with changes outlined in the
subsections below. Additionally, in
order to address the error pointed out to
us via comments in the Procedures Data
Class, as was stated in the draft USCDI
v1,28 we clarified that the American
Dental Association’s Code on Dental
Procedures and Nomenclature (CDT)
should be used for Dental Procedures in
the USCDI v1, not SNODENT as was
erroneously stated in the draft USCDI
v1.
With respect to the USCDI’s
expansion in future years, ONC will
establish and follow a predictable,
transparent, and collaborative process to
expand the USCDI, which will provide
stakeholders with the opportunity to
comment on the USCDI’s expansion and
to advance additional Data Classes and
Data Elements relevant to a wide range
of use cases related to health care. Prior
to this final rule, we published our
initial thinking as well as examples of
Data Classes and Data Elements that we
believed could be appropriate to
propose for adding to the USCDI.29 We
have also solicited feedback and
recommendations from the HITAC. As
we evaluated public comments and
conducted our own research prior to the
issuance of this final rule, we also
wanted to identify for stakeholders
another potential source that could be
used to focus efforts around new USCDI
Data Classes and Data Elements. As is
noted throughout this rule, the HL7®
FHIR® standard represents health
information in what are called ‘‘FHIR
resources.’’ When it comes to logically
organizing FHIR resources that relate to
one another and share common
properties, FHIR uses a concept called
a ‘‘compartment.’’ Through the
standards development process a
‘‘Patient Compartment’’ has been
28 https://www.healthit.gov/sites/default/files/
draft-uscdi.pdf.
29 https://www.healthit.gov/sites/default/files/
draft-uscdi.pdf.
E:\FR\FM\01MYR3.SGM
01MYR3
25672
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
created, which lists all of the FHIR
resources that are associated with a
patient. The Patient Compartment
‘‘includes any resources where the
subject of the resource is the patient,
and some other resources that are
directly linked to resources in the
patient compartment.’’ This organizing
framework provides a potentially rich
set of a Data Classes and Data Elements
to consider for inclusion in the USCDI,
including clinical, encounter, specialty,
and financial data. As ONC looks to
make its own investments to advance
the implementation experience
associated with prospective USCDI Data
Classes and Data Elements, we intend to
leverage the Patient Compartment to
guide our thinking. In addition, we will
also look to and encourage industry to
look at other organizing frameworks
such as the Clinical Quality/Clinical
Decision Support realms and the payerto-provider community (e.g., DaVinci
Project 30) to help identify data that
would be best to focus on for USCDI
expansion.
i. Updated Versions of Vocabulary
Standard Code Sets
We proposed (84 FR 7441) that the
USCDI v1 would include the newest
versions of the ‘‘minimum standard’’
code sets included in the CCDS
available at publication of this final
rule. We requested comment on that
proposal and on whether it could result
in any interoperability concerns. We
also noted that criteria such as the 2015
Edition ‘‘family health history’’ criterion
(§ 170.315(a)(12)), the 2015 Edition
‘‘transmission to immunization
registries’’ criterion (§ 170.315(f)(1)),
and the 2015 Edition ‘‘transmission to
public health agencies—syndromic
surveillance’’ criterion (§ 170.315(f)(2))
reference ‘‘minimum standard’’ code
sets; however, we indicated that we
were considering updating the versions
of these standards listed and
incorporated by reference in part 170
subpart B that are referenced by these
criteria from the versions adopted in the
2015 Edition final rule.
We also noted, for purposes of clarity,
that consistent with § 170.555, unless
the Secretary prohibits the use of a
newer version of an identified minimum
standard code set for certification,
health IT could continue to be certified
or upgraded by developers to a newer
version of an identified minimum
standard code set than that included in
USCDI v1 or the most recent USCDI
version that the National Coordinator
has approved for use in the Program
using the SVAP flexibility.
30 https://www.hl7.org/about/davinci/index.cfm.
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
Comments. There was general support
from commenters for updating
‘‘minimum standard’’ code sets
requirements to the newest versions of
these code sets as part of the update
from CCDS to the USCDI. One
commenter recommended adopting the
Data Class requirement first, followed
by a delayed requirement of updated
versions of the ‘‘minimum standards’’
code sets, in order to allow
implementers more time to make
changes to their systems.
Response. We do not believe that
adopting the corresponding ‘‘minimum
standards’’ code sets that are updated in
the USCDI v1 would impose a
significant burden on implementers. In
consideration of the overall support
from commenters, we have finalized our
proposal that the USCDI v1 include the
newest versions of the ‘‘minimum
standard’’ code sets available at the time
of finalization of this final rule. We have
not, however, finalized the proposal for
the 2015 Edition ‘‘family health history’’
criterion (§ 170.315(a)(12)), the 2015
Edition ‘‘transmission to immunization
registries’’ criterion (§ 170.315(f)(1)),
and the 2015 Edition ‘‘transmission to
public health agencies—syndromic
surveillance’’ criterion (§ 170.315(f)(2))
to reference the newest versions of the
‘‘minimum standard’’ code sets for these
criteria, because the flexibility already
exists to use newer versions of code sets
included in these criteria. We note that
for these certification criteria, health IT
developers may take advantage of the
previously established 31 flexibility to
seek certification to newer versions of
the ‘‘minimum standards’’ code with
§ 170.555.
ii. Address and Phone Number
We proposed (84 FR 7442) new Data
Elements in the USCDI v1 for ‘‘address’’
and ‘‘phone number.’’ We noted that the
inclusion of ‘‘address’’ (to represent the
postal location for the patient) and
‘‘phone number’’ (to represent the
patient’s telephone number) would
improve the comprehensiveness of
health information for patient care. We
further noted that the inclusion of these
Data Elements was consistent with the
list of patient matching Data Elements
already specified in the 2015 Edition
‘‘transitions of care’’ certification
criterion (§ 170.315(b)(1)(iii)(G)), which
supports the exchange of patient health
information between providers of
patient care.
Comments. Commenters unanimously
supported the addition of address and
phone numbers to the USCDI v1. The
majority of commenters on this proposal
31 77
PO 00000
FR 54163, 54268–69 (September 4, 2012).
Frm 00032
Fmt 4701
Sfmt 4700
recommended the use of the U.S. Postal
Service address format to improve
address data quality. Commenters also
recommended additional elements of
address and phone number indicating
effective period (e.g., current address,
former address); use (e.g., mobile phone
number, landline, etc.), and email
address.
Response. We thank the commenters
for their recommendations and agree
that these additional Data Elements can
be useful to provide better care and
assist with patient matching. In
consideration of these comments, we
have finalized the addition of the
following Data Elements within the
Patient Demographics Data Class:
• ‘‘current address’’;
• ‘‘previous address’’;
• ‘‘phone number’’;
• ‘‘phone number type’’; and
• ‘‘email address.’’
We further clarify that ‘‘phone
number’’ and ‘‘phone number type’’
must be represented using the same
standards, ITU–T E.123 (02/2001) and
ITU–T E.164, as already adopted for this
data in 45 CFR 170.207(q) and
referenced in the 2015 Edition
‘‘transitions of care’’ certification
criterion (§ 170.315(b)(1)(iii)(G)).
We appreciate commenters’
recommendations to use the U.S. Postal
Service Postal Addressing Standards,
which include address formatting
guidance and a variety of products to
improve address quality, such as
address element standardization and
validation which are published and
available for public use.32 The U.S.
Postal Service Postal Addressing
Standards include standardized names
for common unit identifiers, line by line
acceptance requirements for mail
services, and overall address format
guidance that has been specifically
designed to support labelling of mail
items for acceptance by the U.S. Postal
Service automated sorting processes. We
acknowledge the potential for its use
within health IT to improve patient
matching. However, while the U.S.
Postal Service Postal Addressing
Standards include a single
representation for certain data elements
(such as rendering apartment as apt,
building as bldg, floor as fl, etc.) they
also allow variations for other data
elements, such as ‘‘acceptable’’ and
‘‘preferred’’ spellings and abbreviations
for street and city names. This may
result in multiple ‘‘valid’’ addresses. To
reconcile this variation, the U.S. Postal
Service provides a file listing preferred
32 U.S. Postal Service: Postal Addressing
Standards (Publication 28) available at https://
pe.usps.com/text/pub28/welcome.htm.
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
city and State combinations as well as
a file of street name and zip code
combinations and the resulting
aggregated address would then require
manual reconciliation. We believe the
U.S. Postal Service Postal Addressing
Standards may be useful guidance for
health IT developers. However, because
of the variation, the required use of
reference files, and the manual
reconciliation necessary for
implementation, we have not adopted
the U.S. Postal Service Postal
Addressing Standards as a required
standard for the address Data Elements
within the USCDI. We encourage the
use of standardized elements to
accurately represent patient address
including use of standardized references
in the U.S Post Service Postal
Addressing Standards where applicable.
In addition, we will continue to work
with standards developing organizations
to evaluate potential solutions to
improve patient matching, including
considering the potential adaptability of
the U.S. Postal Service formats for
health IT use cases.
The U.S. Postal Service also maintains
web based tools for address validation
services and provides implementation
guidance to integrate these tools into
technical workflows for IT systems in ecommerce and other industries. We
agree that these address validation tools
have the potential to greatly improve
address data quality, and we encourage
health IT developers and other relevant
health IT users such as health
information networks to explore
mechanisms by which such address
validation might support patient
matching. While not specifically
designed for patient matching and other
health care related applications, USPS
address validation has been piloted in
these settings. To adapt the address
validation tool to a health care purpose
requires the services of a third party
with licensing of the tool and the
development of a bespoke process to
execute the tool. The aggregated patient
address could then be compared against
the USPS address on file and the patient
data could be amended where
inaccurate, appended where
incomplete, or a linked record of
secondary address data could be created
depending on the percent of confidence
in the specific match. This process
would then require manual
reconciliation. The results of these
pilots indicate significant complexity
and burden associated with
implementation of this process. Given
these burdens, we believe it would not
be appropriate to require the integration
of this distinct functionality into
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
certified health IT at this time. We again
encourage the further development and
use of standardized approaches for
address validation and will continue to
monitor and analyze such efforts for
consideration in future rulemaking.
iii. Pediatric Vital Signs
As proposed (84 FR 7442), the USCDI
v1 included the pediatric vital sign data
elements, which are specified as
optional health information in the 2015
Edition CCDS definition. The proposed
pediatric vital signs included: head
occipital-frontal circumference for
children less than 3 years of age, BMI
percentile per age and sex for youth 2–
20 years of age, weight for age per length
and sex for children less than 3 years of
age, and the reference range/scale or
growth curve, as appropriate. As
explained in section VI.A.2 of this final
rule, the inclusion of pediatric vital sign
Data Elements in the draft USCDI v1
align with the provisions of the Cures
Act related to health IT to support the
health care of children. Prior to the
publication of the Proposed Rule,
stakeholders emphasized the value of
pediatric vital sign data elements to
better support the safety and quality of
care delivered to children. We also note
in our Proposed Rule and in the 2015
Edition proposed rule (80 FR 16818 and
16819) that the Centers for Disease
Control and Prevention (CDC)
recommends as part of best practices the
use of these pediatric vital signs for
settings of care in which pediatric and
adolescent patients are seen. The
availability of a reference range/scale or
growth curve would help with proper
interpretation of the measurements for
the BMI percentile per age and sex and
weight for age per length and sex.
Further, we noted our belief that the
inclusion of this health information in
the USCDI v1 was the appropriate next
step after first specifying them as
optional in the CCDS definition as part
of the 2015 Edition rulemaking (80 FR
62695), and as a means of supporting
patient access to their EHI in a
longitudinal format through certified
health IT (see section 3009(e)(2)(A)(i) of
the PHSA as amended by the Cures
Act). We recognized, however, that
certain health IT developers and their
customers may not find these
capabilities and information useful.
Therefore, we requested comment on
the inclusion of pediatric vital signs in
the USCDI v1, including the potential
benefits and costs for all stakeholders
stemming from its inclusion in the
USCDI v1.
Comments. Commenters generally
supported the inclusion of the pediatric
vital signs Data Elements in the USCDI
PO 00000
Frm 00033
Fmt 4701
Sfmt 4700
25673
v1. Some commenters opposed their
inclusion or believed the inclusion of
these Data Elements should be optional
since pediatric vital signs are not
applicable to all specialties and would
add implementation burden and cost
without benefit. One commenter stated
that only the measurements and
associated metadata (units of measure,
date/time measurement taken, method
of measurement), not the calculated
percentiles according to applicable
pediatric growth charts, should be
required as part of the exchange of
patient data. One commenter
recommended adding the nutritional
status Data Element ‘‘mid-arm
circumference.’’ Finally, several
commenters suggested or requested
clarification on the pediatric vital signs
Data Elements we proposed (84 FR
7442). Specifically, stakeholders in the
pediatric community asked for
clarification of the proposed pediatric
vital sign ‘‘weight for age per length and
sex for children less than 3 years of
age,’’ noting it does not correspond to
any existing pediatric growth charts.
Rather, they noted that there is a growth
chart ‘‘weight-for-length’’ for children
less than 3 years of age.
Response. We recognize that the
adoption of these Data Elements has the
potential to add burden and cost for
some health IT products, but we believe
the inclusion of these Data Elements can
contribute significantly to the
longitudinal care of patients. Pediatric
care is not isolated to a single specialty
or setting of care, and clinicians
providing health care for children—
especially those providing care for
children with complex conditions—may
practice in a wide range of settings
using a wide range of health IT systems.
Many key stakeholders believe that the
ability to capture, calculate, and
transmit key pediatric growth data using
health IT is critical to providing care to
these populations as well as
communicating with other providers,
parent/guardians, and patients. We also
note that adoption of the USCDI
standard and its Data Classes and
elements is not specific as to its usage
within a setting of care, a health care
specialty, or by a specific category of
health IT user; rather it applies to
certified health IT’s ability to send and
receive those Data Elements without
requirements regarding functionality,
user interface, or the use of those Data
Elements in exchange. While some users
may find few opportunities to exchange
these Data Elements, many will
exchange these Data Elements
frequently. As we have noted
previously, we believe that the adoption
E:\FR\FM\01MYR3.SGM
01MYR3
25674
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
of USCDI for all certified health IT will
advance interoperability by ensuring
compliance with new data and
vocabulary codes sets that support the
data.
We also appreciate the commenter’s
suggestion for an additional Data
Element. As we have noted, ONC will
establish and follow a predictable,
transparent, and collaborative process to
expand the USCDI, which will provide
stakeholders with the opportunity to
advance additional Data Classes and
Data Elements relevant to a wide range
of use cases related to health care.
Regarding the request to clarify and
better define these proposed pediatric
vital signs, we note that these Data
Elements, as written and proposed, were
previously included as optional health
information in the 2015 Edition CCDS
definition. The discrepancy between the
adopted pediatric vital signs and
standardized pediatric growth charts
was not identified previously.
Therefore, we wish to clarify that the
above-referenced pediatric vital signs
include both the vital measurements
and the percentiles used in the
following growth charts currently
recommended by the Centers for Disease
Control and Prevention: 33 for infants
birth to 36 months of age: Weight-forlength; and head occipital-frontal
circumference for age; and for children
2–20 years of age: Body mass index
(BMI) for age.
In consideration of these comments,
we have finalized the following
pediatric Data Elements in the Vital
Signs Data Class of the USCDI v1: Head
occipital-frontal circumference
percentile (Birth to 36 Months); weightfor-length percentile (Birth to 36
Months); body mass index (BMI)
percentile (2–20 Years of Age); and the
reference range/scale or growth curve,
as appropriate.
iv. Clinical Notes
We proposed (84 FR 7442) to include
in the USCDI v1 a new Data Class
entitled ‘‘clinical notes.’’ ‘‘Clinical
notes’’ was included in the proposed
USCDI v1 based on significant feedback
from the industry since the 2015 Edition
final rule. We also received similar
feedback during the Trusted Exchange
Framework and Common Agreement
(TEFCA) stakeholder sessions and
public comment period. As we noted,
‘‘clinical notes’’ have been identified by
stakeholders as highly desirable data for
interoperable exchange. The free text
portion of the clinical notes was most
often relayed by clinicians as the data
they sought, but were often missing
33 https://www.cdc.gov/growthcharts/index.htm.
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
during electronic health information
exchange. We additionally noted that
clinical notes can be composed of text
generated from structured (pick-list and/
or check the box) fields as well as
unstructured (free text) data. We
explained that a clinical note may
include the assessment, diagnosis, plan
of care and evaluation of plan, patient
teaching, and other relevant data points.
We recognized that a number of
different types of clinical notes could be
useful for stakeholders. We indicated
our understanding that work is being
done in the community to focus on a
subset of clinical notes. We considered
three options for identifying the
different ‘‘note types’’ to adopt in
USCDI v1. The first option we
considered allowed for the community
to offer any and all recommended notes.
The second option we considered set a
minimum standard of eight note types.
This option was derived from the eight
note types identified by the Argonaut
Project participants.34 The third option
we identified looked to the eleven HL7
Consolidated Clinical Document
Architecture (C–CDA) document types
identified in the C–CDA Release 2.1,
which also included the note types
being identified by the Argonaut Project
participants. We ultimately proposed
the second option because it unites
public and private interests toward the
same goal. We indicated that the eight
selected note types were a minimum bar
and, in the future, the USCDI could be
updated to include other clinical notes.
Specifically, we proposed to include the
following clinical note types for both
inpatient and outpatient (primary care,
emergency department, etc.) settings in
USCDI v1 as a minimum standard: (1)
Discharge Summary note; (2) History &
Physical; (3) Progress Note; (4)
Consultation Note; (5) Imaging
Narrative; (6) Laboratory Report
Narrative; (7) Pathology Report
Narrative; and (8) Procedures Note (84
FR 7442). We requested comment on
whether to include additional note
types as part of the USCDI v1.
Comments. Commenters broadly
supported adding ‘‘clinical notes’’ as a
new Data Class to the USCDI v1, in
particular to enable the use of free text
for data exchange. Several commenters
requested clarity as to whether the
proposal to adopt this new Data Class
would require the capture and exchange
of unstructured, or ‘‘raw’’ or ‘‘free’’ text,
narrative clinical information or more
comprehensive documents such as
34 Link to the Clinical Notes Argonaut Project
identified (to clarify: Seven bullets are listed,
however, we split laboratory and pathology note
types into their own note) https://wiki.hl7.org/
index.php?title=201805_Clinical_Notes_Track.
PO 00000
Frm 00034
Fmt 4701
Sfmt 4700
those defined by C–CDA. Some
commenters recommended adding
certain note types—including continuity
of care, operative, and nursing notes—
while others recommended removing
some of the proposed note types. In
particular, Laboratory/Pathology Report
Narrative note types were thought to be
duplicative of content in the Laboratory
Data Class and element Value/Results.
Some commenters recommended
Imaging Narrative not be used, but
added to a new Data Class, Diagnostic
Tests, which would combine Laboratory
and Radiology tests and results.
Response. We thank commenters for
their support and recommendations.
While we recognize that there may be
alternative methods of organizing
different clinical note types, we believe
there is value in grouping all clinical
notes into a single Data Class within the
USCDI. As we noted above and in the
Proposed Rule, we have adopted the
eight note types identified by the
Argonaut Project participants because it
unites public and private interests
toward the same goal. As we indicated,
the eight selected note types are a
minimum bar and, in the future, the
USCDI could be updated to include
other clinical note types. The eight
selected note types reflect the most
clearly and consistently recommended
set of clinical note type. While a variety
of additional note types were
recommended, there was no consensus
for additional note types beyond these
eight. In consideration of these
comments, we have finalized the
clinical notes as a Data Class in the
USCDI v1, with only the following eight
clinical note types for both inpatient
and outpatient (primary care, emergency
department, etc.) settings as a minimum
standard as proposed: (1) Discharge
Summary Note; (2) History & Physical;
(3) Progress Note; (4) Consultation Note;
(5) Imaging Narrative; (6) Laboratory
Report Narrative; (7) Pathology Report
Narrative; and (8) Procedures Note.
We wish to further clarify that we
have adopted the new Clinical Notes
Data Class in order to enable capture
and exchange of free text clinical
information categorized by the above
clinical note types. We refer
commenters to our response in section
IV.B.1.d of the final rule—Clinical Notes
C–CDA Implementation Specification—
that addresses the relationship of the
clinical notes Data Class to C–CDA
implementation specification.
We also seek to clarify two points.
First, that these clinical note types are
content exchange standard agnostic.
They should not be interpreted or
associated with the specific C–CDA
Document Templates that may share the
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
same name. Secondly, we clarify that
these note types are required to be
represented in their plain-text form
when included in various content
exchange standards (e.g., C–CDA, FHIR)
as may be applicable to the certification
criteria in which the USCDI is
referenced.
v. Provenance
We proposed (84 FR 7442) for the
USCDI v1 to include a new Data Class,
entitled ‘‘provenance.’’ As we indicated,
stakeholders 35 have identified
‘‘provenance’’ as valuable for
interoperable exchange. Stakeholders
also referenced the provenance of data
as a fundamental need to improve the
trustworthiness and reliability of the
data being exchanged. Provenance
describes the metadata, or extra
information about data, that can help
answer questions such as who created
the data and when.
In the Proposed Rule, we noted that
the inclusion of ‘‘provenance’’ as a Data
Class in the USCDI v1 would also
complement the Cures Act requirement
in section 4002(a) to support the
exchange of data through the use of
APIs. This approach differs from the
exchange of data via the C–CDA. While
C–CDAs are often critiqued due to their
relative ‘‘length,’’ the C–CDA represents
the output of a clinical encounter and
includes relevant context. The same will
not always be true in an API context.
APIs facilitate the granular exchange of
data and, as noted in the original 2015
Edition final rule, offer the potential to
aggregate data from multiple sources
using a web or mobile application (80
FR 62675). The inclusion of provenance
would help retain the relevant context
so the recipient can better understand
the origin of the data.
We proposed to further delineate the
provenance Data Class into three Data
Elements: ‘‘the author,’’ which
represents the person(s) who is
responsible for the information; ‘‘the
author’s time stamp,’’ which indicates
the time the information was recorded;
and ‘‘the author’s organization,’’ which
would be the organization the author is
associated with at the time they
interacted with the data (84 FR 7442).
We indicated that we identified these
three Data Elements as fundamental for
data recipients to have available and
noted that they are commonly captured
and currently available through
standards. We requested comment on
the inclusion of these three Data
Elements and whether any other
35 https://www.healthit.gov/topic/interoperability/
trusted-exchange-framework-and-commonagreement.
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
provenance Data Elements, such as the
identity of the individual or entity the
data was obtained from or sent by
(sometimes discussed in standards
working groups as the provenance of the
data’s ‘‘last hop’’), would be essential to
include as part of the USCDI v1
standard. We acknowledged that there is
currently work to help define
provenance in a standard robust
manner, and that we anticipated
adopting the industry consensus once it
became available.
Comments. Commenters
overwhelmingly supported the addition
of provenance as a new Data Class for
USCDI v1. Several commenters stated
that the proposed elements were
insufficient for the purpose of audit logs
for use and disclosure of health data,
citing the existing standard specification
ASTM E2147.36 Other commenters
stated that these proposed elements did
not apply to all use cases of exchanged
data and requested clarification
regarding applicability, including
whether provenance would have to be
created for elements created before the
implementation deadline of USCDI v1.
Because this is a new Data Class, some
commenters also requested additional
time to adopt and implement this new
requirement. Some commenters stated
that there could be ambiguity in
designating ‘‘author’’ for certain clinical
information such as patient-reported
medications, while in certain other
cases, there could be multiple authors
for the same clinical information, such
as clinical notes. Additionally, some
commenters suggested that the ‘‘author’’
be limited to only a limited set of Data
Elements and not to all the Data
Elements. Another commenter
specifically addressed several concerns
related to the definition of ‘‘author’’ for
this purpose. Commenters specifically
stated they understood author to be the
person entering the data into the EHR,
but noted that data may also be
historical, captured from a device,
started by a patient and completed by
clinical staff, entered by a patient,
entered by resident/students working
under a supervising physician, or
reported by a patient. The commenter
noted that there are additional
documentation scenarios such as
dictation to scribes or other medical
staff, which conflate ‘‘responsibility’’ for
authorship, and that defining author for
every Data Element can be complex.
Finally, one health IT developer
recommended a 36-month
implementation period to begin only
after test procedures, implementation
guides, and test and validation tools are
36 https://www.astm.org/Standards/E2147.htm.
PO 00000
Frm 00035
Fmt 4701
Sfmt 4700
25675
available and after ONC has consulted at
least five CEHRT developers.
Response. We acknowledge that these
Data Elements may not be able to fully
support the needs of all use cases, but
we believe their adoption will improve
the trustworthiness and reliability of
data being exchanged. For this Data
Class, it appears that many commenters
over-interpreted our proposal and the
effect of having these data in the USCDI.
As we noted earlier, the adoption of the
USCDI standard and its Data Classes
and elements is not specific as to its
usage within a setting of care, a health
care specialty, or by a specific category
of health IT user. Rather it applies to
certified health IT’s ability to send and
receive those Data Elements without
requirements regarding functionality,
user interface, or the use of those Data
Elements in exchange. Therefore, with
respect to our reference to provenance
data in the USCDI, we have no preset
notion or explicit upfront requirement
for how this data should be used. We
believe that having provenance data is
highly impactful, essential for
trustworthy interoperability, and will
generate greater value for stakeholders
as they identify new ways to put this
data to use.
Regarding ‘‘author’’ as a Data Element
within the provenance Data Class, we
agree that significant practical scope
challenges may arise. Our analysis of
the concerns raised by commenters
identified a risk of unintended burden
and potential risk of error and
misattribution associated with this
particular Data Element. In most use
cases, the inclusion of author
organization and author time stamp is
sufficient to convey provenance. As a
result, we have not finalized the
‘‘author’’ as a required Data Element
within the provenance Data Class in
USCDI. However, we understand that
for exchanging certain data elements,
such as ‘‘clinical notes,’’ it is critical to
also send the ‘‘author’’ information if
available. Our analysis of the various
content exchange standards and
specifications (e.g., C–CDA and FHIR)
indicates that even though the ‘‘author’’
Data Element is not explicitly required
in USCDI, the health IT specifications in
which USCDI Data Elements are
represented also set specific data
element requirements for certain
contexts. For example, in the context of
clinical notes, these content exchange
standards require health IT systems to
be capable of exchanging ‘‘author’’
information when it is available.
Further, ‘‘author’’ is treated as a ‘‘Must
Support’’ data element in the FHIR US
Core Implementation Guide STU 3.1.0
and has a ‘‘SHALL’’ constraint (with
E:\FR\FM\01MYR3.SGM
01MYR3
25676
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
appropriate null flavor value) in the C–
CDA 2.1. As we have noted previously,
we believe that the proposed 24-month
timeline for updating certified health IT
to comply with the new USCDI standard
in § 170.213 is an adequate
implementation timeline and will
maintain this requirement as finalized
earlier in this section.
Therefore, in consideration of the
comments received, we have finalized
the provenance Data Class in the USCDI
v1 and the following two Data Elements:
• ‘‘author time stamp,’’ which
indicates the time the information was
recorded; and
• ‘‘author organization,’’ which
would be the organization the author is
associated with at the time they
interacted with the data.
We believe these two provenance Data
Elements, ‘‘author organization’’ and
‘‘author time stamp,’’ within the USCDI
v1, which are also used in the C–CDA
and FHIR-based certification criteria we
have adopted that incorporate the
USCDI, will serve as a foundation on
which industry stakeholders can
subsequently work together to build out
additional provenance data
requirements in the USCDI. As noted
above, we have not finalized the
proposed Data Element ‘‘the author,’’
which represents the person(s) who was
responsible for the information.
vi. Medication Data Request for
Comment
In the Proposed Rule, we proposed
(84 FR 7443) that the USCDI v1
‘‘Medication’’ Data Class include two
constituent Data Elements within it:
Medications and Medication Allergies.
With respect to the latter, Medication
Allergies, we requested comment on an
alternative approach. This approach
would remove the Medication Allergies
Data Element from the Medication Data
Class and add it to a new Data Class
titled ‘‘Substance Reactions,’’ which
would include the concept of
‘‘Medication Allergies.’’ The new
‘‘Substance Reactions’’ Data Class
would include the following Data
Elements: ‘‘Substance’’ and ‘‘Reaction,’’
and include SNOMED CT as an
additional applicable standard for nonmedication substances.
Comments. The majority of
commenters supported the creation of a
new Data Class ‘‘Substance Reactions’’
but requested we preserve the
Medication Allergy element because of
patient safety concerns related to the
adoption of an entirely new Data
Element. One commenter supported the
change but recommended the new Data
Class name be aligned with the HL7
FHIR resource ‘‘AllergyIntolerance.’’
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
This would also be consistent with the
C–CDA 2.1 ‘‘Allergy and Intolerance’’
section.
Response. We thank the commenters
for their input. While we appreciate that
there may be some risk associated with
the adoption of a new Data Element, we
believe this alternative approach better
aligns with other standards representing
substance reactions, including
medication allergies, and this alignment
enhances patient safety. Additionally,
we agree with the commenter who
suggested renaming this new Data Class
to align with FHIR and C–CDA
approaches.
In consideration of comments, we
have finalized the creation of a Data
Class in USCDI v1 entitled ‘‘Allergies
and Intolerances,’’ instead of
‘‘Substance Reactions’’ from the original
USCDI v1 proposal. The Allergies and
Intolerances Data Class in USCDI v1
consists of the following Data Elements:
‘‘Substance—(Medication),’’
‘‘Substance—(Drug Class),’’ and
‘‘Reaction.’’ ‘‘Substance—(Medication)’’
must be represented by RxNorm codes
and ‘‘Substance—(Drug Class)’’ must be
represented by SNOMED CT codes. The
addition of the ‘‘Substance—(Drug
Class)’’ better represents when an
individual may have a reaction to an
entire drug class as opposed to a
specific medication. Additionally, we
believe having the Allergy and
Intolerances Data Class separated from
the Medication Class will accommodate
potential additions of other substance
Data Elements such as food,
environmental, and biologic agents. The
Data Element ‘‘Reaction’’ is meant to
include, but is not limited to,
medication allergies. As the USCDI is
updated over time to include substances
other than medications, we can also see
the need to have substance reactions
updated as part of this Data Class. To
reflect this change, we have updated the
terminology in the regulatory text in
§ 170.315 to remove ‘‘medication
allergy’’ and replace with ‘‘allergy and
intolerance.’’
c. USCDI Standard—Relationship to
Content Exchange Standards and
Implementation Specifications
In recognition of the evolution of
standards over time and to facilitate
updates to newer versions of standards,
we proposed (84 FR 7443) that the
USCDI v1 (§ 170.213) would be agnostic
as to ‘‘content exchange’’ standard. As
we noted, the USCDI v1 establishes
‘‘data policy’’ and does not directly
associate with the content exchange
standards and implementation
specifications which, given a particular
context, may require the exchange of the
PO 00000
Frm 00036
Fmt 4701
Sfmt 4700
entire USCDI, a USCDI Data Class, or
some or all of the Data Elements within
a given Data Class or classes. We further
indicated that, to our knowledge, all
Data Classes in the USCDI v1 can be
supported by commonly used ‘‘content
exchange’’ standards, including HL7 C–
CDA Release 2.1 and FHIR.
We received no comments on this
specific proposal and we have finalized
our proposal to make USCDI v1 agnostic
as to ‘‘content exchange standard’’ as
described.
2. Clinical Notes C–CDA
Implementation Specification
In conjunction with our proposal to
adopt the USCDI v1, we proposed to
adopt the HL7 CDA® R2 IG: C–CDA
Templates for Clinical Notes R1
Companion Guide, Release 1 in
§ 170.205(a)(5) (‘‘C–CDA Companion
Guide’’). The C–CDA Companion Guide
provides supplemental guidance and
additional technical clarification for
specifying data in the C–CDA Release
2.1.37 As we noted in the Proposed Rule
(84 FR 7443), the proposed USCDI v1
included new Data Classes, such as
‘‘clinical notes,’’ which were further
supported through the C–CDA
Companion Guide. For example, the C–
CDA Companion Guide provides
specifications for clinical notes by
indicating that clinical notes should be
recorded in ‘‘note activity’’ and requires
references to other discrete data, such as
‘‘encounters.’’ The C–CDA Companion
Guide also enhances implementation of
the updated 2015 Edition certification
criteria that reference the C–CDA
Release 2.1 (§ 170.205(a)(4)). As noted
by stakeholders, the C–CDA Release 2.1
includes some optionality and
ambiguity with respect to Data Element
components, such as the locations and
value sets. We attempted to address
some of this optionality by clarifying
requirements using Certification
Companion Guides (CCGs) 38 and by
specifying in the CCDS definition where
certain data should be placed in the C–
CDA Release 2.1 templates (e.g., ‘‘goals’’
in the goals section).39 The C–CDA
Companion Guide, which was released
in August, 2015, provides similar, but
additional C–CDA implementation
structure. For example, race and
ethnicity are required Data Elements in
the USCDI and must be included in C–
CDA exchanges if known, or they may
be marked with a nullFlavor value
‘‘UNK’’ (unknown) if not known. The
37 https://www.hl7.org/implement/standards/
product_brief.cfm?product_id=447.
38 https://www.healthit.gov/topic/certificationehrs/2015-edition-test-method.
39 https://www.healthit.gov/sites/default/files/
topiclanding/2018-04/2015Ed_CCG_CCDS.pdf.
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
C–CDA Release 2.1 is unclear on the
location and value set, but the C–CDA
Companion Guide clarifies the location
and value set. We noted in the Proposed
Rule that the adoption of the C–CDA
Companion Guide would align with our
goal to increase the use of consistent
implementation of standards among
health IT developers and improve
interoperability. We proposed to adopt
this C–CDA Companion Guide to
support best practice implementation of
USCDI v1 Data Classes and 2015 Edition
certification criteria that reference C–
CDA Release 2.1 (§ 170.205(a)(4)). The
criteria include:
• ‘‘transitions of care’’
(§ 170.315(b)(1));
• ‘‘clinical information reconciliation
and incorporation’’ (§ 170.315(b)(2));
• ‘‘care plan’’ (§ 170.315(b)(9));
• ‘‘view, download, and transmit to
3rd party’’ (§ 170.315(e)(1));
• ‘‘consolidated CDA creation
performance’’ (§ 170.315(g)(6)); and
• ‘‘application access—all data
request’’ (§ 170.315(g)(9)).
We proposed, as a Maintenance of
Certification requirement for the real
world testing Condition of Certification
requirement, that health IT developers
with health IT certified to the six aboveidentified certification criteria prior to
the effective date of a subsequent final
rule would have to update such certified
health IT to the proposed revisions (84
FR 7443).40 We further proposed as a
Maintenance of Certification
requirement for the real world testing
Condition of Certification requirement,
that health IT developers would be
required to provide the updated
certified health IT to all their customers
with health IT previously certified to
the identified criteria no later than 24
months after the effective date of a final
rule (84 FR 7443). For the purposes of
meeting that compliance timeline, we
indicated that we expected health IT
developers to update their certified
health IT without new mandatory
testing and notify their ONC–ACB on
the date at which they have reached
compliance. Developers would also
need to factor these updates into their
next real world testing plan as discussed
in section VII.B.5 of the Proposed
Rule.41
Comments. One commenter
supported the use of C–CDA for Clinical
Notes. One commenter sought clarity on
testing for Clinical Notes conformance
to C–CDA 2.1, noting that all C–CDA
40 We proposed to codify this requirement in
§ 170.405(b)(4) (84 FR 7596).
41 The finalized real world testing plan
requirements, codified in § 170.405(b)(2) are
discussed in section VII.B.5 of this final rule.
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
documents are the same except for the
document header. Two commenters
recommended review of the Common
Well Concise Consolidated CDA white
paper.
Response. We thank the commenters
for their suggestions and support.
During the past few months, industry
stakeholders updated the C–CDA
Companion Guide to a newer version to
best address how clinical notes should
be handled in the C–CDA. In
consideration of the update to the C–
CDA Companion Guide and the
comments, we have finalized the
adoption of the most up-to-date version,
HL7 CDA R2 IG: C–CDA Templates for
Clinical Notes STU Companion Guide,
Release 2 in § 170.205(a)(5) (‘‘C–CDA
Companion Guide’’) and have
incorporated by reference in § 170.299.
This includes adoption of the USCDI v1
and the associated Data Classes.
In order to align ‘‘clinical information
reconciliation and incorporation’’
(§ 170.315(b)(2)) with the updated Data
Classes in the USCDI v1 as proposed in
84 FR 7441, we have replaced the
‘‘medication allergies’’ data element in
§ 170.315(b)(2)(iii)(D)(2) criterion to
‘‘Allergies and Intolerances’’ Data Class
and require reconciliation of all the data
elements in ‘‘Allergies and
Intolerances’’ Data Class, which
includes Substance (Medication),
Substance (Drug Class), and Reaction
Data Elements. We have revised the
regulation text (§ 170.315(b)(2)) to align
with this change. We decline to accept
the recommendation to adopt the
CommonWell specification as we
believe the criterion is best met
following the C–CDA specification
published by HL7.
We have additionally finalized the
timeline for the update to the use of the
C–CDA companion guide of 24 months
after the publication date of this final
rule for the following criteria:
• ‘‘transitions of care’’
(§ 170.315(b)(1));
• ‘‘clinical information reconciliation
and incorporation’’ (§ 170.315(b)(2));
• ‘‘care plan’’ (§ 170.315(b)(9));
• ‘‘view, download, and transmit to
3rd party’’ (§ 170.315(e)(1));
• ‘‘consolidated CDA creation
performance’’ (§ 170.315(g)(6)); and
• ‘‘application access—all data
request’’ (§ 170.315(g)(9)).
3. Unique Device Identifier(s) for a
Patient’s Implantable Device(s) C–CDA
Implementation Specification
We noted in the Proposed Rule (84 FR
7443) our awareness of a recently
published implementation guide (IG) by
HL7 that provides further guidance on
the unique device identifier (UDI)
PO 00000
Frm 00037
Fmt 4701
Sfmt 4700
25677
requirements. The Health Level 7 (HL7)
CDA R2 Implementation Guide: C–CDA
Supplemental Templates for Unique
Device Identification (UDI) for
Implantable Medical Devices, Release
1–US Realm (UDI IG Release 1),
identifies changes needed to the C–CDA
to better facilitate the exchange of the
individual UDI components in the
health care system when devices are
implanted in a patient. The UDI
components include the Device
Identifier (DI) and the following
individual production identifiers: The
lot or batch number, serial number,
manufacturing date, expiration date,
and distinct identification code. As this
new IG had been recently published, we
requested comment on whether we
should add this UDI IG as a requirement
in § 170.299(f)(35) for health IT to adopt
in order to meet the requirements for
content exchange using C–CDA. In
addition, we indicated that we did not
have a reliable basis on which to
estimate how much it would cost to
meet the requirements outlined in the
UDI IG; and, therefore, we requested
comment on the cost and burden of
complying with this proposed
requirement.
Comments. Commenters unanimously
supported adoption of the UDI IG
Release 1 as a new requirement for
health IT to meet the requirements for
the USCDI UDI Data Class. One
commenter requested additional
guidance regarding the determination of
the ‘‘person responsible for the
information’’ contained in the ‘‘Device’’
entry. None of the commenters provided
a basis of estimate for the cost to meet
the requirements outlined in the UDI IG
Release 1.
Response. We thank the commenters
for their support. As we noted earlier,
the adoption of the USCDI standard and
its Data Classes and elements is not
specific as to its usage within a setting
of care, a health care specialty, or by a
specific category of health IT user;
rather it applies to certified health IT’s
ability to send and receive those Data
Elements without requirements
regarding functionality, user interface,
or the use of those Data Elements in
exchange. Therefore, we do not specify
who must enter such data.
We note also that the C–CDA
Companion Guide referenced in
subsection (d) below of this final rule
now includes the content of the UDI IG
Release 1 named in the Proposed Rule.
In consideration of comments, we have
finalized the proposed UDI Data Class
within the USCDI v1, and have adopted
the UDI Organizer Template defined in
the UDI IG Release 1 and subsequently
published as Appendix B of the HL7®
E:\FR\FM\01MYR3.SGM
01MYR3
25678
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
CDA® R2 IG: C–CDA Templates for
Clinical Notes, Release 2.1 Companion
Guide, Release 2—US Realm, October
2019, as a new requirement for Health
IT Modules to meet the requirements for
C–CDA-based exchange. We note that
the UDI Organizer Template, though
subsequently published in Appendix B
of the HL7 CDA R2 IG: C–CDA
Templates for Clinical Notes STU
Companion Guide, Release 2, September
2019, remains substantially unchanged
from its previous publication in the UDI
IG Release 1 in November 2018 and has
been thoroughly reviewed and subjected
to balloting and a public comment
process.
4. Electronic Prescribing Criterion
We proposed to adopt a new version
of the NCPDP SCRIPT standard in 45
CFR 170.205(b)(1), specifically NCPDP
SCRIPT standard version 2017071 (84
FR 7444). Because we proposed to adopt
a new standard for electronic
prescribing (e-Rx), we also proposed to
adopt a new certification criterion in
§ 170.315(b)(11) for the proposed e-Rx
standard to replace the old standard in
§ 170.315(b)(3). The proposed new
certification criterion reflected our
proposed adoption of NCPDP SCRIPT
standard version 2017071 as well as all
transactions adopted for the CMS
Medicare Part D E-prescribing Program
(84 FR 23832). These proposals were
made to realign ONC’s Health IT
Certification Program (Program) policies
with those of CMS’ Part D E-prescribing
rules. ONC and CMS have historically
aligned standards adopted under their
programs such as those for e-Rx and
medication history (MH) to ensure that
entities regulated under both schemes
can comply with the different programs’
requirements. For this reason, we stated
that should our proposal to adopt the
new e-Rx criterion (§ 170.315(b)(11)) be
finalized prior to January 1, 2020, we
also proposed to permit continued
certification to the current 2015 Edition
‘‘electronic prescribing’’ criterion
(§ 170.315(b)(3)) that references NCPDP
SCRIPT standard version 10.6 for the
period of time in which that version of
the NCPDP SCRIPT standard would
continue to be used in the CMS
Medicare Part D E-prescribing Program
or the CMS Promoting Interoperability
Programs. Finally, we proposed in 84
FR 7445 that once NCPDP SCRIPT
standard version 10.6 is no longer used
in those Programs, we would no longer
permit certification to that criterion and
would remove it from the Code of
Federal Regulations, and that we would
consider setting an effective date for
such actions in a subsequent final rule
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
based on stakeholder feedback and CMS
policies at the time.
In addition to continuing to reference
the current transactions included in
§ 170.315(b)(3), in keeping with CMS’
Modernizing Part D and Medicare
Advantage To Lower Drug Prices and
Reduce Out-of-Pocket Expenses final
rule (84 FR 23832), we also proposed in
84 FR 7445 and in § 170.315(b)(11) to
require the support of all of the NCPDP
SCRIPT standard version 2017071
transactions CMS has adopted for the
Part D E-prescribing regulations in 42
CFR 423.160(b)(2)(iv). Given the January
1, 2020 effective date in CMS
rulemaking (83 FR 16440) and the
effective date of this final rule, we have
finalized our proposed update to the
new version of the standard for the
electronic prescribing criterion in
§ 170.315(b)(3) instead of creating a new
criterion as proposed in 84 FR 7427 in
§ 170.315(b)(11). Unlike other criteria in
this final rule that allow testing to either
version of a required standard until 24
months after the publication date of this
final rule, we will not allow certification
testing to version 10.6 of the NCPDP
SCRIPT standard, as the implementation
date for CMS’ new Part D E-prescribing
Program of January 1, 2020 has passed.
However, based on stakeholder
feedback, we have finalized a transition
period in 45 CFR 170.405(b)(4)(ii) of 24
months from the date of publication of
this final rule for certification so
developers may test and certify to the
updated criterion with all associated
transactions.
Comments. The majority of
commenters were supportive of our
proposal and recommended moving to
the NCPDP SCRIPT standard version
2017071 for the e-Rx certification
criterion in alignment with CMS’
adoption of the standard for the Part D
E-prescribing Program. However, a
number of commenters expressed
concern that while EHRs or other
electronic prescribing systems may
become certified, pharmacy information
systems (PIS) lack a similar certification
program and associated standards and
technical capability requirements, thus
creating a mismatch between the eprescribing system requirements for
EHR users and PIS users. Several
commenters specifically noted that PIS,
which send or receive these
transactions, are not required to adopt
the capability to support these
transactions as they are out of scope for
the Program.
Response. First, we note that the
comments suggesting that pharmacies
on the sending or receiving end of Part
D e-Rx transactions are not required to
utilize NCPDP SCRIPT standard version
PO 00000
Frm 00038
Fmt 4701
Sfmt 4700
2017071 transactions are inaccurate. To
the extent that a pharmacy conducts
electronic prescribing with prescribers
e-prescribing Part D covered drugs for
Part D eligible individuals, those
pharmacies are required to use the
NCPDP SCRIPT version 2017071
standard. While there may not be 2015
Edition certification criteria to which
pharmacy information systems can be
certified, the Part D rules require
support of the standard under the Part
D E-prescribing Program. Thus, we
believe the mismatch concerns raised by
commenters are unfounded. As a
general matter, Part D prescribers need
health IT systems capable of conducting
compliant transactions (regardless of
ONC certification) and so too do Part D
receiving pharmacies. ONC health IT
certification will provide an added layer
of assurance for Part D prescribers that
their e-Rx systems have been tested and
certified as being capable of accurately
conducting the adopted NCPDP SCRIPT
standard version 2017071
transactions.42
In addition, we received several
comments related to the readiness of PIS
for specific transactions beyond those
defined for Part D. We include these
comments as applicable in the
discussion of each transaction below.
We reiterate that PIS are outside the
scope of the ONC Health IT Certification
Program, and we acknowledge the
challenge of pharmacy readiness to
support all transactions at this time, but
if they conduct e-Rx for part D covered
drugs prescribed to Part D eligible
Medicare beneficiaries, they will be
required to use the standard we are
adopting for our program by the
Medicare Part D e-Rx Program—so if
they do e-prescribing at all, we expect
that they will be able to conduct
transactions using the standard adopted
here. Generally, the goal of certification
is to ensure that Health IT Modules
voluntarily submitted for the Program
are capable of conducting the
transactions as specified. This ensures
that providers have the capability to use
the certified product for these
transactions where feasible. For this
reason, we have finalized the
transactions as described below for
certified Health IT Modules and
encourage pharmacy information system
developers to advance their capacity to
support a nationwide network of fully
interoperable pharmacy information
systems.
Comments. As noted, the majority of
commenters were supportive of the
proposal to remove the 2015 Edition
42 https://www.govinfo.gov/content/pkg/FR-201510-16/pdf/2015-25597.pdf.
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
certification criterion (codified in
§ 170.315(b)(3)) that references NCPDP
SCRIPT standard version 10.6 and
replace it with an updated e-Rx criterion
(proposed to be codified in
§ 170.315(b)(11)). Commenters
requested that ONC work with CMS on
a smooth transition and timeline that
would allow adequate time for the
development, testing, and full adoption
of these updates. A number of
commenters stated that the NCPDP
SCRIPT standard version 2017071 is not
backward compatible with NCPDP
SCRIPT standard version 10.6, and
therefore there should be no transition
period where both standards are
applicable. Commenters sought clarity
on the timing of the change and
expressed concerns that developers and
providers may face operational issues in
their adoption of version 2017071 of the
NCPDP SCRIPT standard by January 1,
2020. Commenters recommended that
ONC allow certification timelines that
support compliance with Part D while
allowing adequate time to mitigate the
risk associated with the additional
requirements for certification to the
proposed criterion.
Response. We appreciate the support
expressed by commenters as well as the
concern about maintaining alignment
between required standards across HHS.
We note that the CMS requirement for
Part D e-Rx transactions includes a
compliance date of January 1, 2020, and
that industry feedback notes a
consistent and deliberate move toward
readiness for the adoption of the new
standard for Part D e-Rx, including by
health IT industry leaders supporting
pharmacy implementation. We believe
that this overall industry readiness
supports our adoption of the update to
the standard for certification purposes
and to be in alignment with the required
standard update for Part D e-Rx
purposes. In response to the request for
a smooth transition and continuity of
certification for health care providers,
we have finalized a revision to the
existing criterion in § 170.315(b)(3)
rather than removing and replacing the
criterion. In order to support the
transition to the new standard for Part
D, at the request of stakeholders, ONC
issued guidance 43 in the third quarter of
CY2019 stating, ‘‘. . . developers of
2015 Edition certified Health IT
Modules certified to the e-prescribing
criterion adopted at 45 CFR
170.315(b)(3) are permitted to update
43 For Part D covered drugs prescribed for Part D
eligible individuals. ONC Electronic Prescribing
Certification Companion Guide: https://
www.healthit.gov/test-method/electronicprescribing.
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
their products to use the NCPDP
SCRIPT standard version 2017071 to
meet CMS’ compliance requirements
. . .’’ This guidance also noted that
ONC would discontinue certification of
new products to the electronic
prescribing certification criterion using
version 10.6 of the NCPDP SCRIPT
standard as of January 1, 2020.
In consideration of the comments we
received, we have finalized our proposal
to update the electronic prescribing (eRx) NCPDP SCRIPT standard used for
electronic prescribing in the 2015
Edition to NCPDP SCRIPT standard
version 2017071, which results in a new
e-Rx standard becoming the baseline for
certification. As the effective date of this
final rule will occur after January 1,
2020, we have not finalized our
proposal to permit new products to
continue to be certified to the prior
standard until the January 1, 2020 date.
Instead, we discontinued certification of
new products to the former electronic
prescribing criterion using the NCPDP
SCRIPT standard version 10.6 to align
with CMS requirements. We have
finalized this update as a modification
to the existing certification criterion
rather than as a separate new
certification criterion to allow for a
smooth transition, and to allow for
continuity with the certification(s)
issued to Health IT Modules for
§ 170.315(b)(3) prior to January 1, 2020
that are updated under the ONC
guidance. This approach will also
continue to allow for compliance with
the January 1, 2020 timeline for CMS’
Medicare Part D e-Rx and Medication
History standards.
As noted by commenters, we
understand that there is a lack of
backward compatibility between the
two standards. In order to allow for a
reasonable transition period to
certification to the full set of NCPDP
SCRIPT transactions and other
requirements defined in the updated eRx certification criterion, we have
framed our Maintenance of Certification
in section 45 CFR 170.405(b)(5)(ii) with
flexibility that will allow health IT
developers up to 24 months from the
date of publication of this final rule to
test and certify to the updated criterion
reflective of all NCPDP SCRIPT 2017071
transactions to demonstrate full
conformance with the updated criterion.
After January 1, 2020, use of the NCPDP
SCRIPT 10.6 standard will be prohibited
under the Part D program, so we do not
expect or anticipate health IT systems
certified to § 170.315(b)(3) will conduct
Part D transactions using that standard.
We also recognize, however, for the
purposes of maintaining a product
certificate with § 170.315(b)(3) in its
PO 00000
Frm 00039
Fmt 4701
Sfmt 4700
25679
scope, that these 24 months from the
date of publication from this final rule
enable continued compliance and
oversight associated with other
capabilities in § 170.315(b)(3) that are
not applicable for Part D, and for which
conformance is still required.
We have finalized this 24-month
period for the update for this criterion
under the real world testing provisions
in § 170.405(b)(5) as follows:
• Electronic Prescribing. A health IT
developer with health IT certified to
§ 170.315(b)(3) prior to June 30, 2020,
must:
Æ Update their certified health IT to
be compliant with the revised versions
of this criterion adopted in
§ 170.315(b)(3)(ii); and
Æ Provide its customers of the
previously certified health IT with
certified health IT that meets paragraph
(b)(5)(i) of this section by May 2, 2022.
a. Electronic Prescribing Standard and
Certification Criterion
Comments. Commenters expressed
concerns about standardization
generally within the context of eprescribing. Several commenters
expressed concern about using the
NCPDP SCRIPT standard version
2017071, the RxNorm standard, as a
requirement for e-prescribing, and other
standards such as Fast Healthcare
Interoperability Resources (FHIR). One
commenter further stated that only
inventory (packaging or unit dose
strength) codes are standardized in
RxNorm, and that drug regimens should
be standardized and made computable
in RxNorm for safety reasons. Another
commenter noted that RxNorm does not
index brand names exhaustively with a
single unique ID for each branded drug,
but that current indexing only allows for
generic-level interoperability and only
at unit dose level. One commenter
expressed concern that the criterion as
proposed does not appear to support
medication assisted treatment (MAT) for
opioid use disorder (OUD) and other
long-acting medications. Another
commenter stated a hope that standards
such as the NCPDP SCRIPT version
2017071 standard can ease data
integration into the workflow, lessen
burden, and help achieve greater
compliance with policy and legal
requirements for querying State
prescription drug monitoring programs
(PDMP). Another commenter supported
the adoption of the NCPDP SCRIPT
standard version 2017071 because the
standard supports the prescribing of
compound medications and the sig (i.e.,
instructions) field is not limited to 140
characters.
E:\FR\FM\01MYR3.SGM
01MYR3
25680
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
Some commenters also provided
suggestions to improve the NCPDP
SCRIPT 2017071 standard and its
availability to the public by the
standards developing organization.
Another commenter stated that today’s
NCPDP standards are not in an APIready format, and recommended CMS
and ONC collaborate with NCPDP to
explore API FHIR standards specific to
the HL7 Da Vinci Project for a January
2022 effective date or later. A few
commenters stated that because many
NCPDP standards are not openly
accessible and require a paid
membership to obtain the technical
specifications, our adoption could limit
widespread adoption and a
standardized implementation
nationwide. Several commenters
suggested that ONC adopt FHIR as a
standard for the Program, and for the eRx criterion specifically. We also
received several comments that are out
of scope which are not addressed in this
rulemaking.
Response. We appreciate the
commenters’ consideration of the
standards. We note that RxNorm is a
standard maintained by the National
Library of Medicine (NLM). ONC
adopted RxNorm to represent
medication information as a vocabulary
standard in § 170.207(d) (80 FR 62612).
We encourage all developers who have
experience with, and feedback relevant
to, RxNorm to contact NLM. As a
reminder, RxNorm is considered a
minimum standard code set under the
Program, and developers are permitted
to upgrade their products to comply
with a newer version of RxNorm
without adversely affecting a product’s
certification status pursuant to 45 CFR
170.555(b)(2) as long as no other law
prohibits such action.
In reference to the OUD prevention
and treatment-related concerns that
commenters expressed, we note that the
NCPDP SCRIPT 2017071 standard does
support the exchange of medicines used
in medication-assisted treatment (MAT)
for opioid use disorder treatment
purposes. An electronic prescription of
controlled substances transaction
containing a MAT drug such as
buprenorphine can be sent from a
prescriber to a pharmacy through the
specified transactions, and the updated
§ 170.315(b)(3) criterion also requires
the inclusion of a reason for the
prescription using
or
elements, or optionally, the technology
must be able to receive and transmit the
reason for the prescription using the
element. In
addition, the RxHistoryRequest
transaction contains a patient consent
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
indicator that the receiving entity must
evaluate for accurate reporting. We are
also aware that many PDMPs across the
country accept reporting of medication
history transactions containing
buprenorphine, naltrexone, and other
medications that could be used in the
treatment of OUD.
We thank commenters for their input
related to improvements that could be
made to the NCPDP SCRIPT version
2017071 standard, however NCPDP is a
member-driven standards developing
organization that requires membership
in order to participate in standards
developing and to access standards and
implementation guides. We appreciate
the suggestion to provide a direct link
to the appropriate NCPDP SCRIPT
standard implementation guide, but we
have no authority over the business
processes of standards developing
organizations like NCPDP. We
encourage any and all participants with
an interest in improving the standard to
engage with NCPDP. Regarding the
recommendation for ONC to collaborate
with NCPDP to explore FHIR, we
appreciate the suggestion and support
any advancements in technical
standards and frameworks that support
interoperability. At this time, NCPDP
SCRIPT standard version 2017071 has
not been mapped to FHIR, but ONC will
continue to monitor the industry for
opportunities to align the ONC Health
IT Certification Program with industry
developments.
Comments. Five commenters fully
supported all proposed transactions and
requirements detailed in the Proposed
Rule. The vast majority of commenters
noted concerns about the proposed
criterion specific to the transactions
proposed for adoption in the
§ 170.315(b)(11) e-Rx certification
criterion; details in support or not in
support of adoption as proposed are
further detailed for each type of
transaction below. As a whole, the
primary concerns for the transactions
and requirements as proposed include
the following: (1) EHRs are required to
comply with the new transactions and
requirements, while receiving pharmacy
information systems are not; (2) lack of
pharmacy adoption and readiness, as
sufficient adoption should occur prior
to making the transactions required; and
(3) implementation of the proposed
transactions and requirements is
resource intensive, if not prohibitive, in
order to meet the January 1, 2020
deadline set by CMS. Several
commenters suggested either an
extension or that certain transactions
should be made optional.
Response. We appreciate all of the
public comments and have modified the
PO 00000
Frm 00040
Fmt 4701
Sfmt 4700
transactions to specify which
transactions are finalized as required for
Health IT Modules for purposes of
obtaining or retaining certification to
§ 170.315(b)(3), which are optional for
Health IT Modules for purposes of
obtaining or retaining certification to
§ 170.315(b)(3), and any other
§ 170.315(b)(3) requirements below.
Additional public comment received
and related responses are grouped
below based on the comment’s relation
to the specific transactions. We note that
‘‘optional’’ for the purposes of
certification does not mean, and should
not be interpreted as, ‘‘optional’’ for Part
D E-prescribing Program compliance. To
the extent that prescribers and
pharmacies conduct electronic
prescribing with Part D covered drugs
prescribed for Part D eligible
individuals they will be required to use
the NCPDP SCRIPT 2017071 standard to
conduct those transactions under the
Part D E-prescribing Program. Thus, a
transaction designated as ‘‘optional’’ for
the purposes of certification means a
health IT developer can elect to have
that transaction explicitly tested as part
of certification for its product or can
choose not to do so—either will allow
its product to be certified to
§ 170.315(b)(3). We reiterate that
comments regarding CMS’ January 1,
2020 timeline are out of scope as we
cannot change CMS’ policy or its
timeline.
b. Electronic Prescribing Transactions
In addition to adopting the NCPDP
SCRIPT version 2017071 standard for
the transactions that are listed in the
current ‘‘electronic prescribing’’
criterion (§ 170.315(b)(3)), we also
proposed to adopt and require
conformance to all of the NCPDP
SCRIPT version 2017071 standard
transactions CMS adopted in 42 CFR
423.160(b)(2)(iv). We proposed this
updated 2015 electronic prescribing
criterion to therefore include the
following transactions:
i. Create and Respond to New
Prescriptions (NewRx, NewRxRequest,
NewRxResponseDenied)
We proposed in 84 FR 7444 to enable
a user to perform the related electronic
transactions for NewRx, NewRxRequest
and NewRxResponseDenied. A NewRx
transaction is a new prescription from a
prescriber to a pharmacy so that it can
be dispensed to a patient. A
NewRxRequest is a request from a
pharmacy to a prescriber for a new
prescription for a patient. A
NewRxResponseDenied is a denied
response to a previously sent
NewRxRequest (if approved by the
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
prescriber, a NewRx would be sent
instead). A NewRxResponseDenied
response may occur when the
NewRxRequest cannot be processed or if
information is unavailable.
Comments. While the NewRx
transaction received unanimous support
as a required transaction for adoption in
the updated § 170.315(b)(3) criterion,
the vast majority of commenters
opposed adopting the NewRxRequest
and NewRxResponseDenied
transactions as required transactions
primarily due to a lack of adoption by
the PIS involved in the exchange.
Several commenters stated that the
NewRxRequest and
NewRxResponseDenied is not yet in
broad use. A commenter who supported
adoption of NewRxRequest and
NewRxRequestDenied believed that
they may be beneficial for electronic
prescribing of controlled substances
(EPCS) and noted that pharmacies have
expressed interest in implementation.
Response. In consideration of public
comments, we have adopted NewRx as
a required transaction, and
NewRxRequest and
NewRxResponseDenied as optional
transactions in the updated
§ 170.315(b)(3) electronic prescribing
criterion. We have finalized these latter
two transactions as optional in response
to commenters’ concerns regarding a
lack of adoption by the PIS that would
be involved in the exchange.
Additionally, we note that pursuant to
the certification criterion, health IT
presented for certification must be
capable of including the reason for the
prescription as referenced in the
updated § 170.315(b)(3)(ii) or
§ 170.315(b)(3)(ii)(D) in the NewRx
transaction.
ii. Request and Respond to Change
Prescriptions (RxChangeRequest,
RxChangeResponse)
We proposed in 84 FR 7444 to enable
a user to perform the related electronic
transactions for RxChangeRequest and
RxChangeResponse. An
RxChangeRequest transaction originates
from a pharmacy and may be sent to a
prescriber to: Request a change in the
original prescription (new or fillable);
validate prescriber credentials; request a
review by a prescriber of the drug
requested; or obtain prior authorization
from the payer for the prescription. An
RxChangeResponse transaction
originates from a prescriber to respond
to: A prescription change request from
a pharmacy; a request for a prior
authorization from a pharmacy; or a
prescriber credential validation request
from a pharmacy.
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
25681
iii. Request and Respond to Cancel
Prescriptions (CancelRx,
CancelRxResponse)
adoption in place before it is a
certification requirement.
Response. We thank commenters for
their overall support of the proposed
CancelRx and CancelRxResponse
transactions. In light of the commenters’
overall support for the proposed
CancelRx transactions and in order to
support patient safety and the free flow
of communication between prescribers
and pharmacies, we have included these
transactions as required in the revised
§ 170.315(b)(3) electronic prescribing
criterion. We reiterate that although PIS
are outside the scope of the ONC Health
IT Certification Program, we encourage
pharmacy information system
developers to advance their capacity to
support a nationwide network of fully
interoperable PIS. Additionally, we note
that pursuant to the certification
criterion, health IT presented for
certification must be capable of
including the reason for the prescription
as referenced in the updated
§ 170.315(b)(3)(ii) or
§ 170.315(b)(3)(ii)(D) in the CancelRx
transaction.
We proposed in 84 FR 7444 to enable
a user to perform the related electronic
transactions for CancelRx and
CancelRxResponse. A CancelRx
transaction is a request from a prescriber
to a pharmacy to not fill a previously
sent prescription. A CancelRx must
contain pertinent information for the
pharmacy to be able to find the
prescription in their system (patient,
medication (name, strength, dosage,
form), prescriber, and prescription
number if available). A
CancelRxResponse is a response from a
pharmacy to a prescriber to
acknowledge a CancelRx, and is used to
denote if the cancellation is approved or
denied.
Comments. The majority of public
comments reflected support for
finalizing CancelRx and
CancelRxResponse as required
transactions. One commenter stated that
the CancelRx transaction will reduce
cost and improve patient safety, as
patients may have remaining refills
available that are subsequently modified
based on a physician’s new assessment.
Another commenter noted that certified
technology currently supports CancelRx
transactions in version 10.6 of the
NCPDP SCRIPT standard and
encouraged developers to upgrade their
technology to support CancelRx
transactions in NCPDP SCRIPT standard
version 2017071, as these transactions
provide great value to end users. One
commenter expressed concern for
pharmacy readiness for CancelRx, and
felt there should be sufficient industry
iv. Request and Respond to Renew
Prescriptions (RxRenewalRequest,
RxRenewalResponse)
We proposed in 84 FR 7444 to enable
a user to perform the related electronic
transactions for RxRenewalRequest and
RxRenewalResponse. An
RxRenewalRequest transaction
originates from a pharmacy to request
additional refills beyond those
originally prescribed. An
RxRenewalResponse transaction
originates from a prescriber to respond
to the request from the pharmacy.
Comments. Commenters supported
adoption of the RxRenewalRequest and
RxRenewalResponse transactions as
proposed. One commenter stated that
these transactions could be
implemented after the CMS deadline of
January 1, 2020 without loss of current
functionality. Another commenter said
that these transactions are widely used
in the industry and provide great value
to end users.
Response. We appreciate the support
for the RxRenewalRequest and
RxRenewalResponse transactions and
have included these transactions as
required in the updated § 170.315(b)(3)
electronic prescribing criterion. We
reiterate that the entire updated
§ 170.315(b)(3) criterion and
requirements must be met before
certification can be granted.
Additionally, we note that pursuant to
the certification criterion, health IT
presented for certification must be
capable of including the reason for the
prescription as referenced in the
Comments. Most commenters
supported the proposed adoption of the
RxChangeRequest and
RxChangeResponse transactions. One
commenter recommended against
adoption until industry adoption is
more widely spread across retail
pharmacies and demonstrates value.
Response. Because the majority of
commenters were in support of
adoption of the RxChangeRequest and
RxChangeResponse transactions as
proposed, we have included these
transactions as required in the updated
§ 170.315(b)(3) electronic prescribing
criterion. Additionally, we note that
pursuant to the certification criterion,
health IT presented for certification
must be capable of including the reason
for the prescription as referenced in the
updated § 170.315(b)(3)(ii) or
§ 170.315(b)(3)(ii)(D) in the
RxChangeRequest and
RxChangeResponse transactions.
PO 00000
Frm 00041
Fmt 4701
Sfmt 4700
E:\FR\FM\01MYR3.SGM
01MYR3
25682
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
updated § 170.315(b)(3)(ii) or
§ 170.315(b)(3)(ii)(D) in the
RxRenewalRequest and
RxRenewalResponse transactions.
v. Receive Fill Status Notifications
(RxFill, RxFillIndicatorChange)
We proposed in 84 FR 7444 to enable
a user to perform the related electronic
transactions for RxFill and
RxFillIndicatorChange. An RxFill
transaction is sent from a pharmacy to
a prescriber or long term and post-acute
care (LTPAC) facility indicating the
FillStatus (dispensed, partially
dispensed, not dispensed or returned to
stock, or transferred to another
pharmacy) of the new, refill, or resupply
prescriptions for a patient.
RxFillIndicator informs the pharmacy of
the prescriber’s intent for fill status
notifications for a specific patient/
medication. An RxFillIndicatorChange
is sent by a prescriber to a pharmacy to
indicate that the prescriber is changing
the types of RxFill transactions that
were previously requested, and in
which the prescriber may modify the fill
status of transactions previously
selected or may cancel future RxFill
transactions.
Comments. While the RxFill
transaction received unanimous support
as a required transaction, the vast
majority of comments opposed adopting
the RxFillIndicatorChange as proposed
due to a lack of industry adoption and
broad use by PIS. One commenter stated
that there has not been a significant use
case for the RxFillIndicatorChange
transaction to prescribers. A few
commenters suggested that ONC wait to
require the RxFillIndicatorChange until
this transaction is more widely adopted
by both prescribers and pharmacies and
value is realized in the industry, and
suggested either removing
RxFillndicatorChange from the
proposed criterion or making this
transaction optional. Another
commenter argued that
RxFillIndicatorChange should be
optional as development to support this
transaction in NCPDP SCRIPT standard
version 2017071 would be resource
intensive. Commenters in support of the
adoption of the RxFillIndicatorChange
transaction stated it is the only way to
alter the prescriber notification
preferences in an ambulatory or acute
setting outside of a fillable message.
Commenters supporting adoption of the
RxFillIndicatorChange transaction
further noted that, historically, the lack
of prescriber control over notification
messages may have had an impact on
hindering adoption. One commenter
suggested that, in lieu of the
RxFillIndicatorChange transaction,
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
EHRs receive all fill notifications and
subsequently use logic to bring the
clinician’s attention to only important
indicators.
Response. We appreciate all of the
comments that supported the RxFill
transaction and the
RxFillIndicatorChange transaction. After
consideration of comments received on
the RxFill and RxFillIndicatorChange
transactions, we have adopted the
RxFill transaction as required and the
RxFillIndicatorChange transaction as
optional in the updated § 170.315(b)(3)
electronic prescribing criterion. We
encourage further development and
innovation to address the concerns that
we heard from commenters, and we will
continue to monitor advancements in
standards and technology for future
rulemaking. We reiterate that PIS are
outside the scope of the ONC Health IT
Certification Program and encourage
pharmacy information system
developers to advance their capacity to
support a nationwide network of fully
interoperable PIS. Additionally, we note
that pursuant to the certification
criterion, health IT presented for
certification must be capable of
including the reason for the prescription
as referenced in the updated
§ 170.315(b)(3)(ii) or
§ 170.315(b)(3)(ii)(D) in the RxFill
transaction.
vi. Request and Receive Medication
History (RxHistoryRequest,
RxHistoryResponse)
We proposed in 84 FR 7444 to enable
a user to perform the related electronic
transactions for RxHistoryRequest and
RxHistoryResponse. An
RxHistoryRequest transaction is a
request from a prescriber to a pharmacy
for a list of medications that have been
prescribed, dispensed, claimed, or
indicated by a patient. An
RxHistoryResponse is a response to an
RxHistoryRequest containing a patient’s
medication history. It includes the
medications that were dispensed or
obtained within a certain timeframe,
and optionally includes the prescriber
that prescribed it.
Comments. Commenters supported
adoption of the RxHistoryRequest and
RxHistoryResponse transactions as
proposed. One commenter also stated
that both transactions could facilitate
EHR and other health IT data integration
with PDMP systems, yet noted that in
many cases, State law or policy
prohibits data integration between EHRs
and PDMPs. Another commenter stated
that these transactions are widely used
in the industry and provide great value
to end users.
PO 00000
Frm 00042
Fmt 4701
Sfmt 4700
Response. We appreciate all
comments we have received on the use
of the RxHistoryRequest and
RxHistoryResponse transactions. We
agree with the commenter that the
RxHistoryRequest and
RxHistoryResponse transactions support
data integration between health IT
systems such as EHRs and other
information technology systems such as
PDMPs, and encourage any efforts made
by developers to fully integrate
prescription and other health data into
a provider’s workflow within allowable
law. We reiterate that ONC does not
have control over State laws that govern
PDMPs. We will continue to monitor
regulatory and industry advancements
in this area and will take them into
consideration in future rulemaking. We
have adopted these transactions as
required in the updated § 170.315(b)(3)
electronic prescribing criterion.
Additionally, we note that pursuant to
the certification criterion, health IT
presented for certification must be
capable of including the reason for the
prescription as referenced in the
updated § 170.315(b)(3)(ii) or
§ 170.315(b)(3)(ii)(D) in the
RxHistoryResponse transaction.
vii. Ask the Mailbox If There Are Any
Transactions (GetMessage)
We proposed in 84 FR 7444 to enable
a user to perform the electronic
transaction GetMessage for Ask the
Mailbox. This transaction is used by the
prescriber or pharmacy when asking the
mailbox if there are any transactions. It
is the basis for the mechanism used by
a prescriber or pharmacy system to
receive transactions from each other,
from a payer, or from the Risk
Evaluation and Mitigation Strategy
(REMS) Administrator via a switch
acting as a mailbox.
Comments. Approximately half of
commenters opposed adoption of the
GetMessage transaction and the other
half supported adoption in the updated
§ 170.315(b)(3) electronic prescribing
criterion. Commenters not in support of
the GetMessage transaction asserted that
it is not in use by prescribers and that
it is an obsolete method of message
retrieval. Commenters in support of
adoption argued that it is applicable
when not transacting with real-time
messaging, and should be adopted as an
optional transaction.
Response. We thank commenters for
their input. After careful consideration
of all comments received, and in our
ongoing efforts to align with CMS Part
D requirements, we have determined to
adopt the GetMessage transaction as
optional for the updated § 170.315(b)(3)
electronic prescribing criterion.
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
viii. Relay Acceptance of a Transaction
Back to the Sender (Status)
We proposed in 84 FR 7444 to enable
a user to perform the related electronic
transaction to relay acceptance of a
transaction back to the sender. A Status
transaction in response to any
applicable transaction other than
GetMessage indicates acceptance and
responsibility for a request. A Status
transaction in response to GetMessage
indicates that no mail is waiting for
pickup. A Status transaction cannot be
held in an electronic mailbox and may
not contain an error.
Comments. Commenters supported
adoption of the Status transaction as
proposed. Two commenters noted that
since the transaction is an
acknowledgement, it would not contain
the reason for the prescription as
referenced in the updated
§ 170.315(b)(3)(ii) or
§ 170.315(b)(3)(ii)(D).
Response. We appreciate all
comments in support of the Status
transaction and have included this
transaction as required in the updated
§ 170.315(b)(3) electronic prescribing
criterion. As an acknowledgement, we
agree that the NCPDP SCRIPT version
2017071 standard does not support the
conveying the reason for the
prescription in the Status transaction,
and have modified the requirement to
reflect this.
ix. Respond That There Was a Problem
With the Transaction (Error)
We proposed in 84 FR 7444 to enable
a user to perform the related electronic
transaction for Error response. This
transaction indicates an error has
occurred and that the request was
terminated. An Error can be generated
when there is a communication problem
or when the transaction actually had an
error. An Error can be held in an
electronic mailbox, as it may be
signifying to the originator that a
transaction was unable to be delivered
or encountered problems in the
acceptance. The Error must be a
different response than a Status, since
the communication between the system
and the mailbox must clearly denote the
actions taking place. An Error is a
response being delivered on behalf of a
previous transaction, while Status
signifies no more mail.
Comments. Commenters supported
adoption of the Error transaction as
proposed. Two commenters noted that
since the transaction is an
acknowledgement, it would not contain
the reason for the prescription as
referenced in the updated
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
§ 170.315(b)(3)(ii) or
§ 170.315(b)(3)(ii)(D).
Response. We appreciate all
comments in support of the Error
transaction and have included this
transaction as required in the updated
§ 170.315(b)(3) electronic prescribing
criterion. As an acknowledgement, we
agree that the NCPDP SCRIPT version
2017071 standard does not support the
reason for the prescription in the Error
transaction, and we have modified that
requirement to reflect this.
x. Respond That a Transaction
Requesting a Return Receipt Has Been
Received (Verify)
We proposed in 84 FR 7445 to enable
a user to perform the related electronic
transaction for Verify. This transaction
is a response to a pharmacy or
prescriber indicating that a transaction
requesting a return receipt has been
received. Verifications result when a
‘‘return receipt requested’’ flag is set in
the original request. Upon receiving a
transaction with ReturnReceipt set, it is
the responsibility of the receiver to
either generate a Verify in response to
the request (recommended), or generate
a Status in response to this request,
followed subsequently by a freestanding Verify transaction. This
transaction notifies the originator that
the transaction was received at the
software system. It is not a notification
of action taking place, since time may
elapse before the ultimate response to
the transaction may take place.
Comments. Commenters supported
adoption of the Verify transaction as
proposed. Two commenters noted that
since the transaction is an
acknowledgement, it would not contain
the reason for the prescription as
referenced in the updated
§ 170.315(b)(3)(ii) or
§ 170.315(b)(3)(ii)(D).
Response. We appreciate all
comments in support of the Verify
transaction and have included this
transaction as required in the updated
§ 170.315(b)(3) electronic prescribing
criterion. As an acknowledgement, we
agree that the NCPDP SCRIPT standard
version 2017071 does not support the
reason for the prescription in the Verify
transaction, and we have modified that
requirement to reflect this.
xi. Request to Send an Additional
Supply of Medication (Resupply)
We proposed in 84 FR 7445 to enable
a user to perform the related electronic
transaction for Resupply. This
transaction is a request from a Long
Term and Post-Acute Care (LTPAC)
organization to a pharmacy to send an
additional supply of medication for an
PO 00000
Frm 00043
Fmt 4701
Sfmt 4700
25683
existing order. An example use case is
when a medication supply for a resident
is running low (e.g., 2–3 doses) and a
new supply is needed from the
pharmacy. In such a circumstance, the
LTPAC organization sends the Resupply
transaction as a way to notify the
pharmacy that an additional supply for
the medication is needed.
Comments. Commenters expressed
concern over adopting this transaction
as a required transaction for a few
reasons. Some commenters noted that
the Resupply transaction is only
applicable to LTPAC practice settings
for management of on-site pharmacy
inventory and for communication
between a LTPAC facility and a
contracted pharmacy. Other
commenters mentioned that PIS on the
sending or receiving end of the
transaction are not required to support
this transaction. Some commenters
stated that this transaction is not widely
adopted among prescribers, and that it
should not be adopted until this occurs.
Two commenters requested that we
either remove the transaction from the
final rule or make the Resupply
transaction optional. Other commenters
stated that while this transaction may be
beneficial in the future, it was their
opinion that it is premature to require
the Resupply transaction in the
electronic prescribing criterion at this
time.
Response. We appreciate all
comments related to the Resupply
transaction and have included this
transaction as optional in the updated
§ 170.315(b)(3) electronic prescribing
criterion. We are aware of several ONCcertified EHRs and other health IT that
were either designed exclusively for, or
were expressly designed to support,
LTPAC providers in addition to other
institutions, and encourage those and
other developers to undergo
certification testing to the Resupply
transaction. Additionally, we note that
pursuant to the certification criterion,
health IT presented for certification
must be capable of including the reason
for the prescription as referenced in the
updated § 170.315(b)(3)(ii) or
§ 170.315(b)(3)(ii)(D) in the Resupply
transaction. We reiterate that PIS are
outside the scope of the ONC Health IT
Certification Program and encourage
pharmacy information system
developers to advance their capacity to
support a nationwide network of fully
interoperable PIS.
xii. Communicate Drug Administration
Events (DrugAdministration)
We proposed in 84 FR 7445 to enable
a user to perform the related electronic
transaction for DrugAdministration.
E:\FR\FM\01MYR3.SGM
01MYR3
25684
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
This transaction communicates drug
administration events from a prescriber
or care facility to the pharmacy or other
entity. It is a notification from a
prescriber or care facility to a pharmacy
or other entity that a drug
administration event has occurred (e.g.,
a medication was suspended or
administration was resumed).
Comments. Commenters expressed
concern over adopting this transaction
as a required transaction for a few
reasons. Some commenters noted that
the DrugAdministration transaction is
only applicable to LTPAC practice
settings and is therefore not relevant to
the scope of all certified health IT
products, though one commenter noted
that there could be possible value of this
transaction in ambulatory and acute
care settings as well. In addition, one
commenter reported LTPAC
organizations interested in potentially
using e-prescribing transactions rated
DrugAdministration as a low priority
transaction type, meaning there may not
be a wide user base interested in
implementing it.
Response. We appreciate comments
related to the DrugAdministration
transaction and have included this
transaction as optional in the updated
§ 170.315(b)(3) electronic prescribing
criterion. We are aware of several ONCcertified EHRs and other health IT that
were either designed exclusively for, or
are used in support of, LTPAC
providers, and encourage those and
other developers to undergo
certification testing to the
DrugAdministration transaction. In light
of the commenters’ concerns, we have
adopted the DrugAdministration
transaction as optional because the ONC
Health IT Certification Program is
agnostic to care settings and programs,
yet still supports many different use
cases. This allows the ONC Health IT
Certification Program to support
multiple program and setting needs,
including but not limited to the
Promoting Interoperability Programs
and long term and post-acute care.
Because the transaction will be optional
in the updated (b)(3) criterion,
developers whose clients do not support
long term care settings will not be
required to demonstrate their capacity
to send this transaction.
xiii. Request and Respond to Transfer
One or More Prescriptions Between
Pharmacies (RxTransferRequest,
RxTransferResponse,
RxTransferConfirm)
We proposed in 84 FR 7445 to enable
a user to perform the related electronic
transactions for RxTransferRequest,
RxTransferResponse and
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
RxTransferConfirm. The
RxTransferRequest transaction is used
when the pharmacy is asking for a
transfer of one or more prescriptions for
a specific patient to the requesting
pharmacy. The RxTransferResponse
transaction is the response to the
RxTransferRequest which includes the
prescription(s) being transferred or a
rejection of the transfer request. It is
sent from the transferring pharmacy to
the requesting pharmacy. The
RxTransferConfirm transaction is used
by the pharmacy receiving (originally
requesting) the transfer to confirm that
the transfer prescription has been
received and the transfer is complete.
Comments. The vast majority of
commenters expressed concerns with
the proposal to adopt
RxTransferRequest,
RxTransferResponse, and
RxTransferConfirm transactions as
proposed because they are only used in
pharmacy-to-pharmacy transactions and
are not applicable to EHRs. Further, two
commenters noted that PIS are not
required to support these transactions.
Conversely, the two commenters that
supported these transactions cited the
benefit of allowing pharmacies to
transfer unfilled controlled substance
prescriptions, including Schedule 2,
between pharmacies.
Response. We thank commenters for
their input. We proposed to require all
of the NCPDP SCRIPT 2017071 standard
transactions CMS adopted in 42 CFR
423.160(b)(2)(iv) to illustrate our
continued dedication to establish and
maintain complementary policies to
ensure that the current standard for
certification to the electronic
prescribing criterion permits use of the
current Part D e-Rx and MH standards.
With consideration of comments, and
because it was not the intent of this
certification criterion to include
pharmacy specific transactions for the
purposes of certification, we have
adopted RxTransferRequest,
RxTransferResponse, and
RxTransferConfirm as optional in the
updated § 170.315(b)(3) electronic
prescribing criterion. We reiterate that
PIS are outside the scope of the ONC
Health IT Certification Program and
encourage pharmacy information system
developers to advance their capacity to
support a nationwide network of fully
interoperable PIS.
xiv. Recertify the Continued
Administration of a Medication Order
(Recertification)
We proposed in 84 FR 7445 to enable
a user to perform the related electronic
transaction for Recertification. This
transaction is a notification from a
PO 00000
Frm 00044
Fmt 4701
Sfmt 4700
LTPAC facility, on behalf of a
prescriber, to a pharmacy recertifying
the continued administration of a
medication order. An example use is
when an existing medication order has
been recertified by the prescriber for
continued use.
Comments. Commenters expressed
concern over adopting the
Recertification transaction as proposed
primarily because it is only applicable
to LTPAC practice settings. One
commenter stated that LTPAC
organizations interested in potentially
using e-prescribing transactions rated
Recertification as a low priority
transaction type, suggesting that there
may not be a wide user base interested
in using it.
Response. We appreciate all
comments in support of the
Recertification transaction. In light of
commenters concerns, we have adopted
this transaction as optional in the
updated § 170.315(b)(3) electronic
prescribing criterion. We are aware of
several ONC-certified EHRs and other
health IT that were either designed
expressly for or in support of LTPAC
providers, among other institutions, and
encourage those and other developers to
undergo certification testing to the
Recertification transaction.
xv. Complete Risk Evaluation and
Mitigation Strategy (REMS)
Transactions (REMSInitiationRequest,
REMSInitiationResponse,
REMSRequest, and REMSResponse)
We proposed in 84 FR 7445 to enable
a user to perform the related electronic
transactions for REMSInitiationRequest,
REMSInitiationResponse,
REMSRequest, and REMSResponse.
With CMS’ adoption of these
transactions in their recently issued
final rule associated with e-Rx for
Medicare Part D (42 CFR
423.160(b)(2)(iv)(W)–(Z)), we believe
that it will be beneficial to include these
four REMS transactions as part of this
certification criterion:
REMSInitiationRequest,
REMSInitiationResponse,
REMSRequest, and REMSResponse.
Furthermore, under the Food and
Drug Administration Amendments Act
(FDAAA) of 2007 (Pub. L. 110–85), the
Food and Drug Administration (FDA)
requires REMS from a pharmaceutical
manufacturer if the FDA determines that
a REMS is necessary to ensure the
benefits of a drug outweigh the risks
associated with the drug. In support of
our sister agencies’ work, we therefore
proposed to include the REMS
transactions as part of this certification
criterion.
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
Comments. The vast majority of
commenters supported adoption of
REMSInitiationRequest,
REMSInitiationResponse,
REMSRequest, and REMSResponse as
optional, not required, transactions.
Those in support of the transactions as
proposed suggested that ONC should
develop strategies to encourage
providers to consciously consider and
appropriately act on alerts to reduce the
risk that these messages can easily be
clicked through and missed, particularly
if that provider is experiencing alert
fatigue. Multiple reasons were provided
by commenters who stated that the
proposed REMS transactions should be
adopted as optional in the proposed
certification criterion. These reasons
included the state of system readiness
and adoption by manufacturers, REMS
administrators, and pharmacy
information systems. Another
commenter stated that these REMS
transactions are not yet in widespread
use and should be piloted before being
required as they require extensive
design and development effort.
Response. Given comments in support
of the REMSInitiationRequest,
REMSInitiationResponse,
REMSRequest, and REMSResponse
transactions, we have included these
transactions as optional in the updated
§ 170.315(b)(3) electronic prescribing
criterion. We encourage commenters,
developers, and other stakeholder to
review and provide feedback on
sections related to REMS (https://
www.healthit.gov/isa/allows-aprescriber-communicate-a-remsadministrator) and all other electronic
prescribing use cases on the ONC
Interoperability Standards (ISA) and
post suggested edits and updates on
these transactions as the industry
advances. We encourage manufacturers,
REMS administrators, and pharmacy
information system developers to adopt
these and other NCPDP SCRIPT
standard version 2017071 transactions
to improve safe prescribing practices
and patient safety, and encourage
developers to test their capacity to send
and receive REMS messages by utilizing
the testing tools that are available.
xvi. Electronic Prior Authorization
The Part D E-prescribing prior
authorization process in 84 FR 28450
through 28458 requires that providers
supply additional clinical information
to verify that the medication can be
covered under the Medicare Part D
benefit. The prior authorization process
is intended to promote better clinical
decision-making and ensure that
patients receive medically necessary
prescription drugs. We are looking for
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
ways that would streamline the process
for exchanging clinical and financial
data amongst prescribers and payers for
prior authorization and improve
patients’ access to needed medications.
Electronic prior authorization (ePA)
automates this process by allowing
providers to request and respond to
electronic prior authorization
transactions within their workflow.
Using electronic prior authorization
(ePA) transactions in the NCPDP
SCRIPT standard version 2017071
provides a standard structure for
exchanging prior authorization (PA)
questions and answers between
prescribers and payers, while allowing
payers to customize the wording of the
questions. Electronic prior authorization
transactions will additionally support
the automation of the collection of data
required for PA consideration, allowing
a health IT developer to systemically
pull data from a patient’s medical
record. The efficiency gains offered by
the ePA transactions in the NCPDP
SCRIPT standard version 2017071 are
the primary driver behind the
development of this new capability. We
believe the adoption of the ePA
transactions included in version
2017071 of the NCPDP SCRIPT standard
as optional transactions aligns with
CMS’ proposals for Part D ePA, and
therefore, will not be adopting NCPDP
SCRIPT standard version 2013101 as
suggested by the commenter. On June
17, 2019, CMS issued the Secure
Electronic Prior Authorization for
Medicare Part D proposed rule (84 FR
28450), including a proposed new
transaction standard for the Medicare
Prescription Drug Benefit program’s
(Part D) e-prescribing program. Under
this proposal, Part D plan sponsors
would be required to support version
2017071 of the NCPDP SCRIPT standard
for four ePA transactions, and
prescribers would be required to use
that standard when performing ePA
transactions for Part D covered drugs
they wish to prescribe to Part D eligible
individuals. While not currently
adopted as part of the Part D eRx
standard, the NCPDP SCRIPT standard
version 2017071 includes eight
transactions that would enable the
prescribers to initiate medication ePA
requests with Part D plan sponsors at
the time of the patient’s visit. The eight
transactions are: PAInitiationRequest,
PAInitiationResponse, PARequest,
PAResponse, PAAppealRequest,
PAAppealResponse, PACancelRequest,
and PACancelResponse.
Comments. Several commenters
recommended the adoption of the ePA
transactions available in the NCPDP
PO 00000
Frm 00045
Fmt 4701
Sfmt 4700
25685
SCRIPT standard version 2017071 for a
variety of reasons, including improving
efficiencies in the prior authorization
process, improving patient outcomes,
reducing point-of-sale rejections,
increasing health IT developer adoption,
and improving the Medicare Part D
member experience. Several
commenters indicated that lack of
vendor support for the ePA transactions
is a major barrier to physician use of the
transactions. One commenter also
suggested ONC adopt the NCPDP
SCRIPT standard version 2013101 prior
authorization transactions.
Response. We thank commenters for
their feedback. In consideration of
comments, we have adopted the ePA
transactions in the NCPDP SCRIPT
standard version 2017071 as optional
for the updated § 170.315(b)(3)
electronic prescribing criterion. We
believe the adoption of the ePA
transactions included in version
2017071 of the NCPDP SCRIPT standard
as optional transactions aligns with
CMS’ proposals for Part D ePA. We note
that this final rule allows only for the
voluntary certification of Health IT
Modules by health IT developers to
support these transactions, and does not
require the certification, adoption, or
use of such Health IT Modules by health
care providers for this or any other
purpose. We also note that
development, testing, and
implementation to support these
transactions are important first steps
toward integrating pharmacies in the
prior authorization process for Part D
prescriptions, while supporting
widespread industry adoption and
reducing burden on providers. We refer
readers to the ONC Strategy on
Reducing Regulatory and
Administrative Burden Relating to the
Use of Health IT and EHRs,44 drafted in
partnership with CMS, for further
discussion of potential opportunities to
ease related clinician burden through
improved health IT enabled processes.
xvii. Reason for the Prescription
For each transaction specified, the
technology must be able to receive and
transmit the reason for the prescription.
Comments. Commenters supported
continued adoption of the reason for the
prescription in specific electronic
prescribing transactions. Some
commenters noted that some of the
proposed transactions would not
contain the reason for the prescription
as referenced in the updated
44 https://www.healthit.gov/topic/usability-andprovider-burden/strategy-reducing-burden-relatinguse-health-it-and-ehrs.
E:\FR\FM\01MYR3.SGM
01MYR3
25686
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
§ 170.315(b)(3)(ii) or
§ 170.315(b)(3)(ii)(D).
Response. We thank commenters for
their feedback. We reiterate our decision
to require Health IT Modules seeking
certification to the updated electronic
prescribing certification criterion to be
capable of including the reason for the
prescription as referenced in the
updated § 170.315(b)(3)(ii) or
§ 170.315(b)(3)(ii)(D) within relevant
electronic prescription transactions to
support patient safety and align with
HHS goals to expand safe, high quality
health care. Health IT certified to the
updated § 170.315(b)(3) criterion must
have the capacity to enable a user to
receive and transmit the reason for the
prescription using the diagnosis
elements: or
, or optionally, the
technology must be able to receive and
transmit the reason for the prescription
using the element,
and be consistent with the International
Statistical Classification of Diseases and
Related Health Problems (ICDs) sent in
the diagnosis element(s). The
element defines the
indication for use of the medication as
meant to be conveyed to the patient, and
is included in the Sig. This requirement
would apply to the following NCPDP
SCRIPT standard version 2017071
transactions that we have adopted in
this criterion (see discussion above):
NewRx, RxChangeRequest,
RxChangeResponse, CancelRx,
RxRenewalRequest,
RxRenewalResponse, RxFill,
RxHistoryResponse, Resupply,
RxTransferRequest, RxTranferResponse,
REMSInitiationRequest,
REMSInitiationResponse,
REMSRequest, REMSResponse,
PAInitiationRequest,
PAInitiationResponse, PARequest,
PAResponse, PAAppealRequest,
PAAppealResponse, PACancelRequest,
and PACancelResponse.
xviii. Oral Liquid Medications
Limit a user’s ability to prescribe all
oral liquid medications in only metric
standard units of mL (i.e., not cc).
Comments. While not within the
scope of the Proposed Rule, one
commenter did not support the
continued requirement to prescribe oral
liquids in ‘‘mL’’ units. The commenter
supported the use of metric units, but
did not agree with the requirement of
the ONC Health IT Certification Program
to limit this to only milliliters. The
commenter recommended that the unit
of measure used by a prescriber be at
their discretion, as long as it is
appropriate for the dosage.
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
Response. We thank the commenter
for the input. Because this requirement
is out of scope for the Proposed Rule in
that we did not propose to change this
conformance requirement, we decline to
relax or retire the requirement for oral
liquid medications to be prescribed in
mL units. When we first adopted this
requirement for the 2015 Edition
Proposed Rule, several commenters
were supportive of improving patient
safety through use of the metric
standard for dosing, but recommended
that this requirement only apply to oral
liquid medications. Incorrect dosage is a
common error with liquid medication,
often resulting from confusion between
different dose measurements (e.g., mL
and teaspoons). If these measurements
are confused with each other, too much
or too little of the medicine can be
given. This requirement is also in
alignment with NCPDP SCRIPT
implementation recommendations.
xix. Signatura (Sig) Element
The Signatura (Sig) element is used to
support electronic prescribing for the
consistent expression of patient
directions for use by relaying this
information between a prescriber and a
pharmacist. It must be legible,
unambiguous, and complete to ensure
the prescriber’s instructions for use of
the medication are understood. For each
transaction, the technology must be able
to receive and transmit the reason for
the prescription using the indication
elements in the SIG Segment.
Comments. One commenter requested
that the Sig element be required rather
than optional to aid in future
medication reconciliation and clinical
reporting. Another commenter noted
that the NCPDP SCRIPT standard
version 2017071 allows for an increase
in Sig length.
Response. Given the lack of attention
paid to and support for modifying the
electronic prescribing criterion for Sig
from optional to required, we have
decided to retain Sig as optional in the
updated § 170.315(b)(3) criterion. As
discussed in the Reason for Prescription
section, health IT may optionally seek
certification to the updated electronic
prescribing criterion by demonstrating
their capacity to receive and transmit
the reason for the prescription using the
Sig element.
xx. Real Time Pharmacy Benefit
While development is still currently
underway by NCPDP, the Real-Time
Pharmacy Benefit (RTPB) standard is
not yet complete. When complete, the
RTPB standard is expected to facilitate
the ability for pharmacy benefit payers/
processors to communicate formulary
PO 00000
Frm 00046
Fmt 4701
Sfmt 4700
and benefit information to providers. In
the absence of that or another similar
standard, CMS has adopted policies
requiring the development and/or
implementation of Real Time Benefit
Transaction (RTBT) standards in the
Part D e-Rx Program in the context of
recent rulemaking. On May 16, 2019,
CMS issued the Modernizing Part D and
Medicare Advantage to Lower Drug
Prices and Reduce Out-of-Pocket
Expenses final rule, which includes a
requirement under the electronic
prescribing standards that Part D plan
sponsors implement one or more
electronic real-time benefit tools that are
capable of integrating with at least one
prescriber’s electronic prescribing
system or electronic health record no
later than January 1, 2021 (84 FR
23832). One commenter recommended
that CMS and ONC coordinate with
NCPDP on requirements for real-time
benefit functionality. We are also aware
of industry efforts to develop a
consumer-facing real-time pharmacy
benefit functionality FHIR®-based
implementation guide that we anticipate
will be balloted in 2020. ONC will
continue to monitor these efforts and
consider proposing the NCPDP RTPB
standard or a similar standard to enable
real-time benefit transactions in future
rulemaking.
xxi. Other Comments Received Outside
the Scope of This Rule
We note that we received several
comments specifically addressing the
electronic prescribing of controlled
substances and prescription drug
monitoring programs. We note that
these specific comments are outside the
scope of the proposals finalized in this
rule. However, we note that we
included a discussion of these topics in
relation to the discussion of the RFI on
OUD prevention and treatment in the
Proposed Rule in 84 FR 7461.
5. Clinical Quality Measures—Report
Criterion
In the 2015 Edition final rule, ONC
adopted four clinical quality measure
(CQM) certification criteria,
§ 170.315(c)(1) CQMs—record and
export, § 170.315(c)(2) CQMs—import
and calculate, § 170.315(c)(3) CQMs—
report, and § 170.315(c)(4) CQMs—filter
(80 FR 62649 through 62655). These
four criteria were adopted with the
intent to support providers’ quality
improvement activities and in
electronically generating CQM reports
for reporting with certified health IT to
programs such as the EHR Incentive
Programs, Quality Payment Program,
and Comprehensive Primary Care plus
initiative. The ‘‘CQMs—report’’
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
certification criterion (§ 170.315(c)(3))
included an optional certification
provision for demonstrating that the
health IT can create Quality Reporting
Document Architecture (QRDA) reports
in the form and manner required for
submission to CMS programs, which is
in accordance with CMS’ QRDA
Implementation Guide (IGs).
The CMS QRDA IGs provide technical
guidance and specific requirements for
implementing the HL7 QRDA Category
I (QRDA I) and Category III (QRDA III)
standards for reporting to CMS quality
reporting programs.45 The CMS QRDA
IGs include the formal template
definitions and submission criteria for
submitting QRDA documents to the
Comprehensive Primary Care Plus
(CPC+) and Merit Based Incentive
Payments System (MIPS) Programs.
Some of the conformance statements in
the HL7 QRDA standards have been
further constrained to meet the specific
requirements from these CMS programs.
The CMS QRDA IGs also only list the
templates specifying CMS-specific
reporting requirements from the base
HL7 QRDA standards. QRDA I is an
individual-patient-level report. It
contains quality data for one patient for
one or more electronic clinical quality
measures (eCQMs). QRDA III is an
aggregate quality report. A QRDA III
report contains quality data for a set of
patients for one or more eCQMs.
Since the 2015 Edition final rule was
published, we have gained additional
certification experience and received
feedback from the industry that health
IT certified to the ‘‘CQMs—report’’
criterion (§ 170.315(c)(3)) are only/
primarily being used to submit eCQMs
to CMS for participation in CMS’
programs. Therefore, as a means of
reducing burden, we proposed to
remove the HL7 CDA® Release 2
Implementation Guide: QRDA I; Release
1, Draft Standard for Trial Use (DSTU)
Release 3 (US Realm), Volume 1
(§ 170.205(h)(2)), as well as the QRDA
Category III, Implementation Guide for
CDA® Release 2 (§ 170.205(k)(1)) and
the Errata to the HL7 Implementation
Guide for CDA® Release 2: QRDA
Category III, DSTU Release 1 (US
Realm), September 2014
(§ 170.205(k)(2)) standard requirements
(HL7 QRDA standards) from the current
2015 Edition CQMs—report criterion in
§ 170.315(c)(3), and we also proposed to
45 The following resources provide additional
information on the differences between the CMS
QRDA and the HL7 QRDA standards: https://
ecqi.healthit.gov/system/files/QRDA_HQR_2019_
CMS_IG_final_508.pdf (pg. 38) and https://
ecqi.healthit.gov/sites/default/files/2019-07/2020CMS-QRDA-III-Eligible-Clinicians-and-EP-IG07182019-508.pdf (pg. 18).
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
require that health IT certified to the
current 2015 Edition CQMs—report
criterion support the CMS QRDA IGs
(84 FR 7446). We stated that this change
would directly reduce burden on health
IT developers and indirectly providers
as they would no longer have to develop
and support two forms of the QRDA
standard.
We also solicited comment in the
Proposed Rule on the future possibility
of FHIR-enabled APIs replacing or
complementing QRDA-based quality
reporting. We also noted in the
Proposed Rule that the Fast Health
Interoperability Resources (FHIR®)
standard offers the potential for
supporting quality improvement and
reporting needs, and holds the potential
of being a more efficient and
interoperable standard to develop,
implement, and utilize to conduct
quality reporting through APIs. We
believe until the potential benefits of
FHIR® APIs can be realized for quality
reporting, and that solely requiring the
CMS QRDA IGs for the updated 2015
Edition ‘‘CQMs—report’’ criterion will
balance the burden on developers, while
still ensuring module users’ abilities to
meet their quality reporting obligations
to CMS (84 FR 7446).
To support the proposal, we proposed
to incorporate by reference in § 170.299
the latest annual CMS QRDA IGs,
specifically the 2019 CMS QRDA I IG
for Hospital Quality Reporting 46
(§ 170.205(h)(3)) and the 2019 CMS
QRDA III IG for Eligible Clinicians and
Eligible Professionals
(§ 170.205(k)(3)).47 We noted in the
Proposed Rule that developers would be
able to update certified health IT to
newer versions of the CMS QRDA IGs
through the real world testing
Maintenance of Certification provision
for standards and implementation
specification updates in § 170.405(b).
We also proposed that a Health IT
Module would need to be certified to
both standards to ensure flexibility for
Health IT Module users. We solicited
comment on whether to consider an
approach that would permit
certification to only one of the standards
depending on the care setting for which
the Health IT Module is designed and
implemented.
Comments. The majority of
commenters were supportive of the
proposal to remove the HL7 QRDA
standard requirements from the 2015
Edition CQMs—report criterion in
46 https://ecqi.healthit.gov/system/files/QRDA_
HQR_2019_CMS_IG_final_508.pdf.
47 https://ecqi.healthit.gov/system/files/2019_
CMS_QRDA_III_Eligible_Clinicians_and_EP_IG508.pdf.
PO 00000
Frm 00047
Fmt 4701
Sfmt 4700
25687
§ 170.315(c)(3), and to require that
health IT certified to the criterion
support the proposed CMS QRDA IGs.
Some commenters observed that the
main use cases for the certified QRDA
export functionality (which is specific
to CMS eCQMs) are to support direct
data submission to CMS at the
conclusion of reporting periods, to
enable use of third party data
submission Health IT Modules to meet
CMS reporting requirements, and to
support data extraction for registry
reporting for participation in CMS
programs such as MIPS. Commenters
noted that while in some cases the
extraction of data using a QRDA may
also support other use cases—for
example for a registry—because of the
specificity of the criteria to the CMS
eCQMs, such a transaction using the
certified functionality is primarily for
CMS reporting. Commenters noted the
use of the CMS QRDA IG does not
impede use of the data for other
purposes. Finally, commenters noted
that ONC should continue to provide
health IT developers the flexibility to
offer a non-certified QRDA functionality
that could support eCQMs beyond those
included for CMS programs. One
commenter observed that while some
health IT systems also provide tools for
internal quality performance
monitoring, those tools often do not rely
on the generation of QRDA exports.
Some commenters reported that the
technical support of multiple versions
of QRDA standards is unnecessary.
Other commenters recommended
maintaining only the HL7 standard or
offering certification to the HL7
standard as an optional alternative to
the CMS QRDA IG. One commenter who
recommended maintaining both the HL7
standard and the CMS QRDA IGs
suggested that ONC cite the CMS
version(s) of the QRDA IG as a technical
resource in the same manner the C–CDA
companion guide is cited for the
transition of care criteria and only
require certifying to the HL7 version.
These commenters agreed that
developers should not have to certify to
both HL7 QRDA and CMS QRDA IGs,
but suggested if a developer passed
certification for the CMS QRDA IGs,
they should be deemed to have achieved
certification to the HL7 QRDA standard
as well. Commenters noted that the
CMS QRDA apply specifications to the
HL7 QRDA to support CMS eCQM
reporting requirements.
Other commenters specifically stated
that the HL7 QRDA should remain as an
optional certification criterion, since
other organizations (e.g., certain
hospital accreditation organizations
such as The Joint Commission) use the
E:\FR\FM\01MYR3.SGM
01MYR3
25688
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
HL7 QRDA, and there is need to assure
the same style for submission across
programs. They recommended that the
HL7 QRDA IG persist as a continuing
option in the Program to enhance
alignment with other standards and C–
CDA, and to encourage a base standard
alignment across implementers such as
CMS and The Joint Commission. They
stated that citing only to the CMS QRDA
IG may lead to misalignment with the
base standards and reduce incentives to
update the base standard.
Some commenters expressed concern
over the proposed removal of HL7
QRDA standards from the original 2015
Edition CQMs, stating it may undermine
private sector efforts to self-regulate and
stated that the removal of the HL7
QRDA may not achieve the envisioned
burden reduction through the mere
elimination of developers’ need to
certify and maintain multiple standards.
While some commenters suggested that
removing HL7 QRDA from the
certification criteria could simplify the
reporting process by recognizing the
widespread use of CMS’ QRDA IGs, they
noted that the HL7 QRDA is currently
the standard for most EHR systems and
questioned how ONC proposed to
implement this change given the
prominence of HL7 standards in EHR
systems. Several commenters noted that
the disconnect between what the
certification testing required, and how
the standard was really being used in
the industry (primarily but not
exclusively to meet the CMS QRDA IG)
created unnecessary certification testing
burden, and asserted that the adoption
of the CMS proprietary IG was more
appropriate than to maintain HL7
QRDA.
Response. We thank commenters for
their support for the proposal and
comments regarding the versions of
standards. We understand the concerns
expressed in opposition to this
proposal, and we appreciate specifically
the identification of potential risk for
the elimination of the HL7 standard as
applicable for other use cases. As noted
previously, since the 2015 Edition final
rule was published (October 16, 2015),
we have gained received feedback from
the industry that health IT certified to
the ‘‘CQMs—report’’ criterion
(§ 170.315(c)(3)) are only or primarily
being used to submit eCQMs to CMS for
participation in CMS’ programs. In
addition, we note that while the HL7
QRDA may be used for other purposes,
the ‘‘CQMs—report’’ criterion
(§ 170.315(c)(3)) is specific to the CMS
eCQMs specified for participation in
CMS reporting programs and no other
eCQMs are tested under that criterion.
This specificity applies not only to the
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
current 2015 Edition ‘‘CQMs—report’’
criterion, but also to the other 2015
Edition CQM criteria and the prior 2014
Edition CQM criteria. This specificity is
intended to provide assurances through
testing and certification of the accuracy
and standardization of CMS program
measures across platforms, while
recognizing that it would not be
possible to specifically test to the entire
universe of potential eCQMs in use by
health care providers. Because of this
dependency, testing and certification of
both the HL7 QRDA for CQMs-report
and the CMS QRDA IG is redundant to
support eCQM data reporting.
This has a dual impact on our
considerations to finalize our proposal
to require only the CMS QRDA IG. First,
for use cases that are not related to CMS
eCQM reporting, the certified
functionality would not specifically
support third party non-CMS eCQM
reporting requirements, and so the
modification to the functionality does
not change the inability to use the
certified version of the functionality for
such purposes. Second, for those use
cases involving registries or other third
parties that are implementing or
supporting CMS eCQM reporting, use of
the CMS QRDA IG could additionally
support such purposes. In addition, we
are not restricting health IT developers
from creating and providing to
customers a non-certified functionality
that supports the HL7 QRDA for the
extraction of data for eCQMs that are not
CMS eCQMs. We note that this is not a
change from the prior policy allowing
such flexibility. The prior certification
for the QRDA IG included testing of
CMS eCQMs only and it neither
supported nor restricted any
development of a QRDA functionality
for non-CMS eCQMs.
We also agree that this approach will
support closer alignment between the
testing to the CMS QRDA IG
specifications for a certified health IT
module and the technical requirements
for CMS program reporting. As part of
the development of the CMS QRDA IGs,
CMS strives to use the annual update
process to resolve issues with CQMs
based on updates to clinical guidelines
and to advance the requirements as the
standard for reporting eCQM data
matures. In this way, aligning the
criterion to the CMS program
requirements that it specifically
supports allows for alignment between
these efforts as well as allowing for
continued updates through the
standards version advancement process.
We also believe our finalized proposal
will not impede private sector
initiatives as the CMS IGs support the
continued efforts by public/private
PO 00000
Frm 00048
Fmt 4701
Sfmt 4700
collaboration through standards
developing organizations (SDOs) to
refine standards.
Therefore, as a means of reducing
burden, we have finalized our proposal
to remove the HL7 QRDA standard
requirements from the 2015 Edition
CQMs—report criterion in
§ 170.315(c)(3). We maintain our
position that this would directly reduce
burden on health IT developers and
indirectly for health care providers as
there would no longer be a requirement
to develop and support two forms of the
QRDA standard. We note that this does
not preclude developers from
continuing to support the underlying
standard, especially where such
standard may support reporting or
health information exchange for other
quality or public health purposes.
Instead, we are simply not requiring
testing and certification of any such
standards, thereby eliminating testing
and certification burden from a criterion
that is at this time scoped to the purpose
of reporting for CMS quality programs.
Comments. A few commenters did not
support the proposal but instead
recommended that CMS adopt the HL7
QRDA standard and do away with its
own. However, several commenters
offered suggestions to CMS on the
development of the CMS QRDA IG and
the alignment to the HL7 QRDA
standard. A number of commenters
noted the National Technology Transfer
and Advancement Act of 1995 principle
that Federal agencies are generally
required to use technical standards that
are developed by voluntary consensus
standards bodies rather than a
proprietary standard specific to an HHS
program. Commenters also stated if
CMS wanted to retain certain aspects of
its standard, it should work with HL7 to
get these vetted, balloted and approved
for inclusion within the HL7 standard.
Commenters also recommended
working with SDOs or other
organizations to sufficiently support
CMS QRDA IGs. Some commenters
suggested that consolidation of QRDA
standards would be more likely result in
reducing provider burdens than what
ONC proposed.
Response. We thank the commenters
for their recommendations to improve
the CMS QRDA IGs, or for CMS to work
toward including the aspects of CMS
QRDA IGs that they require for their
program operations in SDO-balloted and
approved consensus standards. Specific
suggestions for CMS IG development are
outside the scope of this rule. ONC had
previously included the HL7 QRDA
standards for certification in the 2015
Edition in order to potentially support
a broader range of use cases than
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
reporting for CMS programs. However,
the specificity of the criterion to the
CMS eCQMs limits the utility of the
certified functionality beyond use with
CMS eCQMs and as stated in the
Proposed Rule, since the 2015 Edition
final rule, ONC and CMS received
significant stakeholder feedback that
health IT modules certified to the
‘‘CQMs—report’’ criteria at 170.314(c)(3)
in the 2014 Edition and 170.315(c)(3) for
the 2015 Edition are used only or
primarily for reporting to CMS
programs. While we reiterate that these
comments are outside the scope of this
rule, we will continue to take this and
other feedback into consideration and
will continue to work with CMS,
standards developing organizations, and
health IT industry partners to explore
the concerns raised in relation to
reducing burden and promoting
interoperable standards for quality
reporting.
Comments. Commenters provided
mixed feedback on whether the updated
2015 Edition ‘‘CQMs—report’’ criterion
should require adherence to both CMS
QRDA IGs, specifically the 2019 CMS
QRDA I IG for Hospital Quality
Reporting 48 and the 2019 CMS QRDA
III IG for Eligible Clinicians and Eligible
Professionals.49 The majority of
commenters recommended that to
reduce burden, ONC should consider a
certification approach that permits
developers to seek certifications based
on the care setting(s) their health IT
modules are intended serve. For
example, commenters suggested that
ONC should only require certification to
the 2019 QRDA I IG for Hospital Quality
Reporting if a Health IT Module is
designed exclusively for the reporting of
hospital measures, and only require
certification to the 2019 QRDA III IG for
Eligible Clinicians and Eligible
Professionals when a Health IT Module
is designed exclusively for the reporting
of ambulatory measures. In instances in
which both populations are served, the
developer would then seek certification
to both standards. Commenters
suggested this approach would avoid
the unnecessary burden of certifying to
a standard that the Health IT Module
was not intended to serve. Other
commenters stated that the certification
requirements should ensure that
certified Health IT Modules can support
quality measure reporting by all
potential users, especially given the
potential expansion of eligible
https://ecqi.healthit.gov/system/files/QRDA_
HQR_2019_CMS_IG_final_508.pdf.
49 https://ecqi.healthit.gov/system/files/2019_
CMS_QRDA_III_Eligible_Clinicians_and_EP_IG508.pdf.
48
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
participants in certain CMS programs
(e.g., should a program expand from
hospital-based only to include
ambulatory measures). These
commenters recommended the adoption
of a requirement for certified Health IT
Modules to calculate and export both
CMS QRDA I patient-level reports for
Hospital Quality Reporting and CMS
QRDA III aggregate summary reports for
Eligible Clinicians and Eligible
Professionals. These commenters noted
that if a certified Health IT Module can
only send an aggregate report without a
patient level report, then this would
greatly diminish the ability to verify the
underlying calculations. However,
commenters recommended that ONC
clarify that the transition to CMS QRDA
I IG-based reports (patient-level, QRDA
I IG for Hospital Quality Reporting) does
not necessarily mean that a hospital
quality measure must be certified by any
system (i.e., an ambulatory Health IT
Module can certify to only CMS QRDA
III IG requirements). Commenters also
sought clarity that the transition to
QRDA III reports (aggregate-level, IG for
Eligible Clinicians and Eligible
Professionals) does not necessarily
mean that an ambulatory quality
measure must be certified by any system
(i.e., a hospital system can certify to
only hospital measures). Finally, one
commenter noted that certifying
ambulatory quality measures for the
QRDA I to a hospital IG is not effective
and will interfere with the use case of
using QRDA I to combine data between
multiple ambulatory systems such as for
group reporting.
Response. We thank commenters for
their comments regarding whether a
Health IT Module should be certified to
both CMS QRDA IG standards or
whether to consider an approach that
permits certification to only one of the
standards depending on the care setting
for which the Health IT Module is
designed and implemented. We agree
with commenters that our certification
approach should prevent unintended
burden by tailoring the requirements to
the type of measures being tested. This
would mean that for the updated
certification criterion ‘‘CQMs—report’’
in § 170.315(c)(3) a Health IT Module
testing only ambulatory measures would
test only with the CMS QRDA III IG for
ambulatory measures and a Health IT
Module testing only inpatient measures
would test only with the QRDA I CMS
IG for inpatient measures. A Health IT
Module supporting both ambulatory and
inpatient measures would be required to
test to both the CMS QRDA I IG and the
CMS QRDA III IG. We clarify that
testing for the 2015 Edition ‘‘CQM—
PO 00000
Frm 00049
Fmt 4701
Sfmt 4700
25689
capture and export’’ criterion in
§ 170.315(c)(1) criteria includes
demonstrating the capability to export a
QRDA I report specific to the eCQM
being tested—which would support use
case noted by the commenter to
combine data across multiple
ambulatory systems. We have not
proposed and have not finalized a
change to the 2015 Edition ‘‘CQM—
capture and export’’ criterion in
§ 170.315(c)(1). We further note that
health IT developers may leverage
QRDA file formats for a wide range of
use cases and that our inclusion of the
CMS QRDA I and QRDA III IGs does not
prohibit the use of the QRDA standard
for any other purpose. As noted above,
we have finalized the adoption of the
CMS QRDA IGs for the ‘‘CQMs—report’’
criterion in § 170.315(c)(3) for which the
Health IT Module is presented for
certification.
Comments. The majority of
commenters supported the proposal to
adopt the latest CMS QRDA IGs at the
time of final rule publication, as CMS
updates their QRDA IGs annually to
support the latest eCQM specifications
and only accepts eCQM reporting to the
latest version. However, a few
commenters recommended that ONC
monitor this part of the certification
process for unintended consequences
since CMS’ IGs are updated on a yearly
basis. Some commenters noted that
given the lack of alignment with timing,
eCQM measures and standards will
continue to lack testing. Other
commenters recommended the IGs be
updated in alignment with updates to
the certification standards. A few
commenters requested clarification of
the effective dates and asked ONC to
evaluate and propose a timeline for the
implementation of an alignment
between the programs. In addition,
commenters asked for clarification on
whether ONC will propose penalties for
providers who may be unable to meet
the timeline if it is insufficient.
Response. We thank commenters for
their input and have adopted the latest
CMS QRDA IG versions available at the
time of publication of this final rule. For
details on the latest CMS QRDA IGs, we
refer readers to the CMS QRDA I
Implementation Guide for Hospital
Quality Reporting and CMS QRDA III
Implementation Guide for Eligible
Clinicians and Eligible Professionals
available on the eCQI Resource Center
website.50 We note that CMS updates
50 The Electronic Clinical Quality Improvement
(eCQI) Resource Center. CMS QRDA I
Implementation Guide for Hospital Quality
Reporting and CMS QRDA III Implementation
Guide for Eligible Clinicians and Eligible
E:\FR\FM\01MYR3.SGM
Continued
01MYR3
25690
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
the CMS eCQMs on an annual basis as
well as the CMS QRDA IGs for reporting
to CMS programs. As in prior years
going back to the 2014 Edition, HHS
will continue to update the Cypress
testing tool to support health IT
developer testing to the most recent
annual update. We note that CMS has
previously required that EHR
technology used for eCQM reporting be
certified to all eCQMs but does not need
to be recertified each time it is updated
to a more recent version of the eCQM
electronic specifications, unless the
EHR technology is supporting new
eCQMs or functionality (such as the
‘‘CQM—filter’’ criterion in
§ 170.315(c)(4)) (84 FR 42505). This
approach allows for continued updates
to and testing of eCQMs while
minimizing the burden on developers
and providers to support those updates
in time for each annual performance
period. Finally, we note that ONC has
no authority to set requirements,
incentives, or penalties for health care
providers related to the use of health IT,
and we direct readers to CMS for
information on health IT requirements
in CMS programs.
Comments. The majority of
commenters agreed with ONC’s
assessment in the Proposed Rule that
quality reporting is not yet ready to
transition to FHIR and that more testing
and validation of FHIR is needed before
requiring a new API-based reporting
functionality as a part of the Program.
Some commenters supported the
adoption of FHIR Release 4-enabled
APIs as a replacement for QRDA-based
reports, but stated that published
documentation aligning HL7 C–CDA,
QRDA, and/or FHIR standards to CMS’
‘‘Quality Data Model,51’’ which is an
information model that defines
relationships between patients and
clinical concepts in a standardized
format to enable electronic quality
performance measurement and that
would allow for more consistent eCQM
reporting and improved interoperability
in clinical quality feedback between
health systems and data registries. Other
commenters stated that FHIR standards
will likely strengthen standardized data
element availability and flexibility to
improve the types of eCQMs that may be
developed, and suggested that CMS
continue to work with the National
Quality Forum, measure stewards, and
measure developers to advance both
existing evidence-based measures (e.g.,
either administrative or hybrid
measures) and evolving outcome
Professionals. Available at: https://
ecqi.healthit.gov/qrda.
51 https://ecqi.healthit.gov/qdm.
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
measures that utilize population-based
electronic clinical data.
Response. We thank commenters for
their support. We believe there are
potential benefits to be gained by
exploring both near-term, program
specific implementations of APIs to
support current quality reporting
submission mechanisms such as for
CMS eCQM reporting as well as the
long-term potential to reimagine quality
measurement by leveraging API
technologies. We believe that these
technology approaches could help
providers and payers, including CMS,
move from the current approach, in
which providers are required to
calculate and submit results on specific
quality measures, to one in which
payers, including CMS, could obtain
clinical data for quality measurement
directly through an API. This could
potentially include the ability to obtain
clinical data for a defined group or
sample set of patients to assess quality
across patient populations, as well as to
compare clinical data for patients over
time to assess quality impacts through
longitudinal measurement. We believe
emerging innovative standards are now
available to support such models,
specifically the ability to respond with
clinical data for a defined group or
sample set of patients using the bulk
data capabilities in FHIR Release 4. We
note that readiness for such an
approach, both for recipients of quality
data and for health IT developers
supporting quality improvement
solutions, is not yet mature for adoption
of such a criterion in the Program.
However, we are committed to
continuing to work with HHS partners,
health care providers, health IT
developers and SDOs to explore the
potential for such solutions in the
future.
Comments. Several commenters
recommended additional changes not
considered in the Proposed Rule. For
example, one commenter recommended
ONC require that to be certified in
§ 170.315(c)(1) ‘‘CQMs—record and
export,’’ § 170.315(c)(2), ‘‘CQMs—
import and calculate,’’ and
§ 170.315(c)(3) ‘‘CQMs—report,’’ a
Health IT Module be certified in a
minimum of 9 eCQMs instead of one
eCQM and that the § 170.315(c)(1)
criterion should require the ability to
export all patients for a given eCQM.
Currently, the ability to export a QRDA
I file can be limited to one patient at a
time. Commenters noted that this
limitation defeats the purpose of data
interoperability and does not advance
the goals of ONC to increase access to
data and the interoperability of Health
IT Modules. And another commenter
PO 00000
Frm 00050
Fmt 4701
Sfmt 4700
recommended that, in addition to the
adoption of the CMS IGs under the
§ 170.315(c)(3) criterion, that the CMS
IGs replace the corresponding HL7
QRDA IGs as ONC’s Program standard
under the § 170.315(c)(1) criterion
(which currently references QRDA I
exclusively) and § 170.315(c)(2)
criterion (which currently references
only QRDA I as standard, but also
involves use of QRDA III for purposes
of verifying appropriate calculation of
measures from imported QRDAs).
Response. We thank commenters for
input and clarifications. While we
appreciate comments suggesting
changes to § 170.315(c)(1) ‘‘CQMs—
record and export,’’ and § 170.315(c)(2)
‘‘CQMs—import and calculate,’’ the
recommended changes are outside the
scope of our proposal. Therefore, while
we may consider these
recommendations for future Program
rulemaking, we have not adopted the
suggested changes to § 170.315(c)(1)
‘‘CQMs—record and export,’’ or
§ 170.315(c)(2) ‘‘CQMs—import and
calculate in this final rule.
As noted previously, we have
finalized the update to the ‘‘CQMs—
report’’ criterion in § 170.315(c)(3) to
require that health IT developers use the
CMS QRDA IG appropriate to the
measures being submitted for testing
and certification to read as follows:
‘‘Clinical quality measures—report.
Enable a user to electronically create a
data file for transmission of clinical
quality measurement data in accordance
with the applicable implementation
specifications specified by the CMS
implementation guides for Quality
Reporting Document Architecture
(QRDA), category I, for inpatient
measures in § 170.205(h)(3) and CMS
QRDA, category III, for ambulatory
measures in § 170.205(k)(3).’’
6. Electronic Health Information (EHI)
Export Criterion
We proposed to adopt a new 2015
Edition certification criterion referred to
as ‘‘EHI Export’’ in § 170.315(b)(10). The
criterion’s conformance requirements
were intended to support two contexts
in which we believed that all EHI
produced and electronically managed
by a developer’s technology should be
made readily available for export as a
capability of certified health IT. First,
we proposed in § 170.315(b)(10)(i) at 84
FR 7447 that health IT certified to this
criterion would support single patient
EHI export upon a valid request by a
patient or a user on the patient’s behalf.
Second, we proposed in
§ 170.315(b)(10)(ii) at 84 FR 7447 that
the proposed criterion would support
the export of all EHI when a health care
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
provider chooses to transition or migrate
information to another health IT system.
Third, we proposed in
§ 170.315(b)(10)(iii) that the export
format(s) used to support the exports
must be made available via a publicly
accessible hyperlink, including keeping
the hyperlink up-to-date with the
current export format.
At the time of the Proposed Rule, we
indicated our belief that this proposed
certification criterion provided a useful
first step toward enabling patients to
have electronic access to their EHI and
equipping health care providers with
better tools to transition patient EHI to
another health IT system. We noted that
this criterion would create a baseline
capability for exporting EHI. We
requested comments regarding the
proposed single patient EHI export and
the proposed database export
functionalities, as well as the proposed
scope of data export and other criterion
elements throughout the Proposed Rule
section at 84 FR 7447 through 7449.
Comments. Commenters generally
supported the intent of the proposed
‘‘EHI export’’ criterion to advance the
access, exchange, and use of EHI.
Commenters in favor of the criterion
and its proposed conformance
requirements stated that it would foster
innovative export capabilities and
inform areas where additional standards
development could be needed. We also
received a variety of comments asking
for adjustments to proposed
requirements. A majority of commenters
requested revisions to the criterion,
including calling for a defined set of
data elements for export and specific
data transport standards. Many
commenters offered recommended
standards or requested that we provide
specific standards to reduce variation.
These commenters indicated that no
defined standard could lead to broad
interpretation and potential
inadequacies of the data export. Some
commenters expressed a medical record
keeping concern that the proposed
standards-agnostic approach for the
export functionality could be
problematic, stating that the export
could create a dissonance if the EHI
renders health record content in a form
or format that is different from what a
provider produces or utilizes as output.
Other commenters opposed the
adoption of this proposed criterion.
These commenters expressed concern
that later implementation of standards,
such as APIs, would make developers
invest time and funding into the
proposed requirements only for the
work to be discarded in the future.
Response. We thank commenters for
their feedback on the proposed ‘‘EHI
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
export’’ criterion at 84 FR 7446 of the
Proposed Rule (§ 170.315(b)(10)). We
have considered commenters’ concerns,
support, and recommendations and
adopted a revised version of this
certification criterion. This final
certification criterion is designed to
align with section 4006(a) of the Cures
Act, which requires the Secretary, in
consultation with the National
Coordinator, to promote policies that
ensure that a patient’s EHI is accessible
to that patient and the patient’s
designees, in a manner that facilitates
communication with the patient’s
health care providers and other
individuals (84 FR 7447). In addition,
this criterion complements other
provisions that support patients’ access
to their EHI and health care providers
use of EHI, such as the secure, standardbased API certification criterion
(proposed in 84 FR 7427 and finalized
in § 170.315(g)(10)), and also supports
longitudinal data record development.
Therefore, we have finalized the
criterion with revisions. Notably, in
response to comments on this criterion
and the proposed information blocking
policies, we have adopted a focused
definition of EHI in § 170.102 and
§ 171.102. For context purposes, the EHI
definition is focused on ‘‘electronic
protected health information as defined
in 45 CFR 160.103 to the extent that it
would be included in a designated
record set as defined in 45 CFR
164.501’’ with additional caveats not
repeated here for briefness. Put simply,
the EHI definition represents the same
ePHI that a patient would have the right
to request a copy of pursuant to the
HIPAA Privacy Rule. This is a
regulatory concept with which the
industry has nearly 20 years of
familiarity. Health IT developers’
customer base includes health care
providers who are HIPAA covered
entities, and in many cases developers
serve as HIPAA business associates to
their covered-entity customers. Thus,
health IT developers should be
accustomed to identifying ePHI so that
their products support appropriately
securing it, the fulfillment of patient
access requests, and the identification
and reporting on breaches. They should,
therefore, be well prepared to identify
what EHI their product(s) would need to
export in order to support a patient’s
HIPAA right of access. The finalized
criterion requires a certified Health IT
Module to include export capabilities
for a single patient (§ 170.315(b)(10)(i))
and patient population
(§ 170.315(b)(10)(ii)) related to EHI.
More specifically, the export(s) will
need to include the EHI that can be
PO 00000
Frm 00051
Fmt 4701
Sfmt 4700
25691
stored at the time of certification by the
product, of which the Health IT Module
is a part. We emphasize that such
‘‘stored’’ data applies to all EHI and is
agnostic as to whether the EHI is stored
in or by the certified Health IT Module
or in or by any of the other ‘‘noncertified’’ capabilities of the health IT
product of which the certified Health IT
Module is a part. The scope of EHI
applies across the product as a whole as
a means to further promote the access,
exchange, and use of EHI for the use
cases required to be supported by this
certification criterion. The finalized
scope of data included in the criterion
export is discussed in greater detail
under the ‘‘Scope of Data Export’’
(IV.B.6.c) section below.
While the data that must be exported
has been more specifically scoped, the
certification criterion does not require a
specific standard format be used for the
purposes of representing the exported
EHI. We also modified the certification
criterion’s documentation requirements
in § 170.315(b)(10)(iii) to be more
concise. As finalized, the
documentation required for the export
format(s) used to support (b)(10)(i) and
(ii) functionality must be kept up-todate and made available via a publicly
accessible hyperlink. Additional
information is included under ‘‘Export
Format’’ below.
We appreciate the comments received
regarding the specific data sets and data
transmission standards for this
certification criterion. We reiterate that
the finalized certification criterion is
specific to EHI, as defined, that can be
stored at the time of certification by the
product, of which the Health IT Module
is part, and is not limited to a
predefined data set or to specific data
transmission standards. Developers are
required to ensure the health IT
products they present for certification
are capable of exporting all of the EHI
that can be stored at the time of
certification by the product. We
acknowledge that the amount of EHI
exported and format in which such EHI
is represented will differ by developer
and products of which certified Health
IT Modules are a part. Each product
presented for certification, of which the
Health IT Module is a part, will likely
vary in the amount of EHI it can store.
As a result, the amount of EHI that will
need to be able to be exported in order
to demonstrate conformance with this
certification criterion will vary widely
because of the diversity of products
presented for certification. For example,
small software components only capable
of storing a certain scope of EHI (and
only certified to a few certification
criteria) will only need to be able to
E:\FR\FM\01MYR3.SGM
01MYR3
25692
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
export that stored EHI in order to meet
this certification criterion. In contrast, a
more comprehensive product with an
EHI storage scope well beyond all of the
adopted certification criteria would by
its nature need to demonstrate it could
export a lot more EHI. But even in this
latter case, it is important to note that
while that scope of EHI may be
comprehensive for that product, it may
still not be all of the health information
for which a health care provider is the
steward and that meets the EHI
definition within the health IT products
deployed within their organization. In
other words, a health IT user may have
other health IT systems with no
connection to the Certification Program
that store EHI and such EHI would still
be in scope from an information
blocking perspective. We note all of
these distinctions to make clear for and
to dissuade readers from jumping to an
improper conclusion that the EHI export
criterion in the Certification Program is
a substitute for or equivalent to the EHI
definition for the purposes of
information blocking. We direct readers
to the information blocking section
(VIII) for additional information. Unless
a health care provider (which is an
‘‘actor’’ regulated by the information
blocking provision) only used a single
health IT product to store EHI that was
also certified to this certification
criterion, the EHI definition will always
be larger. Regardless of the amount of
EHI each product has within its scope
to export, the purpose of this
certification criterion is to make the EHI
already available in such health IT
products more easily available for
access, exchange, and use by patients
and their providers, which is a
fundamental principle established by
the Cures Act.
As technology continues to advance,
and as stated in the Proposed Rule at 84
FR 7447, this criterion may not be
needed in the future. However, the
comments suggesting we not adopt this
certification criterion at all because it
will be outmoded at some point in the
future did not appear to acknowledge
that all technology is eventually
replaced for a variety of reasons. We too
look forward to a day where standardsbased APIs are the predominant method
for enabling electronic health
information to be accessed, exchanged,
and used. We strongly encourage
industry partners to engage in their own
consortiums, with ONC and other
Federal agencies, and other stakeholders
in the health IT ecosystem to advance
standards development, prototypes, and
pilot testing in order to ultimately build
a body of evidence that could accelerate
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
the adoption and implementation
timeline of technology that could either
add more structure to or remove the
need for this certification criterion in
the future. However, we do not accept
the promise of this future state as a
reason to simply wait, nor do we believe
that the potential of this future justifies
delaying the incremental progress the
industry can make. In this case, had we
followed such commenters direction,
we would be withholding from patients
and health care providers the certainty
that there would be technical
capabilities within a defined time that
could be used to enable the access,
exchange, and use of EHI. We note that
suggestions by commenters to structure
the certification criterion to only move
information within specific data sets or
via specific standards-based export
functionality would delay the ability of
patients and users of health IT to access,
exchange, and use the information they
need and would run counter to the
underlying principles supporting this
certification criterion—that the
electronic health information should be
accessible for access, exchange, and use.
For this reason, we have not included
specific data set or export requirements
in this certification criterion as some
commenters suggested.
In consideration of comments, the
finalized ‘‘EHI export’’ criterion in
§ 170.315(b)(10) is not included in the
2015 Edition Base EHR definition,
which is a modification from what we
proposed. We revised the policy in
recognition of comments received,
including comments regarding the
structure and scope of the criterion as
proposed and the development burden
of the criterion. As finalized here, we
believe that including this certification
criterion in the Conditions and
Maintenance of Certification is the best
place to include the requirement
associated with the criterion. Thus, we
have finalized the § 170.315(b)(10)
certification criterion as a general
certification requirement for the ONC
Health IT Certification Program, and
have not included it in the 2015 Edition
Base EHR Definition.
In general, we also note that those
who use Health IT Module(s) certified to
the ‘‘EHI export’’ criterion remain
responsible for safeguarding the security
and privacy of individuals’ EHI
consistent with applicable laws and
regulations related to health information
privacy and security, including the
HITECH Act, HIPAA Privacy and
Security Rules, 42 CFR part 2, and State
laws. The existence of a technical
capability to make EHI more accessible
and useable by Health IT Module users
does not alter or change any of their
PO 00000
Frm 00052
Fmt 4701
Sfmt 4700
data protection responsibilities under
applicable laws and regulations.
Comments. Comments received
included concerns with the
development and use of the certification
criterion. Some commenters expressed
support for the criterion’s overall
flexibility but cautioned ONC to be
realistic regarding the goals and
expectations for the certification
criterion. These commenters also
expressed concern that the proposed
certification criterion would result in
development for an ambiguous scope of
data export and would divert from work
needed to achieve other interoperability
goals. Other commenters stated
concerns that development costs could
potentially be passed onto health IT
users, such as health care providers.
These commenters also anticipated use
and implementation challenges for users
that work with multiple systems.
Response. We thank commenters for
sharing their concerns. In regards to the
use of the capabilities required by this
certification criterion, we interpreted
from comments some confusion related
to potential ‘‘users’’ of the health IT. As
previously defined under the Program,
‘‘user’’ is a health care professional or
their office staff; or a software program
or service that would interact directly
with the certified health IT (80 FR
62611, 77 FR 54168).
We also appreciate the comments and
concerns regarding the potential
development burden that could result to
meet the requirements of the proposed
criterion. In consideration of those
expressed concerns, we have narrowed
the scope of data that must be exported.
This more focused scope should
measurably reduce the stated ambiguity
by commenters and development
burden for health IT developers in
contrast to what was proposed (84 FR
7448). We appreciate the concerns
expressed for the potential user(s) of
Health IT Modules, but note that the
certification criterion is designed to
advance the electronic movement of
data out of a product while factoring in
the current variability in health IT. As
always, we encourage developers to
seek innovative and expedient
capabilities that, at minimum, meet the
requirements of the certification
criterion, as well as the developing
needs of their health IT users.
Comments. Commenters provided
alternative ideas for the criterion
specific to USCDI. Some recommended
amending the criterion to require the
specific structure and applicable
standards for USCDI elements, or
starting this criterion with a minimum
of USCDI data elements. Several
commenters recommended expanding
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
the existing 2015 Edition ‘‘data export’’
criterion to include USCDI in lieu of the
proposed ‘‘EHI export’’ criterion.
Response. We thank commenters for
sharing these ideas. We have finalized
the ‘‘EHI export’’ criterion as described
above. Our intent under this finalized
criterion is to advance export
functionality for single patient and
patient population EHI exports, while
leaving flexibility in regard to format
and without assigning specific data sets
due to the different scopes of data that
health IT may include. Toward those
ends, limiting the scope of this
certification criterion to solely the data
represented by the USCDI would make
it no different than other USCDI
bounded certification criteria already
adopted and would not advance the
policy interests we have expressed. In
regards to comments on the existing
2015 Edition ‘‘data export’’ criterion
(§ 170.315(b)(6)), we refer readers to our
discussion of the criterion below.
Comments. Some comments
expressed confusion and asked for
guidance on how this certification
criterion would apply to health IT that
is no longer certified. Commenters also
asked for guidance on how this criterion
applies to other systems that interact
with Health IT Modules certified to this
criterion based on the proposed scope of
data for export.
Response. We thank commenters for
requesting clarification. We first clarify
that the export functionality under this
certification criterion applies to Health
IT Modules presented for certification
under the Program. More specifically, if
a health IT developer presents for
certification a health IT product of
which a Health IT Module is a part and
the product electronically stores EHI,
certification to § 170.315(b)(10) is
required. As noted in our response
above, this would include the EHI that
can be stored at the time of certification
by the product, of which the Health IT
Module is a part. This includes all EHI
stored by the product’s certified and
‘‘non-certified’’ capabilities. For
example, if a health IT product includes
a component(s) that is presented for
certification and that component stores
EHI, then that EHI must be made
available for export, in accordance with
§ 170.315(b)(10). Importantly, the scope
of data required to be exported in
accordance with § 170.315(b)(10)
includes only to the EHI that can be
stored at the time of certification by the
product. We emphasize that such
‘‘stored’’ data applies to all EHI and is
agnostic as to whether the EHI is stored
in or by the certified Health IT Module
or in or by any of the other ‘‘noncertified’’ capabilities of the health IT
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
product of which the certified Health IT
Module is a part. The scope of EHI
applies across the product as a whole as
a means to further promote the access,
exchange, and use of EHI for the use
cases required to be supported by this
certification criterion.
a. Single Patient Export To Support
Patient Access
As part of this criterion, we proposed
a functionality for single patient EHI
export at 84 FR 7447 which would
enable a user of certified health IT to
timely create an export file(s), with the
proposed scope of data export of all of
the EHI the health IT product produces
and electronically manages on a single
patient. The functionality would also
require a user to be able to execute this
capability at any time the user chooses
and without subsequent developer
assistance to operate. In addition, we
proposed that health IT certified to this
criterion would be required to enable
the ability to limit the users who could
create such export file(s) in at least one
of two ways: To a specific set of
identified users, and (2) as a system
administrative function. We also
proposed that the export file(s) created
must be electronic and in a computable
format and that the export file(s) format,
including its structure and syntax, must
be included with the exported file(s).
Comments. We received many
comments in support of the proposal for
single patient export to support patient
access under the certification criterion.
The majority of these commenters
provided recommended revisions,
including suggested transmission
formats and data export content
standards. Some commenters
recommended the addition of this
certification criterion to the list of
criteria subject to real world testing.
Response. We thank commenters for
their feedback. We have finalized the
single patient export functionality in
§ 170.315(b)(10)(i) with some
modifications. We finalized a focused
data export scope, which applies to the
data expected to be available for export
under the single patient export
capability. We defined the scope of data
that needs to be exported to EHI that can
be stored at the time of certification by
the product, of which the Health IT
Module is a part. Thus, we have
modified the title of § 170.315(b)(10)(i)
to ‘‘single patient electronic health
information export’’ to reflect the scope
of this data export. We finalized that the
capability for a user to execute a single
patient export must be able to be limited
at least one of two ways: To a specific
set of identified users, and as a system
administrative function. While we
PO 00000
Frm 00053
Fmt 4701
Sfmt 4700
25693
finalized as proposed in
§ 170.315(b)(10)(i)(D) that the export
files must be electronic and in a
computable format, we modified in
§ 170.315(b)(10)(ii)(E) that the publicly
accessible hyperlink of the export’s
format must be included with the
exported file(s). This modification
clarifies that the user is able to access
the format, and that the developer will
keep their hyperlink up-to-date.
We appreciate commenter’s
recommendations for specific data
transmission formats and data content
standards, and considered the range of
recommendations when developing the
finalized scope of data export required
for this criterion. We believe the
definition of EHI as focused in
§ 171.102, as well as the modifications
to the scope of data export, addresses
the data ambiguity concerns received by
commenters. We direct readers to our
detailed discussion of the scope of data
export below. As finalized, the
certification criterion’s export, for both
single and patient population EHI
Export, remain standards-agnostic. We
believe that the finalized certification
criterion will serve as an initial step
towards increased access, exchange, and
use of electronically available data. We
will continue working alongside
industry stakeholders and will revisit
export strategies as standards continue
to develop and mature. We appreciate
confirmation that commenters support
inclusion of the criterion in
§ 170.315(b)(10) alongside the rest of the
care coordination criteria in
§ 170.315(b), and have finalized that this
certification criterion is part of the real
world testing Condition of Certification
requirement.
Comments. Some commenters asked
ONC to clarify how health IT developers
may limit the users’ ability to access and
initiate the export function in
§ 170.315(b)(10)(i), and to include
examples of potential permissible and
non-permissible behaviors.
Response. We appreciate the
comments received. We again clarify
that ‘‘user’’ is a health care professional
or their office staff; or a software
program or service that would interact
directly with the certified health IT (80
FR 62611, 77 FR 54168). In regards to
questions on permissible behaviors for
developers, the ability to limit the
health IT users’ access to the single
patient EHI export functionality in
§ 170.315(b)(10)(i) is intended to be
used by and at the discretion of the
organization implementing the
technology. We reiterate that similar to
the 2015 edition ‘‘data export’’ criterion
in § 170.315(b)(6), this cannot be used
by health IT developers as a way to
E:\FR\FM\01MYR3.SGM
01MYR3
25694
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
thwart or moot the overarching userdriven aspect of this capability (80 FR
62646). We do not wish to limit this
functionality to specific permissible or
non-permissible behaviors at this time,
but reaffirm in § 170.315(b)(10)(i)(B) that
a user must be able to execute the single
patient EHI export capability at any time
the user chooses and without
subsequent developer assistance to
operate. To be clear, the user must be
able to execute the export without the
intervention of the developer. We also
finalize, as proposed, in
§ 170.315(b)(10)(i)(C) that this capability
must limit the ability of user who create
such export files(s) in at least one of two
ways; (1) to a specific set of identified
users, and (2) as a system administrative
function.
Comments. The majority of comments
received asked for further clarity on
‘‘timely’’ regarding a health IT user’s
request to create an export file(s).
Response. We thank commenters for
the questions. We specify that ‘‘timely’’
means near real-time, while being
reasonable and prudent given the
circumstances.
Comments. Commenters also sought
clarity on data in electronic health
records that may be shared between
patients and possibly included in the
export. These commenters asked if
under the proposed criterion, patients
have a right to information about others
that may be contained in their medical
record.
Response. We thank commenters for
submitting these questions. In regards to
shared patient data concerns, we note
that the export functionality
requirements apply to what a product
with a Health IT Module certified to this
criterion must be able to do regardless
of whether the developer is operating
the export for a health care provider or
a health care provider is maintaining
and operating the technology in their
own production environment. Under
the HIPAA Privacy Rule, when a
covered health care provider, in the
course of treating an individual, collects
or otherwise obtains an individual’s
family medical history, this information
may become part of the medical record
for that individual and thus be included
in the ‘‘designated record set’’ (defined
at 45 CFR 164.501)). Thus, if the family
medical history becomes part of the
designated record set, the individual/
patient may exercise the right of access
(45 CFR 164.524) under the HIPAA
Privacy Rule to this information in the
same fashion as any other information
in the medical record. The HIPAA
Privacy Rule does not prevent
individuals, themselves, from gathering
medical information about their family
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
members or from deciding to share this
information with family members or
others, including their health care
providers. Thus, individuals are free to
provide their doctors with a complete
family medical history or communicate
with their doctors about conditions that
run in the family. To the degree that, for
example, Patient A’s medical record
include that their mother had breast
cancer, that information would be
accessible to Patient A because it was
provided by Patient A and included as
part of their medical record. Under this
criterion, patients would not have a
‘‘right’’ to other patient’s records,
consistent with existing laws. In
general, with respect to patient access to
information, we note that Health IT
Module users must ensure that any
disclosures of data conform to all
applicable laws and regulations,
including but not limited to alignment
between this rule and the HIPAA
Privacy Rule, as discussed in IV.B.6
above. We also refer readers to the
information blocking section at VIII in
this preamble, as well.
Comments. Commenters requested
clarity on how ONC will monitor a
developer’s compliance with exporting
in a timely manner and what penalties
ONC will impose if there is a delay in
regards to a Health IT Module user’s
request. Commenters requested ONC
release sub-regulatory guidance that
describes how users may file complaints
and recommended ONC work with the
HHS Office for Civil Rights (OCR) on
patient education.
Response. Any noncompliance by
developers with the finalized ‘‘EHI
export’’ certification criterion
(§ 170.315(b)(10)) or the associated
Conditions and Maintenance of
Certification requirements (e.g.,
§ 170.402(a)(4) and (b)(2)) would be
subject to review, corrective action, and
enforcement procedures under the
Program. We refer readers to the
enforcement (VII) and information
blocking (VIII) sections of this preamble
for further information. We do not
believe there is a general need to work
with OCR further on this particular
issue or to issue further sub-regulatory
guidance. The functionality of the ‘‘EHI
export’’ criterion in § 170.315(b)(10)
provides a user (e.g., a health care
provider) with the ability to export a file
for a single patient and multiple
patients. If a user or other stakeholder
has concerns about ongoing compliance
of health IT certified to this criterion,
with the required functionality of the
criterion, or the associated Conditions
and Maintenance of Certification
requirements, they may file a complaint
PO 00000
Frm 00054
Fmt 4701
Sfmt 4700
with the health IT developer, an ONC–
ACB, or ONC.
Comments. Some commenters
requested specific stakeholder
exemptions from this requirement, such
as health plans.
Response. We thank commenters for
the recommendations. We note that the
‘‘EHI export’’ criterion is applicable
only to health IT products presented by
developers for certification under the
Program that meet the criterion and
‘‘Assurances’’ Condition of Certification
requirements in § 170.402. In addition,
we note that the information subject to
the export requirements is EHI that can
be stored at the time of certification by
the product, of which the Health IT
Module is a part.
i. EHI Export for Patient-Initiated
Requests
In the Proposed Rule, we reiterated
that the ‘‘user’’ of the single patient
export functionality would typically be
a provider or their office staff on behalf
of the patient (80 FR 62611, 77 FR
54168). We also recognized that in
service to innovative and patient-centric
approaches, a health IT developer could
develop a method that allows a patient
to execute the request for data export
without needing a provider to do so on
their behalf. Under this scenario, we
sought comments on whether the single
patient export functionality should be
made more prescriptive and require that
the developers design the health IT to
allow only the patient and their
authorized representative to be the
requestor of their EHI (84 FR 7447).
Comments. In the scenario of patientcentric approaches created by
developers, the majority of commenters
were in favor of developers designing
the export capability to make the patient
and their authorized representative able
to be the direct requestors of their EHI
without needing a provider to execute
this capability on their behalf. We also
received recommended terms to further
define ‘‘authorized representative’’
under this scenario. Several commenters
advised against specifying or restricting
the potential additional user roles able
to initiate a single patient export. Some
commenters recommended additional
requirements for developers, including
requiring developers to create this
capability to enable the patient or their
‘‘proxy’’ to request their information
through and receive information from
the patient’s health portal or an
application. Commenters asked for the
final rule to include clarification on
what the patient and their authorized
representative can access. We did
receive some comments that requested
clarification of this potential approach.
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
We also received comments expressing
confusion with the patient and
authorized representative requests
applying across the certification
criterion, as opposed to the proposed
and previously defined ‘‘users’’ of
health IT that will typically perform the
request on behalf of a patient.
Response. We thank commenters for
their input and requests for clarification.
In response to the concerns and
potential confusion, we clarify the
following. This certification criterion
does not require ‘‘direct-to-patient’’
functionality in order to demonstrate
conformance. Providing such a
capability and demonstrating
conformance to this certification
criterion with such a capability would
be at the sole discretion of the health IT
developer. In general, just like with the
‘‘data export’’ criterion in
§ 170.315(b)(6), the capability to execute
this certification criterion can be health
care provider/health care organization
initiated (presumably upon that
organization receiving a request by
patient for their EHI). In instances
where the functionality certified to this
criterion is implemented in a ‘‘direct-topatient’’ way such that the patient can
request and accept EHI export without
assistance from a user, we recognize that
further configuration of the
functionality or product in which it is
implemented may be needed in order to
account for applicable laws related to
the patient’s information access rights
and other privacy and information
blocking policies that apply to the
configuration and use of the Health IT
Module. While this specific capability
within the certification criterion
emphasizes health IT developer
assistance must not be needed to
operate the export, we recognize that
user assistance (e.g., a provider) may be
necessary to initiate such capability in
the user’s product.
b. Patient Population EHI Export for
Transitions Between Health IT Systems
In addition to the single patient
export functionality in
§ 170.315(b)(10)(i), we proposed in
§ 170.315(b)(10)(ii) that health IT
certified to this criterion would also
facilitate the migration of EHI to another
health IT system. We proposed that a
health IT developer or health IT
certified to this criterion must, at a
user’s request, provide a complete
export of all EHI that is produced or
electronically managed (84 FR 7447
through 7448) by means of the
developer’s certified health IT.
Comments. We received many
comments in support of the
functionality under this criterion for
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
transitions between health IT systems.
Many commenters recommended format
and content specifications, such as the
use of bulk FHIR®-based APIs for export
transmission. Some commenters
stressed that ONC should determine and
require standards, as well as clarify the
scope of data export specific to this use
case. Some commenters expressed
concerns, including gathering patient
consent and the developer burden that
may exist with gathering data from
disparate systems under the proposed
scope terminology. One commenter was
against the transitions between health IT
systems capability, citing that data
structured for one system will not
necessarily work in another.
Response. We thank commenters for
their feedback specific to the
functionality of transitions between
health IT systems under this criterion.
We finalized this export functionality
with modifications. First, this
functionality is now referred to as
‘‘patient population electronica health
information export’’ in
§ 170.315(b)(10)(ii) to better reflect the
policy intent of patient data transitions
in instances of providers switching
health IT systems, and to reflect the
finalized scope of data that a product
with a certified Health IT Module must
be capable of exporting. Similar to the
modifications in § 170.315(b)(10)(i), we
finalized in § 170.315(b)(10)(ii)(A) that
the export files must be electronic and
in a computable format and we
modified in § 170.315(b)(10)(ii)(B) that
the publicly accessible hyperlink of the
export’s format must be included with
the exported file(s). This modification
clarifies that the user is able to access
the format, and that the developer will
keep their hyperlink up-to-date.
In response to comments on defining
a separate scope of data export specific
to the patient population export
functionality, it is our final policy for
this certification criterion to align both
the single patient and patient
population export data to EHI, as
defined in this rule, that can be stored
at the time of certification by the
product, of which the Health IT Module
is a part. This narrower scope also
addressed concerns received regarding
development burden expressed
regarding gathering data from disparate
systems under the proposed scope
terminology.
In regards to the comments on
enforcing format and standards for data
transmission, it is our intent under this
certification criterion that health IT
developers have flexibility regarding
how the export outcome is achieved. We
again encourage the industry to work
together toward this common goal and
PO 00000
Frm 00055
Fmt 4701
Sfmt 4700
25695
to create an industry-wide approach. We
do acknowledge the comments received
that data structured for one system may
not necessarily seamlessly align with
another, and refer commenters to the
export format requirements of this
certification criterion. As finalized in
§ 170.315(b)(10)(ii)(A), the export
created must be electronic and in a
computable format. In contrast with the
single patient EHI export capability,
which must be available to a user
without subsequent developer
assistance to operate, the patient
population EHI export capability of this
criterion could require action or support
on the part of the health IT developer.
We acknowledged in the Proposed Rule
(84 FR 7448) that because of anticipated
large volume of electronic health
information that could be exported
under this specific proposed capability,
developer action or support could be
needed. Our thinking remains the same
post-public comments even with the
narrowed scope of data export. While
exporting one patient’s data on an asneeded basis is a capability that should
be executable by a user on their own,
orchestrating an entire export of EHI for
migration to another health IT system is
an entirely different task and dependent
on a variety of factors such as the
organization’s overall infrastructure and
deployment footprint. Additionally,
developers of health IT certified to this
criterion are required to provide the
assurances in § 170.402, which include
providing reasonable cooperation and
assistance to other persons (including
customers, users, and third-party
developers) to enable the use of
interoperable products and services.
Thus, while developers have flexibility
regarding how they implement the
export functionality for transitions
between systems, they are ultimately
responsible for ensuring that the
capability is deployed in a way that
enables a customer and their third-party
contractors to successfully migrate data.
Such cooperation and assistance could
include, for example, assisting a
customer’s third-party developer to
automate the export of EHI to other
systems. We refer readers to the export
format section below for additional
details.
We note that the narrowed scope of
data that certified Health IT Modules
must be capable of exporting does not
reduce contractual obligations of health
IT developers to continue to support
providers if they do want to change
systems, and direct readers to the
information blocking section (VIII) for
additional information.
E:\FR\FM\01MYR3.SGM
01MYR3
25696
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
c. Scope of Data Export
We proposed in 84 FR 7448 and in
§ 170.315(b)(10) that for both use cases
supported by this criterion, the scope of
data that the certified health IT product
must be capable of exporting would
encompass all the EHI that the health IT
system produces and electronically
manages for a patient or group of
patients. Our intention was that
‘‘produces and electronically manages’’
would include a health IT product’s
entire database. In the Proposed Rule,
our use of the term EHI was deliberate.
At the time of rulemaking, the proposed
definition of the EHI term in § 171.102
was intended to support the consistency
and breadth of the types of data
envisioned by this proposed criterion.
We requested comment on the
terminology used (‘‘produces and
electronically manages’’) or whether
there were alternatives to the proposed
language.
Comments. Some commenters were
supportive of our proposed scope of
data export requirements, while a few
others offered alternative specific
terminology options. Those commenters
suggested terminology such as all EHI
the health IT system ‘‘collects and
retains,’’ or ‘‘produces or can
electronically access, exchange, or use.’’
A majority of commenters, however,
stated that the proposed terminology,
including the proposed EHI definition,
left broad interpretations of the scope of
data a Health IT Module would have to
be capable of exporting under this
criterion. These commenters expressed
concerns that the ambiguity and
potentially vast amounts of data would
create undue burden on health IT
developers for development and upkeep
of export capabilities, as well as
compliance issues with other applicable
laws. A majority of commenters
requested and highlighted a need for
further specificity regarding the
terminology used to define data
exported under this criterion. Some
commenters expressed concerns that a
developer presenting a Health IT
Module for certification may not know
all systems a user may later connect to
the health IT capabilities. We also
received many comments reflecting
varied thoughts on what should or
should not be included in the criterion’s
data export. Some commenters strongly
opposed any data limits, citing existing
regulations such as the HIPAA Privacy
Rule right of access, while others
proposed alternatives to constrain data
export requirements, citing
development infeasibility.
Recommendations to constrain the
proposed criterion’s scope included
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
alignment with other regulations and
data standards, such as the USCDI. We
also received a recommended
requirement for health IT developers to
provide a plain language definition of
the EHI typically included in their
Health IT Module’s export. Some
commenters expressed confusion on
how the criterion’s proposed scope of
data export may apply to EHI ‘‘produced
or electronically managed’’ by both the
product’s certified and ‘‘non-certified’’
capabilities as well as data from third
parties.
Response. We thank commenters for
feedback on our proposed terms and for
specific recommendations. The
finalized criterion draws the upper
bound of its data scope from the focused
definition of EHI as finalized. The
criterion export includes the EHI, as
defined, that can be stored at the time
of certification by the product, of which
the Health IT Module is a part. As
defined in this rule, EHI means
electronic protected health information
as defined in 45 CFR 160.103 to the
extent that it would be included in a
designated record set as defined in 45
CFR 164.501 (other than psychotherapy
notes as defined in 45 CFR 164.501 or
information compiled in reasonable
anticipation of, or for use in, a civil,
criminal, or administrative action or
proceeding), regardless of whether the
actor is a covered entity as defined in 45
CFR 160.103. In response to comments
received, this revised scope of data for
export provides a more manageable and
less administratively burdensome
certification criterion for health IT
developers for several reasons.
We agree with commenters that our
proposed terms of all EHI a health IT
system ‘‘produces and electronically
manages’’ (84 FR 7448) raised the
potential for broad variance in
interpretations and concerns about the
breadth of data intended for export
under this criterion and potential
development burden. We also
considered the comments noting that a
developer presenting a Health IT
Module for certification may not, at the
time of certification, know all systems a
user will later connect to the health IT
capabilities. Ultimately, we considered
several approaches to better reflect the
policy intent and to alleviate confusion
related to the proposed criterion. In
consideration of the public comments
and the policy outcome we sought to
address, we revised the final criterion‘s
phrasing to describe what information
health IT products with Health IT
Module(s) certified to the criterion must
be capable of exporting. The revised
scope of data export applies to both the
single patient and patient population
PO 00000
Frm 00056
Fmt 4701
Sfmt 4700
export functionalities as well as the
Conditions and Maintenance of
Certification requirements tied to this
criterion.
First, we agree with comments
received and acknowledge that a health
IT developer is best positioned to know
(and would be solely responsible for
only) the EHI that can be stored by the
health IT product at the time the Health
IT Module is presented for certification.
In response to comments regarding the
applicability of the scope of export to
the product’s certified and ‘‘noncertified’’ capabilities, as well as data
from third parties, we clarify and
reiterate the following from our prior
responses. We emphasize that such
‘‘stored’’ data applies to all EHI and is
agnostic as to whether the EHI is stored
in or by the certified Health IT Module
or in or by any of the other ‘‘noncertified’’ capabilities of the health IT
product of which the certified Health IT
Module is a part. To be clear,
conformance ‘‘at the time of
certification’’ means the combined data
that can be stored by the product, of
which the Health IT Module is a part,
at the time the Health IT Module is
presented for certification. As such, for
the purposes of this certification
criterion, the EHI that must be exported
does not include any data generated
from unique post-certification in
response to a particular customer
(though such data could meet the
definition of EHI for the purposes of
information blocking). Such
modifications could include custom
interfaces and other data storage
systems that may be subsequently and
uniquely connected to a certified Health
IT Module post-certification.
Additionally, to remain consistent with
‘‘at the time of certification,’’ we clarify
that any new EHI stored by the product
due to ongoing enhancements would
need to be included within the scope of
certification only when a new version of
the product with those new EHI storage
capabilities is presented for certification
and listing on the CHPL. In
consideration of comments, we believe
that this approach to define storage at
the time the product is presented for
certification of a Health IT Module will
make the certification requirements
more clear for health IT developers and
more efficient to administer from a
Program oversight perspective.
In addition, the use of ‘‘can be stored
by’’ refers to the EHI types stored in and
by the health IT product, of which the
Health IT Module is a part. This is
meant to be interpreted as the
combination of EHI a heath IT product
stores itself and in other data storage
locations. Thus, the cumulative data
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
covered by these storage techniques
would be in the scope of data export.
Per our policy intent, by focusing the
definition of EHI and defining the data
for export under this criterion, users of
certified Health IT, such as health care
providers, will have the ability to create
‘‘readily producible’’ exports of the
information of a single patient upon
request by the user, which increases
patient access as reflected in the Cures
Act. Lastly, in support of the second
functionality we finalized for patient
population export, the EHI exported
(within the Health IT product’s scope of
data export) would likely be of
significant importance to health care
providers for the purposes of
transitioning health IT systems and
maintaining continuity of care for
patients, and also helps remove
potential barriers to users switching
systems to meet their needs or their
patient’s needs.
In finalizing this policy, we
emphasize that health IT developers
may provide the export of data beyond
the scope of EHI and for functionalities
beyond those discussed under this
criterion. In such cases, for additional
export purposes, it is advised that
health IT developers and users discuss
and agree to appropriate requirements
and functionalities. We again emphasize
that health IT product users must ensure
that any disclosures of data conform to
all applicable laws, including the
HIPAA Rules and 42 CFR part 2.
Stakeholders should review applicable
laws and regulations, including those
regarding patients’ right of access to
their data, in order to determine the
appropriate means of disclosing patient
data. We also refer readers to the
information blocking section at VIII.
i. Image, Imaging Information, and
Image Element Export
In the Proposed Rule, we noted at 84
FR 7448 that clinical data would
encompass imaging information, both
images and narrative text about the
image. However, we addressed that
EHRs may not be the standard storage
location for images. We solicited
additional feedback and comments on
the feasibility, practicality, and
necessity of exporting images and/or
imaging information. We requested
comment on what image elements, at a
minimum, should be shared such as
image quality, type, and narrative text.
We did not make any proposals in 84 FR
7448.
Comments. Most commenters were
supportive of sharing images and/or
related data elements, expressing that
interoperability should include
electronic ordering of imaging studies,
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
which they asserted would assist health
care providers in delivering care. Other
commenters expressed burden concerns
with data image export, particularly
challenges around the movement and
storage of large amounts of data and
accumulating data from disparate health
IT systems. A few commenters
requested specific exclusion of images
or videos created as a byproduct of
procedures. As for minimum image data
elements to share, recommendations
varied and included Digital Imaging and
Communications in Medicine
(DICOMTM) data elements or file type
recommendations. Comments included
additional policy recommendations,
such as making Picture Archiving and
Communication Systems (PACS)
developers subject to certification rules
and requiring EHI export data to include
links for remote authorized access to
externally hosted images.
Response. We thank commenters for
their shared insight and
recommendations regarding the export
of images, imaging information, and
image elements. Health IT Modules
certified to the finalized criterion must
electronically export all of the EHI, as
defined, that can be stored at the time
of certification by the product, of which
the Health IT Module is a part. Thus,
any images, imaging information, and
image elements that fall within this
finalized scope of EHI that can be stored
at the time of certification in or by the
product, of which the Health IT Module
is a part will need to be exported under
this certification criterion. We
appreciate the recommendations
received for image transfer methods and
encourage the stakeholder community
to continue exploring innovative image
transfer methods, including for image
transfer that would fall outside of this
certification criterion. We appreciate the
policy recommendations, such as
including PACS developers. The ‘‘EHI
export’’ certification criterion only
applies to developers of health IT
seeking or maintaining certification
under the Program. To the extent such
providers are developers of health IT
under the Program they would be
included. If they are not developers
under the Program, they would not be
included.
We also thank commenters for their
suggestions to require data export to
include links for remote authorized
access to externally hosted images. We
note that the export requirements of this
certification criterion refers to the EHI
that can be stored at the time of
certification by the product, of which
the Health IT Module is a part. In the
context of imaging, if the only EHI
stored in or by the product to which this
PO 00000
Frm 00057
Fmt 4701
Sfmt 4700
25697
certification criterion applies are links
to images/imaging data (and not the
images themselves, which may remain
in a PACS) then only such links must
be part of what is exported. We
encourage developers to work with their
customers to achieve innovative ways to
share all relevant data, including
situations outside of the scope of data
export under this criterion where
images could be made more accessible.
ii. Attestation of Information a Health IT
Developer Cannot Support for Export
In the Proposed Rule (84 FR 7448), we
also solicited comment on whether we
should require, to support transparency,
health IT developers to attest or publish
as part of the export format
documentation the types of EHI they
cannot support for export. We did not
have any specific proposals.
Comments. The majority of
commenters supported public
attestation regarding the information a
Health IT Module is unable to export.
Some commenters requested that we
add to the regulatory text to state that
developers attest to information they
cannot support for export ‘‘and/or
ingestion.’’ Some commenters
questioned if it is fair for EHI developers
to delineate what is in their Health IT
Module’s scope of data for export under
this criterion. Another felt that this
requirement should be extended to
health care delivery organizations and
that the attestation should be included
within patient portals or other
communications.
Response. We thank commenters for
their feedback. We again note the
revised scope of data export under this
finalized criterion. Under the finalized
approach, which focuses on the export
of the EHI that can be stored at the time
of certification by the product, we have
determined that our final requirements
provide sufficient clarity and have not
included any additional requirements
such as those on which we sought
comment. Additionally, we believe the
recommendation for ingestion would be
impracticable as part of this certification
criterion due to the flexibility we permit
for the output format(s). It would not be
possible from a regulatory enforcement
perspective to administer a certification
criterion that included within its scope
a conformance requirement for a Health
IT Module’s capability to import any
proprietary format that may exist
without prior knowledge of such
formats.
iii. Export Exclusion Request for
Comments
In the Proposed Rule, we proposed
metadata categories at 84 FR 7448 for
E:\FR\FM\01MYR3.SGM
01MYR3
25698
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
exclusion from this criterion. We also
requested feedback on what metadata
elements should remain included for
export or added to the list of excluded
data. Metadata proposed for exclusion
from the criterion included metadata
present in internal databases used for
physically storing the data, metadata
that may not be necessary to interpret
the EHI export, and metadata that refers
to data that is not present in the EHI
export. Examples of these proposed
exclusions are provided at 84 FR 7448.
Comments. Commenters offered
varied recommendations for metadata
elements to remain excluded, or to be
included under the scope of data export
for this criterion. We received several
comments strongly supporting the
inclusion of audit log metadata.
Commenters noted that the inclusion of
audit log metadata had potential legal
utility and could aid in the patient’s
ability to have all of their data and
knowing who has accessed their data.
Commenters also requested increased
clarity on the definition of metadata,
audit log, and access log in regards to
this rulemaking, and requested the use
of standards to further clarify policy
intentions. We note, however, that other
commenters were against the inclusion
of audit log data as part of the EHI
export. Those against inclusion stated
that this information was not necessary
to interpret the EHI export, could be
burdensome for development of export
capabilities, and potentially contain
personally identifiable information of
the health care staff.
Response. We thank commenters for
their input on potential metadata
exclusions. As noted above, we have
finalized that EHI that can be stored at
the time of certification by the product
is the scope of data that must be
included in exports pursuant to
§ 170.315(b)(10). Under this revised and
specified scope of data export, it is no
longer necessary to list specific
metadata exclusions or inclusions. We
direct readers to the discussion of scope
of data export (IV.B.6.c) under this
criterion for further details.
d. Export Format
We did not propose a content
standard for the export. However, we
did propose to require documentation in
§ 170.315(b)(10)(iii) that health IT
developers include the export file(s)
format, including its structure and
syntax, such as a data dictionary or
export support file, for the exported
information to assist the user requesting
the information in processing the EHI
(84 FR 7448). This was to prevent loss
of information or its meaning to the
extent reasonably practicable when
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
using the developer’s certified Health IT
Module(s). We also proposed in
§ 170.315(b)(10)(iii) that the developer’s
export format must be made available
via a publicly accessible hyperlink and
kept up-to date.
Comments. Comments received were
in favor of this proposal in
§ 170.315(b)(10)(iii). Several
commenters were supportive of the
flexibility of export format for
developers, as long as export
documentation is provided as specified
in the Proposed Rule, citing specifically
how this would support the export
capability in § 170.315(b)(10)(ii). Some
commenters recommended additional
clarification for the publicly accessible
hyperlink, specifically to ensure that
information is available without login or
other associated requirements.
Commenters also provided export
format suggestions.
Response. We thank commenters for
their feedback regarding developers’
export format. We have finalized
§ 170.315(b)(10)(iii) with modifications
to clarify the regulatory text. We
finalized that the export format(s) used
to support § 170.315(b)(10)(i) and
§ 170.315(b)(10)(ii) of this section must
be kept up-to-date.
We clarify that the documentation for
the export format(s) in
§ 170.315(b)(10)(iii) consists of
information on the structure and syntax
for how the EHI will be exported by the
product such as, for example, C–CDA
document(s) or data dictionary for
comma separated values (csv) file(s),
and not the actual EHI. The user will
use the export format documentation to
process the EHI after it is exported by
the product. We also require that health
IT developers keep the export format(s)
used to support § 170.315(b)(10)(i) and
§ 170.315(b)(10)(ii) must be ‘‘up-todate.’’ For example, if the health IT
developer had previously specified the
C–CDA standard as the export format for
meeting the criterion, but subsequently
updated their product to use the FHIR
standard and stopped supporting
C–CDA export format then the
documentation for export format would
need to be updated so that users are able
to continue to accurately process the
EHI exported by the product. We
appreciate suggestions received
regarding ensuring that such
information is available without login or
other associated requirements. In
response to these comments, our policy
intent to foster transparency, and in
alignment with other certification
criterion requirements set forth in this
rule, we note our modifications in
§ 170.315(b)(10)(i)(E) and
§ 170.315(b)(10)(ii)(B) that the publicly
PO 00000
Frm 00058
Fmt 4701
Sfmt 4700
accessible hyperlink of the export’s
format must be included with the
exported file(s). We clarify that the
hyperlink must allow any person to
directly access the information without
any preconditions or additional steps.
We note that the export format need not
be the same format used internally by
the certified health IT and the health IT
developer does not need to make public
their proprietary data model. This
certification criterion also does not
prescribe how (i.e., media/medium) the
exported information is to be made
available to the user, as this may depend
on the size and type of information to
be exported. While file formats and
related definitions are not finalized as
specific certification requirements, we
encourage developers to continue to
foster transparency and best practices
for data sharing, such as machinereadable format, when they create and
update their export format information.
e. Initial Step Towards Real-Time
Access
In the Proposed Rule at 84 FR 7449,
we offered a clarifying paragraph to
highlight that the criterion in
§ 170.315(b)(10) was intended to
provide a step in the direction of realtime access goals, as well as a means to,
within the confines of other applicable
laws, encourage mobility of electronic
health data while other data transfer
methods were maturing. In that section,
we clarified that ‘‘persistent’’ or
‘‘continuous’’ access to data is not
required to satisfy the proposed ‘‘EHI
export’’ criterion’s requirements, and
that the minimum requirement of
developers presenting Health IT
Module(s) for certification to this
criterion is for a discrete data export
capability. In this clarification section,
we did not have specific proposals or
requests for comments.
Comments. We received
recommendations to further specify the
use of ‘‘persistent’’ and ‘‘continuous’’ in
context of access to EHI. Additional
commenters recommended specifying
Representational state transfer (REST) or
‘‘RESTful’’ transfer, or specifying data
transport methods.
Response. We thank commenters for
their input. We first clarify that this
section was added to the Proposed Rule
for additional clarification and to
provide prospective context on the
proposed certification criterion.
However, we recognize from the
comments received that our reference to
‘‘persistent’’ or ‘‘continuous’’ access in
the Proposed Rule may have created
confusion. We again note that
‘‘persistent’’ or ‘‘continuous’’ access is
not required by health IT developers
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
presenting Health IT Module(s) to
satisfy the requirements of this
certification criterion. We have finalized
the ‘‘EHI export’’ criterion as described
above in response to comments received
on proposals we have made. We
appreciate the responses to our future
looking points in the Proposed Rule but
have not made further revisions to the
final certification criterion in response.
f. Timeframes
We requested input and comments on
the criterion and timeframes at 84 FR
7449. In particular, beyond the proposal
to export all the EHI the health IT
system produces and electronically
manages, we sought comment on
whether this criterion should include
capabilities to permit health care
providers to set timeframes for the EHI
export, such as only the ‘‘past two
years’’ or ‘‘past month’’ of EHI (84 FR
7449).
Comments. A majority of commenters
were against the concept of allowing
providers to set timeframes for the
export functionality. Commenters were
concerned that creating the capability to
limit timeframes would involve
significant technical complexity for
health IT developers. Commenters also
expressed concern that allowing
providers the capability to limit
timeframes would not align with the
HIPAA Privacy Rule right of access at 45
CFR 164.524 and could potentially
implicate information blocking.
Commenters provided alternative
approaches and concepts to implement
timeframe capabilities for this criterion,
including use of APIs, granting
flexibility to developers, allowing
intervals or dynamic timeframe
requirements, and considering
permitted fees. Commenters asked for
clarification on how far back the data
request capabilities could go and
requested clarification regarding how
this criterion aligns with other APIrelated criteria within this rule.
Response. We thank commenters for
their feedback. We will not require the
Health IT Module support a specific or
user-defined timeframe range or time
limit capability for the purposes of
demonstrating conformance to this
certification criterion. We agree with
commenters concerns regarding
potential development complexity for
health IT developers if we included
such a requirement upfront. What this
means, however, is that for the purposes
of testing and certification, a health IT
developer will need to prove that the
product, of which a Health IT Module
is part, can perform the capabilities
required by the certification criterion,
inclusive of all EHI that could be
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
exported. In turn, when these
capabilities are deployed in production
they will need to be capable of
exporting all of the EHI that can be
stored at the time of certification by the
product, of which the Health IT Module
is a part. We also agree with the points
received regarding the HIPAA Privacy
Rule right of access at 45 CFR 164.524
and emphasize the importance of
HIPAA covered entities aligning with
applicable law regarding patient access
to health information.
g. 2015 Edition ‘‘Data Export’’ Criterion
in § 170.315(b)(6)
We proposed to remove the ‘‘data
export’’ criterion (defined in
§ 170.315(b)(6)) from the 2015 Edition
Base EHR definition in § 170.102 and to
replace ‘‘data export’’ with the proposed
‘‘EHI export’’ criterion (defined in
§ 170.315(b)(10)) by amending the third
paragraph of the 2015 Edition Base EHR
definition in § 170.102. We did not
propose a transition period for the ‘‘data
export’’ criterion. Rather, we proposed
to remove the criterion from the 2015
Edition Base EHR definition upon the
effective date of a final rule. We also
proposed to modify the 2015 Edition
Base EHR definition to include the new
proposed export criterion (defined in
§ 170.315(b)(10)), with an
implementation date 24 months from
the effective date of the final rule. We
welcomed comments on this approach.
Comments. Some commenters were in
favor of immediate removal of this
criterion (§ 170.315(b)(6)) from the 2015
Edition Base EHR definition, stating it
would reduce burden. However, the
majority of commenters were against a
potential gap in functionality due to the
compliance timeline for the new export
criterion (§ 170.315(b)(10)) and
requested that we keep the ‘‘data
export’’ criterion until the new criterion
in § 170.315(b)(10) and other
standardized data transmission methods
were fully implemented. Some
commenters supported an indefinite
retention of the ‘‘data export’’ criterion,
regardless of the proposed addition of
§ 170.315(b)(10). Several commenters
also recommended to expand the
current § 170.315(b)(6) criterion through
USCDI as an alternative approach to the
proposed ‘‘EHI export’’ criterion in
§ 170.315(b)(10). In addition, some
commenters expressed concern that that
the ‘‘data export’’ criterion is
inconsistent with CMS Quality Payment
Program (QPP) requirements such as
View, Download, and Transmit (VDT) at
83 FR 59814 of the CY 2019 Physician
Fee Schedule final rule.
Response. In consideration of public
comments in support of the retention of
PO 00000
Frm 00059
Fmt 4701
Sfmt 4700
25699
the ‘‘data export’’ certification criterion,
we have maintained the ‘‘data export’’
certification criterion in § 170.315(b)(6)
as available for certification until 36
months after this final rule’s publication
date. To implement this decision, we
have finalized in § 170.550(m) that
ONC–ACBs are permitted to issue
certificates to ‘‘data export’’ in
§ 170.315(b)(6) until, but not after, 36
months after the publication date of this
final rule. However, we note the ‘‘data
export’’ certification criterion has been
removed from the 2015 Edition Base
EHR definition (in § 170.102) as of the
general effective date of this final rule
(60 days after its publication in the
Federal Register). During the 36 months
immediately following publication of
this final rule, developers will be able
to maintain the certification to
§ 170.315(b)(6) as a standardized means
of exporting the discrete data specified
in the CCDS, but the criterion will not
be updated to the USCDI. Given that
certification to the § 170.315(b)(6)
criterion will no longer be available
after 36 months, we do not believe an
update to the USCDI is the best path.
Rather, § 170.315(b)(6) will remain an
unchanged criterion in the Program for
the 36 months immediately following
publication of this final rule in the
Federal Register. After that timeframe,
the EHI export criterion in
§ 170.315(b)(10), including that
certification criterion’s scope of data
export, will remain an available data
export certification criterion for health
IT developers that present for
certification a Health IT Module that is
part of a heath IT product which
electronically stores EHI. This approach
will support prior investments in
§ 170.315(b)(6) by developers and their
customers, and also encourage
movement toward the interoperability
opportunities afforded by new criteria.
Regarding commenter concerns that
the ‘‘data export’’ criterion is
inconsistent with CMS QPP
requirements, such as View, Download
and Transmit (VDT), we do not believe
that this criterion would be inconsistent
with QPP program requirements. In the
CY 2019 Physician Fee Schedule final
rule, CMS removed the VDT measure in
§ 170.315(e)(1) (83 FR 59814). However,
the Promoting Interoperability
performance category of QPP currently
includes the measure entitled Provide
Patients Electronic Access to their
Health Information (83 FR 59812
through 59813), and CMS has identified
technology certified to the ‘‘View,
Download and Transmit to 3rd party’’
criterion at 45 CFR 170.315(e)(1) as
required to meet this measure (83 FR
E:\FR\FM\01MYR3.SGM
01MYR3
25700
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
59817). The Data Export criterion in
§ 170.315(b)(6) is not required for the
Provide Patients Electronic Access to
their Health Information measure
included in the Promoting
Interoperability performance category,
nor have we proposed to change the
‘‘View, Download and Transmit to 3rd
party’’ criterion in § 170.315(e)(1)
required for this measure, thus we do
not believe this final policy will conflict
with CMS requirements for QPP.
7. Standardized API for Patient and
Population Services Criterion
We proposed to adopt a new API
criterion in § 170.315(g)(10) at 84 FR
7449. In response to comments, we are
adopting a Standardized API for Patient
and Population Services criterion for
Certification in § 170.315(g)(10) with
modifications. The new criterion, will
replace the old ‘‘application access—
data category request’’ certification
criterion (§ 170.315(g)(8)). In doing so,
we are also adding the Standardized API
for Patient and Population Services
criterion to the updated 2015 Edition
Base EHR definition and removing the
application access—data category
request criterion (§ 170.315(g)(8)). This
finalized Standardized API for patient
and population services certification
criterion requires the use of the FHIR
Release 4 and several implementation
specifications. The new criterion
focuses on supporting two types of APIenabled services: (1) Services for which
a single patient’s data is the focus and
(2) services for which multiple patients’
data are the focus. Please refer to the
‘‘Application Programming Interfaces’’
section (VII.B.4) in this preamble for a
more detailed discussion of the ‘‘API’’
certification criterion and related
Conditions and Maintenance of
Certification requirements.
8. Privacy and Security Transparency
Attestations Criteria
In 2015, the HIT Standards Committee
(HITSC) recommended the adoption of
two new ‘‘authentication’’ certification
criteria for the Program (81 FR 10635).
The National Coordinator endorsed the
HITSC recommendations for
consideration by the Secretary, and the
Secretary determined that it was
appropriate to propose adoption of the
two new certification criteria through
rulemaking. To implement the
Secretary’s determination, we proposed
two new criteria to which health IT
would need to be certified (84 FR 7450).
These would require the developer to
attest to whether the Health IT Module
for which they are seeking certification
to the criteria encrypts authentication
credentials (§ 170.315(d)(12)) and/or
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
supports multi-factor authentication
(§ 170.315(d)(13)). We did not propose
to require that health IT have these
authentication and encryption-related
functions, but instead proposed that a
health IT developer must indicate
whether or not their certified health IT
has those capabilities by attesting ‘‘yes’’
or ‘‘no.’’ We did, however, propose to
include the two criteria in the 2015
Edition privacy and security
certification framework (§ 170.550(h)).
For clarity, attesting ‘‘yes’’ to either of
these criteria indicates that the Health
IT Module can support either Approach
1 or Approach 2 of the 2015 Edition
privacy and security certification
framework for these criteria.
We note that we received many
comments on the proposed ‘‘encrypt
authentication credentials’’ and ‘‘multifactor authentication’’ criteria, but the
majority of comments conflated the two
proposals and provided collective
responses. Therefore, we have
responded to them in kind to preserve
the integrity of the comments.
a. Encrypt Authentication Credentials
We proposed in 84 FR 7450 to adopt
an ‘‘encrypt authentication credentials’’
certification criterion in § 170.315(d)(12)
and include it in the P&S certification
framework (§ 170.550(h)). We proposed
to make the ‘‘encrypt authentication
credentials’’ certification criterion
applicable to any Health IT Module
currently certified to the 2015 Edition
and any Health IT Module presented for
certification that is required to meet the
‘‘authentication, access control, and
authorization’’ certification criterion
adopted in § 170.315(d)(1) as part of
Program requirements.
Encrypting authentication credentials
could include password encryption or
cryptographic hashing, which is storing
encrypted or cryptographically hashed
passwords, respectively. If a developer
attests that its Health IT Module
encrypts authentication credentials, we
proposed in 84 FR 7450 that the
attestation would mean that the Health
IT Module is capable of protecting
stored authentication credentials in
accordance with standards adopted in
§ 170.210(a)(2), Annex A: Federal
Information Processing Standards (FIPS)
Publication 140–2, ‘‘Approved Security
Functions for FIPS PUB 140–2, Security
Requirements for Cryptographic
Modules.’’ We posited that FIPS
Publication 140–2 is the seminal,
comprehensive, and most appropriate
standard. Moreover, in the specified
FIPS 140–2 standard, there is an
allowance for various approved
encryption methods, and health IT
developers would have the flexibility to
PO 00000
Frm 00060
Fmt 4701
Sfmt 4700
implement any of the approved
encryption methods in order to attest
‘‘yes’’ to this criterion. We noted that
health IT developers should keep
apprised of these standards as they
evolve and are updated to address
vulnerabilities identified in the current
standard.
We did not propose that a Health IT
Module would be required to be tested
to the ‘‘encrypt authentication
credentials’’ certification criterion.
Rather, by attesting ‘‘yes,’’ the health IT
developer is attesting that if
authentication credentials are stored,
then the authentication credentials are
protected consistent with the encryption
requirements above. We proposed in 84
FR 7450 that the attestations ‘‘yes’’ or
‘‘no’’ would be made publicly available
on the Certified Health IT Product List
(CHPL). We proposed in 84 FR 7450
that, for health IT certified prior to the
final rule’s effective date, the health IT
would need to be certified to the
‘‘encrypt authentication credentials’’
certification criterion within six months
after the final rule’s effective date. For
health IT certified for the first time after
the final rule’s effective date, we
proposed that the health IT must meet
the proposed criterion at the time of
certification.
We also noted that some Health IT
Modules presented for certification are
not designed to store authentication
credentials. Therefore, we specifically
requested comment on whether we
should include an explicit provision in
this criterion to accommodate such
health IT. We stated that this could be
similar to the approach we utilized for
the 2015 Edition ‘‘end-user device
encryption’’ criterion
(§ 170.315(d)(7)(ii)), where we permit
the criterion to be met if the health IT
developer indicates that their health IT
is designed to prevent electronic health
information from being locally stored on
end-user devices.
b. Multi-Factor Authentication
We proposed in 84 FR 7450 to adopt
a ‘‘multi-factor authentication’’ (MFA)
criterion in § 170.315(d)(13) and include
it in the P&S certification framework
(§ 170.550(h)). We proposed to make the
‘‘multi-factor authentication’’
certification criterion applicable to any
Health IT Module currently certified to
the 2015 Edition and any Health IT
Module presented for certification that
is required to meet the ‘‘authentication,
access control, and authorization’’
certification criterion adopted in
§ 170.315(d)(1) as part of Program
requirements. To provide clarity as to
what a ‘‘yes’’ attestation for ‘‘multifactor authentication’’ attestation would
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
mean, we provided the following
explanation. MFA requires users to
authenticate using multiple means to
confirm they are who they claim to be
in order to prove one’s identity, under
the assumption that it is unlikely that an
unauthorized individual or entity will
be able to succeed when more than one
token is required. MFA includes using
two or more of the following: (i)
Something people know, such as a
password or a personal identification
number (PIN); (ii) something people
have, such as a phone, badge, card, RSA
token or access key; and (iii) something
people are, such as fingerprints, retina
scan, heartbeat, and other biometric
information. Thus, we proposed in 84
FR 7451 that in order to be issued a
certification, a health IT developer must
attest to whether or not its Health IT
Module presented for certification
supports MFA consistent with industryrecognized standards (e.g., NIST Special
Publication 800–63B Digital
Authentication Guidelines, ISO
27001).52
We proposed in 84 FR 7451 that, for
health IT certified prior to the final
rule’s effective date, the health IT would
need to be certified to the ‘‘multi-factor
authentication’’ certification criterion
within six months after the final rule’s
effective date. For health IT certified for
the first time after the final rule’s
effective date, we proposed that the
health IT must meet this criterion at the
time of certification. We solicited
comment on the method of attestation
and, if the health IT developer does
attest to supporting MFA, whether we
should require the health IT developer
to explain how they support MFA. In
particular, we asked whether a health IT
developer should be required to identify
the MFA technique(s) used/supported
by submitting specific information on
how it is implemented, including
identifying the purpose(s)/use(s) to
which MFA is applied within their
Health IT Module, and, as applicable,
whether the MFA solution complies
with industry standards.
Comments. The vast majority of
commenters supported the adoption of
the two proposed privacy and security
transparency attestation certification
criteria. A few commenters were
opposed to the new criteria. Several
supporters of the proposed criteria
recommended that we make the criteria
operative functional requirements
(including testing), rather than yes/no
attestations. Some of these commenters
reasoned that MFA should be a
requirement for all certified health IT,
52 NIST Special Publication 800–63B: https://
pages.nist.gov/800-63-3/sp800-63b/cover.html
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
given the risks involved with singlefactor authentication and how easy it is
today to implement MFA. We also
received a number of comments
requesting that we clarify that the MFA
proposal does not create a requirement
for health care providers to implement
MFA or encryption of authentication
credentials. Similarly, we received
several comments seeking clarification
that a ‘‘yes’’ attestation would only
require support of MFA, not that MFA
would have to be implemented. Along
these same lines, several commenters
expressed concerns that the
requirements could interfere with
clinical care and urged that the
requirements not contribute to provider
burden.
Response. We have adopted both
proposed privacy and security
transparency attestation criteria and
included both criteria (§ 170.315(d)(12)
and § 170.315(d)(13)) in the P&S
certification framework (§ 170.550(h)),
with minor modifications. While some
commenters recommended that MFA
should be a requirement for all certified
health IT, we did not propose such a
requirement nor could health IT
developers have foreseen such an
outcome in this final rule based on our
proposals, particularly considering the
clarity provided with our proposals (84
FR 7450) and the complexities of such
a requirement. For example, as noted by
commenters below, MFA may not be
appropriate or applicable in all
situations and there is wide variation in
authentication needs and approaches
throughout the industry. These criteria
will, however, still provide increased
transparency, and if a developer attests
‘‘yes’’ to these criteria regarding a
certified Health IT Module, that Health
IT Module will then be subject to ONC–
ACB surveillance for any potential nonconformity with the requirements of
these criteria. Given the strong support
expressed in public comments for these
criteria as proposed, we believe this is
the appropriate approach at this time.
While we believe that encrypting
authentication credentials and MFA
represent best practices for privacy and
security in health care settings, we
emphasize again that these criteria do
not require certified health IT to have
these capabilities or for health IT
developers to implement these
capabilities for a specific use case or any
use case. Equally important, the criteria
place no requirements on health IT
users, such as health care providers, to
implement these capabilities (if present
in their Health IT Modules) in their
health care settings. However, we note
that information regarding the security
capabilities of certified health IT
PO 00000
Frm 00061
Fmt 4701
Sfmt 4700
25701
provided by such transparency can aid
health IT users in making informed
decisions on how best to protect health
information and comply with applicable
security regulations (e.g., the HIPAA
Security Rule).
Comments. Some commenters who
supported the proposed criteria
requested clarification on the scope and
intent of the criteria, including what
level of authentication and which types
of users and user roles the criteria apply
to, as well as on how to attest for
multiple sign-on paths. A number of
commenters noted the wide variation in
authentication needs and approaches
throughout the industry, and they
recommended that we permit health IT
developers to describe how they support
authentication, rather than simply attest
‘‘yes’’ or ‘‘no.’’ The commenters stated
that such information would provide
helpful clarity regarding what the
certified health IT supports.
Additionally, several commenters stated
that we should require that health IT
developers explain how they support
MFA. A number of commenters stressed
that MFA may not be appropriate or
applicable in all situations, and in
particular, several commenters noted
that automated transactions, including
some that may occur in the public
health reporting context, cannot support
MFA.
Response. In response to requests for
modifications and clarifications, we
have modified the ‘‘encrypt
authentication credentials’’ criterion to
permit a health IT developer that attests
‘‘no’’ for its Health IT Module(s) to
indicate why the Health IT Module(s)
does not support encrypting stored
authentication credentials. A health IT
developer that attests ‘‘no’’ to the
‘‘encrypt authentication credentials’’
criterion may explain, for example, that
its Health IT Module is not designed to
store authentication credentials,
therefore there is no need for the Health
IT Module to encrypt authentication
credentials because it does not store, or
have the capability to store,
authentication credentials.
For the ‘‘MFA’’ criterion, consistent
with our solicitation of comments and
the comments received recommending
that health IT developers explain how
they support MFA, we have modified
the criterion to require health IT
developers that attest ‘‘yes’’ to describe
the use cases supported. For example, a
health IT developer could attest ‘‘yes’’ to
supporting MFA and state that the
Health IT Module supports MFA for
remote access by clinical users, thus
providing clarity on the user roles to
which MFA applies for that particular
Health IT Module. To be clear, health IT
E:\FR\FM\01MYR3.SGM
01MYR3
25702
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
developers are not expected to provide
specific technical details about how
they support MFA that could pose
security risks. Again, the purpose is to
enable health IT developers to give an
indication of the types of uses for which
their Health IT Module(s) support MFA.
We note that health IT developers may
wish to add new MFA use cases for
their certified health IT over a period of
time. In such instances, to provide the
clarity sought in the Proposed Rule as
to the MFA technique(s) used/supported
and how MFA is implemented,
including identifying the purpose(s)/
use(s) to which MFA is applied within
their Health IT Modules, any new MFA
use cases are required to comply with
this criterion’s ‘‘yes’’ attestation
provisions and be part of the quarterly
CHPL reporting by health IT developers
and ONC–ACBs under § 170.523(m).
If a health IT developer attests ‘‘no,’’
then it would not be required to explain
why its Health IT Module does not
support authentication, through
multiple elements, of the user’s identity
with the use of industry-recognized
standards. We did not propose to
require an explanation for ‘‘no’’
attestation nor did we request comment
on allowing health IT developers to
provide an explanation for a ‘‘no’’
attestation like we did for ‘‘yes’’
attestations (84 FR 7450–7451).
However, in an effort to provide
transparency and consistency for these
privacy and security attestation criteria,
we will also permit developers to
provide a reason for attesting ‘‘no’’ in
order to provide more context. Such a
reason may be due to MFA being
inapplicable or inappropriate. In those
cases, a developer could state, for
example, that the Health IT Module
does not support MFA because it is
engaged in system-to-system public
health reporting and MFA is not
applicable.
Comments. We received several
comments requesting adjustment to the
deadline for compliance to meet these
criteria. We also received a number of
comments recommending that we only
apply both of the proposed criteria to
new certifications and new Health IT
Modules, and not to Health IT Modules
already in widespread use.
Response. Regarding the timeframe
for compliance, and in response to
comments recommending that we only
apply the criteria to ‘‘new
certifications,’’ we have determined that
certification to these criteria as part of
the updated 2015 Edition privacy and
security certification framework
(§ 170.550(h)) will only be necessary for
Health IT Modules that are presented for
certification. Thus, a new Health IT
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
Module seeking certification for the first
time to the criteria specified in the 2015
Edition privacy and security
certification framework (§ 170.550(h)),
after the effective date of this final rule,
will need to meet these privacy and
security transparency attestation criteria
at the time of certification. Similarly, a
previously certified Health IT Module
that has undergone revision, such as
removal of certain capabilities, and is
presenting for revised certification to
the criteria specified in the 2015 Edition
privacy and security certification
framework (§ 170.550(h)) after the
effective date of this final rule, will need
to meet these privacy and security
transparency attestation criteria at the
time of certification. We believe that
this approach will still provide the
intended transparency as health IT will
need to be issued new certifications as
Health IT Modules are updated or
certified to other new or revised criteria
adopted in this final rule. At the same
time, this approach should reduce
burden for health IT developers and
allow them more time to plan and
prepare to meet these new transparency
requirements.
9. Security Tags and Consent
Management Criteria
In the 2015 Edition final rule, we
adopted two ‘‘data segmentation for
privacy’’ (DS4P) certification criteria.
One criterion, ‘‘DS4P-send’’
(§ 170.315(b)(7)), includes capabilities
for applying security tags according to
the DS4P standard in § 170.205(o) at the
document-level of a summary care
record formatted to the C–CDA 2.1
standard in § 170.205(a)(4). The other
criterion, ‘‘DS4P-receive’’
(§ 170.315(b)(8)), includes capabilities
for receiving a summary care record
formatted to the C–CDA 2.1 standard in
§ 170.205(a)(4) with document-level
security tags according to the DS4P
standard in § 170.205(o). As noted in the
2015 Edition final rule (80 FR 62646),
certification to these criteria is not
required to meet the CEHRT definition
for PI Programs.
Security tagging enables computer
systems to recognize the existence of
sensitive elements in data and properly
protect the privacy and security of the
data by ensuring that only the
appropriate individuals and entities can
access it. Security tagging capabilities
do not compromise the availability or
comprehensiveness of health
information available for treatment or
research purposes; rather, they enable
appropriate access controls in
accordance with existing policies,
governance, and applicable laws. The
DS4P standard describes a method for
PO 00000
Frm 00062
Fmt 4701
Sfmt 4700
applying security tags to HL7 CDA
documents to ensure that privacy
policies established at a record’s source
can be understood and enforced by the
recipient of the record.
The utility of the DS4P standard is not
limited to data subject to the Federal
regulations governing the
Confidentiality of Substance Use
Disorder Patient Records, 42 CFR part 2
(80 FR 62647). DS4P may be
implemented to support other data
exchange use cases in which
compliance with State or Federal legal
frameworks require special protections
for sensitive health information.
Security tagging capabilities are an
initial step towards enabling an
interoperable health care system to use
technical standards to permit
appropriate access, use, or disclosure of
sensitive health information in
accordance with applicable policies and
patient preferences. We understand and
acknowledge additional challenges
related the prevalence of unstructured
data, sensitive images, and potential
issues around use of sensitive health
information by clinical decision support
systems. The adoption of document
level data tagging for structured
documents would not solve these
issues, but could help move technology
in the direction where these issues
could be addressed (80 FR 16841).
Adoption of the 2015 Edition final
rule DS4P criteria was consistent with
earlier HIT Policy Committee (HITPC)
recommendations for the use of security
tagging to enable the electronic
implementation and management of
disclosure policies that originate from
the patient, the law, or an organization,
in an interoperable manner, so that
electronic sensitive health information
may be appropriately shared.53 The
HITPC recommendations consisted of a
glide path for the exchange of 42 CFR
part 2-protected data starting with the
inclusion of Level 1 (document level
tagging) send and receive functionality.
The HITPC also recommended
advancing the exchange of 42 CFR part
2-protected data, by outlining additional
capabilities in sharing, viewing and
incorporating privacy restricted data at
a more granular level, as well as
53 See HIT Policy Committee (HITPC)
Recommendation Letter to ONC, July 2 014, https://
www.healthit.gov/facas/sites/faca/files/PSTT_
DS4P_Transmittal%20Letter_2014-07-03.pdf; see
also HITPC’s Privacy and Security Tiger Team
Public Meeting, Transcript, May 12, 2014, https://
www.healthit.gov/facas/sites/faca/files/PSTT_
Transcript_Final_2014-05-12.pdf.; Public Meeting,
Transcript, May 27, 2014, https://www.healthit.gov/
facas/sites/faca/files/PSTT_Transcript_Final_201405-27.pdf.
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
managing computable patient consent
for the use of restricted data.54
Since the 2015 Edition final rule, the
health care industry has engaged in
additional field testing and
implementation of the DS4P standard.
As of the beginning of the fourth quarter
of the 2019 calendar year, 34 Health IT
Modules were certified to one or both of
the current 2015 Edition DS4P
certification criteria (Health IT Modules
with multiple certified versions were
counted once). Stakeholders have
shared with ONC—through public
forums, listening sessions, and
correspondence—that document-level
security tagging does not provide
enough flexibility to address more
complex privacy and security use cases.
Stakeholders noted that certain provider
types, such as pediatrics and behavioral
health, often rely on burdensome
manual workflows to appropriately
segment and share sensitive health
information according to State and local
laws. Additionally, stakeholders
expressed interest in ONC adopting
health IT standards that work with
DS4P to support electronic consent for
the exchange of security tagged data
over an API.
Therefore, in consideration of
stakeholder feedback and HITPC
recommendations to adopt DS4P
certification criteria on a glide path, we
proposed (84 FR 7452) to remove the
2015 Edition DS4P-send
(§ 170.315(b)(7)) and DS4P-receive
(§ 170.315(b)(8)) certification criteria.
We proposed that the effective date of
removal of these criteria would be the
effective date of the final rule. We
proposed to replace the removed DS4P
criteria with two new 2015 Edition
DS4P certification criteria in
§ 170.315(b)(12) and § 170.315(b)(13)
that would support security tagging
according to the DS4P standard at the
document, section, and entry levels of
C–CDA 2.1 formatted documents. Our
primary purpose for proposing to
remove and replace the criteria, in lieu
of proposing to revise them, was to
provide clarity to stakeholders about the
additional functionality enabled by
health IT certified to the new criteria.
We also proposed a new 2015 Edition
certification criteria for sharing patient
consent information over an API using
the Substance Abuse and Mental Health
Services Administration’s (SAMHSA)
Consent2Share (C2S) IG a FHIR-based
exchange standard, in § 170.315(g)(11).
We noted resources released by ONC
54 For more details on the two glide paths for part
2-protected data, see https://www.healthit.gov/facas/
sites/faca/files/PSTT_DS4P_Transmittal%20Letter_
2014-07-03.pdf.
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
and OCR, such as the HHS Security Risk
Assessment Tool 55 and the Guide to
Privacy and Security of Electronic
Health Information,56 as well as the
Office for Civil Rights’ security risk
analysis guidance 57 that entities may
employ to make risk-based decisions
regarding their implementation of the
proposed DS4P criteria. We also noted
the availability of the Electronic
Consent Management Landscape
Assessment, Challenges, and
Technology report.58 The report
includes suggestions for overcoming
barriers associated with implementing
electronic consent management, which
may be considered for further research
and discussion.
We note that we received many
comments on the proposed DS4P
criteria and the proposed consent
management for the API criterion but
the majority of comments conflated the
two proposals and provided a collective
response. We tried to separate where
possible, but in some instances, we kept
them combined in order to preserve the
integrity of the comments.
a. Implementation With the
Consolidated CDA Release 2.1
In place of the removed 2015 Edition
DS4P criteria, we proposed (84 FR 7452)
to adopt new DS4P-send
(§ 170.315(b)(12)) and DS4P-receive
(§ 170.315(b)(13)) criteria that would
remain based on the CDA 2.1 and the
HL7 DS4P standard. These criteria
would include capabilities for applying
security tags according to the DS4P
standard at the document, section, and
entry level. We believe this offers more
valuable functionality to providers and
patients, especially given the
complexities of the landscape of privacy
laws for multiple care and specialty
settings. We stated in the Proposed Rule
that we believe health IT certified to
these criteria would support multiple
practice settings and use cases.
Comments. We received many
comments both in support and against
this proposal. In certain instances,
commenters were supportive of our
aims but felt there were too many
55 HHS Security Risk Assessment Tool: https://
www.healthit.gov/providers-professionals/securityrisk-assessment.
56 ONC Guide to Privacy and Security of
Electronic Health Information: https://
www.healthit.gov/sites/default/files/ pdf/privacy/
privacy-and-security-guide.pdf.
57 HHS Office for Civil Rights: https://
www.hhs.gov/hipaa/for-professionals/security/
guidance/; and https://www.hhs.gov/
hipaa/for-professionals/security/guidance/
guidance-risk-analysis/?language=es.
58 https://www.healthit.gov/sites/default/files/
privacy-security/ecm_finalreport_
forrelease62415.pdf.
PO 00000
Frm 00063
Fmt 4701
Sfmt 4700
25703
barriers and challenges near term,
including but not limited to the
perceived cost involved with successful
segmentation in practice and indicated
we should delay our finalization of the
proposal. Others felt immediate
adoption of our proposal in the final
rule was critical for patient care and the
secure exchange of sensitive health
information. Many commenters in favor
of our proposal provided examples of
use cases which it could support, such
as helping to combat the opioid crisis by
facilitating the secure exchange of
sensitive health information across
health care settings and including
substance use disorder (SUD)
information covered by 42 CFR part 2.
We also received support of our
proposal for the protection of women’s
health—the commenter explained that
segmenting at the element level would
protect individuals who have
experienced intimate partner violence,
sexual assault, and other sensitive
experiences. Stakeholders shared with
us that focusing certification on
segmentation to only the document
level does not permit providers the
flexibility to address more granular
segmentation needs. We received many
comments on this proposal in the
context of the following topics: provider
and developer burden; readiness of the
standard and C–CDA exchange;
information blocking and EHI; future
multidisciplinary activities (such as
workgroups) and creating a vision for
segmentation using health IT; safety;
privacy policy conformity; suggested
use cases; cost; and requests for specific
clarifications. We describe these
comments further below.
Response. We thank commenters for
their input. To address the comments
concerned about the cost and timing, at
the current time, these criteria are
voluntary and not required under the
definition of CEHRT or to participate in
any HHS program. For more information
on the costs for the adoption of these
criteria, please see the Regulatory
Impact Analysis in section XIII. For the
reasons noted above, in this final rule,
we have finalized our proposal to
support a more granular approach to
privacy tagging data consent
management for health information
exchange supported by the C–CDA
exchange standard. We do this not by
removing and replacing the 2015
Edition DS4P criteria with new
§ 170.315(b)(12) and § 170.315(b)(13),
but by revising the 2015 Edition DS4P
criteria, DS4P criteria DS4P-send
(§ 170.315(b)(7)) and DS4P-receive
(§ 170.315(b)(8)), to include the full
scope of the HL7 DS4P standard for
E:\FR\FM\01MYR3.SGM
01MYR3
25704
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
security tagging at the document,
section and entry level with
modifications as described below.
Comments. We received many
comments regarding the perceived
burden of segmentation on providers
and developers including comments
focused on workflow challenges. One
commenter indicated a lack of system
and explained that tagging is
burdensome for implementers because it
does not describe how to determine
what information is sensitive and
should be tagged. Another indicated
that DS4P creates a permanent added
burden of extensive and costly manual
data curation to redact each page to
meet overlapping Federal and State
regulations. Commenters indicated end
users would be required to flag each
individual data element, a process that
is time consuming and error prone.
They further explained that granular
level privacy tagging has the risk of
adding additional data entry burden to
provider workflows if users must tag
each item individually.
Response. We appreciate the
thoughtful comments submitted on the
proposed criteria. Notably, with respect
to the comments we received that
expressed concern about the DS4P
standard due to the burden, our analysis
of the comments indicates that the
concerns the commenters express are
more closely related to the complexity
of the privacy law landscape than to the
specific functionality and standard in
our proposal. As noted above, at the
current time, these criteria are voluntary
and not required under the definition of
CEHRT or to participate in any HHS
program. The DS4P standard is a tool
and voluntary certification to these
criteria is an initial step towards
enabling an interoperable health care
system to use technical standards to
compute and persist security tags to
permit access, use, or disclosure of
sensitive health information. The
criteria do not specify that a manual
workflow is required to implement
security tagging, and we understand
from examples of DS4P use in practice
that solutions may include the use of
value sets to automate the tagging
process. We reiterate that these criteria
are intended to apply standards to the
transmission of documents so that such
security tags may be interoperable.
Though the updated criteria would
support a more granular approach to
tagging the sensitive information, we
recognize that this will not solve the
whole problem of how to manage data
segmentation for privacy and consent
management. The recipient will still
receive and can view the information
that is tagged—the recipient will need to
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
determine what they are going to do
with that information. Policies and
procedures for what to do with the
information once it is received are
outside the scope of these criteria and
this final rule. However, we emphasize
that health care providers already have
processes and workflows to address
their existing compliance obligations for
State and Federal privacy laws, which
could be made more efficient and cost
effective through the use of health IT,
rather than relying on case-by-case
manual redaction and subsequent
workarounds to transmit redacted
documents. We believe this tool may be
one part of innovative solutions to
support health IT enabled privacy
segmentation in care coordination
workflows to significantly reduce the
burden of these manual processes
currently in practice.
Comments. Several commenters
indicated that enhanced segmentation
may unintentionally impact clinical
care when providers are presented with
an incomplete picture of patient data.
Commenters stated there could be
patient care risks involved with not
sharing elements as users of
downstream systems may not realize
that a single element is filtered and act
improperly, such as by prescribing a
contraindicated medication due to
missing information.
Response. DS4P is a technical
standard for C–CDA that helps health
care providers comply with existing,
applicable laws. As such, health care
providers should already have processes
and workflows in place to address their
existing compliance obligations. The
DS4P standard does not itself create
incomplete records. Under existing law,
patients already have the right to
prevent re-disclosure of certain types of
data by withholding consent to its
disclosure or to place restrictions on its
re-disclosure. DS4P allows providers to
electronically tag (mark) data as
sensitive and express re-disclosure
restrictions and other obligations in an
electronic form. DS4P does not
determine whether a segmentation
obligation exists legally or what that
legal obligation means to the recipient.
Instead, DS4P allows for tagging and
exchange of health information that has
already been determined to be sensitive
and in need of special protections under
existing law.
Comments. We received comments in
support of our proposal indicating that,
without data segmentation, other
mandatory criteria, such as the
proposed ‘‘EHI export’’ criterion, would
be difficult to implement without
risking disclosure of sensitive data or
information blocking. One commenter
PO 00000
Frm 00064
Fmt 4701
Sfmt 4700
indicated that without this technical
standard, it would be difficult for
stakeholders to know whether
appropriate consent has been obtained
prior to releasing health information.
Further, the commenter indicated
concern that without such capabilities,
hospitals and health systems could be
accused of information blocking because
they cannot verify that a patient has
given consent for their EHI to be shared.
They further commented that if ONC
does not finalize this criterion, then we
should provide an appropriate
exception in the information blocking
provisions so that an entity is not
accused of information blocking because
they do not know if another
organization has obtained consent from
patients. One commenter stated ONC
should propose a new information
blocking exception that specifically
clarifies that a health IT developer’s
choice to not certify to an optional
standard cannot be a practice that
implicates information blocking.
Response. We thank commenters for
their support of the DS4P standard.
While we understand commenters’
concerns, we first reiterate the DS4P
capability enables sensitive health
information to be exchanged
electronically with security tags in a
standardized format. It does not enable
the full segmentation of a patient’s
record within an EHR, which may be
necessary when responding to a request
for EHI. Second, we have revised the
Infeasibility Exception in the
information blocking section of this
final rule to provide that an actor is not
required to fulfill a request for access,
exchange, or use of EHI if the actor
cannot unambiguously segment the
requested EHI from other EHI: (1)
Because of a patient’s preference or
because the EHI cannot be made
available by law; or (2) because the EHI
is withheld in accordance with the
Harm Exception in § 171.201
(§ 171.204(a)(2)). For instance, an actor
will be covered under this condition if
the actor could not fulfill a request to
access, exchange, or use EHI because the
requested EHI could not be
unambiguously segmented from patient
records created by federally assisted
programs (i.e., Part 2 Programs) for the
treatment of substance use disorder (and
covered by 42 CFR part 2) or from
records that the patient has expressed a
preference not to disclose. We refer
readers to the Infeasibility Exception
discussion in section VIII.D.1.d of this
final rule.
Comments. Many commenters noted a
low level of adoption for these
standards and concerns related to
readiness expressing that the standard
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
utility is limited by lack of widespread
developer implementation. Several
commenters encouraged ONC to defer
adoption of the DS4P criteria with a few
commenters recommending that the
optional 2015 Edition criterion should
be maintained with document level
tagging only until practical
implementations at scale have been
demonstrated at this level. One
commenter suggested that organic
adoption by end-user providers will
help spark innovation in this emerging
standard while expressing concern that
C–CDA level data tagging for privacy is
largely untested in real world scenarios.
Others encouraged ONC to provide
additional guidance on the adoption of
the DS4P standards and certification
criteria and forgo the inclusion of this
requirement until additional real world
testing is available. They also indicated
ONC should first conduct use test cases
to demonstrate how this functionality
will be effectively used across a variety
of environments.
Response. We appreciate the
comments on the proposed criteria. In
reference to the DS4P standard’s
maturity, we note that it is considered
a ‘‘normative’’ standard from the HL7
perspective—a status which indicates
the content has been enhanced and
refined through trial use. While we
recognize that to date the standard has
not been widely adopted, the SAMHSA
C2S application uses the standard to
segment Part 2 information. Likewise,
the U.S. Department of Veterans Affairs
(VA) and private companies across the
country have used the DS4P standard to
support behavioral health and pediatric
care models. In addition, as of the fourth
quarter of 2019, 34 individual Health IT
Modules obtained certification to one of
or both of the prior 2015 Edition
certification criteria. Our intent for
adopting the updates to these criteria is
that in the absence of adoption of
consensus driven standards there is
increased risk that single-use-case,
proprietary solutions will be developed,
which may increase fragmentation,
provider burden, and cost while
limiting interoperability. Further, the
purpose of adopting these criteria is to
encourage the use of interoperable
standards, in this case to use technical
standards to compute and persist
security tags upon exchange of a
summary of care document in an
interoperable manner. In addition, the
certification criteria using the DS4P
standard are voluntary and therefore our
intent is, as commenters noted, to
support organic adoption of technology
certified to the criteria by providers
seeking to implement health IT
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
solutions to replace burdensome manual
privacy workflows.
Comments. Several commenters
called for the need to increase
conformity among Federal and State
privacy provisions to achieve successful
implementation of granular tagging.
They noted the significant policy
component involved with the successful
implementation of the DS4P standard in
practice, and in certain instances
specifically noted support for HIPAA
Privacy Rule and 42 CFR part 2
harmonization. Several commenters
identified specific areas for technical
development of IT supporting data
segmentation for privacy based on
Federal and State privacy provisions.
One commenter indicated that ONC
could map which clinical codes are
associated with certain health
conditions that receive special privacy
protections in addition to the HIPAA
Rules. Other commenters noted that
mapping of privacy policy to technical
specifications is not a sufficient or
adequate approach given policy
complexities. One commenter indicated
a future approach should focus on
development of criteria that support a
data provenance driven method of
sensitive data management as applicable
under privacy laws.
Response. As we have stated, the
DS4P standard enables sensitive health
information to be exchanged
electronically with security tags in a
standardized format and we encourage
health IT developers to include DS4P
functionality and pursue certification of
their health IT to these criteria in order
to help support their users’ compliance
with relevant State and Federal privacy
laws that protect sensitive health
information. We recognize that the
current privacy law landscape is
complex. In light of the complexities of
the privacy law landscape, we believe
that supporting a standard that allows
for increased granularity in security
tagging of sensitive health information
would better allow for the interoperable
exchange of this information to support
a wide range of privacy related use
cases.
Comments. Many commenters offered
an approach for next steps to advance
the standard. To advance adoption and
implementation of the standard, several
commenters suggested that ONC work
closely with clinicians, privacy subject
matter experts and interoperability
experts (notably the HL7 Privacy and
Security workgroups) to develop a clear
vision for implementing enhanced data
segmentation. Many commenters
specifically called for ONC to sponsor or
lead a multidisciplinary workgroup of
stakeholders to develop
PO 00000
Frm 00065
Fmt 4701
Sfmt 4700
25705
recommendations for industry adoption
and implementation. One commenter in
support of our proposal suggested such
workgroup focus on including whether
additional standards are needed, as well
as data visualization of non-disclosed
data and its utilization in clinical
decision support algorithms. Several
commenters cited existing work to help
support potential new multidisciplinary
efforts indicating that one SDO has
already undertaken early work toward
evolving DS4P implementation
guidance via the HL7 V2 to FHIR
mapping project sponsored by the HL7
Orders Work Group. One commenter,
called for an ONC led public-private
collaborative effort to reduce data entry
burden. One commenter recommended
that ONC stand up a multi-stakeholder
workgroup to identify and define policy
needs and functional requirements to
address patient privacy and provider
needs.
Response. We thank commenters for
their recommendations. ONC believes
that data segmentation is an integral
capability for exchanging sensitive
health data. ONC first studied policy
considerations regarding data
segmentation in electronic health
information exchange in 2010 and
informed ONC’s launch of the DS4P
Standards and Interoperability
Framework (S&I Framework) Initiative
in 2011.59 The initiative focused on the
development of a DS4P technical
specification that would allow highly
sensitive health information to flow
more freely to authorized users while
improving the ability of users of health
IT to meet their obligations under State
and Federal privacy rules.
Recommendations from the initiative
called for the use of metadata security
tags to demonstrate privacy and security
obligations associated with patient
health information. It also advised that
patients and providers be able to share
portions, or segments, of records in
order to maintain patient privacy. Pilot
projects conducted under the DS4P S&I
Framework Initiative demonstrated
ways to enable the sharing of
information that is protected by Federal
and State laws, including the substance
use disorder treatment confidentiality
regulations, 42 CFR part 2. ONC’s prior
Federal Advisory Committee, the
HITPC, also focused on the health IT
certification needed to enable exchange
of behavioral health data.60
Additionally, ONC led a project on
59 https://archive.healthit.gov/providersprofessionals/ds4p-initiative.
60 https://www.healthit.gov/topic/Federaladvisory-committees/health-it-policy-committeerecommendations-national-coordinator.
E:\FR\FM\01MYR3.SGM
01MYR3
25706
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
patient choice where the exchange of
sensitive data was addressed.61 ONC
also led a project on the Behavioral
Health Data Exchange (BHDE)
Consortium. The purpose of the project
was to facilitate and address barriers to
the intra and interstate exchange of
behavioral health data.62 Currently,
ONC’s Leading Edge Acceleration
Projects (LEAP) in Health Information
Technology (IT) program seeks to
address well-documented and fast
emerging challenges inhibiting the
development, use, and/or advancement
of well-designed, interoperable health
IT. In 2019, one of the two LEAP awards
issued by ONC focused on the
standardization and implementation of
the Fast Healthcare Interoperability
Resources (FHIR®) Consent resource.
Under this project, a FHIR® Consent
Implementation Guide (IG) and package
of open-source prototypes and content
to assist partners in using the FHIR®
Consent Resource will become
available.63
Also, ONC actively participates in
HL7 International (HL7®) Workgroups
and standards-development activities
related to data segmentation and
consent management. It is critical for
sensitive health information to be
included in health information
exchange and we are exploring
opportunities for additional
collaboration in the future.
Comments. One commenter
recommended a companion guide be
developed to assist implementers with
the standard. Another indicated ONC
should provide guidance to facilitate
adoption of the DS4P standards and
certification criteria including
dissemination of best practices to help
ensure that providers can most
effectively implement the standards and
associated workflows. Another referred
to a Query-Based Document Exchange
IG which has further guidance on the
ability to assert access policies and
DS4P implementation considerations.
Response. The HL7 Version 3
Implementation Guide: Data
Segmentation for Privacy (DS4P),
Release 1, Part 1: CDA R2 and Privacy
Metadata Reusable Content Profile, May
16, 2014 standard 64 § 170.205(o)(1)
(HL7 DS4P standard) describes the
technical means to apply security tags to
61 https://www.healthit.gov/topic/patient-consentelectronic-health-information-exchange.
62 https://www.healthit.gov/topic/health-it-healthcare-settings/behavioral-health-data-exchangeprimary-care-and-behavioral.
63 https://www.healthit.gov/topic/leading-edgeacceleration-projects-leap-health-informationtechnology-health-it.
64 https://www.hl7.org/implement/standards/
product_brief.cfm?product_id=354.
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
a health record and data may be tagged
at the document-level, the section-level,
or individual data element-level. The
HL7 DS4P standard also provides a
means to express obligations and
disclosure restrictions that may exist for
the data. We appreciate commenters
input on additional guidance beyond
these certification requirements that
may prove useful for developers.
However, we reiterate that in this rule
we address only that guidance that is
required for those developers to
voluntarily submit a Health IT Module
for certification to our criteria.
Additional guidance on best practices
would be outside the scope of this
rulemaking. However, as noted above,
we are committed to continuing to work
with stakeholders, including health IT
developers and those involved in
implementing privacy policy in the
health care industry, to work toward
interoperable solutions for privacy and
consent management.
Comments. We received several
comments seeking clarification on our
proposal to remove the current 2015
Edition ‘‘DS4P-send’’ (§ 170.315(b)(7))
and ‘‘DS4P-receive’’ (§ 170.315(b)(8))
certification criteria and to replace these
two criteria with three new 2015 Edition
DS4P certification criteria (two for C–
CDA and one for a FHIR-based API). As
examples, one commenter sought
clarification on whether our proposal
was for DS4P send and receive to
become mandatory for the revised 2015
Edition certification, or if they will
remain voluntary criteria. One
commenter sought clarification on
whether the data protections apply to
FHIR transmissions. Another indicated
that they believe the DS4P
implementation guide only focuses on
data segmentation for C–CDA
documents and not for HL7 FHIR and
sought ONC clarification regarding
whether or not we intend to apply data
segmentation labeling to the HL7 FHIR
resources in support of the USCDI as
well. Another commenter recommended
that we require FHIR Release 4 version
but commented that a consistent
approach of USCDI across HL7 CDA, C–
CDA and HL7 FHIR is not attainable at
this time. One commenter stated a
similar need for clarification indicating
that the standard for DS4P should be
HL7 standards for CDA Version 2 and
FHIR security tagging and not be the
SAMHSA C2S stating that ONC should
clarify this misunderstanding. Another
commenter sought clarification by ONC
to indicate that the IG is for CCDS and
not FHIR, and also indicated confusion
regarding STU4. One commenter noted
that the DS4P criteria are only effective
PO 00000
Frm 00066
Fmt 4701
Sfmt 4700
for C–CDA-based data exchange and
recommended ONC add FHIR-based
standard for tagging of sensitive data.
Several commenters expressed concern
over what they described as
misalignment of this proposal with
other ONC policies explaining that
neither USCDI nor ARCH, nor HL7 FHIR
US Core includes the FHIR Composition
resource, which would be at the
equivalent level of granularity as a C–
CDA document.
Response. We thank commenters for
their input and we appreciate the need
for clarity requested by commenters. In
the Proposed Rule (84 FR 7452), we
proposed both to adopt an update to the
HL7 DS4P standard for the existing 2015
Edition certification criteria to support
security tagging of a C–CDA upon send
and receive by removing DS4P-send
(§ 170.315(b)(7)) and DS4P-receive
(§ 170.315(b)(8)) and replacing them
with DS4P-send (§ 170.315(b)(12)) and
DS4P-receive (§ 170.315(b)(13)) and to
also adopt a new criterion to support
API exchange via consent management
solutions using the FHIR standard. In
other words, these were two separate
proposals, the first to support security
tags in summary of care documents and
another to support consent management
for specific use cases that leverage a
FHIR-based API. As of this final rule,
these criteria remain voluntary and not
required under the definition of CEHRT
or to participate in any HHS program.
We proposed these several criteria in a
single section of the Proposed Rule
because of the relationship between
them as two potential health IT tools
that could be part of overarching
solutions to manage privacy and
consent in health information exchange.
However, as stated earlier, we note that
neither of these tools addresses the
entirety of the scope of data
segmentation for privacy. To address the
comment on the DS4P implementation
guide, we confirm that the HL7 DS4P
standard in § 170.205(o)(1) describes the
technical means to apply security tags to
a health record and data may be tagged
at the document-level, the section-level,
or individual data element-level in the
C–CDA and not for FHIR. Currently, we
do not intend to apply data
segmentation labeling to the HL7 FHIR
resources in support of the USCDI
because all FHIR resources already
include the capability to apply security
tags to the resource as metadata. We
appreciate the recommendation to
require FHIR Release 4 for consent
management but as discussed below, we
have decided not to finalize the
proposal for consent management for
APIs in this final rule. For further
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
discussion of our FHIR-based consent
management proposal, we direct readers
to subsection b below.
For the updates to the existing DS4P
criteria, to support greater clarity
requested by public comment, rather
than removing the existing 2015 Edition
criteria and replacing them with new
criteria as proposed, we instead
finalized a simple update to the existing
criteria to note the use of the full HL7
DS4P standard for tagging or applying
security tags at the document, section,
and entry level.
We further note that these updated
criteria remain voluntary, and that we
have finalized modifications in
§ 170.315(b)(7)(ii) and
§ 170.315(b)(8)(i)(B) to our proposed
effective date for this change to allow
for a longer glide path for health IT
developers to update Health IT Modules
to the full standard to better support
clinical and administrative workflows.
While certification to the updated
standards will be available after the
effective date of this final rule upon
successful testing, we have finalized
that document-level tagging remains
applicable for up to 24 months after the
publication date of this final rule. For
certification and compliance of Health
IT Modules certified after 24 months
after the publication date of this final
rule, only the full scope of the HL7
DS4P standard is applicable. We have
finalized this 24 month period for the
update for these criteria under the real
world testing provisions in
§ 170.405(b)(6) as follows:
• Security tags. A health IT developer
with health IT certified to § 170.315
(b)(7) and/or § 170.315 (b)(8) prior to
June 30, 2020, must:
Æ Update their certified health IT to
be compliant with the revised versions
of the criteria adopted in § 170.315(b)(7)
and/or the revised versions of the
criteria adopted in § 170.315(b)(8); and
Æ Provide its customers of the
previously certified health IT with
certified health IT that meets paragraph
(b)(6)(i) of this section by May 2, 2022,
In addition, we have finalized these
updated criteria with modifications to
the criteria names to better describe the
function the criteria support in
interoperable health IT systems. The
modifications to the criteria are as
follows:
• Prior criterion: ‘‘DS4P-send’’
(§ 170.315(b)(7)) includes capabilities
for creating a summary care record
formatted to the C–CDA standard and
document-level tagging as restricted
(and subject to restrictions on redisclosure) according to the DS4P
standard.
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
• Revised criterion: ‘‘Security tags—
Summary of Care (send)’’
(§ 170.315(b)(7)) includes capabilities
for creating a summary of care record
formatted to the C–CDA standard and
that is tagged as restricted and subject
to restrictions on re-disclosure
according to the DS4P standard at the
document, section, and entry (data
element) level, or at the document-level
for the period until May 2, 2022.
• Prior criterion: ‘‘DS4P-receive’’
(§ 170.315(b)(8)) includes capabilities
for receiving a summary care record
formatted to the C–CDA standard and
document-level tagged as restricted (and
subject to restrictions on re-disclosure)
according to the DS4P standard.
• Revised criterion: ‘‘Security tags—
Summary of Care (receive)’’
(§ 170.315(b)(8)) includes capabilities
for receiving a summary of care record
formatted to the C–CDA standard and
that is tagged as restricted and subject
to restrictions on re-disclosure
according to the DS4P standard at the
document, section, and entry (data
element) level, or at the document-level
for the period until May 2, 2022. We
have finalized our proposal to include
in the voluntary ‘‘Security tags—
Summary of Care (receive)’’
(§ 170.315(b)(8)) criterion as a
requirement that the Health IT Module
has the capability to preserve privacy
markings to ensure fidelity to the
tagging based on consent and with
respect to sharing and re-disclosure
restrictions as proposed.
b. Implementation With the Fast
Healthcare Interoperability Resources
(FHIR®) Standard
In collaboration with ONC, SAMHSA
developed the C2Sapplication to
address the specific privacy protections
for patients with substance use
disorders whose treatment records are
covered by the Federal confidentiality
regulation, 42 CFR part 2. C2S is an
open source application for data
segmentation and consent management.
It is designed to integrate with existing
FHIR systems. SAMHSA created a FHIR
implementation guide (the
Consent2Share Consent Profile Design,
hereafter referred to as ‘‘Consent
Implementation Guide’’) that describes
how the Consent2Share application and
associated access control solution (C2S
platform) uses the FHIR Consent
resource to represent and persist patient
consent for treatment, research, or
disclosure.65 The implementation guide
65 The draft FHIR IG titled ‘‘Consent2Share FHIR
Profile Design.docx’’ can be accessed through the
Community- Based Care and Privacy (CBCP) HL7
workgroup, within the Package Name titled
PO 00000
Frm 00067
Fmt 4701
Sfmt 4700
25707
provides instructions for using the FHIR
Consent resource to capture a record of
a health care consumer’s privacy
preferences.
In section VII.B.4 of this final rule, we
discuss policies related to the
implementation of a standardized API to
support the exchange of health
information between providers and
patients and among members of a care
team. In the Proposed Rule, we
anticipated that the proposed 2015
Edition ‘‘standardized API for patient
and population services’’ certification
criterion (§ 170.315(g)(10)) would result
in a proliferation of APIs that will
enable a more flexible and less
burdensome approach to exchanging
EHI. We stated our belief that the health
care industry could leverage this API
infrastructure to share segmented data
in a secure and scalable manner.
Therefore, we proposed to adopt a 2015
Edition certification criterion ‘‘consent
management for APIs’’ in
§ 170.315(g)(11) to support data
segmentation and consent management
through an API in accordance with the
Consent Implementation Guide.
Comments. Overall, the majority of
commenters were supportive of the
concept of consent management for
APIs but many had concerns with the
proposed criteria, specifically the
adoption of the Consent Implementation
Guide or the C2S platform as part of a
certification criterion. Many
commenters raised concerns that the
Consent Implementation Guide has not
been balloted as an HL7 standard and
noted that C2S does not support a
consenter’s signature or specification to
protect information content data
requirements. A couple of commenters
stated that the Consent Implementation
Guide is a new emerging standard in
pilot with feedback requested.
Commenters also raised concern that the
IG has not gone through an SDO
process. Another commenter raised
concern that SAMHSA no longer
supports the C2S platform and the
Consent Implementation Guide and it
now lacks a steward. A couple of
commenters suggested ONC defer the
consent management criteria at least
until an API FHIR standard version is
finalized and the Consent
Implementation Guide is revised to
conform that to that version. One
commenter supported the adoption of
FHIR v3-based Consent resource, but
urged ONC to also consider pediatric
and geriatric use cases in its adoption.
Other commenters stated that their
understanding was that tagging will be
‘‘BHITS_FHIR_Consent_IG,’’ at https://
gforge.hl7.org/gf/project/cbcc/frs/.
E:\FR\FM\01MYR3.SGM
01MYR3
25708
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
a feature of FHIR Release 4, but were
unclear how the proposal to move to
FHIR Release 2 would work. One
commenter questioned how if there are
no standards-based approaches for
identifying what in the record is
sensitive, how one could feasibly
implement privacy-tagging and consent
management via FHIR at the Resource
level and that tagging at a more granular
level is too cumbersome and unrealistic.
A number of commenters stated that the
standards were premature and if
adopted could have unintended
negative effects. Commenters were not
supportive of having two versions of
FHIR but instead recommended the use
of FHIR Release 4. Commenters
recommended ONC focus on driving
real-world implementation experience
before adopting the standards.
On the other hand, a few commenters
supported our proposal, and stated that
the C2S platform and the Consent
Implementation Guide is mature and
already supports granular level security
tagging and data segmentation and
supports several API standards listed in
the Proposed Rule. One commenter
expressed support broadly for the C2S
platform indicating that, though it was
originally designed to satisfy 42 CFR
part 2 consent for the substance use
disorder data, it supports the other
sensitive categories such as HIV and
mental health. Several commenters
stated that the criteria should be
required in the Base EHR definition.
Many providers called for patient
education and for ONC to work with
SAMHSA, OCR, and CMS. It was also
suggested that ONC coordinate with
SAMHSA to establish a public-private
project to advance the C2S platform and
the Consent Implementation Guide
using an analogous process to that of the
Da Vinci Project with transparency and
with no membership fees. Finally,
several commenters raised issues that
are out of scope for this rule including
concerns specifically with the HIPAA
Rules or 42 CFR part 2 which are under
the authority of OCR and SAMHSA
respectively.
Response. We appreciate the
comments received and the insights into
real world implementing challenges of
consent management. We agree that
there is continued work to be done to
ballot and field test the C2S platform
and the Consent Implementation Guide
and also agree with commenters that
identified this resource as having
significant potential to support consent
management for specific use cases such
as 42 CFR part 2, behavioral health, and
pediatric care. We also note that we had
included a series of questions in our
Proposed Rule related to the alignment
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
of FHIR releases and we appreciate
comments received related to these
questions. We direct readers to section
VII.B.4.c for further discussion of our
adoption in this rule the FHIR Release
4 standard. We note that the Consent
Implementation Guide is designed in
FHIR Release 3 and that there is
significant work to be done in standards
development before the IG would be
feasible with FHIR Release 4. At this
time, FHIR Release 4 version of FHIR
consent resource is not normative and
can change from version to version and
therefore further development, review,
balloting, and testing would be required
for a FHIR Release 4 based IG to be a
viable consensus standard for adoption
in the Program. In consideration of
comments, and the scope of the
additional work required for readiness
of an IG that could be adopted in our
regulations, we have not finalized the
proposed ‘‘consent management for
APIs’’ certification criterion in
§ 170.315(g)(11). We maintain, as stated
above, that the C2S platform and the
Consent Implementation Guide may still
serve as a template for implementation
of consent management workflows
leveraging APIs and that it may be a part
of health IT solutions to facilitate health
information exchange of sensitive
information. We will continue to
monitor the development of the Consent
Implementation Guide and other FHIR
resources to support consent
management and may consider
including in a future rulemaking.
10. Auditable Events and TamperResistance, Audit Reports, and Auditing
Actions on Health Information
Since adopting the Auditable events
and tamper-resistance (§ 170.315(d)(2)),
Audit Reports (§ 170.315(d)(3)), and
Auditing Actions on health information
(§ 170.315(d)(10)) criteria in the 2015
Edition, there has been an update to
ASTM E2147—1 standard and has been
replaced by a newer version. Given the
older version has been deprecated and
based on comments received, we have
updated these criteria with the most up
to date standard, ASTM E1247—18 in
§ 170.210(h). We have also updated the
requirements to align with the new
numbering sequence of the updated
standard. In order to meet the minimum
requirements for capturing and auditing
electronic health information, we have
specified, in § 170.210(e)(1)(i), that the
data elements in sections 7.1.1 through
7.1.3 and 7.1.6, through 7.1.9 in ASTM
E1247—18 are required. We believe that
the updated standard reinforces what
we have previously required and
maintained with previous certification
PO 00000
Frm 00068
Fmt 4701
Sfmt 4700
requirements and note that there is no
substantial change to the standard.
We further note that health IT
developers must update Health IT
Modules to these updated standards
referenced in these criteria within 24
months after the publication date of this
final rule. We have added as a
Maintenance of Certification
requirement for the real world testing
Condition of Certification requirement,
that health IT developers are required to
provide the updated certified health IT
to all their customers with health IT
previously certified to the identified
criteria no later than 24 months after the
publication date of the final rule.
Developers would also need to factor
these updates into their next real world
testing plan as discussed in section
VII.B.5 of this final rule and in
§ 170.405(b)(7).
C. Unchanged 2015 Edition Criteria—
Promoting Interoperability Programs
Reference Alignment
In the FY 2019 IPPS/LTCH PPS
proposed rule (83 FR 20516), CMS
proposed scoring and measurement
policies to move beyond the three stages
of meaningful use to a new phase of
EHR measurement with an increased
focus on interoperability and improving
patient access to health information. To
reflect this focus, CMS changed the
name of the Medicare and Medicaid
EHR Incentive Programs, to the
Medicare and Medicaid Promoting
Interoperability (PI) Programs. To align
with the renaming of the EHR Incentive
Programs, we proposed to remove
references to the EHR Incentive
Programs and replace them with
‘‘Promoting Interoperability Programs’’
in the updated 2015 Edition ‘‘automated
numerator recording’’ criterion in
§ 170.315(g)(1) and the ‘‘automated
measure calculation’’ criterion in
§ 170.315(g)(2).
Comments. We did not receive any
comments on this proposal to remove
references to the EHR Incentive
Programs and replace them with
‘‘Promoting Interoperability Programs’’
in the updated 2015 Edition ‘‘automated
numerator recording’’ criterion in
§ 170.315(g)(1) and the ‘‘automated
measure calculation’’ criterion in
§ 170.315(g)(2).
Response. We have removed
references to the EHR Incentive
Programs and replaced them with
‘‘Promoting Interoperability Programs’’
in the 2015 Edition ‘‘automated
numerator recording’’ criterion in
§ 170.315(g)(1) and the ‘‘automated
measure calculation’’ criterion in
§ 170.315(g)(2).
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
V. Modifications to the ONC Health IT
Certification Program
A. Corrections
1. Auditable Events and Tamper
Resistance
We proposed to revise § 170.550(h)(3)
to require the End-User Device
Encryption criterion in § 170.315(d)(7)
as appropriate, and exempt Health IT
Modules from having to meet
§ 170.315(d)(7) when the certificate
scope does not require § 170.315(d)(7)
certification (see § 170.315(d)(2)(i)(C))
(84 FR 7454). As noted in the Proposed
Rule (84 FR 7454), paragraph
170.315(d)(2)(i)(C) was not applicable to
the privacy and security testing and
certification of a Health IT Module
required by § 170.550(h)(3)(iii), (v), (vii),
and (viii), but we intended for it to also
be exempted from the aforementioned
paragraphs. We, therefore, proposed to
revise § 170.550(h)(3)(iii), (v), (vii), and
(viii) by removing references to
paragraph 170.315(d)(2)(i)(C).
Comments. One commenter expressed
support of the proposals under section
V (‘‘Modifications of the ONC Health IT
Certification Program’’) of the Proposed
Rule as a whole. However, we received
no comments specific to this proposal.
Response. We have finalized the
revision as proposed. Certification can
proceed for the audit log process
without the Health IT Module
demonstrating that it can record an
encryption status in accordance with
§ 170.315(d)(2)(i)(C). Paragraph
§ 170.315(d)(2)(i)(C) is not applicable for
the privacy and security testing and
certification of a Health IT Module
required by § 170.550(h)(3)(iii), (v), (vii),
and (viii). We had previously identified
this error in guidance,66 and have now
codified the correction to
§ 170.550(h)(3)(iii), (v), (vii), and (viii)
in regulation.
2. Amendments
We proposed to revise § 170.550(h) to
remove the ‘‘amendments’’ criterion’s
application to certain non-applicable
clinical criteria including: ‘‘Drug-drug,
drug-allergy interaction checks for
computerized provider order entry
(CPOE)’’ in § 170.315(a)(4); ‘‘clinical
decision support (CDS)’’ in
§ 170.315(a)(9); ‘‘drug-formulary and
preferred drug list checks’’ in
§ 170.315(a)(10); and ‘‘patient-specific
education resources’’ in § 170.315(a)(13)
(84 FR 7454). The ‘‘amendments’’
certification criterion § 170.315(d)(4) is
not necessarily indicated for health IT
capabilities that may not have any
66 https://www.healthit.gov/test-method/
auditable-events-and-tamper-resistance.
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
patient data for which a request for an
amendment would be relevant.
Comments. One commenter expressed
support of the proposals under section
V (‘‘Modifications of the ONC Health IT
Certification Program’’) of the Proposed
Rule as a whole. However, we received
no comments specific to this proposal.
Response. We have finalized the
proposal with modifications. Health IT
Modules presented for certification to
these criteria do not have to
demonstrate the capabilities required by
the revised 2015 Edition ‘‘amendments’’
certification criterion (§ 170.315(d)(4)),
unless the Health IT Module is
presented for certification to another
criterion that requires certification to
the 2015 Edition ‘‘amendments’’
criterion under the privacy and security
(P&S) certification framework. We note
that, because we have not finalized our
proposal to remove the ‘‘drug-formulary
and preferred drug list checks’’ criterion
in § 170.315(a)(10) and the ‘‘patientspecific education’’ criterion in
§ 170.315(a)(13), but to only permit
ONC–ACBs to issue certificates for these
criteria until January 1, 2022, we have
not removed references to these criteria
from the exemption in § 170.550(h) at
this time. This clarification has already
been incorporated into sub-regulatory
guidance,67 and is now codified in
regulation.
3. View, Download, and Transmit to 3rd
Party
We proposed to remove
§ 170.315(e)(1)(ii)(B), which includes a
cross-reference to § 170.315(d)(2)
indicating that a Health IT Module may
demonstrate compliance with active
history log requirements if it is also
certified to § 170.315(d)(2) (84 FR 7454).
Comments. One commenter expressed
support of the proposals under section
V (‘‘Modifications of the ONC Health IT
Certification Program’’) of the Proposed
Rule as a whole. However, we received
no comments specific to this proposal.
Response. We thank commenters for
their support and have finalized the
proposal to remove
§ 170.315(e)(1)(ii)(B), which includes a
cross-reference to § 170.315(d)(2). As
noted in the Proposed Rule (84 FR
7454), this cross-reference indicates that
a Health IT Module may demonstrate
compliance with activity history log
requirements if it is also certified to the
2015 Edition ‘‘auditable events and
67 https://www.healthit.gov/test-method/drugdrug-drug-allergy-interaction-checks-cpoe; https://
www.healthit.gov/test-method/clinical-decisionsupport-cds; https://www.healthit.gov/test-method/
drug-formulary-and-preferred-drug-list-checks; and
https://www.healthit.gov/test-method/patientspecific-education-resources.
PO 00000
Frm 00069
Fmt 4701
Sfmt 4700
25709
tamper-resistance’’ certification
criterion (§ 170.315(d)(2)). However, we
no longer require testing of activity
history log when certifying for
§ 170.315(d)(2). Therefore, this crossreference is no longer applicable to meet
certification requirements for the
updated 2015 Edition ‘‘view, download,
and transmit to 3rd party’’ certification
criterion (§ 170.315(e)(1)) activity
history log requirements. Consequently,
we have finalized our proposal to
remove § 170.315(e)(1)(ii)(B).
4. Integrating Revised and New
Certification Criteria Into the 2015
Edition Privacy and Security
Certification Framework
We proposed to require the new
certification criteria (§ 170.315(d)(12)
and (d)(13)) to apply to all § 170.315
certification criteria (84 FR 7454).
Therefore, given these and the other
modifications discussed above, we
proposed to revise the P&S Certification
Framework as shown in Table 1 of the
Proposed Rule (84 FR 7455), noting that
the P&S Certification Framework when
finalized could differ depending on
finalization of proposals in section
III.B.4 of the Proposed Rule (84 FR 7436
and 7437) to remove certain 2015
Edition certification criteria.
Comments. One commenter expressed
support of the proposals under section
V (‘‘Modifications of the ONC Health IT
Certification Program’’) of the Proposed
Rule as a whole. However, we received
no comments specific to this proposal.
Response. We thank the commenter
for their input regarding our proposals
under section V (‘‘Modifications of the
ONC Health IT Certification Program’’)
of the Proposed Rule. We have adopted
the revisions as proposed with
modifications. As noted in section
IV.B.8.a, we have also adopted both
proposed privacy and security
transparency attestation criteria
(§ 170.315(d)(12) and (d)(13)) with
minor modifications. We have applied
§ 170.315(d)(12) and (d)(13) to all
certification criteria across the P&S
Certification Framework. Table 2 shows
the final updated P&S Certification
Framework, which includes all changes
including the removal of certain 2015
Edition certification criteria as finalized
in section III.B.4 of this final rule. We
updated the P&S Certification
Framework to reflect other changes
made throughout this final rule. The
privacy and security certification
criteria applicable to a Health IT
Module presented for certification is
based on the other capabilities included
in the Health IT Module and for which
certification is sought (80 FR 62705). In
this final rule, we have determined that
E:\FR\FM\01MYR3.SGM
01MYR3
25710
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
§ 170.315(b)(10) and, consistent with the
rationale provided in the 2015 Edition
final rule, (g)(1) through (6) are exempt
from the P&S Certification Framework
due to the capabilities included in these
criteria, which do not implicate privacy
and security concerns (80 FR 62707).
We have revised § 170.550(h) of this
final rule to reflect these clarifications.
We also corrected Table 2 to accurately
reflect the regulatory text at
§ 170.315(a)(3), (a)(14), and (a)(15).
Sections 170.315(a)(3), (a)(14), and
(a)(15), though included in the
regulatory text, were erroneously
deleted in the Proposed 2015 Edition
Privacy and Security Certification
Framework table and we corrected it in
Table 2.
TABLE 2—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 ‘‘approach 1’’ column
If the Health IT Module includes
capabilities for certification listed
under:
Approach 1
Approach 2
§ 170.315(a)(1) through (3), (5), (12),
(14), and (15).
§ 170.315(d)(1) (authentication, access control, and
authorization), (d)(2) (auditable events and tamper resistance), (d)(3) (audit reports), (d)(4)
(amendments), (d)(5) (automatic log-off), (d)(6)
(emergency access), (d)(7) (end-user device
encryption) (d)(12) (encrypt authentication credentials) (d)(13) (multi-factor authentication).
For each applicable P&S certification criterion not
certified using Approach 1, the health IT developer submits system documentation that is sufficiently detailed to enable integration such that
the Health IT Module has implemented service
interfaces for each applicable P&S certification
criterion that enable the Health IT Module to access external services necessary to meet the requirements of the P&S certification criterion.
§ 170.315(a)(4), (9), (10), and (13) ...
§ 170.315(d)(1) through (d)(3), (d)(5) through (d)(7),
(d)(12), and (d)(13).
§ 170.315(d)(1) through (d)(3), (d)(5) through (d)(8)
(integrity), (d)(12), and (d)(13).
§ 170.315(d)(1) through (d)(3) and (d)(5), (d)(12),
and (d)(13) *.
§ 170.315(d)(1) through (d)(3), (d)(5), (d)(7), (d)(9)
(trusted connection), (d)(12), and (d)(13).
§ 170.315(d)(1) through (d)(3), (d)(5), (d)(9),
(d)(12), and (d)(13) *.
§ 170.315(d)(1) through (d)(3), (d)(7), (d)(12), and
(d)(13).
§ 170.315(d)(1) and (d)(9); (d)(2) or (d)(10) (auditing actions on health information), (d)(12), and
(d)(13).
§ 170.315(d)(1) through (d)(3), (d)(12), and (d)(13) *.
§ 170.315(b)(1) through (3) and (6)
through (9).
§ 170.315(c) .......................................
§ 170.315(e)(1) ..................................
§ 170.315(e)(2) and (3) .....................
§ 170.315(f) ........................................
§ 170.315(g)(7) through (g)(10) .........
§ 170.315(h) .......................................
An ONC–ACB must ensure that a Health IT Module presented for certification to any of the certification criteria that fall into each regulatory
text ‘‘first level paragraph’’ category of § 170.315 (e.g., § 170.315(a)) identified in Table 2 is certified to either Approach 1 (technically demonstrate) or Approach 2 (system documentation).
In order to be issued a certification, a Health IT Module would only need to be tested once to each applicable privacy and security criterion
identified as part of Approach 1 or Approach 2 so long as the health IT developer attests that such privacy and security capabilities apply to the
full scope of capabilities included in the requested certification, except for the certification of a Health IT Module to § 170.315(e)(1) ‘‘view,
download, and transmit to 3rd party.’’ For this criterion, a Health IT Module must be separately tested to § 170.315(d)(9) because of the specific
capabilities for secure electronic transmission included in the criterion.
* § 170.315(d)(2)(i)(C) is not required if the scope of the Health IT Module does not include end-user device encryption features.
B. Principles of Proper Conduct for
ONC–ACBs
1. Records Retention
We proposed to revise the records
retention requirement in § 170.523(g) to
include the ‘‘life of the edition’’ as well
as three years after the retirement of an
edition related to the certification of
Complete EHRs and Health IT Modules
(84 FR 7456). We also proposed to
clarify that HHS has the ability to access
certification records for the ‘‘life of the
edition,’’ which begins with the
codification of an edition of certification
criteria in the Code of Federal
Regulations through a minimum of three
years from the effective date of the final
rule that removes the applicable edition
from the Code of Federal Regulations
(CFR), not solely during the three-year
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
period after removal from the CFR (84
FR 7456).
Comments. Several commenters
expressed support for ONC’s proposal to
revise the records retention
requirement. Another commenter
requested that ONC provide a separate
posting or notice that lists the dates
specific to when the ‘‘life of the edition’’
starts and dates specific to when the
‘‘life of the edition’’ and the minimum
period of three years from the effective
date that removes the applicable edition
end.
Response. We thank commenters for
their input and have finalized this
revision as proposed. Because the ‘‘life
of the edition’’ begins with the
codification of an edition of certification
criteria in the CFR and ends on the
effective date of the final rule that
removes the applicable edition from the
PO 00000
Frm 00070
Fmt 4701
Sfmt 4700
CFR, the start and end dates for the ‘‘life
of the edition’’ are published in the
Federal Register in the rulemaking
actions that finalize them. The period of
three years beyond the ‘‘life of the
edition’’ begins on the effective date of
the final rule that removes the
applicable edition from the CFR, thus
the three-year period after removal from
the CFR continues through three full
calendar years following that date. For
example, if the effective date of a
hypothetical final rule removing an
edition from the CFR were July 1, 2025,
then the three year period following the
end of the life of this hypothetical
edition would be June 30, 2028. We
anticipate continuing to work with
ONC–ACBs to provide guidance and
information resources as necessary or
appropriate to promote successful
adherence to all Principles of Proper
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
Conduct (PoPC) applicable to their
participation in the Program.
2. Conformance Methods for
Certification Criteria
The PoPC in § 170.523(h) specified
that ONC–ACBs may only certify health
IT that has been tested by ONC–ATLs
using tools and test procedures
approved by the National Coordinator.
We proposed to revise the PoPC in
§ 170.523(h) in three ways (84 FR 7456).
First, we proposed to revise this PoPC
to additionally permit ONC–ACBs to
certify Health IT Modules that the ONC–
ACB has evaluated for conformance
with certification criteria without first
passing through an ONC–ATL.
However, we proposed that such
methods to determine conformity must
first be approved by the National
Coordinator.
Second, we proposed to revise the
PoPC to clarify that certifications can
only be issued to Health IT Modules and
not Complete EHRs. We proposed to
remove the 2014 Edition from the CFR
(see section III.B.2 of this preamble) and
Complete EHR certifications are no
longer available for certification to the
2015 Edition (80 FR 62608; 79 FR
54443). We also proposed to remove the
provision that permits the use of test
results from National Voluntary
Laboratory Accreditation Program
(NVLAP)-accredited testing laboratories
under the Program because the
regulatory transition period from
NVLAP-accredited testing laboratories
to ONC–ATLs has expired (81 FR
72447).
Third, we proposed to remove the
provision that permits the certification
of health IT previously certified to an
edition if the certification criterion or
criteria to which the Health IT
Module(s) was previously certified have
not been revised and no new
certification criteria are applicable
because the circumstances that this
provision seeks to address are no longer
feasible with certification to the 2015
Edition.
Comments. One commenter sought
clarification on whether the proposal to
remove references to § 170.545, which
includes the ability to maintain
Complete EHR certification, would
impact § 170.550(k), which requires
ONC–ACBs to accept requests for a
newer version of a previously certified
Health IT Module(s) to inherit the
certified status of the previously
certified Health IT Module(s) without
requiring the newer version to be
recertified. The commenter strongly
urged ONC to allow ONC–ACBs to grant
inherited certification status to updated
versions of certified technology.
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
Another commenter expressed support
for ONC’s proposal to revise the PoPC
to clarify that certifications can only be
issued to Health IT Modules and not
Complete EHRs. The commenter also
expressed support for ONC’s proposal to
remove the provision that permits the
certification of health IT previously
certified to an edition if the certification
criterion or criteria to which the Health
IT Module(s) was previously certified
have not been revised and no new
certification criteria are applicable
because the circumstances that this
provision seeks to address are no longer
feasible with certification to the 2015
Edition.
Response. We have finalized the
proposal to revise the PoPC in
§ 170.523(h). As noted in the Proposed
Rule, the ability to maintain Complete
EHR certification is only permitted with
health IT certified to the 2014 Edition
certification criteria (84 FR 7435).
Because this concept was not continued
in the 2015 Edition (84 FR 7456), we
proposed revisions to clarify that
Complete EHR certifications are no
longer available. We note that ONC–
ACBs have discretion, and processes in
place, to evaluate updates made to
certified health IT and assess the need
for additional testing. These ONC–ACB
processes allow for efficient certification
of upgraded version releases of
previously certified health IT while
ensuring its continued conformity with
certification criteria and standards to
which the prior version release of the
same Module(s) had been certified. We
have finalized this proposal.
Comments. Multiple commenters
expressed support for the use of
conformance methods approved by the
National Coordinator. One commenter
noted that the opportunity would enable
alternative testing methods and less
costly testing. Another commenter
noted that this proposal would reduce
burden for EHR developers and for
ONC–ATLs by leveraging certification
programs and alternative test methods
and specifically requested that ONC
consider a specific proprietary
certification related to e-prescribing
functionalities for potential approval.
While expressing appreciation for the
flexibility offered by the proposed
revision, one commenter expressed
concern about certifications based on
other ONC-approved conformance
methods that are not specifically
designed to test against the ONC criteria
and stressed the importance of assessing
conformance to technical standards
before being deployed to end users.
Another commenter questioned whether
the ONC–ACB would be permitted to do
all evaluation directly, thus eliminating
PO 00000
Frm 00071
Fmt 4701
Sfmt 4700
25711
the need for ONC–ATLs entirely. Two
commenters sought clarity from ONC as
to what metrics the National
Coordinator will use to approve a
conformance method. These
commenters also sought clarification on
ONC’s plan to reduce the risk of
developers seeking certification through
fraudulent means. The commenters
cited the example of two developers
who are currently operating under
corporate integrity agreements with the
HHS Office of the Inspector General due
to court cases brought against them in
relation to conduct including, but not
limited to, the process of seeking
certification.
Response. We thank commenters for
their feedback. We have finalized the
proposal to revise the PoPC in
§ 170.523(h) to permit a certification
decision to be based on an evaluation
conducted by the ONC–ACB for Health
IT Modules’ compliance with
certification criteria by use of
conformity methods approved by the
National Coordinator.
We note that all certification criteria
will continue to have some method of
holding developers responsible for
demonstrating conformity whether
through ONC–ATL testing, developer
self-declaration, or some other method
assessed and approved by the National
Coordinator. As noted in the Proposed
Rule (84 FR 7456), ONC acknowledges
that there is a broad spectrum of types
of evidence of conformance, from
laboratory testing with an ONC–ATL to
developer self-declaration. Some of
these types of evidence may be more
appropriate than others in specific
circumstances. Historically, it has been
proven that, in some circumstances, the
requirement for ONC–ATL testing has
presented more administrative burden
on health IT developers than benefits for
assessing conformity. For example,
under § 170.315(a)(5) demographics
certification criteria require only
documentation or a visual inspection,
and do not require testing by an ONC–
ATL. We note that industry
advancements have presented
opportunities for improved efficiency
for demonstrating conformity and this
flexibility will allow the Program to
advance as the state of the art for
demonstrating conformance evolves.
This flexibility addresses the current
Program construct limitation of ONC–
ACB certification only being permissible
for health IT that has been tested by an
ONC–ATL with ONC-approved test
procedures. In some instances, such as
developer self-declaration, there is no
testing required and thus bypassing the
ONC–ATL testing step reduces burden
and enables a more streamlined and
E:\FR\FM\01MYR3.SGM
01MYR3
25712
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
efficient process. By adopting this
flexibility, we may approve
conformance methods that rely solely
on ONC–ACB evaluation, and not ONC–
ATL testing, when appropriate.
We will follow the same process used
for alternative test methods (76 FR 1280)
for the submission of non-governmental
developed conformance methods to the
National Coordinator for approval. A
person or entity may submit a
conformance method to the National
Coordinator to be considered for
approval for use under the Program. The
submission should identify the
developer of the conformance method;
specify the certification criterion or
criteria that is/are addressed by the
conformance method; and explain how
the conformance method would
evaluate a Health IT Module’s or, if
applicable, other type of health IT’s,
compliance with the applicable
certification criterion or criteria. The
submission should also provide
information describing the process used
to develop the conformance method,
including any opportunity for the public
to comment on the conformance method
and the degree to which public
comments were considered. In
determining whether to approve a
conformance method for purposes of the
Program, the National Coordinator will
consider whether it is clearly traceable
to a certification criterion or criteria
adopted by the Secretary; whether it is
sufficiently comprehensive (i.e.,
assesses all required capabilities) for the
assessment of Health IT Modules’, or
other type of health IT’s, conformance to
the certification criterion or criteria
adopted by the Secretary; whether an
appropriate public comment process
was used during the development of the
conformance method; and any other
relevant factors. When the National
Coordinator has approved a
conformance method for purposes of the
Program, we will publish a notice of
availability in the Federal Register and
identify the approved conformance
method on the ONC website.
3. ONC–ACBs To Accept Test Results
From Any ONC–ATL in Good Standing
We proposed to add the PoPC for
ONC–ACBs in § 170.523(r) in order to
address business relationships between
ONC–ACBs and ONC–ATLs (84 FR
7456). To encourage market
competition, we proposed to require
ONC–ACBs to accept test results from
any ONC–ATL that is in good standing
under the Program and is compliant
with its ISO/IEC 17025 accreditation
requirements. However, if an ONC–ACB
has concerns about accepting test results
from a certain ONC–ATL, the ONC–ACB
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
would have an opportunity to explain
the potential issues to ONC and NVLAP,
and on a case-by-case basis, ONC could
consider the facts and make the final
determination.
Comments. Multiple commenters
expressed support for the proposed
requirement that ONC–ACBs must
accept test results from any ONC–ATL
in good standing. One commenter
expressed an opinion that this proposal
has value in ensuring the credibility of
the Program. Another commenter agreed
that this proposal would encourage
market competition and provide more
options to developers. One commenter
recommended that ONC–ATLs should
also be required to provide their results
to any ONC–ACB to which the
developer has chosen to present its
health IT for certification, stating that
this consistency across ONC–ACBs and
ONC–ATLs would ensure market
competition.
Response. We thank commenters for
their input. We have finalized the PoPC
for ONC–ACBs in § 170.523(r) as
proposed. While an ONC–ATL
attempting to inappropriately restrict
developers’ choice of ONC–ACBs to
those favored by the ONC–ATL would
not support appropriate competition, we
do not believe it would be practical to
mandate direct transmission of ONC–
ATL results to any ONC–ACB
designated by the developer, in part
because developers often do not initiate
engagement with an ONC–ACB until
after they have received and had a
chance to review their ONC–ATL
results. To date, we are not aware of
substantial evidence that the standard
practice of NVLAP-accredited testing
laboratories providing test results to the
client who engaged them to test their
Health IT Modules is not serving as a
sufficient safeguard against anticompetitive behavior on the part of
ONC–ATLs in relation to their client
developers’ selection of ONC–ACBs.
4. Mandatory Disclosures and
Certifications
We proposed to revise the PoPC in
§ 170.523(k) to remove
§ 170.523(k)(1)(ii)(B) because
certifications can only be issued to
Health IT Modules and not Complete
EHRs (84 FR 7456). We also proposed to
revise § 170.523(k)(1)(iii)(A) to broaden
the section beyond the Promoting
Interoperability (PI) Programs. We
proposed to revise the section to include
a detailed description of all known
material information concerning
additional types of costs or fees that a
user may be required to pay to
implement or use the Health IT
Module’s capabilities, whether to meet
PO 00000
Frm 00072
Fmt 4701
Sfmt 4700
provisions of HHS programs requiring
the use of certified health IT or to
achieve any other use within the scope
of the health IT’s certification.
We also proposed to remove the
provision in § 170.523(k)(3) that
requires a certification issued to a precoordinated, integrated bundle of Health
IT Modules to be treated the same as a
certification issued to a Complete EHR
for the purposes of § 170.523(k)(1),
except that the certification must also
indicate each Health IT Module that is
included in the bundle (84 FR 7457).
We proposed to revise § 170.523(k)(4)
to clarify that a certification issued to a
Health IT Module based solely on the
applicable certification criteria adopted
by the ONC Health IT Certification
Program must be separate and distinct
from any other certification(s) based on
other criteria or requirements (84 FR
7457).
We also proposed changes related to
transparency attestations and
disclosures of limitations in section
III.B.5 of the Proposed Rule preamble
(84 FR 7437 and 7438). Additionally, we
proposed other new PoPC for ONC–
ACBs as discussed in sections VII.B.5
(84 FR 7501) and VII.D (84 FR 7506 and
7507) of the Proposed Rule preamble.
Comments. Multiple commenters
expressed support for ONC’s proposal to
include a detailed description of all
known material information concerning
additional types of costs or fees that a
user may be required to pay to
implement or use the Health IT
Module’s capabilities—whether to meet
provisions of HHS programs requiring
the use of certified health IT or to
achieve any other use within the scope
of the health IT’s certification. One
commenter endorsed the transparency
that this proposal would provide, noting
that it would help providers budget for
their health IT, but also expressed
concern that requiring developers to
disclose how much they charge for a
particular functionality may be
impractical due to variations across
contracts and over time, or potentially
have unintended consequences on
market pricing. Multiple commenters
expressed support for our proposal to
remove subsection § 170.523(k)(1)(ii)(B).
One commenter expressed support for
ONC’s proposed revisions to
§ 170.523(k)(4). Another commenter was
supportive of the proposal to remove the
provision in § 170.523(k)(3).
Response. We thank commenters for
their support. We have finalized the
proposals, in their entirety, as proposed.
To clarify, the finalized revision in
§ 170.523(k) requires disclosure of a
detailed description of all known
material information concerning
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
additional types of costs or fees a user
may be required to incur or pay to
implement or use the Health IT
Module’s capabilities to achieve any use
within the scope of the health IT’s
certification. We emphasize that (unless
required elsewhere in CFR part 170) the
requirement is for a description of the
types of costs or fees, not predicted
amounts of these costs or fees across the
full array of probable implementation
circumstances or over time. Among
other considerations, we note that costs
required to achieve some particular uses
within the scope of some certifications
may be for third-party services outside
the control of the developer required to
disclose the detailed description.
C. Principles of Proper Conduct for
ONC–ATLs—Records Retention
We proposed to revise the records
retention requirement in § 170.524(f) to
include the ‘‘life of the edition’’ as well
as 3 years after the retirement of an
edition related to the testing of Health
IT Module(s) to an edition of
certification criteria (84 FR 7457). The
circumstances are the same as in section
V.B.1 of the Proposed Rule preamble, as
summarized above. Therefore, we
proposed the same revisions for ONC–
ATLs as we did for ONC–ACBs. We did
not receive any comments specific to
this proposed revision to the PoPC for
ONC–ATLs. In light of the absence of
comments, we have finalized the
revisions as proposed.
VI. Health IT for the Care Continuum
Health IT should help promote and
support patient care when and where it
is needed. This means health IT should
help support patient populations,
specialized care, transitions of care, and
practice settings across the care
continuum. In the Proposed Rule, we
provided a history of the many actions
we have taken since the inception of the
ONC Health IT Certification Program
through the Proposed Rule (84 FR 7457).
As stated in the Proposed Rule, section
4001(b)(i) of the Cures Act instructs the
National Coordinator to encourage,
keep, or recognize, through existing
authorities, the voluntary certification of
health IT under the Program for use in
medical specialties and sites of service
for which no such technology is
available or where more technological
advancement or integration is needed.
This provision of the Cures Act closely
aligns with our ongoing collaborative
efforts with both Federal partners and
stakeholders within the health care and
health IT community to encourage and
support the advancement of health IT
for a wide range of clinical settings.
These initiatives have included projects
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
related to clinical priorities beyond
those specifically included in the EHR
Incentive Programs (now called the
Promoting Interoperability Programs)
including efforts in public health,
behavioral health, and long-term and
post-acute care. We noted in the
Proposed Rule that these initiatives
often include the development of nonregulatory informational resources to
support the specific implementation
goal and align with the technical
specifications already available in the
Program for certification. To advance
these efforts, we also explained in the
Proposed Rule that we generally
consider a range of factors including:
Stakeholder input and identification of
clinical needs and clinical priorities, the
evolution and adoption of health IT
across the care continuum, the costs and
benefits associated with any policy or
implementation strategy related to care
settings and sites of service, and
potential regulatory burden and
compliance timelines. Our goal was
then and is now to support the
advancement of interoperable health IT
and to promote health IT functionality
in care and practice settings across the
care continuum (see 80 FR 62604). As
stated in the Proposed Rule (84 FR
7458), generally, our approach can be
summarized in three parts:
• First, we analyze existing
certification criteria to identify how
such criteria may be applicable for
medical specialties and sites of service.
• Second, we focus on the real-time
evaluation of existing and emerging
standards to determine applicability to
medical specialties and sites of service
as well as to the broader care
continuum, including the evaluation of
such standards for inclusion in the ONC
Interoperability Standards Advisory
(ISA).68
• Third, we may work in
collaboration with stakeholders to
support the development of
informational resources for medical
specialties and sites of service for which
we identify a need to advance the
effective implementation of certified
health IT.
We continue to believe this approach
is economical, flexible, and responsive
for both health care providers and the
health IT industry. It is also in
alignment with the provisions of section
4001(a) in the Cures Act related to
burden reduction and promoting
interoperability. We are committed to
continuing to work with stakeholders to
promote the adoption of health IT to
support medical specialties and sites of
service and to help ensure that
68 https://www.healthit.gov/isa/.
PO 00000
Frm 00073
Fmt 4701
Sfmt 4700
25713
providers have the tools they need (such
as access to essential health information
across care settings) to support patients
at the point of care.
A. Health IT for Pediatric Setting
Section 4001(b)(iii) of the Cures Act—
‘‘Health information technology for
pediatrics’’ requires:
• First, that the Secretary, in
consultation with relevant stakeholders,
shall make recommendations for the
voluntary certification of health IT for
use by pediatric health providers to
support the health care of children, and
• Second, that the Secretary shall
adopt certification criteria to support
the voluntary certification of health IT
for use by pediatric health providers to
support the health care of children.
In the Proposed Rule (84 FR 7458), we
described our approach to stakeholder
engagement, the analysis used to
develop the recommendations, the
specific 2015 Edition certification
criteria that support each
recommendation, and the voluntary
certification of health IT for use by
pediatric health providers to support the
health care of children.
Comments. We received several
comments requesting further
clarification on whether the pediatric
health IT recommendations will be
adopted as an independent certification
program and/or certification criteria
designated specifically for pediatric
care. One commenter recommended that
pediatric provisions should be
formalized over time within what they
refer to as the current pediatric program
and not as a separate program, and that
this future aligns with the 2015
Children’s EHR Format. One commenter
also sought clarification as whether
ONC intends for other government
agencies/programs such as CHIP, to
develop conditions of participation or
financial incentives around the
adoption of certification criteria
identified in this rulemaking. We also
received several comments stating that
since current EHRs have pediatric
capabilities, there is no need to specify
requirements in regulation, and that
there is no value in having EHRs
certified as ‘‘pediatric-friendly,’’ only
increased costs. We also received
several comments stating that our
approach reflects an attempt to retrofit
the needs of pediatric patients by using
adult requirements.
Response. We thank commenters for
their feedback. The comments we
received suggests a need for greater
clarity on our approach. We therefore
reiterate that we did not propose to
adopt care- or practice-specific
certification tracks, or additional
E:\FR\FM\01MYR3.SGM
01MYR3
25714
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
voluntary program(s), in parallel to the
existing voluntary ONC Health IT
Certification Program. In the Proposed
Rule, we reiterated our statements from
the 2015 Edition final rule, which
explained that we did not intend to
develop and issue separate regulatory
certification ‘‘paths’’ or ‘‘tracks’’ for
particular care or practice settings (e.g.,
a ‘‘long-term and post-acute care
(LTPAC) certification’’) because it
would be difficult to independently
construct such ‘‘paths’’ or ‘‘tracks’’ in a
manner that would align with other
relevant programs and specific
stakeholder needs. We further stated
that stakeholders had indicated that
separate certification pathways could
have unintended consequences related
to increasing burden on health care
providers and health IT developers. We
also stated that we would welcome the
opportunity to work with HHS agencies,
other agencies, and provider
associations in identifying the
appropriate functionality and
certification criteria in the Program to
support their stakeholders (80 FR
62704). In response to the comments
regarding our approach to implement
section 4001(b) of the Cures Act, we
clarify that the 2015 Edition
certification criteria identified for the
voluntary certification of health IT for
use by pediatric health providers are
agnostic to the age of the patient (with
the exception of the pediatric vital signs
in the USCDI). Therefore, we believe our
approach to fulfilling the Cures Act
requirement for pediatric health care
providers and settings, which involves
identifying existing, new, or revised
2015 Edition criteria—as applicable to
an identified clinical or interoperability
priority—is appropriate across patient
populations. We also note that our
authority is limited to implementing the
described requirements of the Cures Act
related to pediatric settings. We cannot
speak for the actions of other Federal
agencies, but would note once again that
we have taken a limited regulatory
approach to implementing the pediatric
provisions of the Cures Act.
Comments. We received multiple
comments requesting clarification on
the intended use and functionality of
the Certified Health IT Products List
(CHPL) for pediatric certification, such
as guidance on navigating the CHPL to
identify relevant products based on
pediatric care settings.
Response. We thank stakeholders for
their comments on the CHPL. We do not
intend to have a separate tag
functionality on the CHPL that
identifies a product specifically for
pediatric care. We did not propose, and
do not intend, for there to be a separate
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
certification pathway or a new ONC
certification designation called pediatric
certification. However, we recognize
that beyond certification and testing
there are certain implementation needs
that are important for pediatric care and
services. We agree with the
overwhelming prior feedback from
stakeholders stating that they should not
have to purchase separate products that
contain universally applicable
functionality, such as the ‘‘API
functionality’’ certification criteria. We
are exploring options for non-regulatory
informational resources on effective
implementation of health IT for use by
pediatric health providers to expand the
availability of health IT products
supporting the care of children.
Comments. We received comments
regarding how the approach for
voluntary certification of health IT for
use by pediatric health providers might
be applicable to other medical
specialties and use cases. One
commenter noted that the pediatric
experience is scalable and should be
extended to other disciplines. Another
commenter sought clarification if this
model could be used for broad
applicability to multiple medical
specialties such as pathologists.
Response. We thank these
commenters for identifying the
applicability of our approach to
pediatrics to other medical specialties.
We confirm that our approach for
advancing health IT can be used for
other use cases and medical specialties,
and welcome the opportunity to engage
with stakeholders representing a wide
range of medical specialties or sites of
service to provide insight into this
process and to inform stakeholder-led
efforts to improve clinically-relevant
health IT implementation across
specialties and settings of care.
1. Background and Stakeholder
Convening
Over the past ten years, a number of
initiatives have focused on the
availability and use of effective health
IT tools and resources for pediatric care.
These have included a number of
public-private partnerships including
efforts between HHS, State agencies,
and health systems for innovative
projects that range from care
coordination enterprise solutions to
immunization information systems and
to point of care solutions for specialty
needs. In order to learn from and build
upon these efforts, ONC has engaged
with stakeholders in both the public and
private sector including other Federal,
State and local government partners,
health care providers engaged in the
care of children, standards developing
PO 00000
Frm 00074
Fmt 4701
Sfmt 4700
organizations, charitable foundations
engaged in children’s health care
research, and health IT developers
supporting pediatric care settings. For
example, significant work has been
done by the Agency for Healthcare
Research and Quality (AHRQ), CMS, the
Health Resources and Services
Administration (HRSA), and
organizations around the Children’s
EHR Format (Children’s Format), which
is critical to any discussion of the
pediatric health IT landscape.69
The Children’s Format was authorized
by the 2009 Children’s Health Insurance
Program Reauthorization Act
(CHIPRA) 70 and developed by AHRQ in
close collaboration with CMS. It was
developed to bridge the gap between the
functionality present in most EHRs
currently available and the functionality
that could optimally support the care of
children. Specifically, the Children’s
Format provides information to EHR
system developers and others about
critical functionality and other
requirements that are helpful to include
in an EHR system to address health care
needs specific to the care of children.
The final version of the Children’s
Format, released in 2015, consists of 47
high priority functional requirements in
19 topic areas that focus on
improvements that would better support
the safety and quality of care delivered
to children. The Children’s Format was
intended as a starting point for
developers, users, and purchasers for
informing an approach for pediatric
voluntary certification. We refer to the
Voluntary Edition proposed rule for a
description of our prior discussion
around the Children’s Format (79 FR
10930).
In the summer of 2017, the American
Academy of Pediatrics (AAP) reviewed
the 2015 Children’s Format using a
robust analytical process and
engagement with their members. The
result was a prioritized list of eight
clinical priorities to support pediatric
health care (‘‘Priority List’’). In October
2017, we held a technical discussion
with stakeholders titled ‘‘Health IT for
Pediatrics’’ with the specific purpose of
obtaining input from an array of
stakeholders in an effort to draw
correlations between the pediatric
providers’ clinical priorities identified
in the Priority List with the detailed
69 Agency for Health Care Information and
Technology. Health Information Technology. https://
healthit.ahrq.gov/health-it-tools-and-resources/
childrens-electronic-health-record-ehr-format.
Accessed September, 2017.
70 Pub. L. 111–3, section 401 https://
healthit.ahrq.gov/sites/default/files/docs/citation/
children-ehr-format-enhancement-finalrecommendation-report-abridged.pdf.
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
technical requirements outlined in the
Children’s Format and the capabilities
and standards that could be included in
certified health IT. Through this
collaborative approach, the meeting
participants identified a set of priority
needs for health IT to support pediatric
care based upon those identified by the
Priority List and the primary correlation
to the Children’s Format.
2. Recommendations for the Voluntary
Certification of Health IT for Use in
Pediatric Care
To support the first part of section
4001(b) of the Cures Act, we considered
the historical efforts on the Children’s
Format, the input from stakeholders,
and our own technical analysis and
review of health IT capabilities and
standards to develop a set of
recommendations for voluntary
certification of health information
technology for use by pediatric health
providers to support the health care of
children. These include eight
recommendations related to the Priority
List:
• Recommendation 1: Use biometricspecific norms for growth curves and
support growth charts for children
• Recommendation 2: Compute
weight-based drug dosage
• Recommendation 3: Ability to
document all guardians and caregivers
• Recommendation 4: Segmented
access to information
• Recommendation 5: Synchronize
immunization histories with registries
• Recommendation 6: Age- and
weight- specific single-dose range
checking
• Recommendation 7: Transferrable
access authority
• Recommendation 8: Associate
maternal health information and
demographics with newborn
We also developed two additional
recommendations beyond the Priority
List, which relate to other items within
the Children’s Format that are
considered important to pediatric
stakeholders. These additional
recommendations, which may be
supported by certified health IT, are as
follows:
• Recommendation 9: Track
incomplete preventative care
opportunities
• Recommendation 10: Flag special
health care needs
In order to implement the second part
of section 4001(b) of the Cures Act for
the adoption of certification criteria to
support the voluntary certification of
health IT for use by pediatric health care
providers, we identified both the 2015
Edition certification criteria and the
new or revised certification criteria
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
proposed in the Proposed Rule that
support the 10 recommendations for the
voluntary certification of health IT for
use by pediatric health providers to
support the health care of children. In
the Proposed Rule (84 FR 7459), we
directed readers to the appendix of the
Proposed Rule for a set of technical
worksheets, which include a crosswalk
of the various criteria specifically
associated with each recommendation.
These worksheets outlined the
following information:
• The alignment of each
recommendation to the primary
Children’s Format 71 item identified by
stakeholders
• The alignment of each
recommendation to the 2015 Edition
certification criteria and the new or
revised criteria described in the
Proposed Rule
• Supplemental items from the
Children’s Format for each
recommendation and the related 2015
Edition certification criteria
We also sought comment on the
following:
1. Relevant gaps, barriers, safety
concerns, and resources (including
available best practices, activities, and
tools) that may impact or support
feasibility of the recommendation in
practice.
2. Effective use of health IT itself in
support of each recommendation as it
relates to provider training, establishing
workflows, and other related safety and
usability considerations.
3. If any of the 10 recommendations
should not be included in ONC’s final
recommendations for voluntary
certification of health IT for use by
pediatric health providers to support the
health care of children.
4. Any certification criteria from the
Program that is identified for the 10
recommendations that should not be
included to support the specific
recommendation.
Comments. We received many
comments asking for detailed guidance
and/or implementation specifications
post final rulemaking, with one
commenter noting that the majority of
recommendations require additional
capabilities beyond the scope of any
aligned existing or proposed
certification criteria. We also received
many comments providing
implementation recommendations
specific to the 10 ONC
recommendations for the voluntary
certification of health IT for use by
pediatric health providers such as
71 https://healthit.ahrq.gov/health-it-tools-andresources/childrens-electronic-health-record-ehrformat.
PO 00000
Frm 00075
Fmt 4701
Sfmt 4700
25715
adding in developmental activity
milestones, including what versions of
growth charts should be supported, and
including listings to clearly identify
medical home providers. Several
commenters also referenced concerns
regarding the feasibility of
implementing the content included as
part of the pediatric health IT technical
worksheet crosswalk analysis included
in the Proposed Rule appendix for
Recommendation 5 ‘‘Synchronize
immunization histories with registries.’’
In this regard, several commenters noted
that FHIR is not currently consistent
with CDC/AIRA standards or practices
for immunization data submission or
query/response, and that public health
is not currently funded to provide this
capability from IIS.
Response. We thank commenters for
their useful input regarding the
technical worksheets in the appendix
we included for the Proposed Rule. As
we stated in the Proposed Rule, these
comments, and the detailed insights
received through stakeholder outreach,
will inform the future development of a
non-binding informational guide or
informational resource to provide useful
information for health IT developers
and pediatric care providers seeking to
successfully implement these health IT
solutions in a clinical setting. To
facilitate adoption of the ten
recommendations, we are developing a
Pediatric Health IT Developer
Informational Resource and a Pediatric
Health IT Provider Informational
Resource to be available for respective
use in 2020. As such, we appreciate the
comments we received specific to
implementation recommendations and
will take them into account in the
support of the creation of non-regulatory
informational resources for health IT
developers and other stakeholders. We
plan to continue working with
stakeholders as we further develop and
consider technical and implementation
recommendations we have received
through solicited public comments, the
Health Information Technology
Advisory Committee (HITAC), and other
engagements. We also direct readers to
our ‘‘pediatrics health IT’’ web page
(www.healthIT.gov/pediatrics) for
information on future work pertaining
to health IT for pediatric care.
Comments. We received several
comments suggesting the use of
pediatric-focused clinicians and settings
to test EHR systems as part of these
provisions, specifically recommending
that we should require EHR developers
to use pediatric-focused scenarios and
mock pediatric patients when testing
functionality, as well as requiring the
E:\FR\FM\01MYR3.SGM
01MYR3
25716
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
inclusion of pediatric clinicians as part
of end-user testing.
Response. We thank commenters for
their input. We agree that it would be
beneficial for health IT developers to
include pediatric-focused testing of
their health IT especially with regards to
ensuring patient safety. We note that we
have established requirements for real
world testing that requires health IT
developers to real world test their health
IT for the types of setting(s) in which it
is intended for use (we refer readers to
section VII.B.5 for more information on
real world testing Condition and
Maintenance of Certification
requirements).
a. 2015 Edition Certification Criteria
In order to implement the second part
of section 4001(b) of the Cures Act to
adopt certification criteria to support
the voluntary certification of health IT
for use by pediatric health providers to
support the health care of children, we
identified the following already adopted
2015 Edition certification criteria in the
Proposed Rule that support the
recommendations. The already adopted
2015 Edition criteria are as follows:
• ‘‘API functionality’’ criteria
(§ 170.315(g)(7)–(g)(9)) which address
many of the challenges currently faced
by patients and by caregivers such as
parents or guardians accessing child’s
health information, including the
‘‘multiple portal’’ problem, by
potentially allowing individuals to
aggregate health information from
multiple sources in a web or mobile
application of their choice.
• ‘‘Care plan’’ criterion
(§ 170.315(b)(9)) which supports
pediatric care by facilitating the
documentation of electronic health
information in a structured format to
improve care coordination (80 FR 62648
and 62649).
• ‘‘Clinical decision support’’ (CDS)
criterion (§ 170.315(a)(9)) which
supports pediatric care by enabling
interventions based on the capture of
biometric data.
• ‘‘Common Clinical Data Set’’
(§ 170.315(b)(4) and § 170.315(b)(5))
which includes optional pediatric vital
sign data elements including as optional
the reference range/growth curve for
three pediatric vital signs—BMI percent
per LOINC identifiers for age per sex,
weight per length/sex, and head
occipital-frontal circumference for
children less than three years of age.
• ‘‘Data segmentation for privacy’’
send criterion and receive criterion
(§ 170.315(b)(7) and § 170.315(b)(8))
which provides the ability to: Create a
summary record that is tagged at the
document level as restricted and subject
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
to re-disclosure; receive a summary
record that is document-level tagged as
restricted; separate the document-level
tagged document from other documents
received; and view the restricted
document without having to incorporate
any of the data from the document.
• ‘‘Demographics’’ criterion
(§ 170.315(a)(5)) which supports
pediatric care through the capture of
values and value sets relevant for the
pediatric health care setting as well as
allowing for improved patient matching
which is a key challenge for pediatric
care.
• ‘‘Electronic Prescribing’’ criterion
(§ 170.315(b)(3)) which includes an
optional Structured and Codified Sig
Format, which has the capability to
exchange weight-based dosing
calculations within the NCPDP SCRIPT
10.6 standard and limits the ability to
prescribe all oral, liquid medications in
only metric standard units of mL (i.e.,
not cc) important for enabling safe
prescribing practices for children.
• ‘‘Family health history’’ criterion
(§ 170.315(a)(12)) which supports
pediatric care because it leverages
concepts or expressions for familial
conditions, which are especially
clinically relevant when caring for
children.
• ‘‘Patient health information
capture’’ criterion (§ 170.315(e)(3))
which supports providers’ ability to
accept health information from a patient
or authorized representative. This
criterion could support pediatric care
through documentation of decisionmaking authority of a patient
representative.
• ‘‘Social, psychological, and
behavioral data’’ criterion
(§ 170.315(a)(15)) which supports
integration of behavioral health data
into a child’s record across the care
continuum by enabling a user to record,
change, and access a patient’s social,
psychological, and behavioral data
based using SNOMED CT® and LOINC®
codes.
• ‘‘Transitions of care’’ criterion
(§ 170.315(b)(1)) which supports
structured transition of care summaries
and referral summaries that help ensure
the coordination and continuity of
health care as children transfer between
different clinicians at different health
care organizations or different levels of
care within the same health care
organization.
• ‘‘Transmission to immunization
registries’’ criterion (§ 170.315(f)(1))
which supports the safe and effective
provision of child health care through
immunizations and registry linkages.
This criterion also provides the ability
to request, access, and display the
PO 00000
Frm 00076
Fmt 4701
Sfmt 4700
evaluated immunization history and
forecast from an immunization registry
for a patient. Immunization forecasting
recommendations allow for providers to
access the most complete and up-to-date
information on a patient’s immunization
history to inform discussions about
what vaccines a patient may need based
on nationally recommended
immunization recommendations (80 FR
62662 through 62664).
• ‘‘View, download, and transmit to
3rd party’’ (VDT) criterion
(§ 170.315(e)(1)) which supports
transferrable access authority for the
pediatric health care setting and
provides the ability for patients (and
their authorized representatives) 72 to
view, download, and transmit their
health information to a 3rd party.
We noted in the Proposed Rule (84 FR
7460) that some of these criteria may be
updated based on proposals contained
in the Proposed Rule (see further
discussion below on new or revised
certification criteria); and stated that we
continue to believe that prior to any
such updates, technology that is
currently available and certified to these
2015 Edition criteria can make a
significant impact in supporting
providers engaged in the health care of
children. We invited readers to use the
technical worksheets in the appendix of
the Proposed Rule to inform their public
comment on the recommendations, the
inclusion of specific items from the
Children’s Format, and the identified
2015 Edition certification criteria as
they relate specifically to use cases for
pediatric care and sites of service.
b. New or Revised Certification Criteria
In order to implement the second part
of section 4001(b)(iii) of the Cures Act
to adopt certification criteria to support
the voluntary certification of health
information technology for use by
pediatric health providers to support the
health care of children, we also
identified new or revised 2015 Edition
certification criteria (and standards) in
the Proposed Rule (84 FR 7460) that
support the recommendations. These
proposed criteria and standards include:
• New API criterion (§ 170.315(g)(10))
which would serve to implement the
Cures Act requirement to permit health
information to be accessed, exchanged,
72 The VDT criterion includes a ‘‘patientauthorized representative’’ concept that aligns with
the use of the term under the EHR Incentive
Program. A ‘‘patient-authorized representative’’ is
defined as any individual to whom the patient has
granted access to their health information (see also
77 FR 13720). However, consent is not needed for
minors, for whom existing local, state, or Federal
law grants their parents or guardians access (see
also 77 FR 13720).
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
and used from APIs without special
effort.
• New ‘‘DS4P’’ criteria (two for C–
CDA ((§ 170.315(b)(12)) and
(§ 170.315(b)(13)) and one for FHIR
(§ 170.315(g)(11))) that would support a
more granular approach to privacy
tagging data for health information
exchange supported by either the C–
CDA or FHIR-based exchange standards.
• New electronic prescribing
certification criterion (§ 170.315(b)(11)),
which would support improved patient
safety and prescription accuracy,
workflow efficiencies, and increased
configurability of systems including
functionality that could support
pediatric medication management.
• USCDI (§ 170.213) and USCDIbased criteria which enables the
inclusion of pediatric vital sign data
elements, including the reference range/
scale or growth curve for BMI percentile
per age and sex, weight for age per
length and sex, and head occipitalfrontal circumference. Each of the new
or revised certification criteria and
standards are further described in other
sections of this final rule, including all
final actions related to the criteria (some
of which are described below in the
response to comments).
Comments. A majority of comments
received supported our
recommendations for the voluntary
certification of health IT for use by
pediatric health providers to support the
health care of children along with the
alignment with the Children’s Format
and 2015 Edition certification criteria.
Several commenters suggested that the
10 recommendations should only be the
first step and encouraged future
development of additional
recommendations using the Children’s
Format. Commenters were also pleased
with the 10 recommendations selected
by ONC from the Children’s Format
stating that they represent a strong,
positive step forward for improving
EHRs used in the care of children. Many
commenters stated that they support the
continued alignment with the 2015
Edition recommendations.
Response. We thank commenters for
their support and feedback. As such, we
have maintained the 10
recommendations for the voluntary
certification of health IT for use by
pediatric health providers to support the
health care of children. We have
finalized in this final rule the majority
of the aligned proposed new 2015
Edition certification criteria that support
the voluntary certification of health IT
for use by pediatric health providers,
with the exception of the proposed
criterion for ‘‘consent management’’ in
§ 170.315(g)(11) since we did not
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
finalize our proposal for the criterion in
this final rule. The functionality of the
proposed new ‘‘DS4P’’ criteria have
been incorporated into the already
adopted 2015 Edition DS4P criteria
DS4P-send (§ 170.315(b)(7)) and DS4Preceive (§ 170.315(b)(8)) now referred to
as ‘‘Security tags—Summary of Caresend’’ and ‘‘Security tags—Summary of
Care—receive,’’ respectively. The
functionality of the proposed new e-Rx
criterion was also incorporated in the
already adopted e-Rx criterion
(§ 170.315(b)(3)). Last, we have removed
the ‘‘Common Clinical Data Set’’
(§ 170.315(b)(4) and § 170.315(b)(5))
from the 2015 Edition in this final rule.
We note that we are aware that the
NCPDP SCRIPT Standard Version
2017071 Implementation Guide
contains a number of requirements
intended to improve accurate dosing
and pediatric patient safety. One such
requirement is the inclusion of the most
recent patient height and weight in the
Observation Segment on all new and
renewal prescriptions sent from the
prescriber to the pharmacy, along with
the date associated with these measures,
for all patients 18 years old and
younger. We are also aware of the
challenges that such a requirement may
pose on specific providers and under
certain circumstances where height and/
or weight is not required or applicable
for dosing of the product. We believe
additional work must be done on
refining this requirement, and will
continue to monitor standards and
industry advancements before
proposing such a requirement. At this
time, we recommend vital signs to be
included in all electronic prescriptions
for all patient populations when
available and where applicable.
The 10 recommendations and the
aligned 2015 Edition certification
criteria support the health IT needs of
pediatric care providers. We believe
further support can be provided through
non-regulatory informational resources.
These resources can help inform
technical and implementation
specifications for health IT developers
and products for use by pediatric health
providers to support the health care of
children. We also agree with
commenters that the 10
recommendations are a first step and
welcome input and collaboration from
the health IT industry and health care
providers to continue efforts to develop
and build a health IT infrastructure
supporting pediatric care and other
specialty care and sites of service across
the continuum.
PO 00000
Frm 00077
Fmt 4701
Sfmt 4700
25717
B. Health IT and Opioid Use Disorder
Prevention and Treatment—Request for
Information
We identified a need to explore ways
to advance health IT across the care
continuum to support efforts to fight the
opioid epidemic. For that purpose, in
the Proposed Rule, we included a
request for information (RFI) related to
health IT and opioid use disorder
prevention and treatment (84 FR 7461
through 7465). We received over 100
comments in responses to this RFI,
which included recommendations from
the HITAC. We appreciate the feedback
and recommendations provided by
commenters and the HITAC taskforce,
respectively. We plan to share this
feedback with appropriate Department
partners.
VII. Conditions and Maintenance of
Certification Requirements for Health
IT Developers
Section 4002 of the Cures Act
modifies section 3001(c)(5) of the Public
Health Service Act (PHSA) to require
the Secretary of HHS, through notice
and comment rulemaking, to establish
Conditions and Maintenance of
Certification requirements for the
Program. Specifically, health IT
developers or entities must adhere to
certain Conditions and Maintenance of
Certification requirements concerning
information blocking; appropriate
exchange, access, and use of electronic
health information; communications
regarding health IT; application
programming interfaces (APIs); real
world testing; attestations regarding
certain Conditions and Maintenance of
Certification requirements; and
submission of reporting criteria under
the EHR Reporting Program under
section 3009A(b) of the PHSA.
A. Implementation
To implement section 4002 of the
Cures Act, we proposed an approach
whereby the Conditions and
Maintenance of Certification
requirements express initial certification
requirements for health IT developers
and their certified Health IT Module(s)
as well as ongoing maintenance
requirements that must be met by both
health IT developers and their certified
Health IT Module(s) under the ONC
Health IT Certification Program
(Program). If these requirements are not
met, the health IT developer may no
longer be able to participate in the
Program and/or its certified health IT
may have its certification terminated.
We proposed to implement each
Condition of Certification requirement
with further specificity as it applies to
E:\FR\FM\01MYR3.SGM
01MYR3
25718
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
the Program. We also proposed to
establish Maintenance of Certification
requirements for certain Conditions of
Certification requirements as standalone
requirements. As we stated in the
Proposed Rule, this approach would
establish clear baseline technical and
behavior Conditions of Certification
requirements with evidence that the
Conditions of Certification requirements
are continually being met through the
Maintenance of Certification
requirements.
Comments. We received comments
expressing general support for the
concept of requiring Conditions and
Maintenance of Certification
requirements. Commenters stated that
these requirements are a step forward
toward promoting transparency,
improving usability, and achieving
interoperability of health IT. We also
received comments asserting that the
Conditions and Maintenance of
Certification requirements should only
apply to developers of certified health
IT.
Response. We thank commenters for
their support. We provide further details
on each of the Conditions and
Maintenance of Certification
requirements within their respective
subsections in this section of the final
rule. However, to clarify our approach
to the Conditions and Maintenance of
Certification requirements in response
to comments, the Conditions and
Maintenance of Certification
requirements, except for the
‘‘information blocking’’ and
‘‘assurances’’ Conditions and
Maintenance of Certification
requirements, apply only to actions and
behaviors of health IT developers
related to their certified health IT as
well as to the certified health IT itself.
For the ‘‘information blocking’’ and
‘‘assurances’’ Conditions and
Maintenance of Certification
requirements, consistent with the Cures
Act provisions and our implementation
of section 3022(a) (information
blocking) of the PHSA, a health IT
developer is also responsible to ensure
that all of its health IT and related
actions and behaviors do not constitute
information blocking or inhibit the
appropriate access, exchange, and use of
electronic health information (EHI). We
refer readers to section VIII of this
preamble for further discussion of the
information blocking regulations.
B. Provisions
1. Information Blocking
The Cures Act requires that a health
IT developer, as a Condition and
Maintenance of Certification
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
requirement under the Program, not take
any action that constitutes ‘‘information
blocking’’ as defined in section 3022(a)
of the PHSA (see 3001(c)(5)(D)(i) of the
PHSA). We proposed to establish this
Information Blocking Condition of
Certification in § 170.401. We proposed
that the Condition of Certification
would prohibit any health IT developer
who has at least one health IT product
certified under the Program from taking
any action that constitutes information
blocking as defined by section 3022(a)
of the PHSA and proposed in § 171.103.
We clarified in the Proposed Rule that
this proposed ‘‘information blocking’’
Condition of Certification and its
requirements would be substantive
requirements of the Program and would
rely on the definition of ‘‘information
blocking’’ established by section 3022(a)
of the PHSA and proposed in § 171.103
(84 FR 7465).
We received no comments specifically
about the Information Blocking
Condition of Certification and have
adopted the Condition of Certification
as proposed. We received many
comments regarding the information
blocking provision, and have responded
to those comments in the information
blocking discussion in section VIII of
this preamble. We also refer readers to
section VII.D of this final rule for
additional discussion of ONC’s
enforcement of this and other
Conditions and Maintenance of
Certification requirements.
2. Assurances
The Cures Act requires that a health
IT developer, as a Condition and
Maintenance of Certification
requirement under the Program, provide
assurances to the Secretary, unless for
legitimate purposes specified by the
Secretary, that it will not take any action
that constitutes information blocking as
defined in section 3022(a) of the PHSA,
or any other action that may inhibit the
appropriate exchange, access, and use of
electronic health information (EHI). We
proposed to implement this Condition
of Certification and accompanying
Maintenance of Certification
requirements in § 170.402. As a
Condition of Certification requirement,
a health IT developer must comply with
the Condition of Certification as recited
here and in the Cures Act. We discussed
in section VIII of the Proposed Rule the
proposed reasonable and necessary
activities specified by the Secretary,
which constitute the exceptions to the
information blocking definition.
We also proposed to establish more
specific Conditions and Maintenance of
Certification requirements for a health
IT developer to provide assurances that
PO 00000
Frm 00078
Fmt 4701
Sfmt 4700
it does not take any action that may
inhibit the appropriate exchange,
access, and use of EHI. These proposed
requirements serve to provide further
clarity under the Program as to how
health IT developers can provide such
broad assurances with more specific
actions.
Comments. Most commenters agreed
with the central premise of our proposal
to adopt the ‘‘assurances’’ Condition
and Maintenance of Certification
requirement, requiring that a health IT
developer provide certain assurances to
the Secretary, including that, unless
done for one of the ‘‘legitimate
purposes’’ specified by the Secretary, it
will not take any actions that constitutes
information blocking as defined in
section 3022(a) of the PHSA, or any
other action that may inhibit the
appropriate exchange, access, and use of
electronic health information (EHI).
Commenters stated that they support
ONC’s efforts to eliminate barriers that
result in information blocking. One
commenter stated that it is not clear
what constitutes ‘‘satisfactory to the
Secretary’’ as interpretations may
change from Secretary to Secretary, and
suggested removing the term
‘‘Secretary.’’
Response. We thank commenters for
their support. We have finalized our
proposal to adopt the ‘‘assurances’’
Condition and Maintenance of
Certification requirement subject to the
clarifications and revisions discussed
below. In response to the comment
recommending we remove the term
‘‘Secretary’’ as Secretaries may change
over time, it will not be removed as it
is in the authorizing Cures Act statutory
language. For clarification, future
Secretaries may establish changes to the
implementation of the Cures Act
‘‘assurances’’ Condition and
Maintenance of Certification
requirements through notice and
comment rulemaking, as has been done
with this rulemaking.
a. Full Compliance and Unrestricted
Implementation of Certification Criteria
Capabilities
We proposed, as a Condition of
Certification requirement, that a health
IT developer must ensure that its health
IT certified under the Program conforms
to the full scope of the certification
criteria to which its health IT is
certified. This has always been an
expectation of ONC and users of
certified health IT and, importantly, a
requirement of the Program. As stated in
the Proposed Rule, we believe that by
incorporating this expectation as an
explicit Condition of Certification
requirement under the Program, there
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
would be assurances, and
documentation via the ‘‘Attestations’’
Condition and Maintenance of
Certification requirements proposed in
§ 170.406, that all health IT developers
fully understand their responsibilities
under the Program, including not to take
any action with their certified health IT
that may inhibit the appropriate
exchange, access, and use of EHI. To
this point, certification criteria are
designed and issued so that certified
health IT can support interoperability
and the appropriate exchange, access,
and use of EHI.
We also proposed that, as a
complementary Condition of
Certification requirement, health IT
developers of certified health IT must
provide an assurance that they have
made certified capabilities available in
ways that enable them to be
implemented and used in production
environments for their intended
purposes. More specifically, developers
would be prohibited from taking any
action that could interfere with a user’s
ability to access or use certified
capabilities for any purpose within the
scope of the technology’s certification.
Such actions may inhibit the
appropriate access, exchange, or use of
EHI and are therefore contrary to this
proposed Condition of Certification
requirement. While such actions are
already prohibited under the Program
(80 FR 62711), making these existing
requirements that prohibit developers
from taking any action that could
interfere with a user’s ability to access
or use certified capabilities for any
purpose within the scope of the
technology’s certification explicit in this
Condition of Certification requirement
will ensure that health IT developers are
required to attest to them pursuant to
the Attestations Condition of
Certification requirement in § 170.406,
which will in turn provide additional
assurances to the Secretary that
developers of certified health IT support
and do not inhibit appropriate access,
exchange, or use of EHI.
As discussed at 84 FR 7466 in our
Proposed Rule, actions that would
violate this Condition of Certification
requirement include failing to fully
deploy or enable certified capabilities;
imposing limitations (including
restrictions) on the use of certified
capabilities once deployed; or requiring
subsequent developer assistance to
enable the use of certified capabilities,
contrary to the intended uses and
outcomes of those capabilities). The
Condition of Certification requirement
would also be violated were a developer
to refuse to provide documentation,
support, or other assistance reasonably
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
necessary to enable the use of certified
capabilities for their intended purposes.
More generally, any action that would
be likely to substantially impair the
ability of one or more users (or
prospective users) to implement or use
certified capabilities for any purpose
within the scope of applicable
certification criteria would be
prohibited by this Condition of
Certification requirement. Such actions
may include imposing limitations or
additional types of costs, especially if
these were not disclosed when a
customer purchased or licensed the
certified health IT.
Comments. We received a comment
recommending additional language to
allow health IT developers to be able to
provide an explanation of how their
software conforms to the certification
criteria requirements and how they
enable the appropriate exchange, access,
and use of EHI.
Response. We thank the commenter
for their input, but do not accept the
recommendation. Health IT must
comply with certification criteria as
specified in regulation. We also refer
readers to the ‘‘Attestations’’ Condition
of Certification requirement in this
section of the preamble for more
information regarding how we proposed
to provide flexibilities, including a
method for health IT developers to
indicate their compliance,
noncompliance, or the inapplicability of
each Condition and Maintenance of
Certification requirement as it applies to
all of their health IT certified under the
Program, as well as the flexibility to
specify noncompliance per certified
Health IT Module, if necessary. As such,
we have finalized the Full Compliance
and Unrestricted Implementation of
Certification Criteria Capabilities
Condition of Certification requirement
as proposed that a health IT developer
must ensure that its health IT certified
under the Program conforms to the full
scope of the certification criteria to
which its health IT is certified, and that
health IT developers would be
prohibited from taking any action that
could interfere with a user’s ability to
access or use certified capabilities for
any purpose within the scope of the
technology’s certification. We note that
because compliance with the
information blocking section of this
final rule (Part 171) is not required until
six months after the publication date of
the final rule, § 170.402(a)(1) also has a
six-month delayed compliance date.
Comments. A couple of commenters
requested clarification on whether
requiring subsequent developer
assistance to enable the use of certain
certified capabilities would be
PO 00000
Frm 00079
Fmt 4701
Sfmt 4700
25719
considered noncompliance with the
Condition of Certification requirement,
such as managed services, hosting,
connecting with exchange networks, or
outsourced arrangements under
agreement.
Response. We clarify that the purpose
of this Condition of Certification
requirement is to make certified
capabilities available in ways that
enable them to be implemented and
used in production environments for
their intended purposes. As stated
above, the Condition of Certification
requirement would be violated were a
developer to refuse to provide
documentation, support, or other
assistance reasonably necessary to
enable the use of certified capabilities
for their intended purposes (see 84 FR
7466). We do not believe that actions by
health IT developers to provide their
customers with education,
implementation, and connection
assistance to integrate certified
capabilities for their customers would
typically constitute actions that interfere
with a customer’s ability to use certified
capabilities for their intended purposes,
but in the absence of specific facts, we
cannot say that whether there are
scenarios that would result in the
assistance interfering with a user’s
ability to access or use certified
capabilities for any purpose within the
scope of the health IT’s certification. As
such, education and other assistance
may be offered, but care should be taken
to do so in a manner that minds the
Condition of Certification requirement
standards.
Comments. We received a comment
asking that health IT developers be
required to provide honest
communication and expert advice as
required by a user.
Response. We appreciate the
commenter’s suggestion regarding
honest communication and expert
advice. However, such a requirement
would not be consistent with this
Condition of Certification requirement,
which focuses on assurances that Health
IT developers did not take actions that
may inhibit the appropriate exchange,
access, and use of electronic health
information (EHI). We also believe it
would be difficult to enforce such a
requirement in terms of determining
what constitutes an ‘‘honest’’
communication and ‘‘expert advice.’’
b. Certification to the ‘‘Electronic Health
Information Export’’ Criterion
We proposed that a health IT
developer that produces and
electronically manages EHI must certify
their health IT to the 2015 Edition ‘‘EHI
export’’ criterion in § 170.315(b)(10). As
E:\FR\FM\01MYR3.SGM
01MYR3
25720
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
a Maintenance of Certification
requirement, we proposed that a health
IT developer that produces and
electronically manages EHI must
provide all of its customers of certified
health IT Modules with health IT
certified to the functionality included in
§ 170.315(b)(10) within 24 months of a
subsequent final rule’s effective date or
within 12 months of certification for a
health IT developer that never
previously certified health IT to the
2015 Edition, whichever is longer.
Consistent with these proposals, we also
proposed to amend § 170.550 to require
that ONC–ACBs certify health IT to the
proposed 2015 Edition ‘‘EHI export’’
certification criterion when the health
IT developer of the health IT Module
presented for certification produces and
electronically manages EHI. As
discussed in section IV.C.1 of the
Proposed Rule, the availability of the
capabilities in the ‘‘EHI export’’
certification criterion promote access,
exchange, and use of health information
to facilitate electronic access to single
patient and patient population health
information in cases such as a patient
requesting their information, or a health
care provider switching health IT
systems. As such, health IT developers
with health IT products that have health
IT Modules certified to the finalized
‘‘EHI export’’ certification requirement
must make this functionality available
to customers and provide assurances
that the developer is not taking actions
that constitute information blocking or
any other action that may inhibit the
appropriate exchange, access, and use of
health information. We discussed the
EHI export functionality in section
IV.B.4 of the Proposed Rule.
Comments. A couple of commenters
expressed their support for the
Condition of Certification requirement,
noting that certifying health IT to
§ 170.315(b)(10) would provide greater
EHI access to end users. Several
commenters requested extending the
implementation timeframe to 36 months
stating that more time is needed for
analysis, product development, and
testing, with an additional 12 months
for client adoption, testing, and training.
A couple of commenters supported the
24-month timeframe, but stated that
they did not support ONC dictating the
adoption schedule for providers, and
that the proposal does not consider the
efforts required from providers to plan
and execute effective implementation
and adoption. One commenter stated
that 24 months is not aggressive enough
and that the rule should prioritize
certain aspects of patient-directed
exchange and make these available in 12
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
months or less. Another commenter
suggested that we narrow the type of
health IT developer that must certify
health IT to § 170.315(b)(10), noting that
some Health IT Modules may manage
data produced by other Health IT
Modules, or received and incorporated
from other sources. We did not receive
any comments specific to our proposal
to amend § 170.550 to require that
ONC–ACBs certify health IT to the
proposed 2015 Edition ‘‘EHI export’’
criterion when the health IT developer
of the health IT Module presented for
certification produces and electronically
manages EHI.
Response. We thank the commenters
for their support. In response to
comments regarding scope of data
export under this criterion, we have
modified the proposed ‘‘EHI export’’
certification criterion and scope of data
export. In doing so, we have also revised
our Condition of Certification
requirement, which we have finalized in
§ 170.402(a)(4), that a health IT
developer of a certified Health IT
Module that is part of a health IT
product which electronically stores EHI
must certify to the certification criterion
in § 170.315(b)(10). Additionally, we
clarify that in attesting to § 170.406, a
health IT developer must attest
accurately in accordance with
§ 170.402(a)(4) and (b)(2) if the health IT
developer certified a Health IT
Module(s) that is part of a health IT
product which can store EHI. The
finalized criterion focuses on the Health
IT Module’s ability to export EHI for the
health IT product’s single and patient
population, which encompasses the EHI
that can be stored at the time of
certification by the product, of which
the Health IT Module is a part. To note,
we do not require developers to disclose
proprietary information about their
products. Also, as clarified above and in
§ 170.315(b)(10)(iii), we do not require
any specific standards for the export
format(s) used to support the export
functionality.
In regards to when health IT
developers must provide all of their
users of certified health IT with health
IT certified to the functionality included
in § 170.315(b)(10), we have removed
the proposed language ‘‘within 12
months of certification for a health IT
developer that never previously
certified health IT to the 2015 Edition,
whichever is longer.’’ Our intention was
to provide equity between existing and
new health IT developers. However, we
have concluded that new health IT
developers will not be at a disadvantage
to meet the same timeline considering
all health IT developers will be aware of
requirements necessary for certification
PO 00000
Frm 00080
Fmt 4701
Sfmt 4700
when this final rule is published. We
also acknowledge the concerns
expressed regarding the 24-month
timeframe and have extended the
compliance timeline to within 36
months of the final rule’s publication
date, as finalized in § 170.402(b)(2)(i).
With the narrowed scope of data export
for the criterion, we believe health IT
developers should be able to provide all
of their customers of Health IT Modules
certified to § 170.315(b)(10) with the
export functionality included in
§ 170.315(b)(10) within 36 months. We
have also finalized in § 170.402(b)(2)(ii)
that on and after 36 months from the
publication of this final rule, health IT
developers that must comply with the
requirements of § 170.402(a)(4) must
provide all of their customers of
certified health IT with health IT
certified to § 170.315(b)(10). From this
milestone forward, a health IT
developer’s participation in the
Certification Program obligates them to
provide the technical capabilities
expressed in § 170.315(b)(10) when they
provide such certified health IT to their
customers. We will monitor ongoing
compliance with this Condition and
Maintenance of Certification through a
variety of means including, but not
limited to, developer attestations
pursuant to § 170.406, health IT
developers real world testing plans,
response to user complaints, and ONC–
ACB surveillance activities.
Consistent with the above revisions
and in alignment with our proposal to
amend § 170.550, we have also amended
§ 170.550(g)(5) regarding Health IT
Module dependent criteria for
consistency with the requirements of
§ 170.402(a)(4) and (b)(2) when a Health
IT Module presented for certification is
part of a health IT product which can
store electronic health information. In
addition, we have amended
§ 170.550(m)(2) to only allow ONC–
ACBs to issue certifications to
§ 170.315(b)(6) until 36 months after the
publication date of this final rule. Thus,
ONC–ACBs may issue certificates for
either § 170.315(b)(6) or (b)(10) up until
36 months after the publication date of
this final rule, but on and after 36
months they may only issue certificates
for Health IT Modules in accordance
with § 170.315(b)(10). We note that
ONC–ACBs are required by their ISO/
IEC 17065 accreditation to have
processes in place to meet the
expectations and minimum
requirements of the Program. Thus,
ONC–ACBs are expected to have
processes in place in order to effectively
monitor these timeline requirements on
and after 36 months after the
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
publication of this rule, and to
additionally ensure that the health IT
developer attests accurately to
§ 170.402(a)(4) and (b)(2). Should a
developer fail to comply, the ONC–ACB
will follow its processes to institute
corrective action and report to ONC in
accordance with Program reporting
requirements in 45 CFR
170.523(f)(1)(xxii). In the event the
developer does not follow through with
the corrective action plan established
and approved with the ONC–ACB, the
ONC–ACB must alert ONC of the health
IT developer’s failure to comply with
the Conditions and Maintenance of
Certification requirements.
Comments. A commenter requested
ONC add functionality to the CHPL (or
in another format) that provides a list of
the start and end dates of each
previously certified Health IT Module.
Response. We appreciate this
suggestion and note that the CHPL
already lists certification dates for
certified Health IT Modules, including
the dates the Health IT Module was last
modified, decertified, or made inactive.
c. Records and Information Retention
We proposed that, as a Maintenance
of Certification requirement in
§ 170.402(b)(1), a health IT developer
must, for a period of 10 years beginning
from the date of certification, retain all
records and information necessary to
demonstrate initial and ongoing
compliance with the requirements of the
Program. In other words, records and
information should be retained starting
from the date a developer first certifies
health IT under the Program and applies
separately to each unique Health IT
Module (or Complete EHR, as
applicable) certified under the Program.
This retention of records is necessary to
verify health IT developer compliance
with Program requirements, including
certification criteria and Conditions and
Maintenance of Certification
requirements. As stated in the Proposed
Rule, 10 years is an appropriate period
of time given that many users of
certified health IT participate in various
CMS programs, as well as other
programs, that require similar periods of
records retention.
In an effort to reduce administrative
burden, we also proposed, that in
situations where applicable certification
criteria are removed from the Code of
Federal Regulations before the 10 years
have expired, records must only be kept
for 3 years from the date of removal for
those certification criteria and related
Program provisions unless that
timeframe would exceed the overall 10year retention period. This ‘‘3-year from
the date of removal’’ records retention
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
period also aligns with the records
retention requirements for ONC–ACBs
and ONC–ATLs under the Program.
We encouraged comment on these
proposals and whether the proposed
requirements can provide adequate
assurances that certified health IT
developers are demonstrating initial and
ongoing compliance with the
requirements of the Program; and
thereby ensuring that certified health IT
can support interoperability, and
appropriate exchange, access, and use of
EHI.
Comments. Some commenters
requested clarification on what records
and information are expected to be
maintained and how this is different
from the records ONC–ACBs and ONC–
ATLs retain. A couple commenters
requested clarification on when the
records and information retention
requirement would take effect. One
commenter requested clarification
regarding the role of health IT
developers that no longer maintain a
certified Health IT Module or have their
certification suspended. One commenter
recommended setting a retention period
for record keeping in the event that a
health IT developer removes a Health IT
Module from market to ensure that
potentially short lived Health IT
Modules would inadvertently not have
their documentation maintained.
Response. We have adopted our
proposal in § 170.402(b)(1) without
revisions. We continue to believe that
10 years is an appropriate period of time
given that many users of certified health
IT participate in various CMS programs,
as well as other programs, that require
similar periods of records retention. We
also finalized that in situations where
applicable certification criteria are
removed from the Code of Federal
Regulations, records must only be kept
for 3 years from the date of removal for
those certification criteria and related
Program provisions unless that
timeframe would exceed the overall 10year retention period. We clarify that
health IT developers are best situated to
determine what records and information
in their possession would demonstrate
their compliance with all of the relevant
Program requirements. We note that it is
our understanding that health IT
developers are already retaining the
majority of their records and
information for the purposes of ONC–
ACB surveillance and ONC direct
review under the Program. We also refer
readers to section VII.D of this final rule
preamble for additional discussion of
records necessary for the enforcement of
the Conditions and Maintenance of
Certification requirements. In regard to
the requested clarification for the role of
PO 00000
Frm 00081
Fmt 4701
Sfmt 4700
25721
health IT developers that no longer
maintain a certified Health IT Module or
have their certification suspended, a
health IT developer who does not have
any certified Health IT Modules within
the Program would no longer have any
obligation to retain records and
information for the purposes of the
Program. However, we note that it may
be in the health IT developer’s best
interest to retain their records and
information. For example, records may
be useful for health IT developers in any
potential investigation or enforcement
action taken outside of the ONC Health
IT Certification Program such as by the
HHS Office of the Inspector General
(e.g., information blocking) or the U.S.
Department of Justice (e.g., False Claims
Act).
d. Trusted Exchange Framework and the
Common Agreement—Request for
Information
In the Proposed Rule, we included a
Request for Information (RFI) as to
whether certain health IT developers
should be required to participate in the
Trusted Exchange Framework and
Common Agreement (TEFCA) as a
means of providing assurances to their
customers and ONC that they are not
taking actions that constitute
information blocking or any other action
that may inhibit the appropriate
exchange, access, and use of EHI. We
received 40 comments on this RFI. We
appreciate the input provided by
commenters and may consider them to
inform a future rulemaking.
3. Communications
The Cures Act requires that a health
IT developer, as a Condition and
Maintenance of Certification
requirement under the Program, does
not prohibit or restrict communication
regarding the following subjects:
• The usability of the health
information technology;
• The interoperability of the health
information technology;
• The security of the health
information technology;
• Relevant information regarding
users’ experiences when using the
health information technology;
• The business practices of
developers of health information
technology related to exchanging
electronic health information; and
• The manner in which a user of the
health information technology has used
such technology.
The Cures Act established the broad
communications protections delineated
above (referred to hereafter as
‘‘protected communications’’) and we
proposed in 84 FR 7467 to implement
E:\FR\FM\01MYR3.SGM
01MYR3
25722
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
this general prohibition against
developers imposing prohibitions and
restrictions on protected
communications in § 170.403.
We also recognized that there are
circumstances where it is both
legitimate and reasonable for developers
to limit the sharing of information about
their health IT. As such, we proposed to
allow developers to impose prohibitions
or restrictions on protected
communications in certain narrowly
defined circumstances. In order for a
prohibition or restriction on a protected
communication to be permitted, we
proposed in 84 FR 7467 that it must
pass a two-part test. First, the
communication that is being prohibited
or restricted must not fall within a class
of communications (hereafter referred to
as ‘‘communications with unqualified
protection’’) that is considered to always
be legitimate or reasonable—such as
communications required by law, made
to a government agency, or made to a
defined category of safety organizations.
Second, to be permitted, a developer’s
prohibition or restriction on
communications must also fall within a
category of communications (hereafter
referred to as ‘‘permitted prohibitions
and restrictions’’) for which it is both
legitimate and reasonable for a
developer to limit the sharing of
information about its health IT. This
would be because of the nature of the
relationship between the developer and
the communicator or because of the
nature of the information that is, or
could be, the subject of the
communication. We proposed that a
developer’s restriction or prohibition
that does not satisfy this two-part test
would contravene the Communications
Condition of Certification requirement.
We note that this two-part test strikes a
reasonable balance between the need to
promote open communication about
health IT and related business practices,
and the need to protect the legitimate
interests of health IT developers and
other entities.
Comments. The majority of public
comments we received supported the
proposed Communications Condition of
Certification requirements, with many
commenters expressing strong support.
Commenters stated that the proposed
requirements would enable better
communication that would improve
health IT and patient care. Some
commenters who supported the
proposed requirements sought
clarification or had specific concerns,
including regarding the proposed
deadlines for contract modification.
These matters are discussed in more
detail below. Additionally, a handful of
public comments strongly opposed the
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
proposed requirements, primarily based
on concerns regarding intellectual
property (IP).
Response. We appreciate the overall
strong support for the Communications
Condition of Certification requirements
as proposed and have finalized with
modifications in § 170.403. We also
recognize the need to provide
clarification regarding some aspects of
the requirements, including regarding
the protections available for IP that are
included in the Communications
Condition and Maintenance of
Certification requirements.
We emphasize that, under section
3001(c)(5) of the PHSA, participation in
the ONC Health IT Certification Program
(Program) is voluntary. In other words,
ONC cannot compel health IT
developers to participate in the Program
nor can ONC impose consequences (e.g.,
enforcement actions or penalties) on
health IT developers who choose not to
participate in the Program. The
requirements of the Program are much
like requirements for any other
voluntary contract or agreement an
entity would enter into with the Federal
Government. Through the Conditions
and Maintenance of Certification
requirements, we have essentially
offered developers terms for
participation in the Program that we
believe are appropriate based on: Our
statutory instruction and interpretation
of the Cures Act; the utility and
necessity of using intellectual property,
including screenshots, to communicate
issues with usability, user experience,
interoperability, security, or the way the
technology is used (and relatedly, the
real and substantial threat to public
health and safety resulting from
prohibitions and/or restrictions on the
communication of screenshots); and the
measured approach we have taken
throughout the Communications
Condition and Maintenance of
Certification requirements (which is
discussed in detail in this section).
Because the Program is voluntary,
developers have the option to agree to
the terms we have offered or to choose
not to participate in the Program. As
such, we believe our policies
concerning intellectual property,
including the use of screenshots, are
consistent with other laws and
regulations that govern terms for
voluntary contracts and agreements
with the Federal Government. Further,
we believe that the final provisions of
this Condition of Certification include
appropriate consideration of health IT
developers’ intellectual property rights.
We further discuss the various aspects
of the Communications Condition of
Certification requirements, as well as
PO 00000
Frm 00082
Fmt 4701
Sfmt 4700
the changes we have made to our
proposals, in more detail below.
a. Background and Purpose
The Communications Condition of
Certification requirements address
industry practices of certified health IT
developers that can severely limit the
ability and willingness of health IT
customers, users, researchers, and other
stakeholders to openly discuss and
share their experiences and other
relevant information about health IT
performance, including about the ability
of health IT to exchange health
information electronically. These
practices result in a lack of transparency
that can contribute to and exacerbate
patient safety risks, system security
vulnerabilities, and health IT
performance issues.
We explained in the Proposed Rule
that the challenges presented by health
IT developer actions that prohibit or
restrict communications have been
examined for some time. The problem
was identified in a 2012 report by the
Institute of Medicine of the National
Academies (IOM) entitled ‘‘Health IT
and Patient Safety: Building Safer
Systems for Better Care’’ 73 (IOM
Report). The IOM Report stated that
health care providers, researchers,
consumer groups, and other health IT
users lack information regarding the
functionality of health IT.74 The IOM
Report observed, relatedly, that many
developers restrict the information that
users can communicate about
developers’ health IT through
nondisclosure clauses, confidentiality
clauses, IP protections, hold-harmless
clauses, and other boilerplate contract
language.75 The report stressed the need
for health IT developers to enable the
free exchange of information regarding
the experience of using their health IT,
including the sharing of screenshots
relating to patient safety.76
Concerns have also been raised by
researchers studying health IT,77 who
emphasize that confidentiality and IP
provisions in contracts often place
broad and unclear limits on authorized
uses of information related to health IT,
73 IOM (Institute of Medicine), Health IT and
Patient Safety: Building Safer Systems for Better
Care (2012). Available at https://
www.nationalacademies.org/hmd/Reports/2011/
Health-IT-and-Patient-Safety-Building-SaferSystems-for-Better-Care.aspx.
74 Id. at 37.
75 Id. at 36, 128.
76 Id.
77 See Hardeep Singh, David C. Classen, and Dean
F. Sittig, Creating an Oversight Infrastructure for
Electronic Health Record-Related Patient Safety
Hazards, 7(4) Journal of Patient Safety 169 (2011).
Available at https://www.ncbi.nlm.nih.gov/pmc/
articles/PMC3677059/.
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
which in turn seriously impact the
ability of researchers to conduct and
publish their research.78
The issue of health IT developers
prohibiting or restricting
communications about health IT has
been the subject of a series of hearings
by the Senate Committee on Health,
Education, Labor and Pensions (HELP
Committee), starting in the spring of
2015. Senators on the HELP Committee
expressed serious concern regarding the
reported efforts of health IT developers
to restrict, by contract and other means,
communications regarding user
experience, including information
relevant to safety and interoperability.79
Developer actions that prohibit or
restrict communications about health IT
have also been the subject of
investigative reporting.80 A September
2015 report examined eleven contracts
between health systems and major
health IT developers and found that,
with one exception, all of the contracts
protected large amounts of information
from being disclosed, including
information related to safety and
performance issues.81
b. Condition of Certification
Requirements
i. Protected Communications and
Communicators
We proposed in 84 FR 7468 that the
protection afforded to communicators
under the requirements of the
Communications Condition of
Certification in § 170.403(a) would
apply irrespective of the form or
medium in which the communication is
made. We proposed in 84 FR 7468 that
developers must not prohibit or restrict
communications whether written, oral,
electronic, or by any other method if
they are protected, unless such
prohibition or restriction is otherwise
permitted by the requirements of this
Condition of Certification. Similarly, we
proposed that these Condition of
Certification requirements do not
impose any limit on the identity of the
communicators that are able to benefit
from the protection afforded, except that
employees and contractors of a health IT
developer may be treated differently
78 Kathy Kenyon, Overcoming Contractual
Barriers to EHR Research, Health Affairs Blog
(October 14, 2015). Available at https://healthaffairs.
org/blog/2015/10/14/overcoming-contractualbarriers-to-ehr-research/.
79 Senate HELP Committee Hearing at 13 and 27
(July 23, 2015), available at https://
www.help.senate.gov/hearings/achieving-thepromise-of-health-information-technologyinformation-blocking-and-potential-solutions.
80 D. Tahir, POLITICO Investigation: EHR gag
clauses exist—and, critics say, threaten safety,
Politico, August 27, 2015.
81 Id.
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
when making communications that are
not afforded unqualified protection
under § 170.403(a)(2)(i). For example,
we proposed that this Condition of
Certification’s requirements are not
limited to communications by health IT
customers (e.g., providers) who have
contracts with health IT developers.
Comments. Many commenters
addressed the scope of protected
communications in their comments.
Several commenters suggested that the
proposed scope of protected
communications was too broad. Other
commenters stated that the scope
should be clarified. One commenter
suggested that the scope of private
communications that can be shared
should be limited and that ONC should
require mutual consent for such
communications to be made public.
Response. We appreciate these
comments. The Cures Act identifies a
list of subject areas about which health
IT developers cannot prohibit or restrict
communications to meet the conditions
for certification. The terms we proposed
for the protected subject areas are taken
from the language in section 4002 of the
Cures Act and include:
• The usability of the health
information technology;
• The interoperability of the health
information technology;
• The security of the health
information technology;
• Relevant information regarding
users’ experiences when using the
health information technology;
• The business practices of
developers of health information
technology related to exchanging
electronic health information; and
• The manner in which a user of the
health information technology has used
such technology.
We continue to interpret the above
statutory terms broadly, but within the
limiting framework we proposed, which
includes a distinction between
communications entitled to unqualified
protections and those communications
not entitled to such protection. We
have, however, finalized some
provisions with further limiting and
clarifying language as well as provided
examples to improve understanding of
the provisions.
We decline to create a consent
requirement as part of the requirements
of this Condition of Certification
because such a requirement could
unnecessarily encumber vital
communications protected by the Cures
Act. As highlighted above, the
Communications Condition of
Certification requirements are intended
to enable unencumbered
communication about usability,
PO 00000
Frm 00083
Fmt 4701
Sfmt 4700
25723
interoperability, and other critical issues
with health IT, and a consent
requirement would chill the ability of
users of health IT to engage in that
communication as well as be contrary to
section 4002 of the Cures Act.
Comments. One commenter stated
that the Communications Condition of
Certification requirements should apply
only to certified health IT,
recommending that ONC clarify that the
use of ‘‘the health IT’’ refers only to the
developer’s health IT that is certified
under the ONC Health IT Certification
Program. The commenter stated that the
use of ‘‘the health IT’’ in the Cures Act
can only be reasonably interpreted as
referring to the health IT for which a
developer is seeking certification, not all
of the developer’s health IT. Another
commenter stated that other health IT,
such as billing systems, should be out
of scope of this requirement and noted
that to do otherwise would create a
regulatory imbalance between
developers of such health IT who also
offer certified health IT and those who
do not.
Response. We appreciate these
comments regarding restricting the
applicability of the Communications
Condition of Certification requirements
to certified health IT. We clarify that, as
with all of the Conditions of
Certification requirements, the
Communications Condition of
Certification requirements apply to
developers of health IT certified under
the Program and to the conduct of such
developers with respect to health IT
certified under the Program. By way of
example, if a developer had health IT
certified under the Program and also
had health IT that was not certified
under the Program, then only those
communications about the certified
health IT would be covered by the
Communications Condition of
Certification requirements.
Comments. We received one comment
requesting more specificity on the
definition of communicators covered by
the Communications Condition of
Certification requirements. The
commenter expressed concern that the
broad scope could impact the ability to
maintain confidentiality in traditional
business-to-business relationships.
Response. We appreciate this
comment and understand the concern
noted by the commenter. As stated in
the Proposed Rule and finalized in
§ 170.403, the Communications
Condition and Maintenance of
Certification requirements generally do
not impose any limit on the identity of
communicators that are able to benefit
from the protection afforded. We also
note that there are limited exceptions
E:\FR\FM\01MYR3.SGM
01MYR3
25724
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
where communications by certain
communicators can be restricted.
Specifically, as finalized in
§ 170.403(a)(2)(ii)(A), health IT
developers can place limited restrictions
on communications by employees and
contractors. We believe this will enable
traditional business-to-business
relationships to continue without undue
disruption, including allowing
implementation of non-disclosure
agreements or other contracts as
necessary to maintain confidentiality.
ii. Protected Subject Areas
Comments. We received several
comments requesting that we clarify
how the Communications Condition of
Certification requirements would apply
to communications regarding public
health reporting, including
communications made by public health
authorities.
Response. We emphasize that the
Cures Act identified a list of subject
areas about which we were required to
forbid developers from prohibiting or
restricting communications. Though
public health reporting was not
specifically covered by the Cures Act or
our proposed regulations, it may be that
certain public health communications
will fall within the categories
established by the statute. We also note
that one of the ‘‘communications with
unqualified protection’’ discussed later
in this section is for communicating
information about adverse events,
hazards, and other unsafe conditions to
government agencies, health care
accreditation organizations, and patient
safety organizations. Depending on the
specific communication in question, a
communication about public health
reporting or a communication made to
public health authorities could be a
communication that could not be
restricted in any way. We also
emphasize that, subject to limited
circumstances already discussed above,
we do not impose any limit on the
identity of the communicators that are
able to benefit from protections afforded
under the Communications Condition of
Certification requirements.
Communicators are broadly defined and
could include public health agencies
and authorities.
Comments. Several commenters had
concerns regarding how a developer
may address communications that
contain false claims or libelous
statements. Commenters discussed the
need to enable health IT developers to—
for example—refute false claims, deal
with anonymous claims, and restrict
certain communications (such as false
statements or communications protected
by attorney-client privilege). Some of
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
these comments emphasized that false
communications such as libel should
not be protected, nor should
communications sent by someone who
obtained them illegally, such as a
hacker. Some of the commenters
recommended adding a category of
communications that would never be
protected under the proposed
framework, and such communications
would not receive unqualified
protection or necessitate permitted
restrictions. This would allow a
developer to—for example—prohibit or
restrict communications that are false or
deceptive, would violate a law or court
order, or would result in a breach of
contract.
Response. We appreciate the concerns
expressed by commenters regarding
statements that may be false or
misleading. However, developers
already have legal means and remedies
available to them to address such
statements, and this rule does not
change that. For example, each State has
libel laws that address libelous or
defamatory statements and provide
remedies in situations where the
specific facts in a damaging statement
can be proven to be untrue. We believe
that such statements are best addressed
through those laws and that it is neither
prudent nor practical for ONC to use the
Program and the Communications
Condition of Certification requirements
to attempt to assess such statements and
make determinations as to their
veracity.
Further, we note that the
Communications Condition of
Certification requirements only provide
that such protected communications
cannot be restricted or prohibited. It is
up to the health IT developer whether
and how they choose to respond to the
protected communication once made.
Therefore, we clarify that it is not a
violation of the Communications
Condition of Certification requirements
for developers to respond to false or
unlawful comments under applicable
law, as they do now, and to pursue
litigation or any other available legal
remedy in response to any protected
communications that are covered by the
Communications Condition of
Certification. For example, it would not
be a violation of the Communications
Condition of Certification for a health IT
developer who restricts the
communication of screenshots as
permitted under § 170.403(a)(2)(ii)(D) to
pursue litigation for Copyright
infringement or violation of contract if
a ‘‘protected communication’’ disclosed
more screenshots than the developer’s
restriction allowed.
PO 00000
Frm 00084
Fmt 4701
Sfmt 4700
Comments. Several commenters
requested that ‘‘safety’’ be added as a
protected category or that ONC should
include in the final rule a specific ban
that prohibits any restrictions on
communications about health IT-related
patient safety. Additionally, several
commenters noted that ONC should
include specific reporting methods or
standards in the final rule to improve
safety reporting or add examples to help
encourage reporting of safety and
security issues. Several commenters also
requested that ONC develop protocols
for reporting safety issues, and one
commenter recommended ONC develop
a patient safety reporting system.
Response. In implementing the Cures
Act requirement that a health IT
developer, as a Condition of
Certification requirement under the
Program, not restrict communications
about health IT, we adhered to the list
of protected subject areas identified by
Congress in the Cures Act. Those subject
areas include communications about
‘‘usability,’’ ‘‘relevant information
regarding users’ experiences when using
the health information technology,’’ and
the ‘‘manner in which a user of the
health information technology has used
such technology.’’ We clarify that
patient safety issues related to an
interaction with the health IT could be
covered in one or more of those
categories. Additionally, we agree with
commenters that safety-related
communications should receive specific
protections, and we emphasize that the
communication of safety concerns is
also addressed as a protected
communication receiving ‘‘unqualified
protection.’’ In the section of this final
rule on ‘‘Communications with
Unqualified Protection,’’ and in
§ 170.403(a)(2)(i)(B), we state that
communicating information about
adverse events, hazards, and other
unsafe conditions to government
agencies, health care accreditation
organizations, and patient safety
organizations is a communication about
which a developer would be prohibited
from imposing any prohibition or
restriction.
(A) Usability of Health Information
Technology
The term ‘‘usability’’ is not defined in
the Cures Act, nor in any other relevant
statutory provisions. We proposed in 84
FR 7469 that the ‘‘usability’’ of health IT
be construed broadly to include both an
overall judgment on the ‘‘usability’’ of a
particular certified health IT product by
the user, as well as any factor that
contributes or may contribute to
usability. We proposed that the factors
of usability that could be the subject of
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
protected communications include, but
are not limited to, the following: The
user interface (e.g., what a user sees on
the screen, such as layout, controls,
graphics and navigational elements);
ease of use (e.g., how many clicks); how
the technology supports users’
workflows; the organization of
information; cognitive burden; cognitive
support; error tolerance; clinical
decision support; alerts; error handling;
customizability; use of templates;
mandatory data elements; the use of text
fields; and customer support.
Comments. One commenter stated
that ‘‘usability’’ is too broadly defined
and should relate more specifically to
judgments on the ease of use of the
health IT, rather than factors related to
usability.
Response. We do not believe that
‘‘usability’’ is inaccurately defined nor
too broadly defined. To define usability
in the Proposed Rule, we referenced the
NIST standard 82 as well as principles
recognized by the Healthcare
Information and Management Systems
Society (HIMSS). We also emphasized
that there are a multitude of factors that
contribute to any judgment about
‘‘usability,’’ including factors
contributing to the effectiveness,
efficiency, and performance of the
health IT. We have finalized the scope
of the protected subject area ‘‘usability
of its health IT’’ in § 170.403(a)(1)(i) as
proposed, providing that the ‘‘usability’’
of health IT be construed broadly to
include both an overall judgment on the
‘‘usability’’ of a particular certified
health IT product, as well as any of the
many factors that could contribute to
usability as described in the Proposed
Rule. We also note that communications
about the usability of health IT may
include communications about features
that are part of the certified health IT as
well as communications about what is
not in the certified health IT (e.g., the
absence of alerts or features that a user
believes would aid in usability or are
related to the other subject areas
identified by the Cures Act).
(B) Interoperability of Health
Information Technology
The Cures Act, as codified in section
3000(9) of the PHSA, provides a
definition of ‘‘interoperability’’ that
describes a type of health IT that
demonstrates the necessary capabilities
to be interoperable. For the purposes of
the Communications Condition of
Certification requirements, we proposed
that protected communications
regarding the ‘‘interoperability of health
IT’’ would include communications
about whether certified health IT and
associated developer business practices
meet the interoperability definition
described in section 3000(9) of the
PHSA, including communications about
aspects of the technology or developer
that fall short of the expectations found
in that definition. We stated that this
would include communications about
the interoperability capabilities of
health IT and the practices of a health
IT developer that may inhibit the access,
exchange, or use of EHI, including
information blocking. As previously
noted, Congress did not define the terms
used in the Communications Conditions
of Certification requirements in section
4002(a) of the Cures Act and codified in
section 3001(c)(5)(D)(iii) of the PHSA.
We believe that ‘‘interoperability’’ was
appropriately defined in the Proposed
Rule by using the interoperability
definition that is located elsewhere in
section 4003(a)(2) of the Cures Act and
codified in section 3000(9) of the PHSA.
We did not receive comments about
this aspect of the Proposed Rule, and we
have finalized the scope of the protected
subject area ‘‘interoperability of its
health IT’’ in § 170.403(a)(1)(ii) as
proposed above.
(C) Security of Health IT
The security of health IT is addressed
by the HIPAA Security Rule,83 which
establishes national standards to protect
individuals’ electronic protected health
information (ePHI) that is created,
received, maintained, or transmitted by
a covered entity or business associate
(as defined at 45 CFR 160.103). Covered
entities and business associates must
ensure the confidentiality, integrity, and
availability of all ePHI; protect against
any reasonably anticipated threats or
hazards to the security or integrity of
such information; and protect against
any reasonably anticipated uses or
disclosures of such information that are
not permitted or required under the
HIPAA Privacy Rule.84 The HIPAA
Security Rule requires health IT
developers, to the extent that they are
business associates of covered entities,
to implement appropriate
administrative, physical, and technical
safeguards to ensure the confidentiality,
integrity, and availability of ePHI.85 We
proposed in 84 FR 7469 that the matters
that fall within the topic of health IT
security should be broadly construed to
include any safeguards, whether or not
83 45
84 45
82 See
https://www.nist.gov/programs-projects/
health-it-usability.
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
CFR part 160 and subparts A and C of part
164.
CFR part 160 and subparts A and C of part
164.
85 Id.
PO 00000
Frm 00085
Fmt 4701
Sfmt 4700
25725
required by the HIPAA Security Rule,
that may be implemented (or not
implemented) by a developer to ensure
the confidentiality, integrity, and
availability of EHI (information that
includes ePHI), together with the
certified health IT’s performance
regarding security.
Comments. One commenter noted
that it is important that developers are
able to remove posts on a website or
forum that could compromise the
security of health IT and recommended
that ONC explicitly allow developers to
do so in the final rule.
Response. We recognize the
importance of protecting the security of
EHI and health IT. We also recognize
that our engagement with stakeholders,
as well as the language in section 4002
of the Cures Act, emphasize the strong
public interest in allowing
unencumbered communications
regarding the protected subject areas
and communications with unqualified
protection, which are discussed in more
detail below and in § 170.403(a)(2)(i).
We emphasize that developers may
respond to communications as allowed
under applicable law and may pursue
any appropriate legal remedy. Taking
these factors into consideration, we
decline at this time to explicitly allow
developers to restrict communications
regarding security as suggested by the
commenter.
Comments. One commenter requested
that ONC consider narrowing the
permitted communication of security
elements in § 170.403(a)(1)(iii) that
might be used to compromise a
particular certified health IT’s security,
for example restricting the sharing of
authentication credentials issued to a
customer or user to access a system
containing sensitive information such as
PHI.
Response. We do not believe it is
necessary in this final rule to narrow or
restrict the information that can be
communicated where security elements
are included in the communication. As
stated above, we believe there is a strong
public interest in allowing
unencumbered communications
regarding the protected subject areas
and communications with unqualified
protection. Further, assurances that
access credentials and PHI
communicated under these
circumstances will not be shared
inappropriately are addressed in the
HIPAA Security Rule and relevant State
laws, and this rule does not change
those protections.
Comments. One comment
recommended that the Communications
Condition of Certification requirements
should protect communication
E:\FR\FM\01MYR3.SGM
01MYR3
25726
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
regarding the overall security posture
that the health IT developer takes or
makes the user take, including
communications regarding a system
with known and longstanding issues or
bugs.
Response. We appreciate this
comment and clarify that
communications related to the overall
security posture taken by a health IT
developer would be within the subject
area of ‘‘security of its health IT,’’ and
thus would be protected
communications covered by the
Communications Condition of
Certification requirements. We have
finalized the scope of the protected
subject area ‘‘security of its health IT’’
in § 170.403(a)(1)(iii) as proposed.
(D) User Experiences
The phrases ‘‘relevant information
regarding users’ experiences when using
the health IT’’ and ‘‘user experience’’
are not defined in the Cures Act nor any
other relevant statutory provisions. We
proposed in 84 FR 7470 to afford the
term ‘‘user experience’’ its ordinary
meaning. To qualify as a ‘‘user
experience,’’ we proposed that the
experience would have to have been one
that is had by a user of health IT.
However, beyond this, we did not
propose to qualify the types of
experiences that would receive
protection under the Communications
Condition of Certification requirements
based on the ‘‘user experience’’ subject
area. To illustrate the breadth of
potential user experiences that would be
protected by the proposed
Communications Condition of
Certification requirements, we proposed
that communications about ‘‘relevant
information regarding users’
experiences when using the health IT’’
would encompass, for example,
communications and information about
a person or organization’s experience
acquiring, implementing, using, or
otherwise interacting with the health IT.
We also proposed that this would
include experiences associated with the
use of the health IT in the delivery of
health care, together with administrative
functions performed using the health IT.
We proposed that user experiences
would also include the experiences
associated with configuring and using
the technology throughout
implementation, training, and in
practice. Further, we proposed that user
experiences would include patients’ and
consumers’ user experiences with
consumer apps, patient portals, and
other consumer-facing technologies of
the health IT developer. We clarified
that a ‘‘relevant user experience’’ would
include any aspect of the health IT user
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
experience that could positively or
negatively impact the effectiveness or
performance of the health IT.
Comments. One commenter stated
that the most relevant aspect of a user’s
experience of a health IT system is
whether that experience resulted in
patient safety events and requested that
ONC specify patient safety events that
arise from the use, misuse, or failure of
health IT systems as ‘‘user experiences’’
that cannot be covered by gag orders.
Response. As previously noted in our
response to patient safety comments
above, we reiterate that a user
experience resulting in a patient safety
event would be covered under the
Communications Condition of
Certification requirements and that a
communication about such an
experience would be protected, subject
to other applicable laws. Further,
communications about ‘‘adverse events,
hazards, and other unsafe conditions to
government agencies, health care
accreditation organizations, and patient
safety organizations’’ receive
unqualified protection as described in
§ 170.403(a)(2)(i). We noted in the
Proposed Rule that the Patient Safety
and Quality Improvement Act of 2005
(PSQIA) provides for privilege and
confidentiality protections for
information that meets the definition of
patient safety work product (PSWP).
This means that PSWP may only be
disclosed as permitted by the PSQIA
and its implementing regulations. We
clarified that to the extent activities are
conducted in accordance with the
PSQIA, its implementing regulation,
and section 4005(c) of the Cures Act, no
such activities shall be construed as
constituting restrictions or prohibitions
that contravene this Condition of
Certification.
We believe that ‘‘user experience’’
was appropriately defined in the
Proposed Rule and have finalized the
scope of the protected subject area
‘‘relevant information regarding users’
experiences when using its health IT’’ in
§ 170.403(a)(1)(iv) as proposed, with the
clarification provided above regarding
patient safety events and to clarify that
any communications regarding
consumer-facing technologies would
need to be about certified consumerfacing technologies per our earlier
clarification about the scope of this
Condition of Certification being limited
to certified health IT.
(E) Manner in Which a User Has Used
Health IT
We proposed in 84 FR 7470 that
protected communications regarding the
‘‘manner in which a user has used
health IT’’ would encompass any
PO 00000
Frm 00086
Fmt 4701
Sfmt 4700
information related to how the health IT
has been used. We also proposed that
the terms used to describe the protected
subject areas should be construed
broadly. We noted in the Proposed Rule
that this subject area largely overlaps
with the matters covered under the
‘‘user experience’’ subject area but may
include additional perspectives or
details beyond those experienced by a
user of health IT. We proposed that the
types of information that would fall
within this subject area include but are
not limited to:
• Information about a work-around
implemented to overcome an issue in
the health IT;
• customizations built on top of core
health IT functionality;
• the specific conditions under which
a user used the health IT, such as
information about constraints imposed
on health IT functionality due to
implementation decisions; and
• information about the ways in
which health IT could not be used or
did not function as was represented by
the developer.
We did not receive comments on this
specific aspect of the Proposed Rule,
and we believe the Proposed Rule
appropriately outlined what would fall
within the subject matter of the manner
in which a user has used health IT. We
have finalized the scope of the protected
subject area ‘‘manner in which a user of
the health IT has used such technology’’
in § 170.403(a)(1)(vi) as proposed, with
the clarification that ‘‘used’’ refers to
any uses of the certified health IT by the
user and is not limited to uses that
involve direct patient care.
(F) Business Practices Related to
Exchange
We proposed in 84 FR 7470 that the
subject matter of ‘‘business practices of
developers of health IT related to
exchanging electronic health
information’’ should be broadly
construed to include developer policies
and practices that facilitate the
exchange of EHI and developer policies
and practices that impact the ability of
health IT to exchange health
information. We further proposed that
the exchange of EHI would encompass
the appropriate and timely sharing of
EHI.
We proposed that protected
communications would include, but
would not be limited to:
• The costs charged by a developer
for products or services that support the
exchange of EHI (e.g., interface costs,
API licensing fees and royalties,
maintenance and subscription fees,
transaction or usage-based costs for
exchanging information);
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
• the timeframes and terms on which
developers would or would not enable
connections and facilitate exchange
with other technologies, individuals, or
entities, including other health IT
developers, exchanges, and networks;
• the developer’s approach to
participation in health information
exchanges and/or networks;
• the developer’s licensing practices
and terms as it relates to making
available APIs and other aspects of its
technology that enable the development
and deployment of interoperable
products and services; and
• the developer’s approach to creating
interfaces with third-party products or
services, including whether connections
are treated as ‘‘one off’’ customizations,
or whether similar types of connections
can be implemented at a reduced cost.
Importantly, we further proposed in
84 FR 7470 that information regarding
‘‘business practices of developers of
health IT related to exchanging
electronic health information’’ would
include information about switching
costs imposed by a developer, as we are
aware that the cost of switching health
IT is a significant factor impacting
health care providers adopting the most
exchange-friendly health IT available.
Comments. One commenter stated
that our proposed ‘‘business practices’’
is too broadly defined and should relate
exclusively to interoperability elements
of certified health IT, rather than to
products and services that support
exchange.
Response. As discussed in the
Proposed Rule, we believe the term
‘‘business practices of developers of
health IT related to exchanging
electronic health information’’ should
be broadly construed consistent with
our interpretation of the Cures Act
language regarding the Communications
Condition of Certification requirements,
but limited to those business practices
that relate to the certified health IT as
clarified previously in this Condition
and Maintenance of Certification
section. A wide variety of business
practices could impact the exchange of
EHI, including developer business
strategies, pricing, and even fraudulent
behavior. As such, we have finalized in
§ 170.403(a)(1)(v) our proposal that such
business practices include developer
policies and practices that impact or
facilitate the exchange of EHI. They
could also include costs charged by a
developer not only specifically for
interoperability elements of the certified
health IT, but also for any products or
services that support the exchange of
EHI through the certified health IT. We
reiterate that business practices related
to exchange could include timeframes
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
and terms on which developers
facilitate exchange; the developer’s
approach to participating in health
information exchanges and/or networks;
the developer’s licensing practices and
terms as related to APIs and other
interoperable services; and the
developer’s approach to creating
interfaces with third-party services. As
proposed in 84 FR 7473, this
Communications Condition of
Certification requirement will also
apply to any communication concerning
a Program requirement (e.g., a Condition
or Maintenance of Certification
requirement) related to the exchange of
EHI or the information blocking
provision.
Comments. Several commenters had
concerns regarding communications
about prices and costs, with some
commenters asserting that such
communications should be protected
and some others asserting that
developers should be able to restrict
communications about prices and costs,
including switching costs. Additionally,
one commenter had concerns about
protecting communications regarding
timeframes and terms as well as
workarounds and customizations. One
commenter also recommended that ONC
seek guidance from the Antitrust
Division of the FTC regarding economic
impacts of regulating health IT
developer terms, prices, and timeframes.
Response. We continue to interpret
costs, information regarding timeframes
and terms, and information about health
IT workarounds and customizations as
protected communications under the
‘‘Business Practices Related to
Exchange’’ provision of this condition.
We believe that this type of information
is frequently relied upon and necessary
in order to optimize health IT for the
exchange of EHI. We emphasize that the
costs charged by a developer for
certified health IT or related services
that support the exchange of EHI are
significant factors that can impact the
adoption of interoperable certified
health IT and should be protected
communications. For example, pricing
could include prohibitive costs that
prevent or discourage customers from
using certified health IT to interact with
competing technologies. Likewise,
information regarding timeframes and
terms is the type of information
considered and relied upon in the
adoption of interoperable certified
health IT and is a protected
communication. We have also finalized
in § 170.403(a)(1)(vi) that information
about certified health IT workarounds
and customizations relates to important
aspects of how a user has used certified
health IT, including how the certified
PO 00000
Frm 00087
Fmt 4701
Sfmt 4700
25727
health IT can be used to achieve greater
interoperability, and is a protected
communication.
In response to the comments
recommending that we seek guidance
from the FTC, we note that we are not
regulating health IT developer terms,
prices, and timeframes under this
Communications Condition of
Certification requirements, and
therefore do not need to seek further
guidance. Rather, the Communications
Condition of Certification requirements
would protect communications about
health IT developer costs, terms, and
timeframes as described above and
ensure that such information could be
shared. We have finalized the scope of
the protected subject area ‘‘business
practices of developers of health IT
related to exchanging electronic health
information’’ in § 170.403(a)(1)(v) as
proposed.
iii. Meaning of ‘‘Prohibit or Restrict’’
The terms ‘‘prohibit’’ and ‘‘restrict’’
are not defined in the Cures Act, nor in
any other relevant statutory provisions.
We discussed in the Proposed Rule that
communications can be prohibited or
restricted through contractual terms or
agreements (e.g., non-disclosure
agreements or non-disparagement
clauses) as well as through conduct,
including punitive or retaliatory
business practices that are designed to
create powerful disincentives to
engaging in communications about
developers or their health IT. Therefore,
we proposed in 84 FR 7470 that the
Communications Condition of
Certification requirements would not be
limited to only formal prohibitions or
restrictions (such as by means of
contracts or agreements) and would
encompass any conduct by a developer
that would be likely to restrict a
communication or class of
communications protected by the
Communications Condition of
Certification requirements. We
explained that the conduct in question
must have some nexus to the making of
a protected communication or an
attempted or contemplated protected
communication.
(A) Prohibitions or Restrictions Arising
by Way of Contract
We explained in the Proposed Rule
that the principal way that health IT
developers can control the disclosure of
information about their health IT is
through contractual prohibitions or
restrictions. We noted that there are
different ways that contractual
prohibitions or restrictions arise. In
some instances, a contractual
prohibition or restriction will be
E:\FR\FM\01MYR3.SGM
01MYR3
25728
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
expressed, and the precise nature and
scope of the prohibition or restriction
will be explicit in the contract or
agreement. However, we also noted that
a contract may also impose prohibitions
or restrictions in less precise terms. We
stated that a contract does not need to
expressly prohibit or restrict a protected
communication in order to have the
effect of prohibiting or restricting that
protected communication. The use of
broad or vague language that obfuscates
the types of communications that can
and cannot be made may be treated as
a prohibition or restriction if it has the
effect of restricting legitimate
communications about health IT.
We stated that restrictions and
prohibitions found in contracts used by
developers to sell or license their health
IT can apply to customers directly and
can require that the customer ‘‘flowdown’’ obligations to the customer’s
employees, contractors, and other
individuals or entities that use or work
with the developer’s health IT. We
proposed that such contract provisions
would not comply with the
Communications Condition of
Certification requirements and would be
treated as prohibiting or restricting
protected communications. We noted
that prohibitions or restrictions on
communications can also be found in
separate nondisclosure agreements
(NDAs) that developers require their
customers—and in some instances the
users of the health IT or third-party
contractors—to enter into in order to
receive or access the health IT. We
proposed that such agreements are
covered by the Communications
Condition of Certification requirements.
We did not receive comments on this
specific aspect of the Proposed Rule and
have finalized our interpretation
proposed in FR 7471 regarding
prohibitions or restrictions arising by
way of contract as stated above.
(B) Prohibitions or Restrictions That
Arise by Way of Conduct
We proposed in 84 FR 7471 that
conduct that has the effect of
prohibiting or restricting a protected
communication would be subject to the
Communications Condition of
Certification requirements. We
emphasized that the conduct in
question must have some nexus to the
making of a protected communication or
an attempted or contemplated protected
communication. As such, developer
conduct that was alleged to be
intimidating, or health IT performance
that was perceived to be substandard,
would not, in and of itself, implicate the
Communications Condition of
Certification requirements unless there
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
was some nexus between the conduct or
performance issue and the making of (or
attempting or threatening to make) a
protected communication.
We did not receive comments on this
specific aspect of the Proposed Rule and
have finalized our interpretation
proposed in 84 FR 7471 regarding
prohibitions or restrictions arising by
way of conduct as stated above.
iv. Communications With Unqualified
Protection
We proposed in 84 FR 7472 a narrow
class of communications—consisting of
five specific types of communications—
that would receive unqualified
protection from developer prohibitions
or restrictions. With respect to
communications with unqualified
protection, a developer would be
prohibited from imposing any
prohibition or restriction. We proposed
that this narrow class of
communications warrants unqualified
protection because of the strength of the
public policy interest being advanced by
the class of the communication and/or
the sensitivity with which the identified
recipient treats, and implements
safeguards to protect the confidentiality
and security of, the information
received. We stated that a developer that
imposes a prohibition or restriction on
a communication with unqualified
protection would fail the first part of the
two-part test for allowable prohibitions
or restrictions, and as such would
contravene the Communications
Condition of Certification requirements.
Comments. One commenter
recommended adding language
specifying the types of entities that can
receive communications with
unqualified protection, noting that such
specificity would help ensure that these
communications go to the appropriate
entities so that they can be addressed
quickly. The commenter recommended
that provisions around reporting to
government entities should be limited to
United States government entities.
Response. We do not believe it is
necessary to further specify the types of
entities that can receive
communications with unqualified
protection. We intend for this protection
to cover a wide variety of organizations,
and further specifying the types of
entities that can receive such
communications, such as limiting
communication to only United States
government entities, would
unnecessarily limit the scope of this
protection and could be counter to the
public policy interest to advance the
ability of these communications to
occur unencumbered. We have finalized
in § 170.403(a)(2)(i) our proposal to
PO 00000
Frm 00088
Fmt 4701
Sfmt 4700
prohibit developers from imposing any
prohibition or restriction on
communications that fall into a narrow
class of communications—consisting of
the five specific types of
communications described below—that
would receive unqualified protection.
(A) Disclosures Required by Law
We proposed in 84 FR 7472 that
where a communication relates to
subject areas enumerated in proposed
§ 170.403(a)(1) and there are Federal,
State, or local laws that would require
the disclosure of information related to
health IT, developers must not prohibit
or restrict in any way protected
communications made in compliance
with those laws. We noted that we
expect most health IT contracts would
allow for, or not prohibit or restrict, any
communication or disclosure that is
required by law, such as responding to
a court or Congressional subpoena, or a
valid warrant presented by law
enforcement. We further proposed that
if required by law, a potential
communicator should not have to delay
any protected communication under the
Communications Condition of
Certification requirements.
We did not receive comments on this
aspect of the Proposed Rule and have
finalized in § 170.403(a)(2)(i)(A) our
approach regarding disclosures required
by law as proposed.
(B) Communicating Information About
Adverse Events, Hazards, and Other
Unsafe Conditions to Government
Agencies, Health Care Accreditation
Organizations, and Patient Safety
Organizations
We proposed in 84 FR 7472 that there
is an overwhelming interest in ensuring
that all communications about health IT
that are necessary to identify patient
safety risks, and to make health IT safer,
not be encumbered by prohibitions or
restrictions imposed by health IT
developers that may affect the extent or
timeliness of communications. In
addition to the public policy interest in
promoting uninhibited communications
about health IT safety, we proposed that
the recognized communication channels
for adverse events, hazards, and unsafe
conditions provide protections that help
ensure that any disclosures made are
appropriately handled and kept
confidential and secure. We proposed
that the class of recipients to which the
information can be communicated
under this specific category of
communications given unqualified
protection should provide health IT
developers with comfort that there is
little risk of such communications
prejudicing the developer’s IP rights.
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
We sought comment on whether the
unqualified protection afforded to
communications made to a patient
safety organization about adverse
events, hazards, and other unsafe
conditions should be limited.
Specifically, we sought comment on
whether the unqualified protection
should be limited by the nature of the
patient safety organization to which a
communication can be made, or the
nature of the communication that can
made.
Comments. Several commenters
stated that ONC should not place any
limits on the unqualified protection
afforded to communications made to
patient safety organizations about
adverse events, hazards, and other
unsafe conditions.
Response. We have finalized in
§ 170.403(a)(2)(i)(B) as proposed
regarding the unqualified protection
afforded to communications about
adverse events, hazards, and other
unsafe conditions that are made to
government agencies, health care
accreditation organizations, and patient
safety organizations. Additionally, we
placed no limits or qualifiers on such
communications, including those
communications made to patient safety
organizations.
(C) Communicating Information About
Cybersecurity Threats and Incidents to
Government Agencies
We proposed in 84 FR 7472 that if
health IT developers were to impose
prohibitions or restrictions on the
ability of any person or entity to
communicate information about
cybersecurity threats and incidents to
government agencies, such conduct
would not comply with the
Communications Condition of
Certification requirements.
We sought comment on whether it
would be reasonable to permit health IT
developers to impose limited
restrictions on communications about
security issues to safeguard the
confidentiality, integrity, and security of
EHI. In the Proposed Rule, we asked if,
for example, health IT developers
should be permitted to require that
health IT users notify the developer
about the existence of a security
vulnerability prior to, or simultaneously
with, any communication about the
issue to a government agency.
Comments. Some commenters stated
that users should never be required to
notify the developer when reporting
cybersecurity issues, as this would
impose a burden on the user and a
potential barrier to reporting. Other
commenters recommended that
developers should be allowed to require
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
users to notify them simultaneously or
prior to reporting such incidents, with
one comment noting that this would
enable developers to better address and
respond to security threats prior to the
knowledge of a threat becoming
widespread. Some commenters
recommended that ONC make it a
violation for developers to not share
cybersecurity vulnerabilities with
providers, and that ONC work with DHS
to mitigate issues around sharing such
vulnerabilities. One commenter
recommended changing the wording
regarding communicating cybersecurity
and security risks to include known
vulnerabilities and health IT defects.
Response. We strongly encourage
users of health IT to notify developers
as soon as possible when reporting
security incidents and issues. However,
it would not be appropriate to require
this practice, which would impose an
obligation on users of health IT that is
outside the scope of this rule. It would
also be outside the scope of this
condition to implement additional
requirements for developers regarding
the sharing of cybersecurity
vulnerabilities with health care
providers. To be clear, we expect
developers with Health IT Modules
certified under the Program to share
information about cybersecurity
vulnerabilities with health care
providers and other affected users as
soon as feasible, so that these affected
users can take appropriate steps to
mitigate the impact of these
vulnerabilities on the security of EHI
and other PII in the users’ systems.
Thus, we have finalized the
Communications Condition of
Certification requirements in
§ 170.403(a)(2)(i)(C) as proposed.
Developers must not place restrictions
on communications receiving
unqualified protections. We also clarify
that known vulnerabilities and health IT
defects would likely be considered
types of ‘‘adverse events, hazards, and
other unsafe conditions’’ that would
receive ‘‘unqualified protection,’’ and
thus a developer would not be able to
restrict a health IT user from
communicating about such issues in
communications receiving unqualified
protections under the Communications
Condition of Certification requirements
(see § 170.403(a)(2)(i) as finalized).
However, we note that in
communications not receiving
unqualified protection under the
Communications Condition of
Certification requirements, a security
vulnerability that is not already public
knowledge would be considered a nonuser-facing aspect of health IT, about
PO 00000
Frm 00089
Fmt 4701
Sfmt 4700
25729
which developers are permitted to
restrict communications (see
§ 170.403(a)(2)(ii)(B) as finalized). Last,
we note that we will continue to work
with our Federal partners to mitigate
and address cybersecurity threats and
incidents.
(D) Communicating Information About
Information Blocking and Other
Unlawful Practices to a Government
Agency
We proposed in 84 FR 7473 that the
public benefit associated with the
communication of information to
government agencies on information
blocking, or any other unlawful
practice, outweighs any concerns
developers might have about the
disclosure of information about their
health IT. We noted that reporting
information blocking, as well as other
unlawful practices, to a government
agency would not cause an undue threat
to a health IT developer’s IP.
Comments. We received several
comments regarding the lack of
whistleblower protections in the
Proposed Rule for individuals who
report information blocking or other
issues regarding certified health IT.
These comments discussed the need to
provide for whistleblower type
protections for individuals who
highlight information blocking
practices, as well as to identify them to
the appropriate authorities so that the
individual is not subject to retaliatory
action by the actor identified by the
whistleblower.
Response. We appreciate these
comments and agree that it is extremely
important for individuals to be able to
report information blocking and
violations of other Conditions of
Certification without fear of retaliation.
We note that the Communications
Condition of Certification requirements
provide protections against retaliation
and intimidation by developers with
respect to protected communications.
We discussed in the Proposed Rule that
the Communications Condition of
Certification requirements cover
communications that are prohibited or
restricted through contractual terms or
agreements (e.g., non-disclosure
agreements, non-disparagement clauses)
between the health IT developer, or
offeror of health IT, and the
communicator, as well as through
conduct, including punitive or
retaliatory business practices that are
designed to create powerful
disincentives to engaging in
communications about developers or
their health IT. We clarify, however,
that merely filing a lawsuit against the
communicator regarding the making of
E:\FR\FM\01MYR3.SGM
01MYR3
25730
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
a communication would not be
considered intimidating conduct in
violation of this Condition. Any such
determination would necessarily be
fact-specific, and the health IT
developer’s lawsuit would have to be
designed to intimidate a communicator
in order to prevent or discourage that
communicator from making a protected
communication, rather than be designed
to pursue a legitimate legal interest. We
believe that the proposed broad
interpretation of ‘‘prohibit’’ and
‘‘restrict’’ is appropriate given the
intention of the Cures Act, which placed
no limitations on the protection of
communications about the protected
subject areas. We finalized this
interpretation of ‘‘prohibit’’ and
‘‘restrict’’ proposed in 84 FR 7470 and
believe that the interpretation would
provide significant protections for
whistleblowers from retaliatory actions.
Thus, retaliatory actions by a developer
against a whistleblower would be in
violation of this provision. We also
emphasize that conduct by a developer
that may be perceived as intimidating or
punitive would not implicate the
Communications Condition of
Certification requirements unless that
conduct was specifically designed to
influence the making of a protected
communication. In other words,
punitive actions must have a nexus to
the making of a protected
communication, such as retaliation for
reporting of information blocking, in
order to violate the Communications
Condition of Certification requirements
in § 170.403(a)(1). Last, we refer readers
to the discussion of ‘‘complaints’’ under
the information blocking section of this
final rule, which details the
confidentiality provided to information
blocking complaints and complainants.
We have finalized the
Communications Condition of
Certification requirements in
§ 170.403(a)(2)(i)(D) as proposed.
(E) Communicating Information About a
Health IT Developer’s Failure To
Comply With a Condition of
Certification or Other Program
Requirement
We proposed in 84 FR 7473 that the
benefits to the public and to users of
health IT of communicating information
about a health IT developer’s failure to
comply with a Condition of Certification
requirement or other Program
requirement (45 CFR part 170) justify
prohibiting developers of health IT from
placing any restrictions on such
protected communications. We
explained that information regarding the
failure of certified health IT to meet any
Condition of Certification requirement
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
or other Program requirement is vital to
the effective performance and integrity
of the Program. Moreover, the failure of
a certified health IT to meet such
requirements could impact the
performance of the certified health IT
with respect to usability, safety, and
interoperability. We stated that it is
important to enable unencumbered
reporting of such information and that
such reporting is essential to the
transparency that section 4002 of the
Cures Act seeks to ensure. While the
current procedures for reporting issues
with certified health IT encourage
providers to contact developers in the
first instance to address certification
issues, we noted that users of health IT
should not hesitate to contact ONCAuthorized Certification Bodies (ONC–
ACBs), or ONC itself, if the developer
does not provide an appropriate
response, or the matter is of a nature
that should be immediately reported to
an ONC–ACB or to ONC.
We did not receive any comments on
this aspect of the Proposed Rule. In
consideration of the above, we have
finalized this provision in
§ 170.403(a)(2)(i)(E) as proposed.
v. Permitted Prohibitions and
Restrictions
We proposed in 84 FR 7473 that,
except for communications with
unqualified protection
(§ 170.403(a)(2)(i)), health IT developers
would be permitted to impose certain
narrow prohibitions and restrictions on
communications. Specifically, we
proposed that, with the exception of
communications with unqualified
protection, developers would be
permitted to prohibit or restrict the
following communications, subject to
certain conditions:
• Communications of their own
employees;
• Disclosure of non-user-facing
aspects of the software;
• Certain communications that would
infringe the developer’s or another
person’s IP rights;
• Publication of screenshots in
narrow circumstances; and
• Communications of information
that a person or entity knows only
because of their participation in
developer-led health IT development
and testing.
The proposed Communications
Condition of Certification requirements
delineated the circumstances under
which these types of prohibitions and
restrictions would be permitted,
including certain associated conditions
that developers would be required to
meet. We emphasized that any
prohibition or restriction not expressly
PO 00000
Frm 00090
Fmt 4701
Sfmt 4700
permitted would violate the
Communications Condition of
Certification requirements.
Additionally, we proposed that it would
be the developer’s burden to
demonstrate to the satisfaction of ONC
that the developer met all associated
requirements. Further, as an additional
safeguard, we proposed that where a
developer sought to avail itself of one of
the permitted types of prohibitions or
restrictions, the developer must ensure
that potential communicators are clearly
and explicitly notified about the
information and material that can be
communicated, and that which cannot.
We proposed this would mean that the
language of health IT contracts must be
precise and specific. We stressed that
contractual provisions or public
statements that support a permitted
prohibition or restriction on
communication should be specific about
the rights and obligations of the
potential communicator. We explained
that contract terms that are vague and
cannot be readily understood by a
reasonable health IT customer would
not benefit from the qualifications to
this Condition of Certification
requirement as outlined in the Proposed
Rule and below.
(A) Developer Employees and
Contractors
We recognized in the Proposed Rule
in 84 FR 7473 that health IT developer
employees, together with the entities
and individuals who are contracted by
health IT developers to deliver products
and/or services (such as consultants),
may be exposed to highly sensitive,
proprietary, and valuable information in
the course of performing their duties.
We also stated that we recognize that an
employer should have the ability to
determine how and when the
organization communicates information
to the public, and that employees owe
confidentiality obligations to their
employers. We noted that this would
similarly apply to contractors of a
developer. We proposed in 84 FR 7473
that on this basis, developers would be
permitted to impose prohibitions or
restrictions on the communications of
employees and contractors to the extent
that those communications fall outside
of the class of communications with
unqualified protection as discussed
above.
Comments. One commenter stated
that this provision should be clarified
and expanded to cover other third
parties with whom the health IT
developer shares its confidential
information, including subcontractors,
agents, auditors, suppliers, partners, cosellers, and re-sellers, as well as
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
potential relationships for which a
contract has not yet been signed in case
information is shared during a precontract evaluation stage.
Response. We reiterate that
‘‘developer employees and contractors’’
include health IT developer employees,
together with the entities and
individuals who are contracted by
health IT developers to deliver health IT
and/or services who may be exposed to
highly sensitive, proprietary, and
valuable information in the course of
performing their duties. This functional
description of employees and
contractors could include
subcontractors, agents, auditors,
suppliers, partners, co-sellers, and resellers, depending on the specific
relationship and circumstances. We
have finalized the proposed approach to
describing employees and contractors in
§ 170.403(a)(2)(ii)(A). We note that we
did not expand this description to
include ‘‘potential relationships’’
because such an addition would make
the description overly broad, and it is
unlikely that individuals who are not
yet under contract would be exposed to
highly sensitive, proprietary, and
valuable information.
Comments. We received one comment
that self-developers should not be
permitted to place restrictions on the
communications of their employees
who are using their certified health IT.
Response. We agree that selfdevelopers should not be allowed to
restrict the communications of users of
their certified health IT who are also
employees or contractors. We have
revised § 170.403(a)(2)(ii)(A) to clarify
that the limited prohibitions developers
may place on their employees or
contractors under the Communications
Condition of Certification requirements
cannot be placed on users of a selfdeveloper’s certified health IT who are
also employees or contractors of the
self-developer. For example, a large
health system with a self-developed
EHR cannot restrict a health care
provider, who is employed by that
health system and using that EHR to
provide services, from communicating
about the EHR as a user based on the
fact that the health care provider is also
an employee of the health system. We
note that the concept of ‘‘selfdeveloped’’ refers to a Complete EHR or
Health IT Module designed, created, or
modified by an entity that assumed the
total costs for testing and certification
and that will be the primary user of the
health IT (76 FR 1300).
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
(B) Non-User-Facing Aspects of Health
IT
We proposed in 84 FR 7474 that the
Communications Condition of
Certification requirements would permit
health IT developers to impose
prohibitions and restrictions on
communications to the extent necessary
to ensure that communications do not
disclose ‘‘non-user-facing aspects of
health IT.’’ We noted that, like all
permitted prohibitions, such
prohibitions and restrictions could only
be put in place by developers if there is
not an unqualified protection that
applies. We proposed in 84 FR 7474 that
a ‘‘non-user-facing aspect of health IT,’’
for the purpose of this Condition of
Certification, was an aspect of health IT
that is not a ‘‘user-facing aspect of
health IT.’’ We stated that ‘‘user-facing
aspects of health IT’’ would include the
design concepts and functionality that is
readily ascertainable from the health
IT’s user interface and screen display.
We stated that they did not include
those parts of the health IT that are not
exposed to persons running, using, or
observing the operation of the health IT
and that are not readily ascertainable
from the health IT’s user interface and
screen display, all of which would be
considered ‘‘non-user-facing’’ concepts.
We proposed in 84 FR 7474 that ‘‘nonuser-facing aspects of health IT’’ would
include source and object code, software
documentation, design specifications,
flowcharts, and file and data formats.
We welcomed comments on whether
these and other aspects of health IT
should or should not be treated as userfacing.
In the Proposed Rule, we noted that
the terminology of ‘‘non-user-facing
aspects of health IT’’ is not intended to
afford only health IT users with specific
protections against developer
prohibitions or restrictions on
communications and is agnostic as to
the identity of the communicator.
Comments. Some commenters
expressed concern regarding the broad
scope of ‘‘user-facing’’ and, by
extension, the scope of ‘‘non-userfacing.’’ One commenter asked for
clarification regarding the definition of
‘‘software documentation’’ with regards
to non-user-facing aspects of health IT
and suggested that it applies to
documentation that is for back-end
components, not documents for normalend use. Additionally, a couple of
comments stated that administrative
functions should not be considered
user-facing, including one comment that
the relevant users for the purpose of the
Communications Condition of
Certification requirements are ‘‘end’’
PO 00000
Frm 00091
Fmt 4701
Sfmt 4700
25731
users, thus the non-user-facing
provision should apply only to ‘‘nonend-user-facing’’ aspects of health IT.
Some commenters emphasized that
administrative portions of health IT
contain more insight into health IT
systems and that administrative
functions affect a limited number of
users and are not the types of
communications or subject matters
contemplated by the Cures Act. One
commenter stated that algorithms
should be considered non-user-facing.
Another commenter stated that ONC
should clarify the status of diagrams and
flowcharts.
Response. We do not see a necessary
or appreciable distinction between
‘‘users’’ and ‘‘end users,’’ as we have
focused on the aspects of the health IT
that are and are not subject to protected
communications under this Condition
of Certification. We also believe that
there could be unintended
consequences with the term ‘‘end user,’’
such as limiting certain users not
specified under the ‘‘permitted
prohibitions and restrictions’’ (e.g.,
developer employees and contractors)
from making protected communications.
Therefore, we believe ‘‘non-user-facing’’
best reflects the scope of the
communications about health IT we
seek to capture with these terms.
We reiterate that ‘‘non-user-facing
aspects of health IT’’ comprise those
aspects of the health IT that are not
readily apparent to someone interacting
with the health IT as a user of the health
IT, including source and object code,
certain software documentation, design
specifications, flowcharts, and file and
data formats. We clarify that ‘‘non-userfacing aspects of health IT’’ would also
include underlying software that is
utilized by the health IT in the
background and not directly by a user
of the health IT. For example, the
programming instructions for
proprietary APIs would be considered
non-user-facing because they are not
readily apparent to the individual users
of the health IT. In addition, underlying
database software that connects to
health IT and is used to store data
would be considered a non-user-facing
aspect of health IT because it serves data
to the health IT, not directly to a user.
We further clarify that algorithms
would be considered ‘‘non-user-facing
aspects of health IT’’ as they are not
readily apparent to persons using health
IT for the purpose for which it was
purchased or obtained. Thus,
communications regarding algorithms
(e.g., mathematical methods and logic)
could be restricted or prohibited, while
communications regarding the output of
the algorithm and how it is displayed in
E:\FR\FM\01MYR3.SGM
01MYR3
25732
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
a health IT system could not be
restricted as ‘‘non-user-facing aspects of
health IT.’’ Similarly, we also clarify
that certain ‘‘software documentation’’
that would be considered to be a nonuser-facing aspect of health IT would
include documentation for back-end
components, again because it is not
readily apparent to persons using health
IT.
Whether or not a communication
would be considered a ‘‘non-user-facing
aspects of health IT’’ would be based on
whether the communication involved
aspects of health IT that would be
evident to anyone running, using, or
observing the operation of the health IT
for the purpose for which it was
purchased or obtained. With respect to
administrative functions, where the
communication at issue relates to
aspects of the health IT that are not
observable by users of the health IT, it
would be considered ‘‘non-user-facing’’
for the purpose of this Condition of
Certification requirement. For example,
a communication regarding an input
process delay experienced by an
administrator of health IT that was
caused by the underlying database
software could be restricted if the
communication discussed the
underlying database software, which
would be considered a non-user-facing
aspect of the health IT. However, if the
communication discussed the user
screens and the delay experienced by
the administrator, which would be
considered user-facing aspects of health
IT, it could not be restricted. Similarly,
as long as diagrams or flowcharts do not
include aspects of the health IT that are
observable by users of the health IT, as
described above, they would be
considered communications about nonuser-facing aspects of health IT.
We have finalized in
§ 170.403(a)(2)(ii)(B) our proposed
approach to the scope of ‘‘non-userfacing aspects of health IT’’ with the
clarification provided above regarding
scope.
(C) Intellectual Property
We proposed in 84 FR 7474 that the
Communications Condition of
Certification requirements are not
intended to operate as a de facto license
for health IT users and others to act in
a way that might infringe the legitimate
IP rights of health IT developers or other
persons. Indeed, we proposed in 84 FR
7474 that health IT developers are
permitted to prohibit or restrict certain
communications that would infringe
their IP rights so long as the
communication in question is not a
communication with unqualified
protection. We proposed in 84 FR 7474
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
that any prohibition or restriction
imposed by a developer must be no
broader than legally permissible and
reasonably necessary to protect the
developer’s legitimate IP interests. We
also proposed in 84 FR 7474 that health
IT developers are not permitted to
prohibit or restrict, or purport to
prohibit or restrict, communications
that would be a ‘‘fair use’’ of any
copyright work comprised in the
developer’s health IT.86 ‘‘Fair use’’ is a
legal doctrine that allows for the
unlicensed use of copyright material in
certain circumstances, which could
include circumstances involving
criticism, commentary, news reporting,
and research.87
Comments. One commenter stated
that fair use should not override other
IP protections and stressed that relying
on fair use could lead to uncertainty
because it is determined on a case-bycase basis. Another commenter stated
that because the fair use doctrine can be
difficult to implement and can lead to
uncertain results, ONC should expand
the list of communications that would
be explicitly protected as fair use to
include news reporting, criticism,
parody, and communications for
educational purposes.
Response. We disagree with
commenters and believe that relying on
the ‘‘fair use’’ doctrine for determining
when a screenshot or other
communication cannot be restricted
should be allowed under the
Communications Condition of
Certification requirements. This
doctrine presents a framework of
analysis that is well-developed in case
law and thus can be interpreted and
applied consistently, even when
materials are not formally copyrighted.
Accordingly, we are retaining the
concept of ‘‘fair use’’ in the final
provision in § 170.403(a)(2)(ii)(C).
Developers and ONC will apply a fair
use test to copyrighted materials and, by
analogy, to materials that could be
copyrighted, to determine whether
developers may prohibit a
communication that would infringe on
IP rights.
The Communication Condition of
Certification requirements relate only to
protected communications, thus
developers can place restrictions on
communications about subject matters
outside of the protected
communications categories without
implicating the Communications
86 See 17 U.S.C. 107 (setting forth the four factors
required to evaluate a question of fair use under the
statutory framework).
87 See https://www.copyright.gov/fair-use/moreinfo.html for more information on fair use.
PO 00000
Frm 00092
Fmt 4701
Sfmt 4700
Condition of Certification requirements.
Also, as discussed earlier regarding
developer employees and contractors in
§ 170.403(a)(2)(ii)(A), developers may
restrict communications by their
employees, contractors, and consultants
without implicating the
Communications Condition of
Certification requirements, provided
they do not restrict communications
with unqualified protections. Further, as
described earlier regarding non-userfacing aspects of certified health IT in
§ 170.403(a)(2)(ii)(B), developers may
restrict communications that disclose
non-user-facing aspects of the
developer’s certified health IT, provided
they do not restrict communications
with unqualified protections. We
clarified in that section that screenshots
or videos depicting source code would
be considered communications of nonuser-facing aspects of health IT and
could be restricted under the
Communications Condition of
Certification requirements as long as
they did not receive unqualified
protection. We also clarify that this
Condition does not prohibit health IT
developers from enforcing their IP rights
and that a lawsuit filed by a health IT
developer in response to a protected
communication regarding infringement
of IP rights would not automatically be
considered intimidation or retaliation in
violation of this Condition.
As discussed later in the pre-market
testing and development section in
§ 170.403(a)(2)(ii)(E), developers can
place restrictions on communications
related to pre-market health IT
development and testing activities,
which could include IP protections,
provided they do not restrict
communications with unqualified
protections. Combined, these avenues
allow for protecting IP in ways that
would not implicate the
Communications Condition of
Certification requirements, thereby
allowing developers to take a number of
actions to protect and safeguard IP in
their certified health IT.
Comments. Several commenters
requested clarity regarding how the
proposed protections for IP would work.
One commenter stated that the rule
must allow developers to protect
legitimate IP interests and asked for
clarity on how ONC would determine
whether a developer’s restriction on the
communication of a screenshot was an
allowable protection of trade secrets or
an impermissible restriction of
protected communications. Several
other commenters, who generally
supported the Communications
Condition of Certification requirements,
requested clarification regarding how a
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
prohibition on communications that is
designed to protect IP can be applied.
Some commenters requested examples
of the types of communications that can
be restricted on the basis of IP and
clarification of the standard ONC will
use to determine what prohibitions are
permissible.
Response. We have finalized an
approach in § 170.403(a)(2)(ii)(C) that
allows developers to prohibit or restrict
communications that involve the use or
disclosure of intellectual property
existing in the developer’s health IT
(including third-party intellectual
property), provided that any prohibition
or restriction imposed by a developer
must be no broader than necessary to
protect the developer’s legitimate
intellectual property interests and
consistent with all other requirements
under the ‘‘permitted prohibitions and
restrictions’’ (§ 170.403(a)(2)(ii)) of this
section. As discussed above, a
restriction or prohibition would be
deemed broader than necessary and
inconsistent with the ‘‘permitted
prohibitions and restrictions’’
(§ 170.403(a)(2)(ii)) if it would restrict or
preclude a public display of a portion of
a work subject to copyright protection
(without regard to whether the
copyright is registered) that would
reasonably constitute a ‘‘fair use’’ of that
work.
Examples of the types of
communications that could be restricted
under the Communications Condition of
Certification requirements might
include a blog post describing a
customization of a developer’s health IT
that includes the source code of the
developer’s health IT or a written
review of an analytical feature of the
developer’s health IT that reveals the
algorithms used. However, as
mentioned above, the restriction must
be no broader than necessary to protect
the developer’s legitimate IP interests,
thus only the infringing portions of the
communications could be restricted.
Comments. One commenter
recommended that a health IT developer
must demonstrate that a communication
was specifically designed to copy or
steal a developer’s IP in order for the
developer to be allowed to prohibit the
communication as an infringement on
their IP rights.
Response. We appreciate this
comment, but decline to require that a
developer demonstrate that a
communication was designed to copy or
steal IP in order for the developer to
restrict the communication as one that
would infringe on IP rights. We believe
that the revised approach discussed
above provides appropriate balance
between protecting IP rights and
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
enabling protected communications and
do not believe that an ‘‘intent’’ element
would be necessary. We have finalized
the proposals regarding IP in
§ 170.403(a)(2)(ii)(C), as amended above.
(D) Faithful Reproductions of Health IT
Screenshots
We proposed in 84 FR 7475 that
health IT developers generally would
not be permitted to prohibit or restrict
communications that disclose
screenshots of the developer’s health IT.
We proposed that the reproduction of
screenshots in connection with the
making of a communication protected
by this Condition of Certification would
ordinarily represent a ‘‘fair use’’ of any
copyright subsisting in the screen
display, and developers should not
impose prohibitions or restrictions that
would limit that fair use.
Notwithstanding this, we proposed that
health IT developers would be allowed
to place certain restrictions of the
disclosure of screenshots as specified in
proposed § 170.403(a)(2)(ii)(D).
With respect to the limited allowable
restrictions on screenshots, we proposed
in 84 FR 7475 that developers would be
permitted to prevent communicators
from altering screenshots, other than to
annotate the screenshot or to resize it for
the purpose of publication. We also
proposed that health IT developers
could impose restrictions on the
disclosure of a screenshot on the basis
that it would infringe third-party IP
rights (on their behalf or as required by
license). However, to take advantage of
this exception, we proposed in 84 FR
7475 that the developer would need to
first put all potential communicators on
sufficient written notice of those parts of
the screen display that contain IP and
cannot be communicated, and would
still need to allow communicators to
communicate redacted versions of
screenshots that do not reproduce those
parts. Finally, we proposed in 84 FR
7475 that it would be reasonable for
developers to impose restrictions on the
communication of screenshots that
contain PHI, provided that developers
permit the communication of
screenshots that have been redacted to
conceal PHI, or where the relevant
individual’s consent or authorization
had been obtained.
We welcomed comments on whether
an appropriate balance had been struck
between protecting legitimate IP rights
of developers and ensuring that health
IT customers, users, researchers, and
other stakeholders who use and work
with health IT can openly discuss and
share their experiences and other
relevant information about the
performance of health IT.
PO 00000
Frm 00093
Fmt 4701
Sfmt 4700
25733
Comments. A large number of
commenters, particularly health care
providers, supported our proposals
regarding the communication of
screenshots, with several stressing how
helpful screenshots are when
communicating usability and safety
issues with health IT. One commenter
noted that communication of
screenshots can help different health
care systems understand whether a
proposed implementation of an EHR has
introduced safety-related challenges at
other locations, or help identify
solutions to common problems, such as
usability challenges. One other
commenter stated that there is nothing
novel displayed in health IT screenshots
that would need to be protected.
Response. We appreciate the many
positive comments on our proposals
regarding screenshots.
Comments. Commenters stated that
the scope of protected communications
as proposed should exclude disclosure
of the health IT itself, such as through
screenshots. The commenter stressed
that the Cures Act required that health
IT developers not restrict
communications about the certified
health IT with respect to specific topic
areas, while the Proposed Rule expands
that restriction to include
communication of the health IT itself.
One commenter noted that the Cures
Act does not mention screenshots and
they should not be included in the
Communications Condition of
Certification requirements.
Response. The Cures Act amended
title XXX of the PHSA to establish this
condition of certification, which applies
to ‘‘health information technology.’’
Title XXX of the PHSA was previously
added by the HITECH Act, which
included the definition of ‘‘health
information technology.’’ Section
3000(5) of the PHSA defines health
information technology to mean
hardware, software, integrated
technologies or related licenses, IP,
upgrades, or packaged solutions sold as
services that are designed for or support
the use by health care entities or
patients for the electronic creation,
maintenance, access, or exchange of
health information. We emphasize both
that this definition includes IP
associated with the health information
technology and that it applies to this
condition of certification as this
condition references communications
regarding health information
technology. We have also adopted this
definition in § 170.102.
We disagree with the commenters’
interpretation of the statutory provision.
The statutory provision focuses on
‘‘communications’’ regarding
E:\FR\FM\01MYR3.SGM
01MYR3
25734
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
enumerated aspects of the health IT.
Communications are not defined nor
limited in the Cures Act, and we
proposed to broadly define them.
Verbal, written, and visual, as well other
types of communications, are all
covered under the Cures Act. A
screenshot is a copy/picture of the user
interface of the health IT, or a ‘‘visual
communication’’ that is protected under
this condition of certification. We have
specifically defined ‘‘communication’’
for this section in § 170.403(c) to mean
any communication, irrespective of the
form or medium. The term includes
visual communications, such as
screenshots and video.
As we emphasized in the Proposed
Rule in 84 FR 7475, the sharing of
screenshots (with accompanying
annotation and/or explanatory prose) is
often a critical form of communication
of issues with health IT related to—for
example—usability, user experience,
interoperability, security, or the way the
technology is used. We believe
screenshots are uniquely helpful as a
form of visual communication that can
non-verbally illustrate the ‘‘user’s
experiences when using the health
information technology’’ and the
‘‘manner in which a user of the health
information technology has used such
technology’’ as they relate intrinsically
to both subject areas and capture those
user experiences immediately and
directly. Further, enabling screenshot
sharing can allow for clearer, more
immediate, and more precise
communication on these pertinent
issues, potentially helping a health
system avoid costly, or even deadly,
complications when implementing
health IT. It is also our understanding
that screenshots are often the only
recourse a user in a network enterprise
system has for capturing, documenting,
and explaining their concerns. We
clarify, however, that the sharing of a
screenshot alone would not be
considered a protected communication
as it would need to be accompanied by
an explanation of the issues or aspects
of the health IT that the screenshot is
meant to communicate or illustrate.
Considering the value of
communicating significant issues
regarding health IT through screenshots,
we have finalized our proposal to
include screenshots as a protected
communications under the Cures Act.
However, as discussed in responses to
other comments below, we have revised
our final policy in multiple ways.
Comments. One commenter
recommended that screenshots should
be defined broadly to include video and
other media that can be helpful in
demonstrating challenges with EHRs.
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
Response. We agree with the
recommendation that protections
afforded to screenshots should extend to
video. We clarify that, like screenshots,
video is considered a form of visual
communication. A video of a computer
screen while a software program is in
operation would capture the user
experience of interacting with that
program and essentially would show a
number of screenshots from that
program in rapid succession. We
emphasize that video, similarly to
individual screenshots, is a critical form
of communication of issues with the
health IT, including issues related to
usability, user experience,
interoperability, security, or the way the
technology is used.
As with screenshots, video is
particularly useful in communicating a
user’s experience with health IT and the
manner in which the user has used
health IT. This is especially the case
when issues of a temporal nature are
involved. For example, video would be
essential for illustrating a latency issue
experienced during drug ordering that
could not be communicated through
screenshots or other forms of
communication. Video also could be
critical to demonstrating an issue with
a clinical decision support alert that is
designed to appropriately and timely
notify the provider of a patient matter
but fails to do so.
Comments. Several commenters
expressed concern regarding how a
developer’s IP may be impacted by the
proposed Communications Condition of
Certification requirements. Several
commenters stated that the Proposed
Rule goes beyond protecting
communications for the purposes of
patient safety and system improvement
and would enable or require
inappropriate sharing and disclosure of
IP, potentially creating security risks,
increased IP theft, and harming
innovation and the marketplace for
health IT. Several commenters stated
that trade secrets, patent protections,
and protections for confidential and
proprietary information were not
addressed or considered appropriately
in the Proposed Rule, and that as a
result it would be possible for bad actors
to create pirated health IT based on the
disclosure of screenshots and similar
communications. Commenters stated
that developers of health IT have
successfully used licensing and
nondisclosure agreements that apply to
user-facing aspects of the technology to
maintain the trade secret status of their
health IT and that the Proposed Rule
would impact their ability to do so and
remain competitive in the market.
PO 00000
Frm 00094
Fmt 4701
Sfmt 4700
Response. We appreciate the
comments regarding how a developer’s
IP may be impacted by the
Communications Condition of
Certification requirements. As discussed
earlier in this section, participation in
the Program is voluntary; and
developers have the option to agree to
the terms we have offered or to choose
not to participate in the Program.
However, we recognize the need to
properly balance the protection of a
developer’s IP with the need to advance
visual communications (e.g., screenshot
and video communications) under the
Communications Condition and
Maintenance of Certification
requirements, which we believe is
critical to addressing—among other
things—the usability, interoperability,
and security of health IT. As discussed
throughout this section and in section
(C) above, we believe that we have
properly considered and addressed
health IT developers’ IP rights in this
final rule in § 170.403(a)(2)(ii)(C) by
amending the proposed regulation as
described above.
We emphasize that the
communication of screenshots is
essential to protect public health and
safety and that our final policies take a
measured approach to responding to
and addressing a real and substantial
threat to public health and safety. The
communication of screenshots enables
providers, researchers, and others to
identify safety concerns, share their
experiences with the health IT, learn
from the problems, and then repair
dangers that could otherwise cause
serious harm to patients. Our position is
informed both by years of experience
regulating health IT and overwhelming
research and academia, which is
discussed below.
For instance, a study published in
2018 was performed to better
characterize accessibility to EHRs
among informatics professionals in
various roles, settings, and organizations
across the United States and
internationally.88 To quantify the
limitations on EHR access and
publication rights, the researchers
conducted a survey of informatics
professionals from a broad spectrum of
roles including practicing clinicians,
researchers, administrators, and
members of industry. The results were
analyzed and levels of EHR access were
stratified by role, organizational
affiliation, geographic region, EHR type,
and restrictions with regard to
88 Khairat, S, et al. 2018 Assessing the Status Quo
of EHR Accessibility, Usability, and Knowledge
Dissemination. eGEMs (Generating Evidence &
Methods to improve patient outcomes), pp. 1–11,
https://doi.org/10.5334/egems.228.
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
publishing results of usability testing,
including screenshots. Among faculty
members and researchers, 72 percent
could access the EHR for usability and/
or research purposes, but, of those,
fewer than 1 in 3 could freely publish
screenshots with results of usability
testing and half could not publish such
data at all. Across users from all roles,
only 21 percent reported the ability to
publish screenshots freely without
restrictions.89
The study explained that the patient
safety implications of EHR publication
censorship and restricted EHR access
are multiple. First, limiting institutions
from sharing usability research findings
can prevent the correction of known
problems. Second, without public
dissemination, poor design practices
will propagate to future iterations of
existing vendor systems. Finally,
research efforts are directed away from
real-world usability problems at a time
when EHR systems have become widely
deployed and when an urgency exists to
accelerate usability testing. The study
referenced the 2011 Institute of
Medicine report (as discussed in the
Proposed Rule and in additional detail
below), which identified contractual
restrictions as a barrier to knowledge
regarding patient safety risks related to
health IT.90
The study emphasized that the result
of this level of censorship is that a vast
majority of scientists researching EHR
usability are either prevented from
publishing screenshots altogether or
must first obtain vendor permission,
thus impeding the free dialogue
necessary in communities of
investigation.91 The study argued that:
(1) Lack of EHR access makes many
critical EHR usability research activities
impossible to conduct, and (2)
publication censorship, especially
regarding screenshots, means that even
those usability studies which can be
conducted may not have the impact
they otherwise would. As a
consequence, innovation can be stifled.
As such, one of the recommendations
made by the researchers was that there
should be a mandate that screenshots
and images from EHR systems be freely
publishable without restrictions from
copyright or trade secret constraints.92
In the report by the Institute of
Medicine that was noted above, entitled
Health IT and Patient Safety: Building
Safer Systems for Better Care,93 the
89 Id.
at 1.
at 2.
91 Id. at 7.
92 Id. at 8.
93 Institute of Medicine 2012. Health IT and
Patient Safety: Building Safer Systems for Better
90 Id.
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
Committee on Patient Safety and Health
Information Technology (Committee)
explained that a significant impediment
to gathering safety data is contractual
barriers (e.g., nondisclosure,
confidentiality clauses) that can prevent
users from sharing information about
health IT–related adverse events. They
further explained that such barriers
limit users’ abilities to share knowledge
of risk-prone user interfaces, for
instance through screenshots and
descriptions of potentially unsafe
processes. In addition, some vendors
include language in their sales contracts
and escape responsibility for errors or
defects in their software (i.e., ‘‘holdharmless clauses’’). The Committee
concluded that these types of
contractual restrictions limit
transparency, which significantly
contributes to the gaps in knowledge of
health IT–related patient safety risks.
Further, these barriers to generating
evidence pose unacceptable risks to
safety.94 Based on these findings, the
committee recommended that the
Secretary of HHS should ensure insofar
as possible that health IT vendors
support the free exchange of
information about health IT experiences
and issues and not prohibit sharing of
such information, including details (e.g.,
screenshots) relating to patient safety.95
Recently, the U.S. Food and Drug
Administration (FDA) funded Brigham
and Women’s Hospital Center for
Patient Safety Research and Practice to
conduct an exploration of computerized
prescriber order entry (CPOE)-related
potential for errors in prescribing,
particularly as these relate to drug name
displays, and ordering and workflow
design issues. The project investigated
ways to better identify, understand, and
prevent electronic ordering errors in the
future.96 However, the researchers noted
that one large vendor would not grant
permissions to share requested
screenshots necessary for the study.
This refusal ran counter to both the
FDA’s task order initial precondition as
well as multiple high-level panels’
health IT safety recommendations. The
FDA emphasized that it is hard to justify
from a safety viewpoint why such
permission was withheld, despite the
vendors’ proprietary concerns. FDA
explained that identifying, preventing,
and learning from errors and improving
Care. Washington, DC: The National Academies
Press, https://doi.org/10.17226/13269.
94 Id. at 3.
95 Id. at 7.
96 U.S. Food & Drug Admin., UCM477419,
Computerized Prescriber Order Entry Medication
Safety: Uncovering and Learning from Issues and
Errors, https://www.fda.gov/downloads/Drugs/
DrugSafety/MedicationErrors/UCM477419.pdf.
PO 00000
Frm 00095
Fmt 4701
Sfmt 4700
25735
prescribing safety should be a priority
and should take precedence over
commercial considerations (and to the
extent correctable problems can be
identified, likely would result in an
improved commercial CPOE product).
In cases where the FDA sought to
illustrate problems in the system, they
drew generic screenshots to illustrate
the issue in question.97
Among their recommendations, the
FDA recommended that vendors be
required to share screenshots and error
reports. The FDA emphasized that
vendors should be required to permit
the sharing of screenshots and
information with the FDA and other
institutions regarding other CPOE
system issues of concern or that pose
risk for errors. They stressed that the
practice of prohibiting such sharing via
copyright must be eliminated. Further,
the FDA recommended that vendors
should be required to disclose errors
reported to them or errors identified in
their products, analogous to the
requirement that drug manufacturers
report significant adverse drug effects.98
One of the co-authors of the FDA
study recently wrote a law review
article that discussed the significance of
screenshots.99 The author noted that the
results of the FDA study were
remarkable and remarkably distressing,
as they identified and took screenshots
of over fifty different dangers in the
health IT. He expressed frustration that
it took up to two years of additional
discussions with the vendors to get
permission to share the screenshots
publicly, and that even after these
extended discussions, one vendor—
‘‘with more than a lion’s share of the
market’’—prevented the study from
displaying the screenshots, some of
which were clearly dangerous or deadly.
He explained that they had worked
around that limitation by substituting
the one vendor’s screens with parallel
screens taken from Harvard’s
homegrown, but by then superannuated,
EHR. The author emphasized that those
images and screenshots illustrated over
fifty EHR risks caused by dangerous and
confusing EHR interfaces. The author
also emphasized that the study could
have been even more helpful in
identifying these risks if the FDA had
been able to present the findings when
first available, rather than haggle for a
year or two, and if the study was able
97 Id.
at 44.
at 52.
99 Ross Koppel, Uses of the Legal System That
Attenuate Patient Safety, 68 DePaul L. Rev. (2019)
Available at: https://via.library.depaul.edu/lawreview/vol68/iss2/6.
98 Id.
E:\FR\FM\01MYR3.SGM
01MYR3
25736
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
to include all of the full images from
each system they studied.100
Comments. A commenter
recommended that ONC draw a
distinction around purpose of use in
relation to the fair use of screenshots
and require that the discloser of a
screenshot be responsible for ensuring
the appropriateness of that purpose.
Response. As discussed under section
(C) above we have retained the concept
of ‘‘fair use’’ as it applies to all health
IT developer intellectual property
covered under ‘‘permitted prohibitions
and restrictions’’ (§ 170.403(a)(2)(ii)). As
discussed throughout this section, we
have placed certain restrictions on the
sharing of screenshots responsive to the
commenter.
Comments. One commenter urged
ONC to revise the proposed approach to
screenshots by adopting a process that
would allow developers to review and
approve screenshots for publication for
specific purposes, such as
communications about safety and
usability.
Response. A pre-approval process
could create potential or perceived
barriers to communications and thus
could discourage or delay the making of
protected communications that are vital
to patient safety or other important
issues regarding certified health IT. For
example, a user might be less willing to
go through the process, the time the
process takes could undermine the
conveyance of the communications, and
the objections raised during the process
may not be valid or amenable to all
parties.
Comments. Several commenters had
concerns regarding the volume of
screenshots that could be shared under
our proposal and potential harms that
could occur. One commenter
emphasized that sharing of screenshots
could disclose information about how
health IT works, including algorithms
and workflows, and enable creation of
duplicate software and theft of valuable
IP. One commenter suggested that if a
user of health IT published hundreds of
screenshots of the health IT, a bad actor
could theoretically deduce trade secrets
based on the screenshots. Several
additional commenters were also
concerned that the Proposed Rule could
allow communication of an unlimited
number of screenshots of certified
health IT, and one commenter suggested
revising the proposed approach to
include limiting sharing of screenshots
to a reasonable number, such as seven.
Response. We appreciate those
comments expressing concerns
regarding the volume of screenshots that
100 Id.
at 280–81.
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
could be shared and the potential
negative consequences of allowing
screenshots to be shared. In the
Proposed Rule in 84 FR 7475, we
proposed to allow developers to place
limited restrictions on the sharing of
screenshots. We stressed in the
Proposed Rule that our goal with our
proposals concerning screenshots was to
enable communications that will
address matters such as patient safety,
system security vulnerabilities, health
IT performance, and usability. Our
intent was not to prevent developers
from restricting the communication of
screenshots for purposes outside the
scope of the protected communications
detailed in the Cures Act. Additionally,
we believe that modern software design
best practices uncouple screen design
from underlying algorithms, and that
limited use of screenshots for safety
would not allow reverse engineering of
large parts of the underlying code.
However, we further emphasize that it
was never our intention that screenshots
(or other visual communications such as
video) depicting source or object codes
would be protected communications
(see the non-user-facing aspects
provision of this Condition of
Certification), so long as such
communications are not
communications with unqualified
protection.
We reviewed comments that
suggested establishing a set numerical
limit for the sharing of screenshots.
However, we have not finalized a
requirement in § 170.403(a)(2)(ii)(D)
with a fixed numerical limit because
there is no non-arbitrary way to
determine what the ‘‘right’’ or
‘‘appropriate’’ number is in a one-sizefits-all way. That is because the number
of screenshots or amount of video that
would be needed to communicate about
the health IT could vary, from one
situation to the next, based on the
specific issue and circumstances. For
instance, an issue with health IT
functionality regarding a particular
process that involves the user viewing
and making selections on several
different screens may necessitate images
of all of the screens involved in order
to communicate the issue. However, an
issue regarding how one value is being
displayed in a particular context (e.g., a
medication name being truncated) may
only necessitate one screenshot in order
to communicate the issue. Thus, we
believe the best approach is to adopt a
qualitative standard that is designed to
be sufficiently flexible for the wide
range of health IT issues that may arise
and the varying visual communications
PO 00000
Frm 00096
Fmt 4701
Sfmt 4700
that need to be communicated to
demonstrate or display the issue.
We have finalized provisions in
§ 170.403(a)(2)(ii)(D)(2) and (3) that
allow health IT developers to require
persons who communicate screenshots
to limit the sharing of screenshots to
only the relevant number of screenshots
and amount of video that are needed to
communicate about the health IT
regarding one or more of the six subject
areas identified in the Cures Act and
detailed in § 170.403(a)(1). Allowing
developers to limit the sharing of
screenshots to only the relevant number
needed to communicate about the
health IT—regarding one or more of
those six subject areas—places a
limitation on the number of screenshots
allowed to be shared under the
Communications Condition of
Certification requirements and requires
that the screenshots are related to, and
thus necessary in illustrating, the
protected communication being made.
In practice, this would mean that if a
particular safety issue in the health IT
could be communicated using three
screenshots, the communicator should
not share additional screenshots that are
irrelevant or only potentially relevant to
communicate the safety issue with the
health IT. If the communication
included additional screenshots that
were not necessary to visually
communicate about the particular safety
issue with the health IT that falls within
the usability category, the health IT
developer would have grounds to seek
redress.
As with screenshots, we wish to be
sensitive to concerns regarding
protecting IP in health IT and allow
developers to appropriately limit video
communication in order to protect
against harms that could occur due to
unlimited sharing. Similar to
screenshots, the amount of video that
may be necessary to make a protected
communication about health IT could
vary, depending on the nature of the
issue or aspect of the health IT being
addressed. For example, a video meant
to communicate a delay in order entry
would need to be long enough to
communicate the significance of the
delay, but would not need to include
video of the log-in process or other
unrelated functionality of the health IT.
We have finalized a provision in
§ 170.403(a)(2)(ii)(D)(3) that allows
health IT developers to place certain
limitations on the communication of
video. Under this provision, a health IT
developer may require persons who
communicate video to limit the sharing
of video to: (1) The relevant amount of
video needed to communicate about the
health IT regarding one or more of the
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
subject areas identified in the Cures Act
and detailed in § 170.403(a)(1); and (2)
only videos that address temporal
matters that the user reasonably believes
cannot be communicated through
screenshots or other forms of
communications.
In sum, any disclosure must be
limited to the relevant number of
screenshots or amount of video that is
necessary to convey the matter that falls
within one of the six subject areas, with
video only being used to convey
temporal matters that cannot be
communicated through screenshots or
other forms of communication. We
believe these additional limitations on
the communication of screenshots and
video will further bolster protections for
developer IP, while still allowing
necessary and effective communication
about health IT issues within the six
subject areas.
Comments. Several commenters
stated that there should be a way to
protect against doctored screenshots.
Response. As proposed,
communicators of screenshots must not
alter the screenshots (or video), except
to annotate the screenshots or resize the
screenshots (§ 170.403(a)(2)(ii)(D)(1)).
These restrictions similarly apply to
video as well (§ 170.403(a)(2)(ii)(D)(1)).
We further note that, despite a lack of
comments, on further reflection, we
have elected to not finalize proposed
limitations to allow developers to
impose restrictions on the
communication of screenshots that
contain PHI. We have made this
determination because we believe that
most of the individuals or entities
communicating the screenshots would
be bound by other laws, including the
HIPAA Rules and State privacy laws,
which would be applicable to the PHI
at issue. Therefore, we do not believe it
is necessary to provide for developers
policing the release of such data in the
form of screenshots in this Condition of
Certification.
Comments. A number of commenters
discussed the infeasibility of the
proposed requirements regarding
restricting communication of
screenshots, and in particular, the
requirement that health IT developers
put all potential communicators on
sufficient written notice of each aspect
of its screen display that contains thirdparty content that cannot be
communicated because it would
infringe IP rights. Some commenters
stated that the proposed language
should be amended to require a list of
third-party content that might appear in
a screen or that the developer
sublicenses, or to require a notice on the
developer’s website. Other commenters
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
stated that the proposal should be
removed. One commenter
recommended ONC consider not
making developers accountable for
actions by health IT users regarding the
disclosure of screenshots with thirdparty information. One commenter
requested additional guidance from
ONC for dealing with third-party, nonhealth IT content in health IT.
Response. Where a health IT
developer is prohibited by this rule from
restricting the communication of a
screenshot and allows a screenshot
containing third-party content to be
communicated, the health IT developer
is acting as required by this final rule
and enabling important communication
regarding critical health IT issues to
occur. Thus, we believe developers
acting in accordance with this final rule
should not be responsible for third-party
content in screenshots that are
communicated as required by the
Communications Condition of
Certification requirements. As such, in
§ 170.403(a)(2)(ii)(D) we have removed
from the requirements related to thirdparty IP rights proposed in 84 FR 7475.
(E) Testing and Development
We discussed in the Proposed Rule in
84 FR 7475 that some health IT
developers expose aspects of their
health IT to health care providers and
others for the purpose of testing and
development prior to a product’s
‘‘general availability’’ release. We stated
that such disclosures may relate to beta
releases that are shared with certain
customers for testing prior to the
software being made generally available
to the market, or may be made as part
of a joint-venture or cooperative
development process. In these
circumstances, we proposed in 84 FR
7475 that a health IT developer would
be justified in keeping information
about its health IT confidential. We
explained that this permitted
prohibition or restriction would allow
developers to seek appropriate IP
protection and discuss novel,
‘‘unreleased’’ product features with
their customer base, which has
significant public policy benefits for
research and innovation in the health IT
industry.
We proposed in 84 FR 7475 that this
permitted restriction would be limited
and would not apply to
communications that are subject to
unqualified protection as specified in
proposed § 170.403(a)(2)(i). We
proposed that this permitted restriction
would also not apply to
communications about the released
version of the health IT once the health
IT has been released.
PO 00000
Frm 00097
Fmt 4701
Sfmt 4700
25737
We requested comment on whether
we should limit the time this protection
would apply for testing purposes. We
also requested comment on whether we
should set specific parameters for
covered testing.
Comments. A couple of commenters
stated that there should be no limit on
how long testing and development
could last for the purpose of the
restrictions that developers would be
allowed to place on communications
regarding products in development.
These commenters stressed that any
limit would be arbitrary and that until
certified health IT is in live commercial
use, health IT developers should be
permitted to restrict communications
about it.
Response. We agree with the
commenters and did not propose to add
a time limit on testing and development
phases for the purpose of this Condition
of Certification requirement.
Comments. A couple of commenters
requested clarification that providers
testing products in real-world
environments would not be considered
‘‘contractors’’ of developers for the
purpose of the Communications
Condition of Certification requirements
because such treatment could result in
developers being allowed to place
additional communication restrictions
on employees and contractors under the
Communication Condition of
Certification requirements. One
comment also stated that restrictions on
communications by employees and
contractors should not extend to their
communications regarding product
features and functionality that the
employees and contractors were not
involved in developing or testing.
Response. The applicability of this
allowable restriction to providers testing
products would be determined by the
particular facts at issue and whether or
not the provider was an actual
contractor, employee, or consultant for
the developer. We also clarify that this
final rule does not limit the restrictions
a developer may place on an employee,
contractor, or consultant with regard to
protected communications, except to
the extent that the communication is
one with unqualified protection, in
which case no such restrictions would
be allowed.
Comments. One commenter
recommended that a health IT user must
have used health IT in a real-world
context before a communication by the
user about the health IT can be
protected.
Response. We have finalized our
proposal in § 170.403(a)(2)(ii)(E) that a
health IT developer would be justified
in keeping information about its health
E:\FR\FM\01MYR3.SGM
01MYR3
25738
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
IT confidential prior to a product’s
‘‘general availability’’ release. We note
that a health IT developer would also be
justified in keeping information about a
product update confidential because the
update is not yet generally available. We
do not place any limits on who the
communicator has to be in order to be
covered by the Communications
Condition of Certification requirements,
particularly since the protections in the
Communications Condition of
Certification requirements extend
beyond users of certified health IT to
cover researchers and other stakeholders
who may experience certified health IT
in a variety of settings and scenarios. As
such, we have decided not to limit the
communication protection to only those
communications that are made by users
of certified health IT in the real-world
context.
c. Maintenance of Certification
Requirements
We proposed in 84 FR 7476 that to
maintain compliance with the
Communications Condition of
Certification requirements, a health IT
developer must not establish or enforce
any contract or agreement provision that
contravenes the Communications
Condition of Certification requirements.
We also proposed in 84 FR 7476 that a
health IT developer must notify all
entities or individuals with which it has
a contract/agreement related to certified
health IT that any communication or
contract/agreement provision that
contravenes the Communications
Condition of Certification requirements
will not be enforced by the health IT
developer. We proposed in 84 FR 7476
that such notification must occur within
six months of the effective date of the
final rule. Further, we proposed in 84
FR 7476 that this notice would need to
be provided annually up to and until
the health IT developer amends the
contract or agreement to remove or
make void any contractual provision
that contravenes the Communications
Condition of Certification requirements.
We further proposed as a Maintenance
of Certification requirement in proposed
§ 170.403(b)(2) that health IT developers
must amend their contracts/agreements
to remove or make void any provisions
that contravene the Communications
Condition of Certification requirements
within a reasonable period of time, but
not later than two years from the
effective date of a final rule.
In the event that a health IT developer
cannot, despite all reasonable efforts,
locate an entity or individual that
previously entered into an agreement
with the developer that prohibits or
restricts communications protected by
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
the Communications Condition of
Certification requirements, we proposed
in 84 FR 7476 that the developer would
not be in contravention of the
Communications Condition of
Certification requirements so long as it
takes no step to enforce the prohibition
or restriction. We did not propose that
health IT developers be required to
furnish to ONC or their ONC–ACB
copies of notices made to customers, or
copies of contracts or agreements
revised, in satisfaction of this
Maintenance of Certification
requirement, although we noted that
those communications could be
requested by ONC or an ONC–ACB in
the usual course of business or to
demonstrate compliance.
Comments. A number of commenters
expressed concerns regarding the
proposed deadlines for complying with
the requirements. Several commenters
stated that the requirement to notify
customers and others with whom the
developer has contracts or agreements
within six months was too long and
recommended that the deadline be
shortened. Regarding the deadline for
amending contracts/agreements that
contravene the Communications
Condition of Certification requirements,
most commenters stated that the
deadline was too short, with several
requesting that it be extended to five
years. Some other commenters
recommended that modification of any
contracts/agreements to comply with
the Communications Condition of
Certification requirements should occur
whenever such contracts/agreements are
renewed, or at the earliest available
time, without the need for a specific
deadline. A couple of commenters
recommended that a health IT developer
not be held responsible for amending
contracts within two years of the
effective date of the final rule if it has
made reasonable efforts to do so. Several
comments recommended that ONC
should allow alternative means of
completing this requirement, such as
posting relevant language on the
developer’s website. One commenter
stated that it would be helpful to have
a ‘‘standard exception clause’’ that
developers could use in their contracts
and agreements.
Response. We appreciate the
comments we received on this
provision. We clarify in
§ 170.403(b)(2)(i) that a developer may
not include provisions that contravene
the Communications Condition of
Certification requirements in any new
contract as of the effective date of the
final rule. In consideration of
comments, we have decided to modify
the timeframe requirement proposed in
PO 00000
Frm 00098
Fmt 4701
Sfmt 4700
84 FR 7476 for amending contracts/
agreements to be in compliance with
this condition. While we considered
extending the deadline to five years to
allow developers to have additional
time for compliance, we determined
that a more flexible solution is
appropriate. As such, we have modified
the requirement in § 170.405(b)(2)(ii) to
state that any contracts/agreements in
place as of the effective date of the final
rule and containing language in
contravention of the Communications
Condition of Certification requirements
must be revised to remove or void the
contractual provision that contravenes
the Communications Condition of
Certification requirements whenever the
contract is next modified for any reason.
We clarify that where a contract
automatically renews, the developer
would still be prohibited under the
Program from enforcing any agreement
or contract provisions that contravene
the Communications Condition of
Certification requirements in
§ 170.403(a) and the developer would
also be responsible for sending an
annual notice as described above until
such provisions have been modified. To
note, we decline to absolve a developer
of the requirement to modify the
contract solely because the developer
has made a reasonable effort to do so.
We finalized the notification
requirements proposed in 84 FR 7476. A
health IT developer must notify all
entities and individuals with which it
has a contract/agreement related to
certified health IT that any
communication or contract/agreement
provision that contravenes the
Communications Condition of
Certification requirements will not be
enforced by the health IT developer.
However, we no longer require that such
notification must occur within six
months of the effective date of the final
rule and annually thereafter until
contravening provisions are amended.
Instead, notification must only occur
annually, beginning in calendar year
2020, and continue until all
contravening provisions are amended.
Given the timing of the publication of
the final rule, health IT developers
could have potentially been required to
provide both initial notification and an
annual notification in the same calendar
year. We believe the removal of the six
months notification deadline and
retention of an annual requirement only,
beginning with notification in calendar
year 2020, will simplify compliance for
health IT developers while still
providing adequate notice and ensuring
that initial notification is provided in a
reasonable amount of time. Therefore
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
we have finalized the deadline for the
notice requirement in § 170.403(b)(1) to
be annually, beginning in calendar year
2020.
Comments. Several commenters
requested clarification that once the
final rule goes into effect, contravening
provisions in developer contracts
prohibiting communications cannot be
enforced. One of these commenters
stated that developers would often
include language in their contracts
prohibiting communication on the part
of end users and entities, thus
preventing communication about issues
with EHRs. Several commenters
requested that ONC explicitly state that
any permitted communication made
following the effective date of the final
rule be inadmissible as a violation of a
contract/agreement regardless of
whether the customer has been notified.
One commenter requested that ONC
clarify that, with respect to protecting
communications regarding developer
business practices, where the disclosure
of certain information is prohibited by
contract, the developer would not be
liable for its inability to communicate
such information.
Response. We emphasize that as of
the effective date of the final rule,
contravening provisions in contracts or
agreements cannot be enforced without
the risk of losing certification for the
developer’s health IT or a certification
ban for the developer under the
Program, regardless of whether the
customer was notified as required by the
Communications Condition of
Certification requirements. We clarify
that provisions of contracts requiring
that the health IT customer ‘‘flowdown’’ obligations onto the customer’s
employees, contractors, and other users
of the health IT that would restrict
protected communications would be in
contravention of this Condition of
Certification. Such provisions could not
be enforced after the effective date of the
final rule without risking loss of
certification as noted above for the
developer under the Program.
We appreciate commenters’ concern
regarding disclosing information that
may be otherwise prohibited by
contract. However, we clarify that the
purpose of the Communications
Condition of Certification requirements
is to prevent developers from
improperly restricting protected
communications, including
communications about a developer’s
practices and policies related to
facilitating the exchange of health
information. As discussed earlier in this
section, costs, timeframes, licensing
practices and terms, as well as the
developer’s approach to working with
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
third-party services, could all be
considered protected communications
to the extent they relate to facilitating
the exchange of health information.
Thus, we reiterate that where a contract
entered into by the developer would
restrict a communication protected by
the Communications Condition of
Certification requirements, the
developer may not enforce such a
contract and may not restrict a protected
communication in violation of the
Communications Condition of
Certification requirements after the
effective date of the final rule without
risking loss of certification. It is also
important to note that not all
contractual provisions related to
communications would create a risk of
de-certification. As noted above, the
Communications Condition of
Certification requirements in
§ 170.403(a)(2)(ii) do allow for
developers to place restrictions on
certain communications as discussed
above. Therefore, contractual provisions
that appropriately address those
allowances would not create a risk of
de-certification under the Program.
Comments. One commenter suggested
that ‘‘renew’’ should be added to the
maintenance requirement to not
establish or enforce any contract or
agreement that contravenes the
Communications Condition of
Certification requirements in
§ 170.403(a).
Response. We appreciate this
comment and amended the proposed
regulatory text in § 170.403(b)(2)(i) to
include ‘‘renew.’’ We clarify that where
a contract auto-renews, the developer
would still be prohibited under the
Program from enforcing any agreement
or contract provisions that contravene
the Communications Condition of
Certification requirements without
risking loss of certification and would
also be responsible for sending an
annual notice as described above until
such provisions have been modified.
Comments. A couple of commenters
expressed concern about developer
efforts to re-negotiate other terms of a
contract that are unrelated to protected
communications as part of the contract
modification process.
Response. We stress that the contract
modifications required as part of the
Communications Condition of
Certification requirements are strictly
limited to removing any provisions of
the relevant contract/agreement that
would restrict protected
communications in contravention of the
Communications Condition of
Certification requirements and are not
required to be done until the contract/
PO 00000
Frm 00099
Fmt 4701
Sfmt 4700
25739
agreement is modified for other
purposes.
4. Application Programming Interfaces
The API Condition of Certification
requirement in Section 4002 of the
Cures Act requires health IT developers
to publish APIs that allow ‘‘health
information from such technology to be
accessed, exchanged, and used without
special effort through the use of APIs or
successor technology or standards, as
provided for under applicable law.’’ The
requirement also states that a developer
must, through an API, ‘‘provide access
to all data elements of a patient’s
electronic health record to the extent
permissible under applicable privacy
laws.’’ Additionally, the API Condition
of Certification requirement of the Cures
Act includes several key phrases and
requirements for health IT developers
that go beyond the technical
functionality of the Health IT Modules
they present for certification. In this
section of the preamble, we outline the
proposals we have adopted to
implement the API Condition of
Certification requirement of the Cures
Act to provide compliance clarity for
health IT developers.
We have adopted new standards, new
implementation specifications, a new
certification criterion, Condition and
Maintenance of Certification
requirements, and modified the Base
EHR definition. Health IT developers
should consider these final
requirements in the context of
information blocking provisions
described in section VIII of this
preamble.
a. Statutory Interpretation and API
Policy Principles
Section 4002 of the Cures Act requires
health IT developers certified to the
Program to publish APIs that allow
‘‘health information from such
technology to be accessed, exchanged,
and used without special effort through
the use of APIs or successor technology
or standards, as provided for under
applicable law.’’ To implement the
Cures Act API requirements, we
proposed a new 2015 Edition Cures
Update ‘‘API’’ certification criterion at
84 FR 7476 that included requirements
for an API to have ‘‘read’’ capabilities
that support two types of services: (1)
Services for which a single patient’s
data is the focus; and (2) services for
which multiple patients’ data are the
focus.
We conveyed in the Proposed Rule
our belief that ‘‘without special effort’’
requires APIs and the health care
ecosystem in which they are deployed
to be standardized, transparent, and pro-
E:\FR\FM\01MYR3.SGM
01MYR3
25740
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
§ 170.215(a)(1) and finalized its use in
§ 170.315(g)(10).
competitive. Therefore, we noted that
any Health IT Module certified to the
new 2015 Edition Cures Update API
criterion and a health IT developer’s
business practices would have to have
these attributes.
b. API Standards and Implementation
Specifications
i. Base Standard
We proposed in § 170.215(a)(1) at 84
FR 7477 to adopt HL7® FHIR® Draft
Standard for Trial Use (DSTU) 2 for
reference in the criterion proposed in
§ 170.315(g)(10). Additionally, we
requested comment in 84 FR 7478 and
7479 on four options to determine the
best version of HL7 FHIR to reference
for use in § 170.315(g)(10): Option 1:
FHIR DSTU 2, Option 2: FHIR DSTU 2
and FHIR Release 3, Option 3: FHIR
DSTU 2 and FHIR Release 4, and Option
4: FHIR Release 4 only. We requested
commenters review the proposed
certification criterion in § 170.315(g)(10)
and the accompanying Condition of
Certification requirements attributed to
the API certification criteria. Notably,
we stated in the Proposed Rule at 84 FR
7479 that if we adopted another FHIR
Release in a final rule as an alternative
to FHIR Release 2 for the proposed API
criterion in § 170.315(g)(10), then we
would also adopt the applicable
implementation specifications
associated with the FHIR Release.
Comments. We received
overwhelming support for Option 4:
Adopt solely FHIR Release 4 in the final
rule for reference in § 170.315(g)(10).
We received support for the adoption of
FHIR Release 4 across a broad array of
stakeholders, including health IT
developers, medical trade associations,
software application developers, and
payers. Commenters noted that FHIR
Release 4 is the first FHIR release with
normative FHIR resources and support
for enhanced capabilities. Most
commenters emphasized that Option 4
will allow the industry to unify and
focus on a single baseline standard,
rather than accommodating multiple
releases proposed in Options 2 and 3. A
minority of commenters suggested
alternative or multiple versions, noting
this would allow for flexibility, but the
vast majority of commenters supported
the adoption of FHIR Release 4 only.
Response. We appreciate the feedback
and agree with commenters that
adoption of a single standard is the best
option to align industry and enable
widespread interoperability. We have
adopted the latest version of the
standard at the time of this final rule
publication (FHIR Release 4.0.1) in
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
ii. United States Core Data for
Interoperability
We proposed in § 170.215(a)(2) at 84
FR 7479 to adopt the API Resource
Collection in Health (ARCH) Version 1
implementation specification, which
listed a set of base HL7® FHIR®
resources that Health IT Modules
certified to the proposed criterion in
§ 170.315(g)(10) would need to support.
Comments. Most commenters were
opposed to the adoption of the ARCH in
the final rule. Commenters argued for
the use of American National Standards
Institute accredited standards, and
suggested ONC work with standards
developing organizations for standards
development and maintenance.
Several commenters noted that the
ARCH has not gone through a formal
balloting process, did not support
ONC’s proposal to rely upon the
National Technology Transfer and
Advancement Act’s exception to adopt
the ARCH in the final rule, and
encouraged the use of technical
standards developed or adopted by
voluntary consensus standards bodies.
Several commenters noted that
requiring the ARCH in addition to the
other adopted standards could create
confusion. Commenters further
emphasized the importance of
maintaining ongoing consistency
between the ARCH and the other
adopted standards, and noted this
would be challenging to achieve.
Additional comments against the
ARCH expressed concern with the
proposed updates through the Standards
Version Advancement Process, and with
ONC over-regulating API functionality.
Commenters also noted that ONC could
encourage API access to specific data
elements without creating a new
implementation specification.
Some commenters in favor of the
ARCH implementation specification
asked for data element revisions.
Commenters also asked for clarity that
EHRs will not need to provide the full
set of data to modular applications, and
asked for specificity on how much of
this data would need to be mapped by
the API Technology Supplier.
Additionally, commenters asked for
guidance on lab results, including
application creation implementation
guides that would ensure accuracy and
compliance when incorporating lab
data.
Response. In response to commenters,
we did not adopt the ARCH as an
implementation specification in the
final rule. Upon consideration of public
comments and in an effort to
PO 00000
Frm 00100
Fmt 4701
Sfmt 4700
consistently approach how we reference
the United States Core Data for
Interoperability (USCDI) with various
content standards (e.g., C–CDA), we
determined that having an
implementation specification to map
USCDI to HL7 FHIR could create more
restrictions than we intended. We
appreciate the concerns raised by
stakeholders, and as we evaluated the
ARCH in context of our other proposals,
we determined that we could achieve
our desired policy outcome to link the
USCDI Data Elements to FHIR Resources
without the ARCH. We refer
commenters to the sections that follow
for further clarity regarding the
implementation of Data Elements
included in the USCDI implementation
specification (IV.B.1).
iii. US Core IG and Bulk IG
We proposed in 84 FR 7480 in
§ 170.215(a)(3) to adopt the Argonaut
Data Query Implementation Guide
version 1 (Argonaut IG) implementation
specification, which specifies
constraints for 13 of the HL7® FHIR®
resources proposed in § 170.215(a)(2).
Additionally, we proposed in
§ 170.215(a)(4) to adopt the Argonaut
Data Query Implementation Guide
Server implementation specification.
Comments. Several commenters
advocated for the adoption of the FHIR
US Core Implementation Guide STU 3
Release 3.0.0 implementation
specification instead of the Argonaut
Implementation Guides. Commenters
noted that the US Core Implementation
Guide was built from the Argonaut
Implementation Guides and has been
balloted by the standards community.
Response. We thank commenters for
their feedback. We note that in the
Proposed Rule at 84 FR 7479 we stated
that if we were to adopt another FHIR
Release in the final rule as an alternative
to FHIR Release 2, then we would also
adopt the applicable implementation
specifications and FHIR profiles
associated with the FHIR Release.
Considering this and commenters’
recommendations, we have adopted the
HL7 FHIR US Core Implementation
Guide STU 3.1.0 (US Core IG)
implementation specification in
§ 170.215(a)(2). We note that we
adopted the latest version of the US
Core IG at the time of the final rule
publication. The US Core IG defines the
minimum conformance requirements for
accessing patient data using FHIR
Release 4 (adopted in § 170.215(a)(1)),
including profiled resources, operations,
and search parameters for the Data
Elements required in the USCDI
implementation specification (adopted
in § 170.213).
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
We note that in the Proposed Rule at
84 FR 7479 we proposed to require that
the ‘‘Patient.address’’ and
‘‘Patient.telecom’’ elements of the
‘‘Patient’’ resource must be supported.
We note these requirements have since
been subsumed by the US Core IG, given
that ‘‘Patient.address’’ and
‘‘Patient.telecom’’ elements are both
flagged ‘‘must support’’ for the ‘‘Patient’’
profile in the US Core IG. We also
proposed to require that the
‘‘Device.udi’’ element follow the human
readable representation of the unique
device identifier found in the
recommendation, guidance, and
conformance requirements section of
the ‘‘HL7 Version 3 Cross Paradigm
Implementation Guide: Medical Devices
and Unique Device Identification
Pattern, Release 1.’’ These requirements
have also been subsumed by the US
Core IG. Additional information can be
found in the ‘‘Device’’ profile of the US
Core IG adopted in § 170.215(a)(2).
We note that in the Proposed Rule we
proposed in 84 FR 7480 that the clinical
note text included in the
‘‘DocumentReference’’ resource would
need to be represented in its ‘‘raw’’ text
form, and further proposed in 84 FR
7480 that it would be unacceptable for
the note text to be converted to another
file or format (e.g., .docx, PDF) when it
is provided as part of an API response.
We clarify that the clinical note text
included in any of the notes described
in the ‘‘Clinical Notes Guidance’’
section of the US Core IG adopted in
§ 170.215(a)(2) must be represented in a
‘‘plain text’’ form, and would be
unacceptable for the note text to be
converted to another file or format (e.g.,
.docx, PDF) when it is provided as part
of an API response.
We note that in the Proposed Rule we
proposed in 84 FR 7480 to require that
the ‘‘Provenance.recorded’’ and
‘‘Provenance.agent.actor’’ elements of
the ‘‘Provenance’’ resource must be
supported. We note these requirements
have been subsumed by the US Core IG,
given that ‘‘Provenance.recorded’’ and
‘‘Provenance.agent.who’’ elements are
both flagged ‘‘must support’’ for the
‘‘Provenance’’ profile in the US Core IG.
As addressed under the header
‘‘Standardized API for Patient and
Population Services’’ in the section
V.B.4.c, we have finalized the adoption
of the HL7 FHIR Bulk Data Access (Flat
FHIR) (v1.0.0: STU 1) implementation
specification (Bulk IG), including
mandatory support for the ‘‘groupexport’’ ‘‘OperationDefinition’’ in
§ 170.215(a)(4).
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
iv. HL7 SMART IG and Backend
Services Authorization
We proposed in 84 FR 7481 in
§ 170.215(a)(5) to adopt the HL7®
SMART Application Launch Framework
Implementation Guide Release 1.0.0
implementation specification, a profile
of the OAuth 2.0 specification.
Comments. Most commenters
expressed support for the HL7 SMART
Application Launch Framework
Implementation Guide Release 1.0.0
(SMART IG) implementation
specification. Multiple commenters
suggested that in addition to requiring
support for ‘‘refresh tokens,’’
‘‘Standalone Launch,’’ and ‘‘EHR
Launch’’ capabilities from the SMART
IG, ONC also require support for ‘‘ssoopenid-connect,’’ ‘‘launch-standalone,’’
‘‘launch-ehr,’’ ‘‘client-public,’’ ‘‘clientconfidentialsymmetric,’’ ‘‘context-ehrpatient,’’ ‘‘context-standalone-patient,’’
‘‘permission-patient,’’ ‘‘permissionuser,’’ and ‘‘permission-offline’’
capabilities.
Response. We thank stakeholders for
their comments. The ten optional
capabilities commenters suggested are
included in the ‘‘SMART on FHIR Core
Capabilities’’ section of the SMART IG.
The ‘‘SMART on FHIR Core
Capabilities’’ suggested by commenters
include ‘‘sso-openid-connect,’’ which
allows for support of the OpenID
Connect profile in the SMART IG;
‘‘client-public’’ and ‘‘client-confidentialsymmetric,’’ which allow for client
authentication; ‘‘context-ehr-patient’’
and ‘‘context-standalone-patient,’’
which provide context to apps at launch
time; and ‘‘permission-patient,’’
‘‘permission-user,’’ and ‘‘permissionoffline,’’ which allow support for
patient-level scopes, user-level scopes,
and refresh tokens, respectively. Other
‘‘SMART on FHIR Core Capabilities’’
that were not suggested by commenters
include ‘‘context-banner’’ and ‘‘contextstyle,’’ which provide basic context to
apps at launch time, and ’’context-ehrencounter’’ and ‘‘context-standaloneencounter,’’ which provide encounterlevel granularity to apps at launch time.
Given the importance of these ‘‘SMART
on FHIR Core Capabilities,’’ and in
consideration of public comments and
our own research, we have adopted the
SMART IG, including mandatory
support for the ‘‘SMART on FHIR Core
Capabilities’’ in § 170.215(a)(3). We
explicitly require mandatory support of
the ‘‘SMART on FHIR Core
Capabilities’’ in § 170.215(a)(3) because
these capabilities are indicated as
optional in the implementation
specification. We further clarify these
‘‘SMART on FHIR Core Capabilities’’ are
PO 00000
Frm 00101
Fmt 4701
Sfmt 4700
25741
in scope for Program testing and
certification. Additionally, we clarify
that by requiring the ‘‘permissionpatient’’ ‘‘SMART on FHIR Core
Capability’’ in § 170.215(a)(3), Health IT
Modules presented for testing and
certification must include the ability for
patients to authorize an application to
receive their EHI based on FHIR
resource-level scopes. Specifically, this
means patients would need to have the
ability to authorize access to their EHI
at the individual FHIR resource level,
from one specific FHIR resource (e.g.,
‘‘Immunization’’) up to all FHIR
resources necessary to implement the
standard adopted in § 170.213 and
implementation specification adopted
in § 170.215(a)(2). This capability will
give patients increased control over how
much EHI they authorize applications of
their choice to receive. For example, if
a patient downloaded a medication
management application, they would be
able to use these authorization scopes to
limit the EHI accessible by the
application to only information
contained in FHIR ‘‘MedicationRequest’’
and ‘‘Medication’’ profile.
Comments. Some commenters noted
concerns for privacy and security of
APIs. Specifically, one commenter
explained the threat of cross-site request
forgery (CSRF), and suggested we take
action to mitigate that risk, including by
requiring the use of both OAuth 2.0 and
OpenID Connect Core 1.0.
Response. We appreciate the concerns
expressed by commenters regarding the
privacy and security of APIs. The
OAuth 2.0 standard defined at Request
For Comment (RFC) 6749 101 describes
that ‘‘[The OAuth 2.0 authorization]
framework was designed with the clear
expectation that future work will define
prescriptive profiles and extensions
necessary to achieve full web-scale
interoperability.’’ The SMART IG serves
as a ‘‘prescriptive profile’’ as described
in RFC 6749. Thus, consistent with
commenters’ recommendations, we
have adopted a profile of the OAuth 2.0
standard (SMART IG) in § 170.215(a)(3).
Additionally, we have adopted OpenID
Connect Core 1.0 incorporating errata
set 1 in § 170.215(b), and require
conformance with the relevant parts of
this standard as part of testing and
certification. CSRF is a welldocumented security threat in OAuth
2.0, which can be prevented with
adequate security practices. We
encourage implementers to adhere to
industry best practices to mitigate CSRF
and other known security threats.
Relatedly, we note that the HL7
community has developed an
101 https://tools.ietf.org/html/rfc6749.
E:\FR\FM\01MYR3.SGM
01MYR3
25742
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
‘‘Implementer’s Safety Check List,’’ 102 a
guide of security best practices for
implementing FHIR-based APIs. We
encourage stakeholders to consult this
guide during development and
implementation of § 170.315(g)(10)certified Health IT Modules to minimize
security risks.
For backend services authorization, as
addressed under the header
‘‘Standardized API for Patient and
Population Services’’ in the section
V.B.4.c, we have finalized the adoption
of the HL7 FHIR Bulk Data Access (Flat
FHIR) (v1.0.0: STU 1) implementation
specification (Bulk IG), which includes
the ‘‘Backend Services Authorization
Guide’’ in § 170.215(a)(4).
v. OpenID Connect
We proposed in 84 FR 7480 through
7481 in § 170.215(b) to adopt OpenID
Connect Core 1.0 including errata set 1.
Comments. We received few
comments regarding the adoption of
OpenID Connect Core 1.0 including
errata set 1, however, commenters
generally supported the adoption of this
standard.
Response. We thank commenters for
their feedback. Given their support, we
have finalized the adoption of OpenID
Connect Core 1.0 including errata set 1
as proposed in § 170.215(b). We clarify
that only the relevant parts of the
OpenID Connect Core 1.0 including
errata set 1 adopted in § 170.215(b) that
are also included in the implementation
specification adopted in § 170.215(a)(3)
will be in-scope for testing and
certification.
c. Standardized API for Patient and
Population Services
We proposed in 84 FR 7481 to adopt
a new certification criterion,
§ 170.315(g)(10), to replace
§ 170.315(g)(8), and we proposed in 84
FR 7495 to update the 2015 Edition Base
EHR definition, as referenced in
§ 170.102. The proposed certification
criterion would require Health IT
Modules to support API-enabled ‘‘read’’
services for single and multiple patients.
‘‘Read’’ services include those that
allow authenticated and authorized
third-party applications to view EHI
through a secure API. These services
specifically exclude ‘‘write’’
capabilities, where authenticated and
authorized third-party applications
would be able to create or modify EHI
through a secure API.
Comments. Commenters supported
the proposed adoption of a new
certification criterion, § 170.315(g)(10),
to replace § 170.315(g)(8).
102 https://www.hl7.org/FHIR/safety.html.
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
Response. We appreciate the support
from commenters. As a result, we have
adopted a new certification criterion in
§ 170.315(g)(10), to replace
§ 170.315(g)(8) and made several
revisions to address public comment as
discussed further below. Although the
certification criteria finalized at
§ 170.315(g)(10) will replace
§ 170.315(g)(8), we note that
§ 170.315(g)(8) is not removed from
regulation. We maintain § 170.315(g)(8)
and have finalized in § 170.550(m) that
ONC–ACBs can issue certificates for
§ 170.315(g)(8) during the transition
period to § 170.315(g)(10) for 24 months
after the publication date of the final
rule.
Comments. Commenters suggested
dividing the § 170.315(g)(10) criterion
into two separate criteria for single and
multiple patients.
Response. We appreciate the
feedback. We decline to split the
certification criterion into two criteria.
In consideration of comments and for
clarity, we have improved the
organization of the final certification
requirements for API-enabled ‘‘read’’
services for single and multiple patients
by separating the criterion into distinct
sections in the regulation text.
Comments. Several commenters
supported referencing a standard for
API-enabled ‘‘read’’ services for
multiple patients, including the HL7®
FHIR® Bulk Data Access
Implementation Guide Release 1.0.0.
Commenters felt that omitting a
standard in the criterion would
undermine interoperability for APIenabled ‘‘read’’ services for multiple
patients.
Response. We thank commenters for
their feedback. To enable consistent
health IT implementation of APIenabled ‘‘read’’ services for multiple
patients, we have finalized the adoption
of the Bulk IG, including mandatory
support for the ‘‘group-export’’
‘‘OperationDefinition’’ in
§ 170.215(a)(4). As part of the Program,
we require Health IT Modules presented
for testing and certification to conform
to the Bulk IG implementation
specification finalized in
§ 170.215(a)(4). The adoption of an
implementation specification for APIenabled ‘‘read’’ services for multiple
patients in § 170.215(a)(4) is responsive
to stakeholder concerns and further
supports our intent to prevent ‘‘special
effort’’ for the use of APIs as mandated
in section 4002 of the Cures Act.
Furthermore, based on our analysis, we
believe the ‘‘group-export’’
‘‘OperationDefinition,’’ as defined in the
Bulk IG implementation specification is
essential to fulfill the use cases
PO 00000
Frm 00102
Fmt 4701
Sfmt 4700
envisioned for API-enabled ‘‘read’’
services for multiple patients. The
‘‘group-export’’ ‘‘OperationDefinition’’
will allow application developers
interacting with § 170.315(g)(10)certified Health IT Modules to export
the complete set of FHIR resources as
constrained by the US Core IG adopted
in § 170.215(a)(2) and USCDI adopted in
§ 170.213 for a pre-defined cohort of
patients. We appreciate commenters’
recommendations, and agree that
coalescing around a common
implementation specification will
advance interoperability of API-enabled
‘‘read’’ services for multiple patients.
We provide further discussion of the
supported search operations, data
response, and authentication and
authorization requirements for APIenabled ‘‘read’’ services for multiple
patients in the sections below.
Comments. Commenters requested
clarification that API-enabled ‘‘read’’
services for multiple patients are not
intended for patient end users and that
health IT developers and health care
providers are therefore not expected to
supply a patient-facing mechanism for
these requests.
Response. We appreciate the feedback
from commenters. API-enabled ‘‘read’’
services for multiple patients are not
intended for patient end users because
API-enabled ‘‘read’’ services for
multiple patients allow for the
disclosure of multiple patients’ records,
and individual patients only have the
right to access their own records or
records of patients to whom they are the
personal representative (45 CFR
164.502(f)(1)). Health IT Modules are
not required to support patient-facing
API-enabled ‘‘read’’ services for
multiple patients for the purposes of
this certification criterion.
Comments. One commenter suggested
we modify the language that defines the
purpose of this section to provide more
clarity, specifically the term ‘‘services.’’
The commenter also requested we
include the scope of cohorts we
intended to address in ‘‘population
services.’’
Response. We appreciate the feedback
from commenters. The term ‘‘services’’
includes all § 170.315(g)(10)-related
technical capabilities included in a
Health IT Module presented for testing
and certification. The API-enabled
‘‘read’’ services for single patients is
intended to support EHI requests and
responses for individual patient records
and the API-enabled ‘‘read’’ services for
multiple patients is intended to support
EHI requests and responses for multiple
patients’ records. The scope of patient
cohorts for ‘‘population services’’ can
include various groups defined at the
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
discretion of the user of the API-enabled
‘‘read’’ services for multiple patients,
including, for example, a group of
patients that meet certain disease
criteria or fall under a certain insurance
plan. We have adopted the Bulk IG in
§ 170.215(a)(4) to support this function
as discussed further below. The
technical capabilities expected of APIrelated Health IT Modules presented for
testing and certification are included in
§ 170.315(g)(10).
Comments. Commenters requested
clarification for information blocking
policies and health care provider
obligations for API-enabled ‘‘read’’
services for multiple patients.
Response. We appreciate the request
for clarification from commenters. We
clarify that the criteria finalized in
§ 170.315(g)(10) includes the technical
capabilities that must be met by APIrelated Health IT Modules presented for
testing and certification. The
information blocking policies in this
rule do not compel health care
providers to implement Health IT
Modules certified to requirements in
170.315(g)(10). We note that other
programs, like CMS value-based
programs, may require the use of this
technology. We refer commenters to the
information blocking section (VIII) for
additional clarification.
Comments. Commenters asked us to
clarify the relationship between the APIenabled ‘‘read’’ services for single and
multiple patients in § 170.315(g)(10) and
the ‘‘EHI export’’ criterion in
§ 170.315(b)(10).
Response. We thank commenters for
this request. The API criterion in
§ 170.315(g)(10) is separate from the
‘‘EHI export’’ criterion in
§ 170.315(b)(10). While both criteria aim
to advance health IT in alignment with
the Cures Act’s goal of ‘‘complete
access, exchange, and use of all
electronically accessible health
information’’ for both single and
multiple patients, the criteria
specifications and Condition and
Maintenance of Certification
requirements are distinct.
The ‘‘EHI export’’ criterion focuses on
a Health IT Module’s ability to
electronically export EHI, as defined in
§ 171.102, that can be stored at the time
of certification by the product, of which
the Health IT Module is a part. In
contrast, the finalized API criterion in
§ 170.315(g)(10) focuses on ‘‘read’’
services for single and multiple patients
for the USCDI (adopted in § 170.213)
Data Elements and US Core IG (adopted
in § 170.215(a)(2)) FHIR profiles.
Additionally, the ‘‘EHI export’’ criterion
finalized in § 170.315(b)(10) does not
mandate conformance to standards or
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
implementation specifications, whereas
the criterion finalized in
§ 170.315(g)(10) requires conformance to
several standards and implementation
specifications, as described further
below. We refer to the finalized ‘‘EHI
export’’ criterion in § 170.315(b)(10) for
additional information.
Comments. Several commenters
supported requiring Health IT Modules
to support API-enabled ‘‘write’’ services
for single patients, either in this rule or
in a future rulemaking. One commenter
suggested including a subset of data
classes for ‘‘write’’ services for single
patients, including ‘‘patient goals,’’
‘‘patient-generated health data’’
(including patient-reported outcomes,
patient generated device data, and
questionnaires), and ‘‘care plans.’’
Another commenter suggested adding a
list of required operations (‘‘read’’ and
‘‘write’’) to USCDI elements, limited to
‘‘read’’ for this rulemaking.
Response. We appreciate the feedback
from commenters. While we support the
interest in API-enabled ‘‘write’’ services,
we have not adopted such requirements.
We do not believe API-enabled ‘‘write’’
services have reached a level of a
maturity to warrant the addition of
regulatory conformance requirements
within the Program. We encourage
industry to consider all the implications
and implementation requirements for
API-enabled ‘‘write’’ services, and
perform additional API-enabled ‘‘write’’
pilot implementations to demonstrate
the readiness for API-enabled ‘‘write’’
services in the testing and certification
of Health IT Modules. Additionally, we
encourage industry to expand existing
profiles like the US Core IG to support
‘‘write’’ services.
Comments. Commenters
recommended including a requirement
for event logging for ‘‘read’’ services for
single and multiple patients.
Response. We appreciate the
recommendation from commenters. The
2015 Edition Privacy and Security
Certification Framework requires that if
a Health IT Module includes
capabilities for certification under
§ 170.315(g)(10) it needs to be certified
to several privacy and security
certification criteria including auditable
events in § 170.315(d)(2) or auditing
actions on health information in
§ 170.315(d)(10).
Comments. Commenters noted that
references to APIs focus exclusively on
RESTful query and ignore ‘‘push’’
elements of the FHIR API, such as
‘‘POST,’’ ‘‘PUT,’’ and FHIR messaging.
Response. We appreciate the feedback
from commenters. While we support the
interest in the ‘‘push’’ operations of the
FHIR standard, including ‘‘POST,’’
PO 00000
Frm 00103
Fmt 4701
Sfmt 4700
25743
‘‘PUT,’’ and FHIR messaging, we have
not adopted such requirements for the
Program. We encourage industry
stakeholders to further consider all the
requirements and implications for the
‘‘push’’ operations of the FHIR standard,
develop use cases, perform additional
API-enabled ‘‘push’’ pilot
implementations, create or expand
implementation profiles to support
‘‘push’’ services, and demonstrate the
utility of the ‘‘push’’ operations of the
FHIR standard for future potential
inclusion in the Program.
i. Data Response
We proposed in 84 FR 7482 in
§ 170.315(g)(10)(i) that Health IT
Modules presented for testing and
certification must be capable of
responding to requests for data on single
and multiple patients in accordance
with proposed standards and
implementation specifications adopted
in § 170.215(a)(1) (HL7® FHIR® DSTU 2
(v1.0.2–7202)), specified in the
proposed § 170.215(a)(2) (API Resource
Collection in Health (ARCH) Version 1),
and consistent with the proposed
specifications in § 170.215(a)(3)
(Argonaut Data Query Implementation
Guide Version 1.0.0). We clarified that
all data elements indicated as
‘‘mandatory’’ and ‘‘must support’’ by the
proposed standards and implementation
specifications must be supported and
would be in scope for testing.
Comments. Commenters expressed
concern with fully enforcing
‘‘mandatory’’ and ‘‘must’’ support
requirements of the referenced
specifications and implementation
guides, explaining that developers may
be required to support requirements that
are not applicable to the stated intended
use of the Health IT Module(s).
Response. We appreciate the concerns
expressed by commenters. We clarify
that the standards and implementation
specifications adopted and required for
this certification criterion were created
by standards developing organizations
to support a wide range of health care
use cases.
We have finalized in
§ 170.315(g)(10)(i)(A) that Health IT
Modules presented for testing and
certification must be capable of
responding to requests for a single
patient’s data according to the standard
adopted in § 170.215(a)(1) and
implementation specification adopted
in § 170.215(a)(2), including the
mandatory capabilities described in ‘‘US
Core Server CapabilityStatement,’’ for
each of the Data Elements included in
the standard adopted in § 170.213. This
requirement will enable Health IT
Modules to support US Core IG
E:\FR\FM\01MYR3.SGM
01MYR3
25744
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
operations for each of the Data Elements
included in the USCDI.
Additionally, we have finalized in
§ 170.315(g)(10)(i)(B) that Health IT
Modules presented for testing and
certification must be capable of
responding to requests for data on
multiple patients as a group according
to the standard adopted in
§ 170.215(a)(1) and implementation
specifications adopted in § 170.215(a)(2)
and § 170.215(a)(4), for each of the Data
Elements included in the standard
adopted in § 170.213. Finally, we clarify
that the use of the ‘‘SMART Backend
Services: Authorization Guide’’ section
of the implementation specification
adopted in § 170.215(a)(4) is required
for API ‘‘read’’ services for multiple
patients as finalized in
§ 170.315(g)(10)(i)(B) and described
above.
For requests for data on multiple
patients, we note that the
implementation specification adopted
in § 170.215(a)(4) has optional
parameters which can be used to filter
results to a period of time, or one or
several specified FHIR resources. While
these parameters are not required for
testing and certification, we encourage
health IT developers to adopt these
parameters and other
‘‘OperationDefinitions’’ to enhance the
utility of requests for data on multiple
patients.
ii. Search Support
We proposed in 84 FR 7482 in
§ 170.315(g)(10)(ii) that Health IT
Modules presented for testing and
certification must be capable of
responding to all of the ‘‘supported
searches’’ specified in the proposed
implementation specification in
§ 170.215(a)(4) (Argonaut Data Query
Implementation Guide Server). We
reiterated that Health IT Modules
presented for testing and certification
and as implemented must support all
search capabilities for single and
multiple patients in accordance with the
proposed implementation specification
in § 170.215(a)(4). We also requested
comments on the minimum ‘‘search’’
parameters that would need to be
supported for the ’’DocumentReference’’
and ‘‘Provenance’’ HL7® FHIR®
resources.
Comments. Most commenters
supported this proposal. One
commenter recommended only
requiring the ‘‘target’’ query parameter
for the ‘‘Provenance’’ FHIR resource,
and ‘‘patient’’ and ‘‘date’’ query
parameters for the
‘‘DocumentReference’’ FHIR resource.
One commenter suggested deferring this
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
certification requirement until a
standard is published by HL7.
Response. We appreciate the feedback
from commenters. Since we have not
finalized the adoption of the ARCH as
proposed in § 170.215(a)(2), and instead
rely on the search parameters specified
in the US Core IG finalized in
§ 170.215(a)(2) and Bulk IG finalized in
§ 170.215(a)(4), the comments related to
the specific ‘‘Provenance’’ and
‘‘DocumentReference’’ FHIR resources
are no longer applicable. We have
finalized in § 170.315(g)(10)(ii)(A) that
Health IT Modules presented for testing
and certification must support all search
capabilities for single patients according
to the implementation specification
adopted in § 170.215(a)(2), including
support for all mandatory capabilities
included in the ‘‘US Core Server
CapabilityStatement.’’ Additionally, we
have finalized in § 170.315(g)(10)(ii)(B)
that Health IT Modules presented for
testing and certification must respond to
search requests for multiple patients’
data consistent with the search criteria
included in the implementation
specification adopted in § 170.215(a)(4).
We clarify that the scope of data
available in the data responses defined
in § 170.315(g)(10)(i) must be supported
for single and multiple patient searches
via the supported search operations
finalized in § 170.315(g)(10)(ii).
Additionally, we clarify for the
requirements finalized in
§ 170.315(g)(10)(i) and (ii) that all data
elements indicated as ‘‘mandatory,’’
‘‘must support,’’ by the standards and
implementation specifications must be
supported and are in scope for testing.
iii. Application Registration
We proposed in 84 FR 7483 in
§ 170.315(g)(10)(iii) that Health IT
Modules presented for testing and
certification must be capable of enabling
apps to register with an ‘‘authorization
server.’’ As proposed, this would have
required an API Technology Supplier to
demonstrate its registration process, but
would not have required conformance
to a standard. We requested comment at
84 FR 7483 on whether to require the
OAuth 2.0 Dynamic Client Registration
Protocol (RFC 7591) 103 standard as the
sole method to support registration for
the proposed certification criterion in
§ 170.315(g)(10), and requested
comment on whether we should require
its support as part of the final rule’s
certification criterion. Additionally, we
requested comment at 84 FR 7483 on
whether to include application
registration in the testing and
certification of apps executed within an
103 https://tools.ietf.org/html/rfc7591.
PO 00000
Frm 00104
Fmt 4701
Sfmt 4700
API Data Provider’s clinical
environment.
Comments. Commenters generally
supported that Health IT Modules
presented for testing and certification
must enable apps to register with an
authorization server. Some commenters
supported excluding application
registration from the testing and
certification of apps executed within an
API Data Provider’s clinical
environment.
Response. We appreciate the feedback
from commenters. Given the
overwhelming support, we have
finalized in § 170.315(g)(10)(iii) that
Health IT Modules presented for testing
and certification must enable apps to
register with an authorization server.
We clarify that Health IT Modules
presented for testing and certification
must support application registration
regardless of the scope of patient search
utilized by the application (e.g., single
or multiple). This certification criterion
requires a health IT developer, as
finalized in the Condition of
Certification requirements section
below, to demonstrate its registration
process, but does not require
conformance to a standard.
Additionally, we expect that apps
executed within an implementer’s
clinical environment will be registered
with an authorization server, but we do
not require a health IT developer to
demonstrate its registration process for
these ‘‘provider-facing’’ apps. We
reiterate that we believe implementers
of § 170.315(g)(10)-certified Health IT
Modules should have the discretion to
innovate and execute various methods
for application registration within a
clinical environment.
Comments. Commenters provided a
mix of support and opposition for
requiring the OAuth 2.0 Dynamic Client
Registration Protocol (RFC 7591)
standard as the sole method of
application registration. Some
commenters felt that the Program
should require dynamic client
registration in the context of patientaccess scenarios only, and others felt the
standard is not ready for mandated
adoption in the Program. Commenters
opposed to requiring the OAuth 2.0
Dynamic Client Registration Protocol
(RFC 7591) felt that not specifying a
standard would allow flexibility for
different innovative registration
approaches to be used and developed.
Other commenters suggested there
should be an option for data holders to
support dynamic client application
registration if the data holder prefers
that approach, including support for
dynamic application registration via
trusted networks.
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
Response. We appreciate the feedback
from commenters. We have not adopted
a requirement for Health IT Modules
presented for testing and certification to
support the OAuth 2.0 Dynamic Client
Registration Protocol (RFC 7591)
standard. We agree with commenters
and believe that requiring registration
without a mandated standard will allow
registration models to develop further.
We encourage health IT developers to
coalesce around the development and
implementation of a common standard
for application registration with an
API’s authorization server.
Comments. Commenters suggested
permitting implementers of
§ 170.315(g)(10)-certified Health IT
Modules to undertake a review of thirdparty applications prior to permitting
them to connect to the implementers’
deployed APIs.
Response. We appreciate the
suggestion from commenters. The
requirement that health IT developers
must enable an application to register
with the § 170.315(g)(10)-certified
Health IT Module’s authorization server
only applies for the purposes of
demonstrating technical conformance to
the finalized certification criterion and
Condition and Maintenance of
Certification requirements. The
practices by all parties (including
implementers of Health IT Modules)
other than developers of certified Health
IT Modules are not in scope for this
certification criterion nor the associated
Condition and Maintenance of
Certification requirements. All other
practices associated with third-party
application review or ‘‘vetting’’ by
implementers must not violate the
information blocking provision
described in section VIII of this
preamble and applicable laws and
regulations. In general, an implementer
of § 170.315(g)(10)-certified Health IT
Modules (e.g., health care providers)
would be allowed to review third-party
applications the implementer intends to
use for its own business use (e.g., a
third-party decision-support application
used by the health care provider in the
course of furnishing care) prior to
permitting the third-party applications
to connect to the implementer’s
deployed APIs within its enterprise and
clinical users’ workflow. However,
implementers of § 170.315(g)(10)certified Health IT Modules (e.g., health
care providers) are not permitted to
review or ‘‘vet’’ third-party applications
intended for patient access and use (see
section VII.C.6 of this preamble). We
clarify that the third-party application
registration process that a health IT
developer must meet under this
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
criterion is not a form of review or
‘‘vetting’’ for purposes of this criterion.
Comments. Commenters requested
clarity on whether the ‘‘EHR Launch’’
scenario was out of scope for testing
during registration with an
authorization server.
Response. Commenters referred to the
‘‘EHR Launch’’ scenario, which is the
‘‘launch-ehr’’ ‘‘SMART on FHIR Core
Capability’’ included in the
implementation specification adopted
in § 170.215(a)(3). Health IT Modules
presented for testing and certification
must enable all apps that utilize the
SMART IG ‘‘launch-standalone’’
‘‘SMART on FHIR Core Capability’’ to
register with an authorization server.
We reiterate that the application
registration requirement finalized in
§ 170.315(g)(10)(iii) does not require
conformance to a standard or
implementation specification. We
envision that apps using only the
SMART IG ‘‘launch-ehr’’ ‘‘SMART on
FHIR Core Capability’’ will be tightly
integrated with § 170.315(g)(10)certified Health IT Modules deployed by
implementers, and will be able to
accommodate registration processes that
best suit the needs of those
implementers. Additionally, while we
do not require conformance to a
standard or implementation
specification for application
registration, we clarify that Health IT
Modules presented for testing and
certification are required to support
application registration functions to
enable authentication and authorization
as finalized in § 170.315(g)(10)(v).
iv. Secure Connection
We proposed in 84 FR 7483 in
§ 170.315(g)(10)(iv) that Health IT
Modules presented for testing and
certification must be capable of
establishing a secure and trusted
connection with an application
requesting patient data in accordance
with the proposed § 170.215(a)(5) (HL7
SMART Application Launch Framework
Implementation Guide Release 1.0.0),
including mandatory support for
‘‘Standalone Launch’’ and ‘‘EHR
Launch’’ modes.
Comments. Commenters asked for
clarification around where ‘‘Standalone
Launch’’ and ‘‘EHR Launch’’
capabilities are required, suggesting that
‘‘Standalone Launch’’ support be used
exclusively for patient access and ‘‘EHR
Launch’’ support be used exclusively for
provider/clinician access. They also
noted that testing and certification of
‘‘Standalone Launch’’ would not be a
valid use case and should be excluded
from the certification criterion.
PO 00000
Frm 00105
Fmt 4701
Sfmt 4700
25745
Response. We appreciate the feedback
from commenters. The SMART IG
‘‘Standalone Launch’’ and ‘‘EHR
Launch’’ modes can be used by both
provider- and patient-facing
applications. We refer to the adopted
implementation specification in
§ 170.215(a)(3) for clarification of
certification requirements for the
SMART IG. We have finalized in
§ 170.315(g)(10)(iv)(A) that Health IT
Modules presented for testing and
certification must demonstrate the
ability to establish a secure and trusted
connection with an application
requesting data for a single patient in
accordance with the implementation
specifications adopted in § 170.215(a)(2)
and (a)(3). We amended this text from
the Proposed Rule by adding the US
Core IG implementation specification
adopted in § 170.215(a)(2) because the
US Core IG specifically requires
Transport Layer Security 1.2 (RFC
5246) 104 or higher for all transmissions
not taking place over a secure network
connection. Pursuant to this adopted
implementation specification, we will
test Health IT Modules for support for
all ‘‘SMART on FHIR Core Capabilities’’
including both ‘‘launch-ehr’’ and
‘‘launch-standalone.’’
Additionally, we have finalized in
§ 170.315(g)(10)(iv)(B) that Health IT
Modules presented for testing and
certification must demonstrate the
ability to establish a secure and trusted
connection with an application
requesting data for multiple patients in
accordance with the implementation
specification adopted in § 170.215(a)(4).
The implementation specification
adopted in § 170.215(a)(4) has several
sections, but for testing and certification
to this criterion, we specifically require
conformance to, but not limited to, the
‘‘SMART Backend Services:
Authorization Guide.’’
v. Authentication and Authorization
We proposed in 84 FR 7483 in
§ 170.315(g)(10)(v) that Health IT
Modules presented for testing and
certification must demonstrate the
ability to perform user authentication,
user authorization, and issue a refresh
token valid for a period of at least 3
months during its initial connection
with an application to access data for a
single patient in accordance with the
proposed standard in § 170.215(b)
(OpenID Connect Core 1.0 incorporating
errata set 1) and the proposed
implementation specification in
§ 170.215(a)(5) (HL7® SMART
Application Launch Framework
Implementation Guide Release 1.0.0).
104 https://tools.ietf.org/html/rfc5246.
E:\FR\FM\01MYR3.SGM
01MYR3
25746
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
Additionally, we proposed in
§ 170.315(g)(10)(vi) that Health IT
Modules presented for testing and
certification must demonstrate the
ability of an application to access data
for a single patient and multiple
patients during subsequent connections
of applications capable of storing a
client secret, in accordance with the
proposed implementation specification
in § 170.215(a)(5) (HL7 SMART
Application Launch Framework
Implementation Guide Release 1.0.0),
without requiring the user to reauthorize and re-authenticate when a
valid refresh token is supplied.
Additionally, we proposed in 84 FR
7483 that Health IT Modules presented
for testing and certification must
demonstrate it can issue a new refresh
token to an application, valid for a
period of at least 3 months.
Comments. A majority of commenters
supported that Health IT Modules
presented for testing and certification
must demonstrate the ability to perform
user authentication, user authorization,
and issue a refresh token valid for a
period of at least 3 months. Some
commenters noted that the OAuth 2.0
implementation guide does not
recommend servers provide refresh
tokens to public/non-confidential
applications.
Response. We thank commenters for
their feedback. Given the general
support and in response to these
comments, we have consolidated the
proposed requirements in
§ 170.315(g)(10)(v) and
§ 170.315(g)(10)(vi) as a revised set of
requirements finalized in
§ 170.315(g)(10)(v). Specifically, we
have finalized requirements for
authentication and authorization for
patient and user scopes in
§ 170.315(g)(10)(v)(A) and requirements
for authentication and authorization for
system scopes in § 170.315(g)(10)(v)(B).
We have focused the revised
requirements around authentication and
authorization scopes to remove any
confusion associated with requirements
for single and multiple patients. We
have finalized authentication and
authorization requirements for first time
connections for patient and user scopes
in § 170.315(g)(10)(v)(A)(1). This
include the requirement finalized in
§ 170.315(g)(10)(v)(A)(1)(i) that Health
IT Modules presented for testing and
certification must demonstrate that
authentication and authorization occurs
during the process of granting access to
patient data in accordance with the
implementation specification adopted
in § 170.215(a)(3) and standard adopted
in § 170.215(b). It also includes the
requirement finalized in
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
§ 170.315(g)(10)(v)(A)(1)(ii) that an
application capable of storing a client
secret must be issued a refresh token
valid for a period of no less than three
months. Additionally, we have finalized
authentication and authorization
requirements for subsequent
connections for patient and user scopes
in § 170.315(g)(10)(v)(A)(2). This
includes the requirements finalized in
§ 170.315(g)(10)(v)(A)(2)(i) that Health
IT Modules presented for testing and
certification must demonstrate that
access is granted to patient data in
accordance with the implementation
specification adopted in § 170.215(a)(3)
without requiring re-authorization and
re-authentication when a valid refresh
token is supplied by the application. It
also includes the requirements finalized
in § 170.315(g)(10)(v)(A)(2)(ii) that an
application capable of storing a client
secret must be issued a new refresh
token valid for a new period of no less
than three months.
Additionally, we have finalized
requirements for authentication and
authorization for system scopes in
§ 170.315(g)(10)(v)(B), which require
that Health IT Modules presented for
testing and certification must
demonstrate that authentication and
authorization occurs during the process
of granting an application access to
patient data in accordance with the
‘‘SMART Backend Services:
Authorization Guide’’ section of the
implementation specification adopted
in § 170.215(a)(4) and the application
must be issued a valid access token. We
note that for system scopes, applications
will likely be authorized via a prior
authorization negotiation and agreement
between applications and Health IT
Modules.
For clarity, we use the term ‘‘an
application capable of storing a client
secret’’ to refer to ‘‘confidential clients.’’
In the definition at RFC 6749,
‘‘confidential’’ clients are ‘‘clients
capable of maintaining the
confidentiality of their credentials (e.g.,
client implemented on a secure server
with restricted access to the client
credentials), or capable of secure client
authentication using other means.’’ RFC
6749 also defines ‘‘public’’ clients as
‘‘clients incapable of maintaining the
confidentiality of their credentials (e.g.,
clients executing on the device used by
the resource owner, such as an installed
native application or a web browserbased application), and incapable of
secure client authentication via any
other means.’’ We clarify that the term
‘‘an application capable of storing a
client secret’’ specifically excludes
‘‘public’’ clients.
PO 00000
Frm 00106
Fmt 4701
Sfmt 4700
Additionally, we clarify that Health IT
Modules will be explicitly tested for US
Core IG operations using authentication
and authorization tokens acquired via
the process described in the
implementation specification adopted
in § 170.215(a)(3), and Health IT
Modules will be explicitly tested for
Bulk IG operations using authentication
and authorization tokens acquired via
the process described in the
implementation specification adopted
in § 170.215(a)(4).
Comments. One commenter
recommended that ONC introduce a
Condition of Certification requirement
to ensure that implementers of
§ 170.315(g)(10)-certified Health IT
Modules can obtain automated systemlevel access to all API calls from the API
servers offered by the Certified Health
IT Developers (e.g., via the SMART
Backend Services authorization guide),
with ‘‘system/*.*’’ scopes.
Response. We decline to accept the
recommendation to require ‘‘system/
*.*’’ scopes as a certification
requirement in § 170.315(g)(10). Insofar
as the commenter requested that Health
IT Modules make available automated
system-level scopes for the purposes of
an ‘‘all information export,’’ we have
finalized a similar requirement in
§ 170.315(b)(10), and refer the
commenter to that section for additional
detail. Additionally, we have finalized
in § 170.315(g)(10)(v)(B) that Health IT
Modules must perform authentication
and authorization during the process of
granting an application access to patient
data using system scopes in accordance
with the ‘‘SMART Backend Services:
Authorization Guide’’ section of the
implementation specification adopted
in § 170.215(a)(4). We recognize that the
capabilities supported by ‘‘SMART
Backend Services: Authorization Guide’’
could be used for many other use cases
that are currently not required by the
criterion. We clarify that implementers
of Health IT Modules are not prohibited
from configuring Health IT Modules to
support the backend ‘‘system’’ scope
described in the ‘‘SMART Backend
Services: Authorization Guide’’ section
of the Bulk IG adopted in § 170.215(a)(4)
for API-enabled ‘‘read’’ services defined
in the US Core IG. Indeed, we strongly
encourage health IT developers to
support these use cases as they develop
in order to make full use of the certified
functions of Health IT Modules and
advance the state of the industry.
Comments. Commenters suggested
specifying that refresh tokens apply
exclusively to patient access scenarios,
noting that there are too many security
risks to allow persistent tokens for
provider-facing applications.
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
Additionally, commenters suggested
permitting Health IT Modules to
support the revocation of refresh tokens
in appropriate scenarios to address
legitimate security concerns.
Response. We appreciate the feedback
from commenters. We do not agree that
there are too many security risks to
allow refresh tokens to be used for
provider-facing applications. Refresh
tokens are commonly used in health
care and other industries to provide
seamless integration of systems with
other applications while reducing the
need for the burdensome process of reauthentication and re-authorization. We
expect implementers of § 170.315(g)(10)certified Health IT Modules to have the
capability of revoking refresh tokens
where appropriate. Additionally, we
clarify that implementers of
§ 170.315(g)(10)-certified Health IT
Modules are not prohibited from
changing the length of refresh tokens for
users of the API including patients and
providers to align with their
institutional policies. However,
implementers of § 170.315(g)(10)certified Health IT Modules should be
mindful of information blocking
provisions applicable to them and that
requiring patients to re-authenticate and
re-authorize at a high frequency could
inhibit patient access and implicate
information blocking.
Comments. Commenters suggested
amending the time from three months to
12 months. One commenter agreed that
the patient token should be valid for
three months, but suggested the
provider token be limited to 24 hours.
One commenter suggested requiring reauthentication every time information is
sought via APIs.
Response. We appreciate the feedback
from commenters. We believe a refresh
token valid for a period of three months
is sufficient to balance persistent access
and security concerns. Moreover, for
subsequent connections of applications
capable of storing a client secret, Health
IT Modules are required to issue a new
refresh token valid for a new period of
no shorter than three months per the
API certification criterion requirement
finalized in § 170.315(g)(10)(v)(A)(2)(ii).
Given this requirement, we anticipate
that the user’s application will renew its
refresh token (valid for a new period of
three months) every time the user
actively engages with the application.
We believe this justifies a refresh token
length for a moderate period of no
shorter than three months rather than a
long period of 12 months suggested by
commenters. Additionally, as stated
above, implementers of § 170.315(g)(10)certified Health IT Modules are not
prohibited from changing the length of
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
refresh tokens for users of the API,
including patients and providers, to
align with their institutional policies.
Further, implementers of
§ 170.315(g)(10)-certified Health IT
Modules are not prohibited from
implementing their § 170.315(g)(10)certified Health IT Modules in
accordance with their organizational
security policies and posture, including
by instituting policies for reauthentication and re-authorization
(e.g., providers and/or patients could
always be required to re-authenticate
and re-authorize after a set number of
refresh tokens have been issued). We
also note that we have finalized a
requirement in § 170.315(g)(10)(vi) that
a Health IT Module’s authorization
server must be able to revoke an
authorized application’s access at a
patient’s direction. This required
capability will enable patients to
definitively revoke an application’s
authorization to receive their EHI until
reauthorized, if ever, by the patient.
Comments. Commenters suggested
creating a more robust assessment
process for identity management,
including adding additional criteria for
identity proofing, authentication, and
authorization, and ensuring software
developers do not act in a way that
could inhibit patient control of their
data.
Response. We appreciate the feedback
and suggestions. Although we agree that
identity proofing is an important
practice, we did not include
requirements for identity proofing in the
Proposed Rule, and have not finalized
requirements for identity proofing in
response to this comment. We note that
the certification criterion finalized in
§ 170.315(g)(10) only applies to health
IT developers. Given the scope of the
Program, we believe that mandating
identity proofing, which are generally
business practices performed by
organizations and other entities, is not
something appropriate to require of
health IT developers. We note that per
the requirements of the 2015 Edition
Privacy and Security Certification
Framework, health IT developers with
Health IT Modules certified to
§ 170.315(g)(7) through (g)(10) are
required to certify to § 170.315(d)(1),
which includes requirements for
authentication, access control, and
authorization. Additionally,
authentication and authorization for use
of § 170.315(g)(10)-certified Health IT
Modules are included in the
requirements finalized in
§ 170.315(g)(10)(v). We appreciate the
sentiment expressed by commenters,
and have created thorough and rigorous
requirements to ensure adequate privacy
PO 00000
Frm 00107
Fmt 4701
Sfmt 4700
25747
and security capabilities are present in
§ 170.315(g)(10)-certified Health IT
Modules. Regarding the request for
certification requirements to ensure that
software developers do not act in a way
that could inhibit patient control of
their data, we refer to the requirement
finalized in § 170.315(g)(10)(A), which
requires that patients have the ability to
grant applications authorization to
access their EHI using granular FHIR
Resources of their choice to comply
with the adopted implementation
specification in § 170.215(a)(3), and
requirement in § 170.315(g)(10)(vi),
which requires that a Health IT
Module’s authorization server must be
able to revoke an authorized
application’s access at a patient’s
direction.
Comments. Several commenters
suggested that patients be able to specify
refresh token length, if desired, and
revoke a third-party application’s access
at any time. Commenters suggested that
clear information be provided to
patients whether authorized access is
one-time or ongoing.
Response. We appreciate the feedback
from commenters. Refresh tokens are an
OAuth 2.0 concept, and are largely
opaque to the end user. However, we
clarify that patients are not prohibited
from changing the length of refresh
tokens to the degree this option is
available to them. Additionally,
pursuant to these comments, and to
ensure patients have the ability to
revoke an application’s access to their
EHI at any time, we have finalized an
additional certification requirement in
§ 170.315(g)(10)(vi) which requires that
a Health IT Module’s authorization
server must be able to revoke an
authorized application’s access at a
patient’s direction. We have finalized
this as a functional requirement to allow
health IT developers the ability to
implement it in a way that best suits
their existing infrastructure and allows
for innovative models for authorization
revocation to develop. Additionally, per
the requirement finalized in
§ 170.315(g)(10)(v)(A), Health IT
Modules must perform authorization
conformant with the implementation
specification adopted in § 170.215(a)(3),
including all ‘‘SMART on FHIR Core
Capabilities.’’ The ‘‘permission-offline’’
‘‘SMART on FHIR Core Capability’’
includes support for the ‘‘offline_
access’’ scope. Importantly, the
implementation specification adopted
in § 170.215(a)(3) requires that patients
have the ability to explicitly enable the
‘‘offline_access’’ scope during
authorization. If the ‘‘offline_access’’
scope is not enabled by patients,
patients will be required to re-
E:\FR\FM\01MYR3.SGM
01MYR3
25748
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
authenticate and re-authorize an
application’s access to their EHI after
the application’s access token expires.
Comments. Commenters suggested
providing the ability for implementers
of § 170.315(g)(10)-certified Health IT
Modules to perform token introspection
using services enabled by health IT
developers to ensure that additional
resource servers can work with the same
access tokens and authorization policies
as the resource servers provided by API
Technology Suppliers.
Response. We appreciate the feedback
from commenters. Based on feedback,
we have finalized in
§ 170.315(g)(10)(vii) that Health IT
Modules presented for testing and
certification must demonstrate the
ability to receive and validate a token
issued by its authorization server, but
we did not specify a standard for this
requirement. Token introspection will
allow implementers of § 170.315(g)(10)certified Health IT Modules to use API
authorization servers and authorization
tokens with various resource servers.
This functionality has the potential to
reduce complexity for implementers of
§ 170.315(g)(10)-certified Health IT
Modules authorizing access to several
resource servers and reduces the overall
effort and subsequent use of
§ 170.315(g)(10)-certified Health IT
Modules consistent with the goals of
section 4002 of the Cures Act to enable
the use of APIs without ‘‘special effort.’’
Although we do not specify a standard
for token introspection, we encourage
industry to coalesce around using a
common standard, like OAuth 2.0
Token Introspection (RFC 7662).105
Comments. One commenter expressed
concerns with the privacy and security
of APIs, and nefarious actors posing as
legitimate health facilities.
Response. Regarding the privacy and
security of APIs, the Standardized API
for Patient and Population Services
certification criterion finalized in
§ 170.315(g)(10) requires Health IT
Modules presented for testing and
certification to implement the
implementation specification adopted
in § 170.215(a)(3), which is based on the
OAuth 2.0 security standard that is
widely used in industry. The
implementation of OpenID Connect
paired with OAuth 2.0 allows health
care providers to securely deploy and
manage APIs consistent with their
organizational practices. Health care
providers retain control over how their
workforce and patients authenticate
when interacting with the API. For
example, a patient may be required to
use the same credentials (e.g., username
105 https://tools.ietf.org/html/rfc7662.
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
and password) they created and use to
access their EHI through a patient portal
as they do when authorizing an
application to access their data. Since
patients complete the authentication
process directly with their health care
provider, no application will have
access to their credentials. There is little
protection software can provide to
protect against nefarious actors posing
as legitimate health facilities, however,
we believe that implementing the
security controls and safeguards
described above, along with the privacy
and security requirements required
under the 2015 Edition Privacy and
Security Certification Framework, will
help to protect Health IT Modules
against nefarious actors. Additionally,
the protections required for ePHI in
Health IT Modules offered by health IT
developers acting as business associates
of health care providers remain
unchanged.
vi. Technical Documentation
We proposed in 84 FR 7484 in
§ 170.315(g)(10)(vii) that an API
Technology Supplier needed to provide
complete documentation via a publicly
accessible hyperlink, without additional
access requirements, for all aspects of its
§ 170.315(g)(10)-certified API, especially
for any unique technical requirements
and configurations, including API
syntax, function names, required and
optional parameters supported and their
data types, return variables and their
types/structures, exceptions and
exception handling methods and their
returns, the software components and
configurations necessary for an
application to successfully interact with
the API and process its response(s), and
all applicable technical requirements
and attributes necessary for an
application to be registered with an
authorization server. Additionally, we
proposed in 84 FR 7484 to remove the
‘‘terms of use’’ documentation
provisions in the API certification
criteria adopted in § 170.315(g)(7)
through (g)(9) in order to reflect the
Condition of Certification requirements
and not be duplicative of the terms and
conditions transparency Condition of
Certification requirements proposed in
84 FR 7485.
Comments. Commenters generally
supported the requirements for this
criterion as proposed. Some
commenters suggested technical
documentation should be limited to
descriptions of how the API differs from
the utilized standards and
implementation specifications, like
HL7® FHIR® and the SMART IG.
Response. We appreciate the feedback
from commenters. We did not make
PO 00000
Frm 00108
Fmt 4701
Sfmt 4700
substantive changes to the requirements
proposed in § 170.315(g)(10)(vii). We
have finalized these requirements
§ 170.315(g)(10)(viii). We recognize that
our formal adoption of the HL7 FHIR
standard and the associated
implementation specifications
referenced in § 170.315(g)(10) would be
consistent across all Health IT Modules
presented for certification. As a result,
there may be minimal additional
documentation needed for these
capabilities beyond what is already
documented in adopted standards and
implementation specifications. We
expect health IT developers to disclose
any additional data their
§ 170.315(g)(10)-certified Health IT
Module supports in the context of the
adopted standards and implementation
specifications. The content of technical
documentation required to meet this
certification criteria are described in
requirements finalized in
§ 170.315(g)(10)(viii)(A). We expect
these and any additional documentation
relevant to the use of a health IT
developer’s § 170.315(g)(10)-certified
Health IT Module to be made available
via a publicly accessible hyperlink
without preconditions or additional
steps to meet the requirement as
finalized in § 170.315(g)(10)(viii)(B).
d. API Condition of Certification
Requirements
i. Key Terms
We proposed in 84 FR 7477 to adopt
new definitions for ‘‘API Technology
Supplier,’’ ‘‘API Data Provider,’’ and
‘‘API User’’ in § 170.102 to describe the
stakeholders relevant to our proposals.
Comments. The majority of
commenters recommended updating
definitions and providing examples for
the key terms, including API User. Most
commenters recommended dividing
‘‘API User’’ into two categories: ‘‘FirstOrder Users,’’ to include patients, health
care providers, and payers that use
apps/services that connect to API
technology, and ‘‘Third-Party Users,’’ to
include third-party software developers,
and developers of software applications
used by API Data Providers.
Response. We thank commenters for
their feedback. We note that in this
section we use the terms proposed in
§ 170.102 that we finalized in
§ 170.404(c) with added quotation
marks for emphasis and clarity. We
considered separating the term ‘‘API
User’’ into distinct terms for developers
of software applications and other users,
such as patients and health care
providers. However, we determined that
this distinction was unnecessary from a
regulatory perspective. Narrowing our
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
definitions to distinct subgroups could
exclude unforeseen stakeholders that
emerge in a future API ecosystem. The
term ‘‘API User’’ was intended to
describe stakeholders that interact with
the certified API technology either
directly (e.g., to develop third-party
apps/services) or indirectly (e.g., as a
user of a third-party app/service).
Based on suggestions to revise the
proposed key terms, we have renamed
the term ‘‘API Data Provider’’ to ‘‘API
Information Source’’ finalized in
§ 170.404(c) to make clear which party
is the source and responsible for the EHI
(as in ‘‘the source of the information is
the health care provider’’), and ‘‘API
Technology Supplier’’ to ‘‘Certified API
Developer’’ finalized in § 170.404(c) to
more clearly refer to health IT
developers with Health IT Modules
certified to any of the API criteria under
the Program. Rather than keeping ‘‘API
technology’’ an undefined term, we
renamed it to ‘‘certified API technology’’
and finalized a definition in
§ 170.404(c). Additionally, we amended
the definition of ‘‘API User’’ for clarity
in § 170.404(c) to ‘‘API User means a
person or entity that creates or uses
software applications that interact with
the ‘certified API technology’ developed
by a ‘Certified API Developer’ and
deployed by an ‘API Information
Source.’’’ Additionally, we did not
include the non-exhaustive list of
examples of ‘‘API User’’ in the
definition finalized in § 170.404(c).
Instead, we rely on preamble to provide
guidance for examples of ‘‘API Users’’
rather than appearing to limit the
regulatory definition to these examples.
We interpret that ‘‘API Users’’ can
include, but are not limited to, software
developers, patients, health care
providers, and payers. We simplified
the definition of ‘‘API Information
Source’’ in § 170.404(c) to ‘‘API
Information Source means an
organization that deploys ‘certified API
technology’ created by a ‘Certified API
Developer.’’’ We revised the definition
of ‘‘Certified API Developer’’ in
§ 170.404(c) to ‘‘Certified API Developer
means a health IT developer that creates
the ‘certified API technology’ that is
certified to any of the certification
criteria adopted in § 170.315(g)(7)
through (10).’’ We added the definition
of ‘‘certified API technology’’ in
§ 170.404(c) as ‘‘certified API
technology means the capabilities of
Health IT Modules that are certified to
any of the API-focused certification
criteria adopted in § 170.315(g)(7)
through (10).’’ For ease of reference and
to clarify that these terms only apply to
the Condition and Maintenance of
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
Certification requirements, we have
finalized these revised definitions in
§ 170.404(c). In this and other sections
of the rule, we use the original proposed
terms in the proposal and comment
summaries, and the finalized terms in
our responses.
Comments. Some commenters
suggested ONC allow flexibility for
instances where stakeholders may meet
the definition of more than one key
term, and others recommended
restricting stakeholders from meeting
the definition of more than one key
term. Commenters expressed concern
with the complexity of key terms in the
Proposed Rule, and confusion with the
interaction of these terms with other
criteria within the rule.
Response. We thank commenters for
expressing their concern about
stakeholders being able to serve more
than one role under the definitions
proposed in § 170.102 that we have
finalized in § 170.404(c). We do not
believe it is practical to restrict persons
or entities to just one definition. We
anticipate situations where a person or
entity can serve more than one role. For
example, a large health care system
could purchase and deploy ‘‘certified
API technology’’ as an ‘‘API Information
Source’’ and have ‘‘API Users’’ on staff
that create or use software applications
that interact with the ‘‘certified API
technology.’’ Additionally, a health IT
developer could serve as a ‘‘Certified
API Developer’’ that creates ‘‘certified
API technology’’ for testing and
certification and as an ‘‘API User’’ when
it creates software applications that
connect to ‘‘certified API technology.’’
We clarify that a stakeholder will meet
a role defined in § 170.404(c) based on
the context in which they are acting. For
example, only health IT developers
(when acting in the context of a
‘‘Certified API Developer’’) are required
to comply with these API Condition and
Maintenance of Certification
requirements.
Comments. Commenters expressed
concern that ONC exceeded its
regulatory authority by implicating
physicians in the definition of ‘‘API
Data Providers.’’
Response. We remind commenters
that these definitions were created to
describe relationships between key API
stakeholders and to help describe the
Condition and Maintenance of
Certification requirements. We clarify
that health care providers are not
covered by the Condition and
Maintenance of Certification
requirements to which the definitions
apply in § 170.404(c) unless they are
serving the role of a ‘‘Certified API
Developer.
PO 00000
Frm 00109
Fmt 4701
Sfmt 4700
25749
ii. Scope and Compliance
We proposed in 84 FR 7485 that the
Condition and Maintenance of
Certification requirements proposed in
§ 170.404 apply to API Technology
Suppliers with Health IT Modules
certified to any API-focused certification
criteria adopted in the proposed
§ 170.315(g)(7) through (11).
Comments. Commenters agreed that
the proposed applicability for the
Condition of Certification requirements
proposed in § 170.404 should be limited
to health IT developers certified to any
API-focused criteria adopted in the
proposed § 170.315(g)(7) through (11).
One commenter requested clarification
whether non-certified internally
developed laboratory systems would be
subject to this requirement.
Response. We thank stakeholders for
their comments. We have generally
finalized the scope and compliance for
the Condition and Maintenance of
Certification requirements as proposed
in § 170.404 with one modification.
Given that we have not adopted the
certification criterion proposed for
adoption in § 170.315(g)(11), the scope
of the Condition and Maintenance of
Certification requirements apply only to
health IT developers with Health IT
Modules certified to any of the APIfocused criteria finalized in
§ 170.315(g)(7) through (10). The
Condition and Maintenance of
Certification requirements finalized in
§ 170.404 do not apply to health IT
developers not seeking certification, nor
do they apply to health IT developers
certified to solely non-API-focused
criteria. Additionally, we clarify that the
Condition and Maintenance of
Certification requirements only apply to
practices of Certified API Developers
with respect to the capabilities included
in § 170.315(g)(7) through (10). In other
words, the Condition and Maintenance
of Certification requirements would not
apply to practices of Certified API
Developers with respect to non-certified
capabilities or practices associated with,
for example, the immunization
reporting certification criterion in
§ 170.315(f)(1), because that criterion is
not one of the API-focused criteria
finalized in § 170.315(g)(7) through (10).
However, health IT developers should
understand that other requirements in
this final rule, especially those related
to information blocking, could still
apply to its business practices
associated with non-API-focused
certification criteria.
iii. General
We proposed in 84 FR 7485 in
§ 170.404(a)(1) to adopt the Cures Act’s
E:\FR\FM\01MYR3.SGM
01MYR3
25750
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
API Condition of Certification
requirement stating that an API
Technology Supplier must, through an
API, ‘‘provide access to all data
elements of a patient’s electronic health
record to the extent permissible under
applicable privacy laws.’’ We then
subsequently proposed in 84 FR 7485 to
interpret ‘‘all data of a patient’s
electronic health record’’ for the
purposes of the scope of this API
Condition of Certification requirement
to include the proposed ARCH standard,
its associated implementation
specifications, and the policy expressed
around the data elements that must be
supported by § 170.315(g)(10)-certified
APIs.
Comments. Commenters supported
our adoption of the Cures Act’s API
Condition of Certification requirement.
For the purposes of the scope of data
covered under this API Condition of
Certification requirement, most
commenters recommended defining ‘‘all
data elements’’ as the Data Elements
referenced by the USCDI and the FHIR
resources in the FHIR US Core
Implementation Guide STU 3 (US Core
IG) for FHIR Release 4. We received
comments recommending additional
data elements to be included that we
discuss in our comment summary for
the ARCH in the ‘‘API Standards,
Implementation Specifications, and
Certification Criterion’’ section of this
final rule.
Response. We appreciate stakeholder
feedback. The § 170.315(g)(10)
certification criterion requirement and
associated standards and
implementation specifications will
enable secure, standards-based API
access to a specific set of information.
We have finalized that a Certified API
Developer must publish APIs, and must
allow EHI from such technology to be
accessed, exchanged, and used without
special effort through the use of APIs or
successor technology or standards, as
provided for under applicable law,
including providing access to all data
elements of a patient’s electronic health
record to the extent permissible under
applicable privacy laws, in
§ 170.404(a)(1). Additionally, for the
purposes of meeting this portion of the
Cures Act’s API Condition of
Certification requirement, we clarify the
data required and that must be
supported to demonstrate conformance
to the final § 170.315(g)(10) certification
criterion (including all of its associated
standards and implementation
specifications) constitutes ‘‘all data
elements of a patient’s electronic health
record to the extent permissible under
applicable privacy laws.’’ Regarding the
recommendation by commenters that
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
the scope of ‘‘all data elements’’ include
the Data Elements of the standard
adopted in § 170.213 and FHIR
resources referenced by the
implementation specification adopted
in § 170.215(a)(2), we note that both the
standard and implementation
specification are included in the
interpretation of ‘‘all data elements of a
patient’s electronic health record to the
extent permissible under applicable
privacy laws’’ above. We note that this
specific interpretation does not extend
beyond the API Condition and
Maintenance of Certification
requirements finalized in § 170.404 and
cannot be inferred to reduce the scope
or applicability of other Cures Act
Conditions of Certification or the
information blocking policies, which
include a larger scope of data.
iv. Transparency Conditions
We proposed in 85 FR 7485 and 7486
in § 170.404(a)(2)(i) to require API
Technology Suppliers make available
complete business and technical
documentation via a publicly accessible
hyperlink, including all terms and
conditions for use of its API technology.
Additionally, we proposed that API
Technology Suppliers must make clear
to the public the timing information
applicable to their disclosures in order
to prevent discrepancies between an
API Technology Supplier’s public
documentation and its direct
communication to customers.
Additionally, we requested comment at
84 FR 7486 on whether the expectation
for API Technology Suppliers to make
necessary changes to transparency
documentation should be finalized in
regulation text, or whether this would
be standard practice as part of making
this documentation available.
Comments. We received overall
support from commenters for the need
to make complete business and
technical documentation available via a
publicly accessible hyperlink. We did
not receive public comment on whether
we should formally include public
disclosure requirements for regular
updates to business and technical
documentation in regulatory text.
Response. We thank commenters for
their support to make complete business
and technical documentation available
via a publicly accessible hyperlink. We
have finalized in § 170.404(a)(2)(i) that a
Certified API Developer must publish
complete business and technical
documentation, including the
documentation described in
§ 170.404(a)(2)(ii), via a publicly
accessible hyperlink that allows any
person to directly access the
information without any preconditions
PO 00000
Frm 00110
Fmt 4701
Sfmt 4700
or additional steps. We made small
adjustments to § 170.404(a)(2)(i) to
reflect the changes in API definitions
finalized in § 170.404(c).
Given that we did not receive public
comment on whether we should
formally include public disclosure
requirements for regular updates to
business and technical documentation
in regulatory text, so we have finalized
in 170.404(a)(4)(iii)(B) that a Certified
API Developer must provide notice and
a reasonable opportunity for API
Information Sources and API Users to
update their applications to preserve
compatibility with certified API
technology and to comply with
applicable terms and conditions. We
note that notice could include a public
notice made available on a website, but
also encourage Certified API Developers
to contact API Information Source
customers and registered API Users
(application developers) directly prior
to updating business and technical
documentation.
(A) Terms and Conditions
We proposed in 84 FR 7485 in
§ 170.404(a)(2)(ii)(A) that API
Technology Suppliers must publish all
terms and conditions for its API
technology, including any restrictions,
limitations, obligations, registration
process requirements, or other similar
requirements that would be needed to:
Develop software applications to
interact with the API technology;
distribute, deploy, and enable the use of
software applications in production
environments that use the API
technology; use software applications,
including to access, exchange, and use
EHI by means of the API technology; use
any EHI obtained by means of the API
technology; and register software
applications. Additionally, we proposed
in § 170.404(a)(2)(ii)(B) that any and all
fees charged by an API Technology
Supplier for the use of its API
technology must be described in
detailed, plain language, including the
persons or classes of persons to whom
the fee applies; the circumstances in
which the fee applies; and the amount
of the fee, which for variable fees must
include the specific variable(s) and
methodology(ies) that will be used to
calculate the fee.
Comments. We received support from
stakeholders regarding the transparency
of ‘‘all terms and conditions’’ associated
with the use of API technology.
Response. We thank commenters for
their support. We believe this terms and
conditions transparency requirement
would ensure that API Information
Sources and API Users do not
experience ‘‘special effort’’ in the form
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
of unnecessary costs or delays in
obtaining the terms and conditions for
certified API technology. Furthermore,
we believe full transparency is
necessary to ensure that API Users have
a thorough understanding in advance of
any terms or conditions that might
apply to them once they have
committed to developing software that
interacts with certified API technology.
We have finalized in
§ 170.404(a)(2)(ii)(A) that Certified API
Developers must publish all terms and
conditions for its certified API
technology, including any fees,
restrictions, limitations, obligations,
registration process requirements or
other similar requirements as
enumerated in § 170.404(a)(2)(ii)(A)(1)
through (6). We made small adjustments
to § 170.404(a)(2)(ii)(A) to reflect the
changes in API definitions finalized in
§ 170.404(c). Additionally, we moved
‘‘App developer verification’’ from its
proposed location in
§ 170.404(a)(2)(ii)(C) and finalized it in
§ 170.404(b)(1) to improve organization.
We added the phrase ‘‘Used to verify the
authenticity of API Users’’ to the
regulation text finalized in
§ 170.404(a)(2)(ii)(A)(5) for consistency
with our proposed policy. We also
moved the phrase ‘‘Register software
applications’’ from its proposed location
in § 170.404(a)(2)(ii)(A)(5) to the
finalized location in
§ 170.404(a)(2)(ii)(A)(6) and revised the
phrase for consistency. Additionally, we
made small changes to the regulation
text finalized in § 170.404(a)(2)(ii)(A)(1)
through § 170.404(a)(2)(ii)(A)(6) for
clarity.
Comments. We received both support
and disagreement for the requirement to
publish transparency documentation on
API fees. Some commenters felt
transparency documentation of API fees
should be limited to value-added
services, because those are the only
permitted fees applicable to API Users,
and the other permitted fees applicable
to API Data Providers (usage-based fees
and fees to recover costs for
development, deployment, and
upgrades) would be included in
contractual documentation with their
customers.
Response. We recognize that some
commenters had concern with making
documentation on permitted fees
publicly available. We believe that
transparent documentation of all
permitted fees is necessary to maintain
a competitive marketplace and ensure
that fees are reasonably related to the
development, deployment, upgrade, and
use of certified API technology. Fee
transparency will also enable API
Information Sources and API Users to
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
shop for certified API technology and
related services that meet their needs.
We have finalized in
§ 170.404(a)(2)(ii)(B) that any and all
fees charged by a Certified API
Developer for the use of its certified API
technology must be described in
detailed, plain language, including all
material information described in
§ 170.404(a)(2)(ii)(B)(1) through (3).
Additionally, we made small
adjustments to § 170.404(a)(2)(ii)(B) to
reflect the changes in API definitions
finalized in § 170.404(c).
Comments. Multiple stakeholders
expressed the need to include consumer
protections in the terms and conditions
documentation with an explanation
about how EHI will be used.
Response. This provision of the
Condition of Certification requirements
does not prohibit additional content or
limit the type of content a Certified API
Developer may include in its terms and
conditions. A Certified API Developer
would be permitted to include
consumer protections in their terms and
conditions documentation.
Additionally, we clarify these API
Conditions of Certification requirements
only apply to Certified API Developers.
As such, API Information Sources and
API Users are not required by the API
Condition of Certification requirements
to publish any terms and conditions,
including those that apply to consumer
protections.
v. Fees Conditions
(A) General Fees Prohibition
We proposed in § 170.404(a)(3)(i)(A)
that API Technology Suppliers would
be prohibited from imposing fees
associated with API technology as a
Condition of Certification requirement.
In establishing this general prohibition,
ONC was mindful of the need for API
Technology Suppliers to recover their
costs and to earn a reasonable return on
their investments in providing API
technology that has been certified under
the Program. Accordingly, we identified
categories of ‘‘permitted fees’’ in 84 FR
7487 that API Technology Suppliers
would be permitted to charge and still
be compliant with the Condition of
Certification and Program requirements.
These include the proposed
§ 170.404(a)(3)(ii) (permitted fee for
developing, deploying, and upgrading
API technology), proposed
§ 170.404(a)(3)(iii) (permitted fee to
recover costs of supporting API usage
for purposes other than patient access),
and proposed § 170.404(a)(3)(iv)
(permitted fee for value-added services).
We also proposed in 84 FR 7487 that
API Technology Suppliers would not be
PO 00000
Frm 00111
Fmt 4701
Sfmt 4700
25751
permitted to impose fees on any person
in connection with an API Technology
Supplier’s work to support the use of
API technology to facilitate a patient’s
ability to access, exchange, or use their
EHI. We also clarified that while the
proposed permitted fees set the
boundaries for the fees API Technology
Suppliers would be permitted to charge
and to whom those permitted fees could
be charged, the proposed regulations
did not specify who could pay the API
Technology Supplier’s permitted fee.
Rather, we proposed general conditions
that an API Technology Supplier’s
permitted fees must satisfy in
§ 170.404(a)(3)(i)(B)(1) through (4), and
requested comment in 84 FR 7488 on
these conditions and whether they
sufficiently restrict fees from being used
to prevent access, exchange, and use of
EHI through APIs without special effort.
We include detailed discussions of
permitted fees and related conditions
below.
Comments. Some commenters
supported the clear prohibition on API
fees outside those fees permitted in
§ 170.404(a)(3)(ii) through (iv),
expressing that the language in the rule
would prevent confusion regarding
allowable and restricted fees. Some
commenters noted that prohibiting fees
would enable patients to exercise their
HIPAA right of access without
experiencing cost barriers, and remove
cost barriers to hospitals and health care
facilities using APIs for interoperability.
Commenters noted that the proposals
addressed many of the access and
pricing practices that API Technology
Suppliers engaged in to limit data
exchange and gain a competitive
advantage. Commenters noted that API
Technology Supplier pricing practices
often create barriers to entry and
competition for apps that health care
providers seek to use. Some commenters
supported the proposal that prohibits
API Technology Suppliers from
charging fees to API Users.
Response. We thank stakeholders for
their support of and feedback on our
proposal. We have finalized in
§ 170.404(a)(3)(i)(A) that all fees related
to certified API technology not
otherwise permitted by § 170.404(a)(3)
are prohibited from being imposed by a
Certified API Developer. Additionally,
we have modified and reorganized these
Condition of Certification requirements
for clarity. We have renamed the title for
the section from the Proposed Rule to
‘‘Fees conditions’’ because the
requirements include both permitted
and prohibited fees. We have updated
the terminology used in this section to
reflect changes made to the terminology
used throughout the API Condition of
E:\FR\FM\01MYR3.SGM
01MYR3
25752
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
Certification requirements and finalized
in § 170.404(c). We finalized a
requirement in § 170.404(a)(3)(i)(A) that
permitted fees in paragraphs
§ 170.404(a)(3)(ii) and § 170.404(a)(3)(iv)
may include fees that result in a
reasonable profit margin in accordance
with the information blocking Costs
Exception provision finalized in
§ 170.302. We clarify that any fee that is
not covered by those exceptions would
be suspect under the information
blocking provision, and would equally
not be permitted by this API Condition
of Certification requirement.
This general prohibition on fees as
finalized in § 170.404(a)(3)(i)(A) is
meant to ensure that Certified API
Developers do not engage in pricing
practices that create barriers to entry
and competition for apps and API-based
services that health care providers seek
to use. Such activities are inconsistent
with the goal of enabling API-based
access, exchange, and use of EHI by
patients and other stakeholders without
special effort. As finalized, this general
prohibition allows for three categories of
permitted fees (§ 170.404(a)(3)(ii)
through (iv)) to allow Certified API
Developers to recover their costs and to
earn a reasonable return on their
investments in providing certified API
technology while being compliant with
the Condition of Certification and
Program requirements.
Comments. Some commenters were
critical of our proposals, expressing
concerns that the proposed policies may
stifle relationships between API
Technology Suppliers and application
developers. Others expressed concern
that the proposed fee structure would
place undue burden on API Data
Providers, and that ONC should instead
consider regulations that allow fee
sharing across stakeholders. Some
commenters stated that ONC should
remove all prohibitions, and allow for
market pricing and revenue sharing.
Several commenters, many of whom
were providers and provider
organizations, requested additional
clarity and guidance regarding the API
fees that can be charged under the
Condition of Certification requirements.
Some commenters requested
clarification regarding whether an API
Data Provider can transfer costs to API
Users. Other commenters requested
clarification regarding when it is (and is
not) appropriate for an API User to be
charged a fee in connection with use of
API technology. A few commenters
requested that ONC provide a chart that
lists all actors, all types of costs, and
who can charge whom.
Response. We appreciate this
feedback from commenters. These
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
‘‘general conditions,’’ as finalized in
§ 170.404(a)(3)(i) and discussed above,
will facilitate API-based access,
exchange, and use of EHI by patients
and other stakeholders without special
effort. We disagree with commenters
that the permitted fee policies will stifle
relationships between Certified API
Developers and API Users.
Cumulatively, these final policies create
guardrails to protect against anticompetitive practices and reinforce the
independence that we believe API
Information Sources should have to
establish relationships with API Users.
Furthermore, we believe these fee
policies are necessary in light of the
potential for Certified API Developers to
use their market position and control
over certified API technology to engage
in discriminatory practices that create
special effort and barriers to the use of
certified API technology. We continue
to receive evidence that some Certified
API Developers are engaging in
practices that create special effort for the
use of certified API technology. These
practices include fees that create
barriers to entry or competition as well
as rent-seeking and other opportunistic
behaviors. For example, we have
received feedback that some Certified
API Developers are conditioning access
to technical documentation on revenue
sharing or royalty agreements that bear
no plausible relation to the costs
incurred by the Certified API Developer
to provide or enable the use of certified
API technology. We are also aware of
discriminatory pricing policies that
have the purpose or effect of excluding
competitors from the use of APIs and
other interoperability elements despite
the fact that the API Information Source
would like to partner with and use these
competitive, best-of-breed services.
These practices from Certified API
Developers close off the market to
innovative applications and services
that could empower patients and enable
providers to deliver greater value and
choice to health care consumers and
other service providers.
We note that Certified API Developers
and API Users have the ability to
collaborate and form relationships, so
long as these relationships do not
conflict with any of the provisions of
this final rule or other applicable
Federal and State laws and regulations.
Further, we clarify that while the
permitted fees set the boundaries for the
fees Certified API Developers are
permitted to charge and to whom those
permitted fees can be charged, they do
not prohibit who may pay the Certified
API Developer’s permitted fee. In other
words, these conditions limit the party
PO 00000
Frm 00112
Fmt 4701
Sfmt 4700
from which a Certified API Developer
may require payment, but they do not
speak to who may pay the fee. For
example, a permitted practice under
these conditions could include a
relationship or agreement where an API
User or other party offered to pay the fee
owed by the API Information Source to
a Certified API Developer. This is an
acceptable practice because the fee is
first agreed upon between the Certified
API Developer and API Information
Source and subsequently paid by the
API Information Source directly or by a
third party on behalf of the API
Information Source. We note that fees
charged for ‘‘value-added services’’ can
arise between an API Information
Source and Certified API Developer or
API User. As a general matter, we note
that stakeholders should be mindful of
other Federal and State laws and
regulations that could prohibit or limit
certain types of relationships involving
remuneration.
We provide additional clarity and
guidance regarding the API fees that can
be charged under the Condition of
Certification requirements in the
sections that follow. Additionally, we
appreciate commenters’ requests for
clarification, including a chart of actors
and costs. We will take this comment
into consideration as we develop
educational materials to help explain
the permitted fees conditions finalized
in § 170.404(a)(3).
Comments. Commenters suggested
that one way to clarify the limits on API
fees would be to require API
Technology Suppliers provide fee
information to ONC and for ONC to
make this information publicly
available, including information on
individual pricing transactions.
Response. We appreciate the
recommendation from commenters to
require Certified API Developers to
provide fee information to ONC. We
view fee transparency as a responsibility
that a Certified API Developer can fulfill
without having to send a listing of its
API fees to ONC. We have finalized the
provision in § 170.404(a)(2)(ii) that a
Certified API Developer must publish
all terms and conditions for its certified
API technology, including any fees.
Specifically, we have finalized in
§ 170.404(a)(2)(ii)(B) that any and all
fees charged by a Certified API
Developer for the use of its certified API
technology must be described in
detailed plain language, including the
persons or classes of persons to whom
the fee applies; the circumstances in
which the fee applies; and the amount
of the fee, which for variable fees must
include the specific variable(s) and
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
methodology(ies) that will be used to
calculate the fee.
(B) Certified API Developer Permitted
Fees Conditions
We proposed general conditions in
§ 170.404(a)(3)(i)(B)(1) through (4) that
an API Technology Supplier’s permitted
fees must satisfy in order for such fees
to be expressly permitted.
Comments. We received support for
the general conditions for permitted fees
from commenters. Some commenters
expressed appreciation for the
guardrails and transparency of the
permitted fees. Under the first
condition, commenters sought clarity on
the nature and extent of some of the
permissible fees an API Technology
Supplier can charge and how to model
such fees, specifically regarding the
‘‘objective and verifiable’’ criteria.
Another commenter supported the
second condition that fees must be
reasonably related to API Technology
Supplier’s costs of supplying and, if
applicable, supporting the API
technology to the API Data Provider,
especially in situations where
physicians may also develop APIs or
support apps.
However, some commenters
expressed concern with the third
condition to reasonably allocate fees
across all customers of the API.
Commenters explained that fees could
not be reasonably allocated across all
customers of the API, because the
number of customers will change over
time. We received no comments on the
fourth condition that API Technology
Suppliers must ensure that fees are not
based on whether the requestor or other
person is a competitor who will be
using the API technology in a way that
facilitates competition. In addition to
the general permitted fees proposed,
some commenters recommended clear
fee exemption for any health
information provided or reported by a
practice for the purpose of meeting
reporting requirements.
Response. We appreciate feedback
from commenters. We have finalized
these general conditions for permitted
fees in § 170.404(a)(3)(i)(B) with some
modifications as described further
below. We have finalized that for all
permitted fees, a Certified API
Developer must: (1) Ensure that such
fees are based on objective and
verifiable criteria that are uniformly
applied to all similarly situated API
Information Sources and API Users; (2)
Ensure that such fees imposed on API
Information Sources are reasonably
related to the Certified API Developer’s
costs of supplying certified API
technology to, and if applicable, support
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
certified API technology for, API
Information Sources; (3) Ensure that
such fees for supplying, and if
applicable, supporting certified API
technology are reasonably allocated
among all similarly situated API
Information Sources; and (4) Ensure that
such fees are not based on whether API
Information Sources or API Users are
competitors, potential competitors, or
will be using the certified API
technology in a way that facilitates
competition with the Certified API
Developer. We have revised the term
‘‘substantially similar’’ to ‘‘similarly
situated’’ in § 170.404(a)(3)(i)(B)(1) for
clarity and to align with changes made
in § 171.302. Additionally, in response
to comments and to align with changes
made in § 171.302 and
§ 170.404(a)(3)(i)(B)(1), we have revised
the term ‘‘substantially similar’’ to
‘‘similarly situated’’ in
§ 170.404(a)(3)(i)(B)(3). We emphasize
that this provision is meant to prevent
one customer or a specific group of
customers to whom the certified API
technology is supplied or for whom it is
supported from bearing an unreasonably
high cost compared to other customers,
which could lead to ‘‘special effort’’ for
accessing and using APIs. We believe
the final policy achieves the same goal
as proposed and provides clearer
guidelines for the regulated community
to follow. Additionally, we have revised
the phrase ‘‘classes of persons and
requests’’ to ‘‘API Information Sources
and API Users’’ in
§ 170.404(a)(3)(i)(B)(1) to clearly express
the actors being charged fees by
Certified API Developers. Additionally,
we have revised the sentence structure
and grammar in § 170.404(a)(3)(i)(B)(2)
through (4) for simplification.
In response to comments requesting
clarity on the nature and extent of
permissible fees a Certified API
Developer can charge and how a
Certified API Developer should model
such fees, specifically regarding the
‘‘objective and verifiable’’ requirement
finalized in § 170.404(a)(3)(i)(B)(1), we
emphasize that there will be significant
variability in the fee models and
specific fees charged by each Certified
API Developer. Our goal with the
requirement that fees be ‘‘objective and
verifiable’’ is to require Certified API
Developers to apply fee criteria that,
among other things, will lead the
Certified API Developer to come to the
same conclusion with respect to the
permitted fee’s amount each time it
administers a fee to an API Information
Source or API User. Accordingly, the fee
cannot be based on the Certified API
PO 00000
Frm 00113
Fmt 4701
Sfmt 4700
25753
Developer’s subjective judgment or
discretion.
Comments. A few commenters
suggested that ONC allow API Data
Providers the ability to recoup the costs
for upgrading technology.
Response. This comment appears to
misunderstand the scope and
applicability of ONC’s authority with
respect to these Condition of
Certification requirements. We clarify
that these Condition of Certification
requirements apply only to Certified
API Developers. We note that similar to
any IT investment, API Information
Sources (as ‘‘health care providers’’)
would generally be expected to recover
these costs through fees administered
while delivering health care services.
Additionally, if an API Information
Source were to recoup such costs they
would need to do so consistent with the
information blocking exceptions and
other applicable laws and regulations.
Comments. Some commenters
requested that ONC conduct evaluations
after the implementation of the rule and
use the results to drive future policy.
Some commenters recommended a
study to evaluate the real-world cost of
APIs used by health systems in areas
such as clinical decision support,
payments, machine learning, and
precision medicine. Commenters also
suggested ONC conduct a study on
whether these regulations improve
patient access to their EHI.
Response. We appreciate the
evaluation recommendations. We will
consider these suggestions as we
implement and administer the Program.
(C) Certified API Developer Prohibited
Fees
We proposed in 84 FR 7595 in
§ 170.404(a)(3)(iii)(B) that permitted
fees would not include costs associated
with intangible assets (including
depreciation or loss of value), except the
actual development or acquisition costs
of such assets. Additionally, we
proposed in § 170.404(a)(3)(iii)(C) that
permitted fees would not include
opportunity costs, except for the
reasonable forward-looking cost of
capital.
Comments. We did not receive any
comments specific to the proposal for
costs associated with intangible assets
other than actual development or
acquisition costs of such assets.
Response. We moved the proposed
§ 170.404(a)(3)(iii)(B) and (C) to the
general conditions for permitted fees
finalized in § 170.404(a)(3)(i)(C)(1) and
(2), respectively, because they are
general conditions on permitted fees
rather than conditions for ‘‘Recovering
API usage costs.’’ We did not make
E:\FR\FM\01MYR3.SGM
01MYR3
25754
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
other changes to the proposed
regulation text in these two sections
other than updating terms to the
finalized definitions in § 170.404(c).
Additionally, in the discussion of the
Fees Exception in this final rule
(VIII.D.2.b), we discussed that one
commenter expressed concern that the
overlap between the Fees Exception and
the Licensing Exception creates the
potential for actors to recover the same
costs twice. The commenter explained
that licensing of IP is intended to recoup
the costs of development of that IP, so
where the IP is an interoperability
element, the costs reasonably incurred
for its development should be
incorporated into the royalty rate. The
commenter recommended that we be
clearer that, in these circumstances,
only a single recovery is permitted. In
order to address this comment and align
the API permitted fees with related
provisions finalized in the Fees
Exception (§ 170.302(a)(2)(vi)) and
Licensing Exception
(§ 170.303(b)(2)(iv)), we have added and
finalized § 170.404(a)(3)(i)(C)(3), which
states that the permitted fees in this
section cannot include any costs that
that led to the creation of IP if the actor
charged a royalty for that IP pursuant to
§ 170.303 and that royalty included the
development costs for the creation of
the IP. We refer readers to the ‘‘Basis for
Fees Condition’’ sub-section within
section VIII.D.2.b for a more detailed
discussion of the rationale for this
addition.
(i) General Examples of Prohibited Fees
As discussed in the Proposed Rule in
84 FR 7481 and finalized in
§ 170.404(a)(3)(i)(A), any API-related fee
imposed by a Certified API Developer
that is not expressly permitted is
prohibited. In the Proposed Rule, we
provided the following non-exhaustive
examples of fees for services that
Certified API Developers would be
prohibited from charging, and reiterate
them here in the final rule for clarity:
(1) Any fee for access to the
documentation that a Certified API
Developer is required to publish or
make available under this Condition of
Certification requirement.
(2) Any fee for access to other types
of documentation or information that a
software developer may reasonably
require to make effective use of certified
API technology for any legally
permissible purpose.
(3) Any fee in connection with any
services that would be essential to a
developer or other person’s ability to
develop and commercially distribute
production-ready applications that use
certified API technology. These services
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
could include, for example, access to
‘‘test environments’’ and other resources
that an application developer would
need to efficiently design and develop
apps. The services could also include
access to distribution channels if they
are necessary to deploy productionready software and to production
resources, such as the information
needed to connect to certified API
technology (e.g., service base URLs) or
the ability to dynamically register with
an authorization server.
Comments. At least one commenter
expressed concern about the openended nature of the examples of
prohibited fees we provided in the
Proposed Rule. In particular, that any
fee in connection with any services that
would be essential to a developer or
other person’s ability to develop and
commercially distribute productionready applications that use API
technology would be prohibited. They
stated that if the example were not more
clearly defined and scoped, it could be
used by API Users to create
requirements for API Technology
Suppliers beyond what would normally
be considered necessary to successfully
deploy apps in production. They
requested ONC more clearly define
‘‘essential services’’ in final rulemaking
or withdraw the reference.
Response. We appreciate the feedback
from commenters. We disagree with
commenters that the examples are too
broad. We believe that in some cases
they need to be general because of the
diverse and varied practices that could
be used by Certified API Developers to
create special effort to use certified API
technology. While we understand that
the generality of the example regarding
‘‘essential services’’ may at first appear
difficult for Certified API Developers to
follow and, per the commenter, could be
creatively used by an API User to
request more support than necessary,
we offer the following as additional
guidance: A Certified API Developer is
best positioned to know what an API
User, for example, needs to have access
to and do programmatically in order for
the API User’s application to be
developed and commercially distributed
as production-ready for use with
certified API technology. From a
Certified API Developer’s perspective, if
that requires any number of mandatory
steps (e.g., passing tests in sandbox/test
environment, conducting a demo,
submitting documentation or
paperwork) in order for the application
to be production-ready for use with
certified API technology, then fees
associated with those mandatory steps
are prohibited. Conversely, fees for
requirements beyond what a Certified
PO 00000
Frm 00114
Fmt 4701
Sfmt 4700
API Developer considers necessary to
successfully deploy applications in
production are considered supplemental
to the development, testing, and
deployment of software applications
that interact with certified API
technology, and are permitted fees for
value added services as finalized in
§ 170.404(a)(3)(iv).
(D) Record-Keeping Requirements
We proposed in § 170.404(a)(3)(v) that
API Technology Suppliers must keep for
inspection detailed records of all API
technology fees charged, all costs
incurred to provide API technology to
API Data Providers, methodologies used
to calculate such fees, and the specific
costs to which such fees are attributed.
We requested comment in 84 FR 7492
on whether these requirements provide
adequate traceability and accountability
for costs permitted under this API
Condition of Certification and whether
to require more detailed accounting
records or prescribe specific accounting
standards.
Comments. A majority of commenters
expressed concerns with the level of
granularity proposed for record keeping
in § 170.404(a)(3)(v). These commenters
stated that the required recordkeeping
would exceed documentation performed
for any other purpose. Some
commenters stated that the requirement
for health IT developers to track who
pays fees and how fees enter the system
will cause significant administrative
burden, especially on smaller vendors
or vendors with business models that
require less operational overhead.
Additionally, they stated that the
requirement for clients to maintain and
potentially publicly disclose records of
fees for inspection would place a
burden on IT providers, and could
potentially allow bigger companies to
engage in practices such as predatory
pricing. Commenters suggested ONC
have a more scaled-back method, and
simply allow patients the ability to
access their EHI without charge. These
commenters recommended focusing on
a good conduct approach rather than
prescriptive requirements.
Response. We thank commenters for
their feedback and perspective. We
moved § 170.404(a)(3)(v) to
170.404(a)(3)(i)(D) for better
organization because this provision
applies to the permitted fee Condition of
Certification requirements finalized in
§ 170.404(a)(3)(ii) through (iii). We have
finalized in § 170.404(a)(3)(i)(D) that
Certified API Developers must keep
detailed records for inspection of all
fees charged, all costs incurred to
provide certified API technology to API
Information Sources, methodologies
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
used to calculate such fees, and the
specific costs to which fees are
attributed. Considering the feedback on
perceived burden, we believe
transparency and documentation of API
fees is necessary to mitigate unfair
pricing practices that may stifle
innovation or otherwise create barriers
to the goals of enabling API-based
access, exchange, and use of EHI
without special effort. Further, we
believe that the accounting practices
already used by health IT developers
will largely support the health IT
developer to meet this requirement.
Examples of these practices by health IT
developers include the methods used to
track their own investments, determine
how to bill and issue invoices to their
customers, document receipt of
payment, and to maintain overall
accurate financial records of business
transactions. We find it difficult to
believe, as some commenters appeared
to indicate, that health IT developers are
not already keeping such financial
records and that this requirement would
create substantial new documentation
burden for Certified API Developers.
The record-keeping requirements
finalized in 170.404(a)(3)(i)(D) foster
transparency and promote
accountability in the Program. In
response to the comments received, we
have not added additional requirements
for accounting records or standards.
(E) Permitted Fee for Development,
Deployment, and Upgrades
We proposed in § 170.404(a)(3)(ii) to
permit an API Technology Supplier to
charge API Data Providers reasonable
fees for developing, deploying, and
upgrading Health IT Modules certified
to § 170.315(g)(7) through (g)(11).
Comments. Many commenters
applauded the permitted fee related to
development, deployment, and
upgrading API technology. The majority
supported the proposal that fees would
not be permitted if they interfere with
an API User’s ability to efficiently and
effectively develop and deploy
production-ready software. A few
commenters expressed concern that our
proposals regarding development,
deployment, and upgrade fees were not
restrictive enough. Commenters noted
that API Technology Suppliers will use
the allowable fees, such as for program
upgrades, as a barrier to providing
interoperability between systems or
other applications and a means to
eliminate competitive threats. Some of
these commenters recommended that
ONC explicitly prohibit API Technology
Suppliers from charging any fees for
implementing APIs and for facilitating
the interoperable exchange of EHI and
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
that this blanket prohibition apply to all
new and updated API technology. A few
commenters noted that it is possible that
API Technology Suppliers will bundle
or upcharge service fees to recoup API
technology development costs and API
Technology Suppliers should not be
allowed to charge costs for development
or impose surcharges for product feature
development. They noted that product
feature development should be
considered a cost of doing business and
can be amortized as a one-time capital
expense across the vendor’s entire
customer base without the need for
recovering costs from API Users. They
emphasized that API access and use
prices need to be transparent as the
intent of Congress was to have APIs be
made easily available and at no or low
cost, not to be a source of revenue for
profit. Other commenters noted that the
development of the APIs themselves
should be regarded as part of the license
fee and the API Technology Suppliers
should not be permitted to charge an
additional license fee to either the API
Data Provider or API User for what is an
inherent part of the software. Another
commenter requested that consideration
be applied toward potential additional
hidden integration fees.
Response. We appreciate the support,
concerns, and recommendations from
commenters. We finalized this proposal
in § 170.404(a)(3)(ii) as proposed with
updated terms based on the revised
finalized definitions in § 170.404(c). We
refer to the discussions below and 84 FR
7488 for additional details on what
Certified API Developer fees for
‘‘developing,’’ ‘‘deploying,’’ and
‘‘upgrading’’ certified API technology
comprise. We also note that the nature
of the costs charged under this category
of permitted fees depends on the scope
of the work to be undertaken by a
Certified API Developer (i.e., how much
or how little labor an API Information
Source requires of the Certified API
Developer to deploy and upgrade the
certified API technology).
We sincerely thank commenters for
the various recommendations to
prohibit or restrict fees regarding
certified API technology. In order to
reconcile the recommendations specific
to § 170.404(a)(3)(ii) and other
conditions in this final rule, we have
aligned related conditions to address
concerns and mitigate potential fee
practices that could limit API-based
access, exchange, and use of EHI by
patients and other stakeholders without
special effort. As finalized, we believe
the fees permitted in § 170.404(a)(3)(ii)
and § 170.404(a)(3)(i)(B), transparency
requirements in § 170.404(a)(2), and
openness and pro-competitive
PO 00000
Frm 00115
Fmt 4701
Sfmt 4700
25755
conditions in § 170.404(a)(4) will ensure
that fees permitted for upgrade costs
will not be used as a barrier to providing
interoperability between systems or
other applications, or as a means to
eliminate competitive threats.
Additionally, the transparency
requirements regarding the publication
of fees finalized in § 170.404(a)(2)(ii)(B)
will help prevent hidden integration
fees cited by commenters.
We thank commenters for
recommending and noting that
development of the APIs themselves
should be regarded as part of a license
fee and that Certified API Developers
should not be permitted to charge an
additional license fee for what is an
inherent part of the software. In
response to this recommendation, we
have added a provision in
§ 170.404(a)(3)(i)(C)(3) that states that
permitted fees in § 170.404(a)(3)(ii)
through (iv) may not include any costs
that led to the creation of IP, if the actor
charged a royalty for that IP pursuant to
the information blocking Licensing
Exception (§ 171.303). This provision
aligns with similar provisions included
in the information blocking section and
will ensure that Certified API
Developers cannot earn a double
recovery in instances described by the
commenter.
We will continue to work with
stakeholders to advance policies that
promote interoperability and deter
practices that may stifle innovation or
present barriers to the access, exchange,
and use of EHI through APIs. Subject to
the general conditions in
§ 170.404(a)(3)(i), our final policies
support the ability of Certified API
Developers to recover the full range of
reasonable costs associated with
developing, deploying, and upgrading
API technology over time. It is
important that Certified API Developers
be able to recover these costs and earn
a reasonable return on their investments
so that they have adequate incentives to
make continued investments in these
technologies. In particular, we
anticipate Certified API Developers will
need to continually expand the data
elements and upgrade the capabilities
associated with certified APIs as the
USCDI and HL7® FHIR® standard and
associated implementation
specifications mature. We refer readers
to the information blocking section of
this preamble (VIII) for additional
information on activities that may
constitute information blocking and for
discussion about how the fees
provisions in this Condition of
Certification and within the information
blocking section support innovation.
E:\FR\FM\01MYR3.SGM
01MYR3
25756
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
Comments. Some developers
expressed concern regarding balancing
and distributing costs with regard to the
permitted fee for developing, deploying,
and upgrading technology. The
commenters noted ONC proposed that
the cost for development be distributed
among those who will use it, which they
felt was problematic in many ways, but
most fundamentally because it suggests
a serious misconception about how
software development is funded, priced,
and sold. The commenters emphasized
that requiring development costs to be
divided among clients purchasing the
API necessitates new and complex
business processes and creates
unsolvable scenarios that could easily
create business conflicts between API
Technology Suppliers and their clients.
At least one commenter suggested that
ONC should consider balancing the
costs associated with API development
and deployment across both API Data
Providers and certain API Users to
ensure that third-party software
application developers also bear some of
the financial burden, since they stand to
generate revenue from the use of their
apps. Commenters asked ONC clarify
why it believes it is inappropriate to
pass development, deployment, and
upgrade costs on to API Users. Other
commenters noted that the costs for
updating information systems and
Health IT Modules to the new standards
and requirements should not be passed
on to physicians and patients.
Response. We appreciate the feedback
from commenters. We proposed and
finalized this permitted fee for
development, deployment, and upgrade
costs because we believe that these costs
should be negotiated solely between the
Certified API Developer that supplies
the capabilities and the API Information
Source that implements them in their
production environment. In our view, it
is inappropriate for Certified API
Developers to go around the API
Information Source to directly impose
financial cost burdens on API Users for
the benefit of working with or
connecting to the API Information
Source. Based on our experience, the
practice of a Certified API Developer
going around its customer (the API
Information Source) to also charge API
Users erodes an API Information
Source’s choice and the independence
of their relationship with API Users. As
such, that kind of business practice
would be something that we would
consider creating special effort on the
part of the API Users if they had to
continue to face additional fees just for
permission to work with or connect to
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
an API Information Source’s certified
API technology.
While the development, deployment,
and upgrade permitted fee is limited
between the Certified API Developer
and API Information Source as a way to
recoup a Certified API Developer’s costs
to supply certified API technology to a
particular API Information Source, we
again reiterate that the value added
services permitted fee providers
Certified API Developers a wide range of
options to make additional revenue
related to their certified API technology.
Should API Users stand to generate
revenue from the use of their apps, any
fee an API Information Source may
impose would not be in scope for this
Condition of Certification but would be
likely be covered by information
blocking. Accordingly, we emphasize
that such stakeholders should take care
to ensure they are compliant with other
Federal and State laws and regulations
that may prohibit or limit certain types
of relationships involving remuneration.
In response to comments suggesting
that costs for updating information
systems and Health IT Modules to the
new standards and requirements would
be passed on to physicians and patients,
we disagree. We emphasize that most of
the information contained in a patient’s
electronic record has been documented
during the practice of medicine or has
otherwise been captured in the course of
providing health care services to
patients. In our view, patients have
effectively paid for this information,
either directly or through their
employers, health plans, and other
entities that negotiate and purchase
health care items and services on their
behalf, and should be able to access the
information via certified API technology
without fees.
Comments. Some developers
suggested that API Technology
Suppliers should be able to charge fees
for access to a test environment and
requested clarification as to whether an
API Technology Supplier can charge for
the use of sandboxes by API Users.
Response. We appreciate the feedback
from commenters. As detailed in the
‘‘General Examples of Prohibited Fees’’
section of the preamble text and
included in the general prohibition
finalized in § 170.404(a)(3)(i)(A),
Certified API Developers are prohibited
from charging fees in connection with
any services essential to a developer or
other person’s ability to develop and
commercially distribute productionready applications for use with certified
API technology. In general, if a test
environment or sandbox is required to
be used by a Certified API Developer
and is essential for an application to be
PO 00000
Frm 00116
Fmt 4701
Sfmt 4700
developed in order to be considered
production-ready by the Certified API
Developer for use with its certified API
technology, then fees associated with
that kind of test environment would be
prohibited as they would impose special
effort. However, we note that this
prohibition is not globally applicable. If
instead, the purpose of the testing
environment was to provide specific
testing above-and-beyond productionreadiness for use with certified API
technology, then fees could be charged
for such testing as part of the valueadded services permitted fee.
Comments. A few commenters
requested guidance on how ONC
expects API Technology Suppliers to
account for the costs incurred to
develop, deploy, and upgrade the API
technology, which is part of, and not
necessarily separable from, the broader
EHR product. Several commenters
opposed the prohibition against
charging for work to upgrade the
broader EHR product, expressing that
this is essential work needed to
modernize their solutions as broader
technologies evolve. One commenter
noted that the Proposed Rule does not
set specific guidelines on what
constitutes an upgrade or how much the
fee could be, and it is the commenter’s
experience that EHR systems often
charge fees for such services as
integrating with a clinical data registry
or using outside or non-preferred
software.
Response. We thank stakeholders for
their comments. While we understand
that there is overlap between features of
the certified API technology and the
‘‘broader EHR product,’’ we refer
specifically to development,
deployment, and upgrades made to
‘‘certified API technology’’ as defined in
§ 170.404(c). Namely, development,
deployment, and upgrades made to the
capabilities of certified Health IT
Modules that fulfill the API-focused
certification criteria adopted at
§ 170.315(g)(7) through (10). In response
to commenters concerned that EHR
developers often charge fees for services
such as integrating with a clinical data
registry or using outside or nonpreferred software, we note that, as
described in § 170.404(a)(3)(i)(A),
Certified API Developers are prohibited
from imposing fees associated with
certified API technology unless
included as a permitted fee in
§ 170.404(a)(3)(ii) through (iv). We do
not include specific price information
for permitted fees to develop, deploy, or
upgrade API technology, because these
costs are subject to change over time
with new technology and varying
development, deployment, and upgrade
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
efforts. Instead, we allow Certified API
Developers to recover their costs
(including costs that result in a
reasonable profit margin for permitted
fees in § 170.404(a)(3)(ii) and
§ 170.404(a)(3)(iv)) in providing
certified API technology while being
compliant with the Condition and
Maintenance of Certification and
Program requirements. We include
descriptions of fees for developing,
deploying, and upgrading API
technology in the sections that follow,
in which we offer additional clarity, as
discussed in the Proposed Rule at 84 FR
7488, on the fees for developing,
deploying, and updating API
technology.
(i) Fees for Developing Certified API
Technology
Fees for ‘‘developing’’ certified API
technology comprise the Certified API
Developer’s costs of designing,
developing, and testing certified API
technology. In keeping with our
discussion at 84 FR 7488, fees for
developing certified API technology
must not include the Certified API
Developer’s costs of updating the nonAPI related capabilities of the Certified
API Developer’s existing Health IT
Modules, including its databases, as part
of its development of the certified API
technology. As we further discussed in
84 FR 7488 in our Proposed Rule, these
costs are connected to past business
decisions made by the Certified API
Developer and typically arise due to
Health IT Modules being designed or
implemented in nonstandard ways that
unnecessarily increase the complexity,
difficulty or burden of accessing,
exchanging, or using EHI. The recovery
of costs associated with updating a
Certified API Developer’s non-API
related Health IT Modules capabilities
would be inconsistent with the Cures
Act requirement that API technology be
deployed ‘‘without special effort.’’
(ii) Fees for Deploying Certified API
Technology
Certified API Developer’s fees for
‘‘deploying’’ certified API technology
comprise the Certified API Developer’s
costs of operationalizing certified API
technology in a production
environment. Such fees include, but are
not limited to, standing up hosting
infrastructure, software installation and
configuration, and the creation and
maintenance of API Information Source
administrative functions. We discussed
in our Proposed Rule that a Certified
API Developer’s fees for ‘‘deploying’’
certified API technology does not
include the costs associated with
managing the traffic of API calls that are
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
used to access the certified API
technology, which a Certified API
Developer can only recover under the
permitted fee for usage support costs
(§ 170.404(a)(3)(iii)). We emphasize that
for the purpose of this Condition of
Certification, we consider that certified
API technology is ‘‘deployed’’ by the
customer—the API Information
Source—that purchased or licensed it.
(iii) Fees for Upgrading Certified API
Technology
The Certified API Developer’s fees for
‘‘upgrading’’ certified API technology
comprise the Certified API Developer’s
costs of supplying an API Information
Source with an updated version of
certified API technology. Such costs
would include the costs required to
bring certified API technology into
conformity with new requirements of
the Program, upgrades to implement
general software updates (not otherwise
covered by development fees or under
warranty), or developing and releasing
newer versions of the certified API
technology at the request of an API
Information Source. The nature of the
costs that can be charged under this
category of permitted fees depends on
the scope of the work undertaken by a
Certified API Developer (i.e., how much
or how little labor an API Information
Source requires of the Certified API
Developer to upgrade the certified API
technology being supplied from one
version or set of functions to the next).
(F) Permitted Fee to Recover Costs of
Supporting API Usage
We proposed in 84 FR 7489 in
§ 170.404(a)(3)(iii) to permit an API
Technology Supplier to charge API
usage-based fees to API Data Providers
to recover the API Technology
Supplier’s reasonable incremental costs
for purposes other than facilitating the
access, exchange, or use of EHI by
patients or their applications,
technologies, or services. We considered
‘‘usage-based’’ fees to be the fees
imposed by an API Technology Supplier
to recover the costs that would typically
be incurred supporting API interactions
at increasing volumes and scale within
established service levels. Additionally,
in 84 FR 7489 under § 170.404(a)(3)(iii),
we proposed that any usage-based fees
associated with API technology be
limited to the recovery of the API
Technology Supplier’s ‘‘incremental
costs.’’ Additionally, we proposed in
§ 170.404(a)(3)(iii)(A) that the permitted
fee would not include any costs
incurred by the API Technology
Supplier to support uses of the API
technology that facilitate a patient’s
ability to access, exchange, or use their
PO 00000
Frm 00117
Fmt 4701
Sfmt 4700
25757
EHI. Finally, we proposed in
§ 170.404(a)(3)(iii)(B)–(C) restrictions for
permitted fees that were moved to the
general permitted fees section finalized
in § 170.404(a)(3)(i)(C).
Comments. Commenters generally
supported our proposal to permit an API
Technology Suppliers to charge usagebased fees to API Data Providers to the
extent that the API technology is used
for purposes other than facilitating the
access, exchange, or use of EHI by
patients or their applications,
technologies, or services.
Response. We appreciate support
from commenters and have finalized
this proposal in § 170.404(a)(3)(iii) with
some modification. We amended the
title of the regulation text for clarity in
§ 170.404(a)(3)(iii) to ‘‘Permitted fee—
Recovering API usage costs.’’
Additionally, we amended the
regulation text to focus on usage-based
fees and Certified API Developer’s
reasonable incremental costs. We did
not finalize the specific prohibition on
permitted fees proposed in
§ 170.404(a)(3)(iii)(A) that the
‘‘permitted fee does not include costs
incurred by the API Technology
Supplier to support uses of the API
technology that facilitate a patient’s
ability to access, exchange, or use
electronic health information.’’ We did
not finalize this aspect of the provision
because upon further consideration of
this cost and the fee prohibition
included in information blocking
related to patient access, we determined
that these fees remain necessary in order
to allow Certified API Developers to
recover incremental costs reasonably
incurred during the process of hosting
certified API technology on behalf of the
API Information Source. We reiterate
that a Certified API Developer’s
‘‘incremental costs’’ comprise the
Certified API Developer’s costs that are
directly attributable to supporting API
interactions at increasing volumes and
scale within established service levels.
A Certified API Developer should
‘‘price’’ its costs of supporting access to
the certified API technology by
reference to the additional costs that the
Certified API Developer would incur in
supporting certain volumes of API use.
For comments and responses related to
the proposed provisions in
§ 170.404(a)(3)(iii)(B) and (C), we refer
readers to the header ‘‘Certified API
Developer Prohibited Fees.’’
Comments. We received a few
comments focused on volume
thresholds and incremental costs. A few
commenters supported a reasonable cap
for API call fees. Several recommended
changing the parameters around API
usage-based fees to focus on volume
E:\FR\FM\01MYR3.SGM
01MYR3
25758
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
thresholds being included in any
contractual language related to these
fees, to ensure that any incremental
costs attributable to supporting API
interactions at increasing volumes and
scale are addressed appropriately.
Commenters noted that if an API
Technology Supplier is receiving fees to
develop, deploy, and upgrade API
technology, it is unlikely that they
would also need to charge for usage of
the APIs, as long as their usage remains
under a pre-determined volume
threshold. A few commenters noted that
the volume of requests that will be
pinging APIs may compromise the
performance of data retrieval and
effective user experience. In order to
protect against denial of service attacks
whether intentional or inadvertent, they
stated ONC should consider an
additional throttling or rate-limiting
layer or capability onto the API in order
for the API to accept and digest the data
being entered or extracted. A few
commenters noted that our proposal
could create loopholes that would
enable certain organizations to charge
highly burdensome, excessive fees to
clinical registries to access their data.
A few commenters expressed concern
that this proposal is not restrictive
enough. Some commenters requested
that ONC provide more definitive
guidance, including a range of prices
based on examples from the current
marketplace, to ensure providers are not
charged unreasonable fees by API
Technology Suppliers and can
reasonably charge API Users for the cost
of accessing their API technology.
Response. We appreciate the feedback
from commenters. This Condition of
Certification requirement offers the
flexibility necessary to accommodate
reasonable pricing methodologies and
will allow Certified API Developers to
explore innovative approaches to
recovering the costs associated with
supporting the use of certified API
technology with a permitted fee. As
described in the Proposed Rule (84 FR
7489), ‘‘usage-based’’ fees are fees
imposed by a Certified API Developer to
recover costs typically incurred for
supporting API interactions at
increasing volumes and scale within
established service levels. That is,
‘‘usage-based’’ fees recover costs
incurred by a Certified API Developer
due to the actual use of the certified API
technology once it has been deployed
(e.g., costs to support a higher volume
of traffic, data, or number of apps via
the certified API technology). Certified
API Developers can adopt a range of
pricing methodologies when charging
for the support of API usage. We
appreciate commenters’ request to
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
establish a reasonable cap for API usagebased fees, but the focus of our policy
is to identify usage fees as a type of
permitted fee and not to dictate a
singular fee model, which we believe
could limit Certified API Developers
ability to create innovative fee models
that serve to benefit themselves and API
Information Sources. We decline to
include a price cap for API usage-based
fees or a range of prices for API fees
based on examples from the current
marketplace because we anticipate the
cost of technology will change over time
and so too will the way in which usage
costs are calculated. Additionally, while
we understand and expect that Certified
API Developers and API Information
Sources will deploy particular security
methods to mitigate the risk of denial of
service attacks and other impacts on API
availability, these types of technology
layers are separate from the focus of our
policy on permitted API usage fees.
Comments. Several commenters
requested that ONC further clarify that
API Technology Suppliers should not
attempt to charge different fees for
different API transactions as they
frequently do today.
Response. We appreciate this
information and feedback from
commenters. We clarify that Certified
API Developers are permitted to charge
‘‘usage-based’’ fees to recover the costs
that would typically be incurred
supporting API transactions at
increasing volumes and scale within
established service levels. To clarify,
usage-based fees recover costs incurred
by a Certified API Developer related to
the actual use of certified API
technology once it has been deployed
(e.g., costs to support a higher volume
of traffic, data, or number of apps via
the API Technology). We acknowledge
that Certified API Developers could
adopt a range of pricing methodologies
when charging for the support of API
usage, including potentially charging
higher prices for some API transactions
that incur relatively higher costs than
others. However, in combination with
this flexibility, Certified API Developers
will still need to be mindful of not
violating any overarching information
blocking policies. We refer readers to a
discussion in the Proposed Rule in 84
FR 7489 for additional discussions on
usage-based fees.
Comments. Some commenters
emphasized that it is unreasonable to
presume that API User-driven data
overages should be the responsibility of
the API Data Provider. While other
commenters expressed concern that our
proposal will leave providers, who are
mandated to use certified EHRs that
include API technology and provide
PO 00000
Frm 00118
Fmt 4701
Sfmt 4700
patients with access to data via those
APIs, responsible for a variety of
unwarranted costs with little recourse to
recover those costs.
Response. While we understand the
perspective from which these concerns
arise, especially regarding unpredictable
overuse of certified API technology, an
API Information Source has financial
responsibility for its overall technology
infrastructure. This accountability is no
different for certified API technology
than it is for non-certified APIs and
other interfaces that may also create
costs for the API Information Source
(i.e., health care provider). Given that
API Users can also include an API
Information Source’s own employees/
internal tools and 3rd party partners’
tools, an API Information Source is best
positioned and generally accountable
for its financial commitments. Again, as
noted above, we do not limit who may
pay for the charges an API Information
Source incurs. An API Information
Source should have full knowledge and
ability to assess what employees,
internal applications, and 3rd party
services it has granted access to use and
interact with its certified API
technology. With respect to potential
overages as a result of patient access, as
we have stated before, we believe
patients have effectively paid for this
information, either directly or through
their employers, health plans, and other
entities that negotiate and purchase
health care items and services on their
behalf, and believe they should not be
charged.
Additionally, as stated in the
Proposed Rule (84 FR 7489) and
finalized here, usage fees for certified
API technology will only apply when
the Certified API Developer acts on
behalf of the API Information Source to
deploy its certified API technology. In
scenarios where the API Information
Source, such as a large hospital system,
assumes full responsibility for the
technical infrastructure necessary to
deploy and host the certified API
technology it has acquired, the volume
and scale of its usage would be the API
Information Source’s sole responsibility,
and a Certified API Developer would
not be permitted to charge usage-based
fees. Instead, the Certified API
Developer would be limited to charge
fees under the ‘‘development,
deployment, upgrade’’ permitted fee in
§ 170.404(a)(3)(ii). Additionally, the
costs recovered under ‘‘usage-based’’
fees can only reflect ‘‘post-deployment’’
costs. As such, ‘‘usage-based’’ fees
cannot include any costs necessary to
prepare and ‘‘get the certified API
technology up, running, and ready for
use,’’ which are costs that must be
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
recovered as part of the deployment
services delivered by the Certified API
Developer if permitted under
§ 170.404(a)(3)(ii).
Comments. Several commenters
supported ONC’s efforts to bolster
patient access, noting that the capacity
to offer a patient’s access to all elements
of their electronic medical record,
through an API, without cost, is wellsupported in the Proposed Rule. One
commenter noted that the proposed
provisions regarding fees supports uses
of the API technology that facilitate a
patient’s ability to access, exchange, or
use their EHI. The commenters noted
that the clear language in the Proposed
Rule will prevent any potential
confusion or friction in the future.
A few commenters expressed concern
that application developers will attempt
to leverage the patient access fee
limitations by claiming to be patient
facing. One commenter suggested that
the proposed fee limitations regarding
patient access applied only with respect
to fees API Technology Providers
impose on API Data Providers, should
also apply to fees charged to consumerfacing application developers who in
the past have been charged high fees by
CEHRT developers. One commenter
recommended making it clear that
provider organizations and health IT
developers cannot charge patients, or
the apps that they use, for using patientfacing APIs. At least one commenter
requested that ONC clarify that
permitted usage-based fees do not apply
to patients or patient designees.
Response. We thank commenters for
their support for restricting API-related
fees. As noted above, we have
reconfigured the permitted fee for usage
costs in response to public comments
and our assessment of the intersection
of API permitted fees policies and
information blocking policies. We have
finalized an approach that permits
Certified API Developers to recover
incremental usage costs reasonably
incurred during the process of hosting
certified API technology on behalf of an
API Information Source, which could
include fees to the API Information
Source for providing and supporting
patient access. However, the Certified
API Developers and API Information
Sources cannot recover these costs from
patients or the developers of
applications that facilitate access to and
receipt of patients’ EHI. Patients have
already effectively paid for their EHI,
either directly or through their
employers, health plans, and other
entities that negotiate and purchase
health care items and services on their
behalf. We refer readers to the Fees
Exception in the information blocking
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
section of this final rule in VII.D.2.b,
which applies to health IT developers
and a broader set of actors than these
Condition and Maintenance of
Certification requirements, for a
discussion of the restrictions on
charging patients for access to their EHI.
Comments. Several commenters
requested that ONC provide further
guidance on the types of costs that a
developer could charge to permit API
Data Suppliers to offer population-level
queries to API Users. They requested
ONC clarify that such usages fees must
relate to the costs associated with actual
hardware (e.g., server space) needed to
support the increased volume of queries
for non-patients and not the cost of
implementing the population-level
query functionality itself.
Response. We clarify that API usage
fees related to API ‘‘read’’ services for
multiple patients would be calculated
using a similar methodology to calculate
API usage fees related to API ‘‘read’’
services for single patients. These
‘‘usage-based’’ fees are fees imposed by
a Certified API Developer to recover the
costs typically incurred to support API
interactions for API ‘‘read’’ services for
multiple patients once these services
have been deployed. This could
include, but not be limited to, costs to
support a higher volume of traffic, data,
or number of apps via the certified API
technology (which could include higher
costs for hardware, including server
space). We appreciate the
recommendation from commenters;
however, we have not prescribed the
centralization of all of this content.
Comments. Some commenters
suggested that API Technology
Suppliers publish their fees on the same
website as their API documentation so
there is full transparency and an API
Data Supplier and API User can easily
understand costs before embarking upon
development.
Response. We appreciate the
recommendation and support from
commenters. As finalized under
§ 170.404(a)(2)(ii)(B), a Certified API
Developer must publish all terms and
conditions for its certified API
technology, including any fees. Any and
all fees charged by a Certified API
Developer for the use of its certified API
technology must be described in
detailed, plain language, including the
persons or classes of persons to whom
the fee applies; the circumstances in
which the fee applies; and the amount
of the fee, which for variable fees must
include the specific variable(s) and
methodology(ies) that will be used to
calculate the fee.
Comments. Some commenters stated
that usage-based fees may not be
PO 00000
Frm 00119
Fmt 4701
Sfmt 4700
25759
appropriate. They stated that, in the
case of TEFCA, HIEs and providers must
be responsive to inbound requests to
broadcast data and should not be
charged a fee for responding to such
requests. They explained that such an
arrangement could be used maliciously
between market participants seeking to
increase the operational expenses of
their competitors.
Response. We appreciate this
comment, but we continue to believe
that that usage-based fees should be
permitted subject to the conditions
described in § 170.404(a)(3)(iii). We
have addressed commenter’s concern
regarding potential anticompetitive
behavior through the final provisions in
§ 170.404(a)(3)(i)(B). Specifically, in
§ 170.404(a)(3)(i)(B)(1), a Certified API
Developer must ensure that fees are
based on objective and verifiable criteria
that are uniformly applied for all
similarly situated classes of persons and
requests. In addition, under
§ 170.404(a)(3)(i)(B)(4), a Certified API
Developer must ensure that fees are not
based in any part on whether the
requestor or other person is a
competitor, potential competitor, or will
be using the certified API technology in
a way that facilitates competition with
the Certified API Developer.
Comments. Several commenters
expressed concern about incremental
costs that can be recovered by actors
supporting the use of APIs for purposes
other than patient access. They
requested ONC clarify that recovery of
incremental costs for these other
purposes should not be allowed,
because they believed the incremental
costs do not add any efficiency to the
health care system, do not benefit
patients, and do not serve any other
procompetitive purpose.
Response. We appreciate these
comments, but continue to believe that
‘‘incremental costs’’ should be allowed.
A Certified API Developer’s
‘‘incremental costs’’ comprise the
Certified API Developer’s costs that are
directly attributable to supporting API
interactions at increasing volumes and
scale within established service levels.
We believe a Certified API Developer
should ‘‘price’’ its costs of supporting
access to the certified API technology by
reference to the additional costs that the
Certified API Developer would incur in
supporting certain volumes of API use.
In practice, we expect that this means
that a Certified API Developer will offer
a certain number of ‘‘free’’ API calls
based on the fact that, up to a certain
threshold, the Certified API Developer
will not incur any material costs in
supporting certified API technology in
addition to the costs recovered for
E:\FR\FM\01MYR3.SGM
01MYR3
25760
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
deployment services. However, after
this threshold is exceeded, we expect
that the Certified API Developer will
impose usage-based costs commensurate
to the additional costs that the Certified
API Developer must incur to support
certified API technology use at
increasing volumes and scale.
We expect that Certified API
Developers will charge fees that are
correlated to the incremental rising of
costs required to meet increased
demand. For example, if, at a certain
volume of API calls, the Certified API
Developer needed to deploy additional
server capacity, the associated
incremental cost of bringing an
additional server online could be passed
on to the API Information Source
because the certified API technology
deployed on behalf of the API
Information Source was the subject of
the higher usage. In this example, up
until the point that the threshold is
reached, the additional server capacity
is not required, so the Certified API
Developer would not be permitted to
recover the costs associated with it.
Moreover, the additional server capacity
would support ongoing demand up to a
certain additional volume, so the
Certified API Developer would not be
permitted to recover the costs of further
additional server capacity until the
existing capacity was exhausted.
(G) Permitted Fee for Value-Added
Services
We proposed in 84 FR 7490 and 7491
in § 170.404(a)(3)(iv) to permit an API
Technology Supplier to charge fees to
API Users for value-added services
supplied in connection with software
that can interact with the API
technology. We also clarified in 84 FR
7491 that a fee will only be permitted
if it relates to a service that an API User,
such as a software developer, can elect
to purchase, but is not required to
purchase in order to develop and deploy
production-ready apps for API
technology.
Comments. Several commenters
supported our proposal to permit an API
Technology Supplier to charge fees to
API Users for value-added services
supplied in connection with software
that can interact with certified API
technology. Some commenters
requested certain clarifications
regarding our proposal. One commenter
requested that we clarify within the
discussion of value-added services, that
references to ‘‘app stores’’ and ‘‘listing
processes’’ for software applications that
register to connect with the API
technology are solely intended as
examples to illustrate when a fee would
or would not qualify as a ‘‘value-added
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
service,’’ and are not meant to convey a
requirement or expectation that API
Technology Suppliers provide an app
store with application listing free of
charge. A few commenters requested
that ONC clarify that EHR developers
can charge value-add fees without
triggering the information blocking
provision. A couple other commenters
requested additional examples of what
constitutes a ‘‘value-added’’ service for
which an API Technology Supplier can
charge fees to an API User.
Response. We thank commenters for
the feedback. We have finalized
§ 170.404(a)(3)(iv) as proposed, with the
exception of updating terms based on
the definitions finalized in § 170.404(c).
Our final policy permits Certified API
Developers to charge fees, including a
reasonable profit margin, to API Users
for value-added services related to
certified API technology, so long as such
services are not necessary to efficiently
and effectively develop and deploy
production-ready software that interacts
with certified API technology. We
clarify that the value-added services
need to be provided in connection with
and supplemental to the development,
testing, and deployment of productionready software applications that interact
with certified API technology. A fee is
permitted if it relates to a service that a
software developer can elect to purchase
from a Certified API Developer, but is
not required to purchase in order to
develop and deploy production-ready
apps for certified API technology.
In response to comments for clarity,
we note that examples used to illustrate
when a fee would or would not qualify
as a ‘‘value-added service,’’ such as app
store listing, are demonstrative, but not
required unless otherwise noted in the
regulation text. Under this condition,
we permit fees for services associated
with the listing and promotion of apps
beyond basic application placement so
long as the Certified API Developer
ensures that basic access and listing in
the app store is provided free of charge
(if an application developer depended
on such listing to efficiently and
effectively develop and deploy
production-ready apps for use with
certified API technology). Fees charged
for additional/specialized technical
support or promotion of the API User’s
application beyond basic access and
listing services would be examples of
permitted value-added services. We
caution health IT developers not to
over-interpret the scope of this
Condition of Certification, which is
focused on certified API technology. To
the degree that a health IT developer
administers an ‘‘app store’’ and offers
value-added services associated with
PO 00000
Frm 00120
Fmt 4701
Sfmt 4700
certified API technology, the Condition
of Certification covers its practices
related to certified API technology only.
Conversely, this Condition of
Certification would not apply to any
practices that do not involve certified
API technology. However, health IT
developers would need to be mindful of
any applicable information blocking
rules that may apply to their app store
practices given applicable facts and
circumstances. Regarding the request for
specific value-added fees that would not
constitute information blocking, we
refer readers to the information blocking
section (VIII) of this preamble.
(H) Request for Comment on
§ 170.404(a)(3)
We requested comment at 84 FR 7491
on any additional specific ‘‘permitted
fees’’ not addressed in our Proposed
Rule (84 FR 7491) that commenters felt
API Technology Suppliers should be
able to recover in order to assure a
reasonable return on investment.
Furthermore, we requested comment on
whether it would be prudent to adopt
specific, or more granular, cost
methodologies for the calculation of the
permitted fees. We encouraged
commenters to consider, in particular,
whether the approach we described
would be administrable and
appropriately balance the need to
ensure that stakeholders do not
encounter unnecessary costs and other
special effort with the need to provide
adequate assurance to API Technology
Suppliers, investors, and innovators that
they will earn a reasonable return on
their investments in API technology. We
welcomed comments on whether the
approach adequately balances these
concerns and achieves our stated policy
goals. We also welcomed comments on
potential revisions or alternative
approaches. We encouraged detailed
comments that included, where
possible, economic justifications for
suggested revisions or alternative
approaches.
Comments. Commenters suggested we
alter our approach to APIs so that it is
tiered fee structure. They suggested that
ONC could establish categories where
the technology requirements designate
the fees: (1) A ‘‘no fee’’ category would
limit API Technology Suppliers from
charging API Data Providers or API
Users any fees for exchanging data in
compliance with Federal requirements;
(2) an ‘‘at cost’’ category would allow
API Technology Suppliers to charge API
Data Providers or API Users the cost of
interfacing APIs with a non-API
Technology Supplier’s commercial
technology; and (3) a ‘‘cost plus
reasonable profit’’ category would allow
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
API Technology Suppliers to charge API
Data Providers or API Users a
reasonable profit when conducting
legitimate custom API development or
creating custom apps.
Response. We appreciate the
recommendation from commenters, but
we have not adopted a tiered fee
structure in the final rule because it
would require unnecessary specificity
and prescribe a particular method that
could have unintended effects of
limiting the market’s evolution over
time. We believe the current structure
for prohibited and permitted fees allows
for the adequate cost recovery and
reasonable profit by Certified API
Developers while also establishing the
guardrails around which API access can
be enabled without special effort.
Comments. Many commenters
expressed concerns related to the effect
our proposals regarding API fees would
have on innovation and business.
Several commenters noted that the
structure of permitted fees could have
unintended consequences that will
ultimately work to impede innovation,
increase administrative burden, and
focus on cost recovery rather than
creation of novel ways to improve data
access.
Several developers stated that the
proposed fee structure specifically
works to sever business relationships
between API Technology Providers and
API Users for anything other than
‘‘value added services’’ and effectively
eliminates the ability for API Users to
work directly with API Technology
Suppliers to innovate and accelerate
API development, and to achieve truly
integrated and supported products
throughout the product lifecycle. They
suggested that a better model would be
one that gives API Data Providers rights
to leverage APIs ‘‘without special
effort,’’ while supporting the ability for
API Technology Suppliers and API
Users to voluntarily engage in direct
business relationships under mutually
agreeable terms that are fair and
equitable. Some developers stated that
the market should determine permitted
fees. They stated that in order to
maintain a vigorously competitive
market, API Technology Suppliers must
be adequately compensated for their
work to create and deploy non-standard
APIs and support expanding standards.
They explained that without this
compensation, there will be far fewer
entrants into the certified health IT
space and current participants will
depart.
A couple of developers recommended
that ONC allow revenue-sharing models
for certain components of certified APIs.
The commenters suggested that ONC
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
should view revenue sharing
arrangements as a type of market-based
compensation that will ultimately
benefit innovation and competition.
Conversely, one commenter stated that
it is essential that API Technology
Suppliers be expressly prohibited from
conditioning access to API technology
on charging revenue-sharing or royalty
agreements to API Data Providers or API
Users outside of actual usage costs
incurred. The commenter noted this
rent-seeking behavior is anticompetitive in nature and can have a
significant impact on squelching any
new market entrants and allow existing
health IT actors to prevent all the
positive outcomes that could arise from
the ONC’s proposed rules. Some
developers stated that the prohibition
against health IT developers charging
for work to update their code structure
is unreasonable, emphasizing that this is
important work that is necessary for
companies to be able to modernize their
solutions as broader technologies
evolve.
Response. We appreciate these
comments, but disagree with
commenters regarding the potential
negative effect of the final permitted fee
structure on innovation. We also note
that the value-added services permitted
fee does permit a direct relationship
between Certified API Developers and
API Users. What is generally prohibited
and what we noted presented ‘‘special
effort’’ in the Proposed Rule were
Certified API Developer practices that
required an API Information Source to
seek permission to use its own certified
API technology from the Certified API
Developer.
We reiterate that complying with the
requirements of this permitted fee and
the information blocking exception will
generally not prevent an actor from
making a reasonable profit in
connection with the access, exchange,
or use of EHI. To be responsive to
comments, we have added a provision
in § 171.404(a)(3)(i)(A) to clarify this
point. This final provision states that
certain permitted API fees
(§ 170.404(a)(3)(ii) and
§ 170.404(a)(3)(iv)) may include fees
that result in a reasonable profit margin
in accordance with the Costs Exception
(§ 171.302). We believe that the
allowance of reasonable profits is
necessary to incentivize innovation and
allow innovators to earn returns on the
investments they have made to develop,
maintain, and update innovations that
ultimately improve health care delivery
and benefit patients. Our finalized
approach to API fees strikes the
appropriate balance of addressing the
rent-seeking and exclusionary pricing
PO 00000
Frm 00121
Fmt 4701
Sfmt 4700
25761
practices noted by the commenters
while enabling and supporting
innovation.
We also emphasize that a majority of
the EHI has been generated and
recorded in the course of furnishing
health care services paid with public
dollars through Federal programs,
including Medicare and Medicaid, or
directly subsidized through the tax
preferences for employer-based
insurance. Yet, this EHI is not readily
available where and when it is needed.
We believe the overwhelming benefits
of publishing certified APIs that allow
EHI from such technology to be
accessed, exchanged, and used without
special effort far outweigh the potential
burden on Certified API Developers and
API Information Sources.
Comments. A few commenters
requested that ONC clarify whether API
Data Suppliers would be allowed to
recoup costs from API Users in light of
the information blocking provisions. A
few commenters expressed confusion
that fees are addressed under the API
Condition and Maintenance of
Certification and information blocking.
The commenters suggested that ONC
address fees in one consolidated
section.
Response. We appreciate this
comment and refer readers to the
information blocking section of this
rule. We do not believe that a discussion
of fees should be consolidated in one
section for a couple of reasons. First, the
information blocking provision has a
much broader reach than the Condition
and Maintenance of Certification
requirements and regulates conduct of
health IT developers of certified Health
IT Modules, health care providers,
health information networks, and health
information exchanges. The Condition
and Maintenance of Certification
requirements only relate to conduct by
health IT developers of certified Health
IT Modules. Second, the API Condition
of Certification covers a much narrower
scope of potential fees, as the fees in
this section are specific to certified API
technology only while fees in the
information blocking section generally
relate to the access, exchange, or use of
EHI regardless of the particular
technology used.
We emphasize that we have finalized
a provision in § 171.302(c) that if the
actor is a health IT developer subject to
the Condition of Certification
requirements in § 170.402(a)(4)
(Assurances), § 170.404 (API), or both,
the actor must comply with all
requirements of such conditions for all
practices and at all relevant times.
Under this provision, health IT
developers of certified Health IT
E:\FR\FM\01MYR3.SGM
01MYR3
25762
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
Modules subject to the API Condition of
Certification requirements may not
charge certain types of fees and are
subject to more specific cost
accountability provisions than apply
generally under the Costs Exception. We
explain in the Costs Exception that a
failure of developers to comply with
these additional requirements would
impose impediments to consumer and
other stakeholder access to EHI without
special effort and would be suspect
under the information blocking
provision.
vi. Openness and Pro-Competitive
Conditions
We proposed in 84 FR 7595 in
§ 170.404(a)(4) that an API Technology
Supplier must grant API Data Providers
the sole authority and autonomy to
permit API Users to interact with the
API technology deployed by the API
Data Provider in a non-discriminatory
manner; provide all reasonably
necessary support and other services to
enable the effective development,
deployment, and use of API technology
by API Data Providers and its API Users
to access, exchange, and use EHI in
production environments; not impose
collateral terms or agreements that
could interfere with the use of API
technology; and provide reasonable
notice prior to making changes to its
API technology or terms and conditions.
Comments. The majority of
commenters supported the proposed
openness and pro-competitive
conditions. Several commenters
requested clarification about API Data
Providers’ rights and responsibilities
when providing access to an application
of a patient’s choice. Specifically, they
sought clarification on whether they can
vet, deny, or limit access by
applications that are using the API
technology inappropriately. Another
commenter proposed that app
developers be required to obtain a
business associate agreement (BAA)
with providers prior to the application
developer gaining access to a patient’s
EHI on behalf of a patient.
Response. We appreciate the feedback
from commenters. Based on the support
from commenters, we have finalized
that a Certified API Developer must
grant API Information Sources the
independent ability to permit API Users
to interact with the certified API
technology deployed by the API
Information Source in § 170.404(a)(4).
Under the HIPAA Privacy Rule, a
business associate relationship exists if
an entity creates, receives, maintains, or
transmits ePHI on behalf of a covered
entity (directly or through another
business associate) to carry out the
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
covered functions of the covered entity.
HIPAA does not require a covered entity
(e.g., API Information Source) or its
business associate (e.g., API Technology
Supplier) to enter into a business
associate agreement with an app
developer that does not create, receive,
maintain, or transmit ePHI on behalf of
or for the benefit of the covered entity
(whether directly or through another
business associate). However, if the app
was developed to create, receive,
maintain, or transmit ePHI on behalf of
the covered entity (API Information
Source), or was provided by or on behalf
of the covered entity (directly or
through its API Technology Supplier,
acting as the covered entity’s business
associate), then a business associate
agreement would be required.106 In such
cases, API Information Sources have the
ability to conduct whatever ‘‘vetting’’
they deem necessary of entities (e.g.,
app developers) that would be their
business associates under the HIPAA
Rules before granting access and use of
EHI to the entities. In this regard,
covered entities must conduct necessary
vetting in order to comply with the
HIPAA Security Rule.
For third-party applications chosen by
individuals to facilitate their access to
their EHI held by actors, there would
not be a need for a BAA as discussed
above. There would also generally not
be a need for ‘‘vetting’’ on security
grounds and such vetting actions
otherwise would be an interference.
Please see our discussion of ‘‘vetting’’ in
the ‘‘Interference Versus Education
When an Individual Chooses
Technology to Facilitate Access’’
discussion in the Information Blocking
section of the preamble (Section VIII).
We also refer readers to our discussion
of ‘‘vetting’’ versus verifying an app
developer’s authenticity under the API
Condition of Certification later in this
section of the preamble.
Comments. Several commenters
requested clarification about the types
of business relationships permitted
between API Technology Suppliers and
API Users and requested examples of
permitted activities and responsibilities
under each role. These comments
expressed concern about prohibiting
API Technology Suppliers from being
able to form direct relationships with
API Users for the purpose of joint
development and commercialization of
their products. Other commenters
requested clarifications about
relationships that existed prior to the
involvement of an API Data Provider.
106 https://www.hhs.gov/hipaa/for-professionals/
privacy/guidance/access-right-health-apps-apis/
index.html.
PO 00000
Frm 00122
Fmt 4701
Sfmt 4700
Response. We appreciate the feedback
from commenters. Based on the general
support, we have finalized in
§ 170.404(a)(4)(i)(A) that a Certified API
Developer must provide certified API
technology to API Information Sources
on terms that are no less favorable than
it provides to itself and its own
customers, suppliers, partners, and
other persons with whom it has a
business relationship. Additionally, we
have finalized in § 170.404(a)(4)(i)(B)
that the terms on which a Certified API
Developer provides certified API
technology must be based on objective
and verifiable criteria that are uniformly
applied to all substantially similar or
similarly situated classes of persons and
requests. Furthermore, we have
finalized in § 170.404(a)(4)(i)(C) that a
Certified API Developer must not offer
different terms or services on the basis
of: Competition or potential for
competition and revenue or other value
the other party receiving the services
may receive from using the certified API
technology. We note that we slightly
modified the finalized requirements in
§ 170.404(a)(4)(i) based on the revised
definitions finalized in § 170.404(c). We
clarify that this rule does not prohibit
Certified API Developers from forming
business relationships with API Users.
To the degree that a Certified API
Developer seeks to charge an API User
for particular services associated with
its certified API technology, it would
need to do so pursuant to the ‘‘valueadded services’’ permitted fee.
Comments. Commenters requested
clarification about how ‘‘the sole
authority and autonomy to unilaterally
permit connections to their health IT
through certified API technology’’
applies to application registration.
Specifically, they asked whether API
Users are required to register once with
the API Technology Supplier, or several
times with each instance of API
technology deployed by API Data
Providers.
Response. We appreciate the feedback
from commenters. We refer commenters
to § 170.315(g)(10)(iii) for the
application registration requirements for
Health IT Modules presented for
certification. In general, we do not
prescribe the registration paradigm that
Certified API Developers create for
themselves and their customers. Thus,
in different scenarios, an API User may
only be required to register once with an
Certified API Developer, or several
times with each instance of a
§ 170.315(g)(10)-certified Health IT
Module deployed by an API Information
Source. When it comes to apps that
focus on the ‘‘launch-ehr’’ ‘‘SMART on
FHIR Core Capability’’ from the
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
implementation specification adopted
in 170.215(a)(3), such an approach will
be tightly integrated with the Health IT
Modules deployed by API Information
Sources. Because of the tight integration
between API Information Sources and
Health IT Modules, registration for these
apps could more often fall to the API
Information Source. When it comes to
apps that enable patient access,
registration could be handled centrally
by Certified API Developers or in a
distributed manner with each API
Information Source, especially in cases
where API Information Sources take full
responsibility for administering their
§ 170.315(g)(10)-certified Health IT
Modules.
Regarding ‘‘the sole authority and
autonomy to unilaterally permit
connections to their health IT through
certified API technology,’’ we have
finalized in 170.404(a)(4)(ii)(A) that
Certified API Developer must have and,
upon request, must grant to API
Information Sources and API Users all
rights that may be reasonably necessary
to (1) access and use certified API
technology in a production
environment; (2) develop products and
services that are designed to interact
with the Certified API Developer’s API
technology; and (3) market, offer, and
distribute products and services
associated with the Certified API
Developer’s certified API technology.
Additionally, we have finalized in
§ 170.404(a)(4)(ii)(B) that a Certified API
Developer must not condition any of the
rights described in § 170.404(a)(4)(ii)(A)
on: (1) Receiving a fee, including but not
limited to a license fee, royalty, or
revenue-sharing arrangement; (2)
agreeing to not compete; (3) agreeing to
deal exclusively with the Certified API
Developer; (4) Obtaining additional
services that are not related to the
certified API technology; (5) sharing
intellectual property with the Certified
API Developer; (6) meeting any Certified
API Developer-specific testing or
certification requirements; and (7)
providing the Certified API Developer or
technology with reciprocal access to
application data. We slightly modified
the conditions from the Proposed Rule
for what we finalized in
§ 170.404(a)(4)(ii)(B) for clarity, and
amended terms to the revised
definitions finalized in § 170.404(c).
Additionally, we clarify that while
Certified API Developers are not
permitted to condition the rights
described in § 170.404(a)(4)(ii)(A) on
receiving a fee, Certified API Developers
are permitted to charge fees compliant
with the permitted fees described in
§ 170.404(a)(3). We also clarify that
‘‘meeting any Certified API Developer-
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
specific testing or certification
requirements’’ would include
preconditions like registering and
testing in a testing environment prior to
moving to production, and meeting
Certified API Developer-created
certification requirements.
Comments. Commenters expressed
concern about software applications
maintaining compatibility when
upgrading API technology, and
highlighted the importance of adopting
backwards-compatible standards.
Response. We appreciate the feedback
from commenters. We share the concern
expressed by commenters. We
specifically consider features of
standards like backwards compatibility
when proposing and finalizing testing
and certification requirements for the
Program. As mentioned above, we have
finalized the standard adopted in
§ 170.215(a)(1) as the base standard for
the certification criterion adopted in
§ 170.315(g)(10) Standardized API for
Patient and Population Services. We
note that the standard adopted in
§ 170.215(a)(1) includes many FHIR
resources that need to retain their
compatibility over time, which will help
as upgrades to newer standards occur.
Additionally, we have finalized in
§ 170.404(a)(4)(iii) the service and
support obligations required by a
Certified API Developer, including the
requirements that a Certified API
Developer must provide all support and
other services reasonably necessary to
enable the effective development,
deployment, and use of certified API
technology by API Information Sources
and API Users in production
environments. These include
requirements for changes and updates to
API technology finalized in
§ 170.404(a)(4)(iii)(A), where Certified
API Developers must make reasonable
efforts to maintain the compatibility of
its certified API technology and to
otherwise avoid disrupting the use of
certified API technology in production
environments, and requirements for
changes to terms and conditions
finalized in § 170.404(a)(4)(iii)(B), where
Certified API Developers must provide
notice and reasonable opportunity for
its API Information Source customers
and registered API Users to update their
applications to preserve compatibility
with API technology and to comply
with applicable terms and conditions.
e. API Maintenance of Certification
Requirements
i. Authenticity Verification
We proposed in 84 FR 7486 in
§ 170.404(a)(2)(ii)(C) to permit API
Technology Suppliers to verify the
PO 00000
Frm 00123
Fmt 4701
Sfmt 4700
25763
authenticity of application developers,
limited to a duration of no greater than
five business days of receipt of a request
to register an application developer’s
software with the API technology. We
noted the authenticity verification
process would need to be objective,
apply to the application developer and
not their software, and be the same for
all application developers. We sought
comment in 84 FR 7486 on factors that
would enable registration with minimal
barriers, including options and
associated trade-offs. Additionally, we
sought comment at 84 FR 7486 on other
timing considerations for application
developer authenticity verification.
Comments. Commenters asked for a
longer timeframe to complete the
authenticity verification process of
application developers. Some
commenters asked to extend the
authenticity verification timeframe to
ten business days. Commenters
suggested adding ‘‘and any receipt of
any additional requested information
needed in order to verify the developer’s
authenticity’’ to ‘‘within five business
days of receipt of an application
developer’s request to register their
software application with the API
technology provider’s authorization
server.’’
Commenters suggested various
methods for verifying the authenticity of
application developers and
applications, including by proposing
required registration information, or
required attestation to model privacy
guidelines or industry best practices.
Other commenters suggested various
approaches for verifying application
developers and applications, including
by working with industry to establish a
verification body, privacy and security
trust or certification framework, and
other more detailed recommendations.
Several commenters suggested requiring
application developers to attest to
providing a model privacy notice to
patients. Commenters suggested
mandating terms and conditions and
consent requirements as part of the
registration process.
Response. We appreciate feedback
from commenters. To improve the
organization of these Condition and
Maintenance of Certification
requirements, we moved the
requirements proposed in
§ 170.404(a)(2)(ii)(C) to the finalized
§ 170.404(b)(1)(i) under the combined
§ 170.404(b)(1), ‘‘Authenticity
verification and registration for
production use.’’ We accept
commenters’ requests to establish a
longer time period for this permitted,
but not required, process to verify the
authenticity of application developers
E:\FR\FM\01MYR3.SGM
01MYR3
25764
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
who seek to register their software
application for use with the Certified
API Developer’s certified API
technology. We have adopted ten
business days as the timeframe by
which this process would need to be
completed and as a result find it
unnecessary to add the text
contemplating a back and forth between
the Certified API Developer and API
User. We recommend that Certified API
Developers who elect to institute a
verification process implement a
process that is as automated as possible
to ensure they remain in compliance
with our final policy. Given that we
combined authenticity verification and
registration for production use in one
requirement finalized in § 170.404(b)(1),
we reduced the scope of these
requirements to Certified API
Developers with a Health IT Module
certified to the certification criterion
adopted in § 170.315(g)(10) to remain
consistent with the scope of
applicability of registration for
production use from the Proposed Rule.
We also note that authenticity
verifications would likely occur more
frequently for patient-facing
applications that are not sponsored by
API Information Sources. We anticipate
that an API Information Source (e.g., a
health care organization) that is a
HIPAA covered entity would vet and
enter into a HIPAA business associate
agreement with a provider-facing
application developer prior to using the
application within their internal
technical enterprise. In comparison, a
patient-facing application is likely to
connect to an API Information Source’s
resource server using a public service
base URL of a § 170.315(g)(10)-certified
Health IT Module in service to the
patient’s HIPAA Privacy Rule right of
access (45 CFR 164.524) or based on a
patient’s HIPAA authorization (45 CFR
164.508) without first establishing a
relationship with the API Information
Source. For patient-facing applications,
and to the comments suggesting we
require various modes of attestation to
privacy guidelines in such contexts, we
refer commenters to the information
blocking provisions in section VIII for a
discussion of permitted behaviors
regarding privacy attestations.
Comments. Commenters suggested
including a warning by the API Data
Provider that the application developer
selected by the patient or patientdesignee is untrusted.
Response. We thank commenters for
their feedback. An API Information
Source would not be prohibited from
showing a warning to patients as part of
the patient authorization for an
application to receive their EHI from an
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
API Information Source. This could
include a warning that an application
attempting to access data on behalf of a
patient is untrusted. We refer
commenters to the information blocking
provisions in section VIII for additional
information about providing warnings
to patients.
ii. Registration for Production Use
We proposed in 84 FR 7494 in
§ 170.404(b)(1) to require API
Technology Suppliers to register and
enable all applications for production
use within one business day of
completing its verification of an
application developer’s authenticity.
Comments. Commenters generally
supported the proposed registration
requirements. Most commenters
suggested extending the registration
timeframe to five business days.
Response. We appreciate the feedback
from commenters. We have reorganized
this section of the regulation text for
readability by combining ‘‘Authenticity
verification’’ with ‘‘Registration for
production use’’ under the heading
‘‘Authenticity verification and
registration for production use’’ in
§ 170.404(b)(1). We accepted the
recommendation from commenters to
extend the registration timeline and
have finalized in § 170.404(b)(2)(ii) a
requirement for Certified API
Developers with Health IT Modules
certified to the certification criterion
finalized in § 170.315(g)(10) to register
and enable all applications for
production use within five business
days of completing its verification of an
application developer’s authenticity
pursuant to requirements finalized in
§ 170.404(b)(1)(i).
iii. Service Base URL Publication
We proposed in 84 FR 7595 in
§ 170.404(b)(2) to require an API
Technology Supplier to support the
publication of service base URLs for all
of its customers, and make such
information publicly available, in a
computable format, at no charge.
Comments. A majority of commenters
supported the proposal requiring API
Technology Suppliers to publish service
base URLs for all of its customers.
Several commenters recommended the
creation of a single, publicly available
repository to maintain all client
endpoints. Some stakeholders
recommended ONC require additional
facility information be published with
the service base URL. Commenters who
disagreed with this proposal stated that
health IT developers cannot publish
client information without their
consent, and that API Data Providers
PO 00000
Frm 00124
Fmt 4701
Sfmt 4700
should have the sole authority to
publish their endpoints.
Response. We thank commenters on
their feedback on our proposal requiring
a Certified API Developer to publish
service base URLs for all of its
customers. The public availability and
easy accessibility of this information is
a central necessity to assuring the use of
certified API technology without special
effort, particularly for patient-facing
applications. We agree with the points
made by commenters on the need for a
single or multiple publicly available
repositories that maintain provider
service base URLs. We encourage
industry to coalesce around the
development of a public resource from
which all stakeholders could benefit.
We believe this would help scale and
enhance the ease with which service
base URLs could be obtained and used.
While we support the concept of
repositories for service base URLs, we
do not believe that creating a
requirement under the Program is the
appropriate mechanism to foster
industry support around this concept at
this time.
We acknowledge that stakeholders
expressed concern about Certified API
Developers publishing client service
base URLs and revised our approach to
focus on service base URLs necessary to
support patient access. We anticipate
that many services related to certified
API technology will be developed and
made available and do not believe it is
appropriate to burden Certified API
Developers with publishing all service
base URLs for these services for all of
their customers. We considered several
options, including requiring Certified
API Developers to publish service base
URLs for only those API Information
Source customers for whom they
manage/host an authorization server
centrally. However, we determined that
alternative options would not meet our
policy interests and would lead to
unnecessarily complex and burdensome
approaches and would not achieve the
Cures Act’s goals of enabling EHI to be
accessed, exchanged, and used without
special effort. Additionally, we
considered requiring that all Certified
API Developers with certified API
technology, that is, health IT developers
with a Health IT Module certified to
§ 170.315(g)(7) through (10), meet this
requirement. However, we determined
that it would be more beneficial to allow
health IT developers to focus energy and
resources on upgrading their technology
to the certification criterion finalized in
§ 170.315(g)(10). Therefore, we have
finalized in § 170.404(b)(2) that a
Certified API Developer must publish
service base URLs for all Health IT
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
Modules certified to § 170.315(g)(10)
that can be used by patients to access
their EHI. We further require that a
Certified API Developer must publicly
publish service base URLs for all
customers in a machine-readable format
at no charge regardless of whether the
Health IT Modules certified to
§ 170.315(g)(10) are centrally managed
by the Certified API Developer or locally
deployed by an API Information Source.
We note our focus for this criterion on
‘‘service base URLs for Health IT
Modules certified to § 170.315(g)(10)
that can be used by patients to access
their EHI.’’ We believe that Certified API
Developers will have adequate
relationships with API Information
Sources in the process of providing
Health IT Modules certified to
§ 170.315(g)(10) and will be able to
collect and publish all service base
URLs that support patient access on
behalf of their customers. Furthermore,
we note that API Information Sources
would be obligated to share such service
base URLs with Certified API
Developers to avoid violating the
Technical Interference Information
Blocking provisions as discussed further
in section VIII. Certified API Developers
must make available appropriately
scoped service base URLs that can be
used by patients to access their EHI for
Health IT Modules certified to
§ 170.315(g)(10).
iv. Providing (g)(10)-Certified APIs to
API Data Providers
We proposed in 84 FR 7494 in
§ 170.404(b)(3) that an API Technology
Supplier with Health IT Modules
previously certified to § 170.315(g)(8)
must provide all API Data Providers
Health IT Modules certified to
§ 170.315(g)(10) within 24 months of
this final rule’s effective date.
Comments. The majority of comments
received urged ONC to extend the
timeline beyond the 24 months
proposed. Many commenters requested
separate timelines for developers and
providers. Several commenters
recommended 36 months. Some
commenters offered alternatives ideas
for timelines, including a stepwise
approach, or ONC only determining
technical timelines, and allowing CMS
to cover provider timelines. Only a few
commenters encouraged faster adoption.
Response. We appreciate commenters’
feedback on our proposal. Given the
reduced scope of the overall updates
required by this final rule, our belief
that the industry is well-prepared to
meet this certification criterion’s
requirements once the final rule is
published, and the Cure’s Act
expectation that secure, standards-based
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
APIs would be made available in a
timely manner, we have retained a 24
month compliance timeline, which will
start from the publication date of the
final rule. At that point, it will be
approximately five years since the Cures
Act’s passage and we believe its
implementation should not be delayed
any further. We also remind
stakeholders that this is within 24
months of this rule’s publication
compliance date for supplying all API
Information Sources with Health IT
Modules certified to § 170.315(g)(10)
enables Certified API Developers (based
on their client base and IT architecture)
to determine the most appropriate
timeline for development, testing,
certification, and product release cycles.
Thus, we have finalized in
§ 170.404(b)(3) that a Certified API
Developer with certified API technology
previously certified to the certification
criterion at § 170.315(g)(8) must provide
all API Information Sources with such
certified API technology deployed with
certified API technology certified to the
certification criterion in § 170.315(g)(10)
within 24 months of the publication
date of the final rule.
v. Compliance for Existing Certified API
Technology
We proposed in 84 FR 7486 that API
Technology Suppliers with Health IT
Modules certified to § 170.315(g)(7), (8),
or (9) must revise their existing API
documentation within six months from
the final rule’s effective date.
Comments. Some commenters
supported the requirement to revise
existing API documentation within six
months of the final rule’s effective date.
Others requested more time to allow
documentation and all other websites to
come into alignment before enforcement
of this Condition of Certification
requirement. One commenter requested
clarification on which documentation
requires revision within the six-month
timeframe.
Response. In order to align the API
Condition of Certification requirements
policies, we have broadened the scope
of the provision finalized in
§ 170.404(b)(4) to apply to all API
Condition of Certification requirements
finalized in § 170.404(a), including
§ 170.404(a)(1) through (4). Given the
change of scope, we renamed this
section to ‘‘Compliance for existing
certified API technology.’’ We
considered commenters’ request for
more time, but given the already
delayed effective date of Part 170 we
believed the proposed time of six
months sufficient to enable Certified
API Developers to become compliant
with the Condition of Certification
PO 00000
Frm 00125
Fmt 4701
Sfmt 4700
25765
requirements finalized in § 170.404(a).
This additional time provides Certified
API Developers with Health IT Modules
already certified to § 170.315(g)(7), (8),
or (9) a total of eight months from the
final rule’s publication to update their
policies and documentation to comply
with the requirements finalized in
§ 170.404(a). We did not allow a longer
time period than six months in
§ 170.404(b)(4) due to the fact that we
have finalized our proposal in
§ 170.404(b)(3) to require Certified API
Developers with Health IT Modules
previously certified to the certification
criterion in 170.315(g)(8) to provide
§ 170.315(g)(10)-certified APIs to API
Information Sources within 24 months
of final rule’s publication date. These
policies finalized in § 170.404(b)(4)
provide API Information Sources with
Health IT Modules certified to
§ 170.315(g)(8) with 18 months of
updated documentation before the new
requirements finalized in § 170.404(b)(3)
become effective. Setting a more
delayed compliance date than the one
finalized in § 170.404(b)(4) would have
unreasonably delayed and ultimately
diminished the benefits of the Program
requirements we have finalized in this
rule. In summary, we finalized in
§ 170.404(b)(4) that Certified API
Developers with Health IT Modules
certified to § 170.315(g)(7), (8), or (9)
must comply with § 170.404(a) no later
than six months after this final rule is
published in the Federal Register,
including by revising their existing
business and technical API
documentation and making such
documentation available via a publicly
accessible hyperlink that allows any
person to directly access the
information without any preconditions
or additional steps.
5. Real World Testing
The Cures Act requires, as Condition
and Maintenance of Certification
requirements under the Program, that
health IT developers successfully test
the real world use of the technology for
interoperability 107 in the type of setting
in which such technology would be
marketed. As discussed in the Proposed
Rule (84 FR 7495), the objective of real
world testing is to verify the extent to
which certified health IT deployed in
production contexts continues to
demonstrate conformance to the full
scope of applicable certification criteria
and functions with the intended use
cases as part of the overall maintenance
107 Defined in statute in section 3000 of the Public
Health Service Act (as modified by section 4003 of
the Cures Act) and defined in regulation at 45 CFR
170.102.
E:\FR\FM\01MYR3.SGM
01MYR3
25766
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
of a health IT’s certification. Real world
testing should assess that the certified
health IT is meeting the intended use
case(s) of the certification criteria to
which it is certified within the
workflows, system architectures, and
type(s) of care setting(s) for which it is
marketed (advertised, promoted, or
sold).
For the purpose of this Condition of
Certification requirement, in
§ 170.405(a), we proposed (84 FR 7495)
that successful real world testing means:
• The certified health IT continues to
be compliant to the full scope of the
certification criteria to which it is
certified, including the required
technical standards and vocabulary
codes sets;
• The certified health IT is
exchanging electronic health
information in the care and practice
settings for which it is intended for use;
and
• Electronic health information is
received by and used in the certified
health IT.
To fully implement the real world
testing Condition of Certification
requirement, we proposed Maintenance
of Certification requirements that would
require health IT developers to submit
publicly available prospective annual
real world testing plans and
retrospective annual real world testing
results for the certification criteria
focused on interoperability to which
each of its Health IT Modules is
certified (84 FR 7496).
Comments. Comments on the whole
support the establishment of a robust
process of real world testing. Several
commenters expressed concerns
regarding the quality and usability of
health IT. Specifically, commenters
indicated that issues related to health IT
usability may be contributing to
clinician burn-out or impacting patient
safety, noting that they therefore
strongly support the inclusion of robust
real world testing requirements.
Response. We appreciate all
comments, and have finalized real
world testing Condition and
Maintenance of Certification
requirements in § 170.405(a) and (b) as
proposed, with minor adjustments to
due dates and clarifications of several
points in response to specific comments
as discussed below.
Comments. Commenters indicated
that additional clarification of the real
world testing requirements would make
these Condition and Maintenance of
Certification requirements less
burdensome to implement. These
commenters specifically sought
additional guidance around the
expectations for an appropriate testing
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
plan and method of execution. One
commenter recommended that ONC
provide more guidance around what
care settings must be covered by test
plans, and establish a minimum number
of settings and test sites that are
applicable for certified Health IT
Modules.
Response. In response to comments
requesting additional guidance around
expectations and acceptable methods for
real world testing, we provide below
additional discussion, explanation, and
illustrative examples. At this time, we
have decided not to establish a
minimum number of settings or
minimum percentage or fraction of
production instances of the developer’s
applicable certified Health IT Modules
that must be included in the developer’s
annual real world testing activities.
While health IT developers are not
required to test their certified health IT
in each and every setting in which it is
intended for use, we would expect a
developer’s real world testing plan to
address each type of clinical setting for
which their health IT is marketed.
Developers must address in their real
world testing plans their choice of care
and/or practice settings to test and
provide a justification for their chosen
approach. We also remind developers
that although we are not requiring
testing in every setting for which the
certified health IT is marketed, we
encourage real world testing in as many
specific settings as feasible within each
type of setting for which the certified
health IT is marketed.
Comments. Some commenters
expressed a view that there has been too
much focus on the export capabilities of
systems and not enough attention paid
to providers being able to ingest data
received in standardized formats—such
as the Continuity of Care Document
(CCD) standard—from other providers,
including other providers who use the
same developer’s Health IT Modules
certified to produce exports in
conformance with the standards.
Response. The interoperability
focused criteria listed in § 170.405(a)
include required capabilities for
receiving and incorporating data in
accordance with referenced standards
and implementation specifications
adopted by the Secretary in part 170
subpart B. We believe this appropriately
aligns requirements for real world
testing of Health IT Modules’ ability to
ingest data with the capabilities their
certifications address.
Comments. A commenter
recommended that, for real world
testing of Health IT Modules certified to
the API criterion, the final rule require
health IT developers to provide a testing
PO 00000
Frm 00126
Fmt 4701
Sfmt 4700
environment (or ‘‘developer sandbox’’)
and require the use of a testing platform
and test scripts that validate the ability
of the API to meet the underlying
requirements for the version of FHIR® to
which Health IT Module(s) are certified,
any applicable FHIR® profiles, and
implementation guides.
Response. As discussed in the
Proposed Rule (84 FR 7496), we believe
health IT developers are in the best
position to design and facilitate
implementation of real world testing
approaches that balance the burdens of
this statutory requirement with its
intended assurances that certified health
IT as deployed in the types of clinical
settings for which it is marketed
(advertised, promoted, or sold)
continues to meet the Program
requirements, including but not limited
to interoperability performance,
applicable under the certification it
holds. While we recognize that testing
environments can be useful for a variety
of purposes, and would not generally
discourage developers from offering test
platforms specific to their products or
participating in the development and
use of open-source testing platforms, the
purpose of real world testing is to
demonstrate that Health IT Modules
continue to perform in conformance to
their certification when and as they are
deployed in production environments
supporting the types of clinical settings
for which the Health IT Modules are
marketed. Thus, real patient data and
real production environments will in
most cases best meet that need and
should be first considered when
developing real world testing plans.
Mandating creation or use of testing
environments for real world testing
would compete for developers’ time and
effort with the focus on innovative ways
to best serve the purpose of the real
world testing Conditions and
Maintenance of Certification
requirements at the least burden on
their customers and end users. We have
therefore not required health IT
developers to provide a testing
environment (or ‘‘developer sandbox’’)
nor have we required the use of a testing
platform or test scripts in order to
satisfy real world testing Condition and
Maintenance of Certification
requirements.
Comments. Several commenters
requested that ONC be mindful of the
burdens this testing could place on
health care providers in terms of time
and cost and take all necessary steps to
minimize such burdens. Commenters
specifically stated real world testing
would require significant work by
providers for whom, in the commenters’
stated view, there is no incentive to
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
participate in real world testing. Some
commenters specifically recommended
that HHS incentivize providers to
participate, stating that without
providers’ participation, this proposal
would become an untenable
requirement. One commenter requested
HHS clarify whether a developer would
be permitted to compensate its
customers for the time the customer
spends supporting the developer’s real
world testing activities.
Response. We thank commenters for
their feedback noting the potential for
health IT developers’ real world testing
activities to impose burden on
providers. We do appreciate the
importance of recognizing that
providers engage directly and actively
in various types of activities supporting
advancement of health IT. The fact that
many of these activities could be
included in robust real world testing
regimes suggests that we should provide
developers with extensive flexibility to
develop innovative real world testing
plans. We have therefore built into our
real world testing policy flexibility that
offers the developer a substantial
opportunity to design real world testing
approaches that minimize burden and
fully optimize value of the real world
testing activities and results to current
and prospective customers. We do not
believe that HHS incentives to providers
participating in real world testing would
be the most effective means of
alleviating burdens on health care
providers specifically attributable to
developers’ real world testing activities.
Rather, the flexibility of our policy
allows for, and encourages, developers
to approach real world testing in an
innovative mode so that they can
maximize efficiency and minimize
burden of real world testing for both the
developer and its customers. A wide
range of practical strategies are available
for developers to potentially consider in
creating such optimized solutions for
real world testing of their specific health
IT with their particular customer base.
Examples of this range of practical
strategies include, but are not
necessarily limited to: Avoiding some
activities that satisfy only the real world
testing Maintenance of Certification
requirements by including in its overall
real world testing plans the testing
typically associated with confirming
functionality of new installations and
upgrades of their software; and
innovating methods of measuring
products’ performance in real time use
through system metadata and/or
feedback from health information
networks and other exchange partners of
their customers.
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
In response to the recommendation
that developers be allowed to
compensate their customers for
participating in the developer’s real
world testing activities, we note that
nothing in our proposed or finalized
policy under part 170 would prohibit
that. In the event a developer concludes
that its real world testing approach
imposes on its customers directly
participating in real world testing
activities a burden that the developer
would like to offset for those customers,
we would not discourage the developer
from considering whether there may be
opportunities within the bounds of
other applicable laws or regulations for
developers of certified health IT to offer
customers some types of burdenoffsetting compensation or other
incentive for real world testing
participation. Analysis, interpretation,
or changes to such other law or
regulation is outside the scope of this
particular rulemaking action. Moreover,
outside the rulemaking process,
developers should be aware that ONC is
not in a position to provide general
guidance on Federal laws specific to
compensation arrangements or advice
specific to any particular circumstances
or contemplated conduct related to
developers compensating providers for
participating in developers’ real world
testing activities. However, if developers
or providers may be contemplating a
potential compensation arrangement
related to offsetting providers’ cost or
burden of engagement in developers’
real world testing, we offer as a point of
information that one publicly stated
purpose of the HHS Office of the
Inspector General advisory opinion
process is to provide meaningful advice
about of the applicability of the antikickback statute or other OIG sanction
statutes in specific factual situations.108
Comments. One commenter expressed
concern that developers with small
customer bases will have smaller pools
of participants willing to undergo a
lengthy process which will require
significant resources and suggested
developers submit results from a more
limited scope of testing only every three
years.
Response. We reiterate that the policy
we have finalized includes substantial
flexibility for developers to assess how
to meet the real world testing Condition
and Maintenance of Certification
requirements in a way that
appropriately minimizes burden on the
current users of their certified health IT.
108 For more information about HHS Office of the
Inspector General advisory opinions and advisory
opinion process, please visit: https://oig.hhs.gov/
compliance/advisory-opinions/index.asp.
PO 00000
Frm 00127
Fmt 4701
Sfmt 4700
25767
Comments. A commenter expressed
concern that health care providers might
be unwilling to use health IT that had
not yet been certified, and that this
could make real world testing of Health
IT Modules prior to certification
impractical.
Response. In our Proposed Rule (84
FR 7429), we proposed in § 170.405(a)
to limit the applicability of this
Condition of Certification to health IT
developers with Health IT Modules that
are certified to one or more 2015 Edition
certification criteria focused on
interoperability and data exchange. We
also proposed that the real world testing
Condition of Certification would be met
through meeting the real world testing
Maintenance of Certification
requirements in § 170.405(b). We have
finalized this proposal as proposed.
Thus, the real world testing Condition
and Maintenance of Certification
requirements do not mandate testing
real world use of a Health IT Module in
actual production environments before
it is certified.
a. Unit of Analysis at Which Testing
Requirements Apply
Comments. One commenter requested
confirmation if real world testing is
required per CHPL listing, per product,
or per company.
Response. The real world testing
Condition and Maintenance of
Certification requirements apply to each
developer that has at least one Health IT
Module certified to at least one of the
interoperability and exchange focused
criteria listed in § 170.405(a), because
Condition and Maintenance of
Certification requirements apply to the
developer of certified health IT.
However, each developer of certified
health IT to which the real world testing
Condition and Maintenance of
Certification requirements apply must
conduct real world testing for each
criterion within the scope of real world
testing (§ 170.405(a)) to which each
developer presents for certification a
Health IT Module that is part of a health
IT product to be listed on the CHPL are
certified. A health IT developer with
multiple products that are listed on the
CHPL and that include one or more
Health IT Module(s) certified to one or
more of the criteria listed in § 170.405(a)
need only submit one real world testing
plan, and one real world testing results
report, for any given annual cycle of real
world testing, but the real world testing
plan and results report must address
each of the developer’s products that is
listed on the CHPL. Health IT
developers with multiple health IT
products that may include the same
Health IT Module(s) certified to one or
E:\FR\FM\01MYR3.SGM
01MYR3
25768
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
more of the criteria listed in 170.405(a)
have discretion to design their real
world testing plans in a way that
efficiently tests a combination of
products that include Health IT
Modules certified criteria listed in
§ 170.405(a) so long as testing plans and
results are traceable to specific certified
Health IT Modules and each criterion to
which the Health IT Module(s) are
certified, and address the types of
settings for which the products are
marketed. Because the purpose of real
world testing is to test health IT
products as they are deployed in
production, developers of health IT
products deployed through the cloud
who offer their products for multiple
types of clinical settings will be
required to test the same capability for
those different types of settings even if
it uses a single instance of the deployed
capability to serve all of those types of
settings.
b. Applicability of Real World Testing
Condition and Maintenance of
Certification Requirements
We proposed (84 FR 7495) to limit the
applicability of the real world testing
Condition of Certification requirement
to health IT developers with Health IT
Modules certified to one or more of the
certification criteria focused on
interoperability and data exchange or
availability listed in (then-proposed)
§ 170.405(a):
• The care coordination criteria in
§ 170.315(b);
• The clinical quality measures
(CQMs) criteria in § 170.315(c)(1)
through (c)(3);
• The ‘‘view, download, and transmit
to 3rd party’’ criterion in § 170.315(e)(1);
• The public health criteria in
§ 170.315(f);
• The application programming
interface criteria in § 170.315(g)(7)
through (g)(10); and
• The transport methods and other
protocols criteria in § 170.315(h).
We solicited comment on whether to
also include the ‘‘patient health
information capture’’ certification
criteria in § 170.315(e)(3), including the
value of real world testing these
functionalities compared to the benefit
for interoperability and exchange (84 FR
7496). We also solicited comment on
whether any other 2015 Edition
certification criteria should be included
or removed from the applicability list
(to be codified at 170.405(a)) for this
Condition of Certification requirement.
Comments. The vast majority of
commenters addressing this proposal
were in support of the specific criteria
proposed to be within the scope of real
world testing and expressed agreement
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
that required testing should be limited
to Health IT Modules certified to one or
more of the certification criteria listed in
§ 170.405(a) as proposed.
Response. We appreciate all feedback
received. The list of criteria to which
real world testing Condition and
Maintenance of Certification
requirements apply is finalized in
§ 170.405(a) as proposed.
Comments. We received one comment
supporting and two comments opposing
the addition of patient health
information capture criterion in
§ 170.315(e)(3) to the scope of real world
testing. One commenter specifically
recommended against including the
patient health information capture
criterion in § 170.315(e)(3) in real world
testing because of the significant
variability in how health IT certified to
this criterion is implemented. They
stated that this variability in the real
world could make cross-implementation
comparisons difficult, and stated that
testing for this criterion could present a
particular challenge based on difficulty
they anticipated would be encountered
in securing needed engagement from
patients as well as the exchange
partners who would presumably receive
the data as a result of the patient using
the ‘‘transmit’’ functionality.
Commenters opposed to addition of this
criterion to the real world testing
Condition and Maintenance of
Certification requirements also stated
this addition would add cost to the
developer which would then flow down
to end users and be burdensome to
clinician practices.
Response. On balance, the comments
received do not support expansion of
the scope of real world testing
requirements to include the patient
health information capture criterion in
§ 170.315(e)(3) at this time. In
developing the proposed list of criteria
to which real world testing Condition
and Maintenance of Certification
requirements would apply, we
concluded an initial focus on those
particular criteria would strike an
appropriate balance between the
magnitude of the challenge represented
by the new real world testing
requirements and the potential benefits
of their broader application. The
concerns raised by the commenters
recommending against adding the
patient health information capture
criterion in § 170.315(e)(3) to the scope
of real world testing requirements at this
time, combined with other comments
more generally recommending against a
broader scope at this time, tend to
support the conclusion that the scope
we proposed strikes an appropriately
practical balance until we and the
PO 00000
Frm 00128
Fmt 4701
Sfmt 4700
industry have benefit of experience and
innovation in real world testing. Thus,
the finalized list of criteria to which real
world testing requirements apply
(§ 170.405(a)) does not include the
patient health information capture
criterion in § 170.315(e)(3).
Comments. A few commenters
suggested expanding the scope of real
world testing requirements to include
the proposed ‘‘EHI export’’ criterion in
§ 170.315(b)(10).
Response. We appreciate the
confirmation that commenters
supported inclusion of the ‘‘EHI export’’
criterion in § 170.315(b)(10) alongside
the rest of the care coordination criteria
in § 170.315(b). We have finalized the
criteria listed in § 170.405(a) including,
as proposed, all criteria within
§ 170.315(b).
Comments. One commenter expressed
an opinion that the initial scope of
criteria is more expansive than the
commenter would suggest for an
introductory set, and asked that fewer
criteria be required for the initial rollout
of real world testing, delaying
application of the requirement to more
interoperability focused criteria until
experience has been amassed with real
world testing for a narrower selection of
criteria than we had proposed.
Response. Noting that the majority of
comments received were supportive of
the scope as proposed, we also balance
suggestions such as that offered by this
commenter against the Program’s needs
and the purpose of the real world testing
Condition and Maintenance of
Certification requirements. We do not
believe it would be in the best interest
of the Program or the health care
providers and patients who rely on
certified health IT to meet their needs
for interoperable health IT to narrow the
applicability of the real world testing
Condition and Maintenance of
Certification requirements further than
we proposed. We have, therefore,
finalized the criteria listed in
§ 170.405(a) as proposed.
Comments. Some commenters
advocated expanding the scope of the
real world testing requirement to
include select functionally-based
‘‘clinical’’ criteria within § 170.315(a)
that are included in the base EHR
definition.
Response. As explained in the
Proposed Rule (84 FR 7495), we did not
propose to include in the scope of real
world testing functionally-based
criteria, administrative criteria, or other
criteria that do not focus on
interoperability and exchange or
availability of data. The ‘‘clinical’’
certification criteria in § 170.315(a) were
noted in the Proposed Rule as an
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
example of criteria not proposed
because they require only that the
health IT enable the provider to record,
change, and access specific types of data
within the Health IT Module being
certified (or within a product that
includes the Health IT Module being
certified to the particular criteria).
However, real world testing of health
IT’s ability to exchange the types of data
these clinical criteria reference is
addressed through the inclusion of the
USCDI in the interoperability-focused
criteria listed in § 170.405(a) as
proposed, which is finalized as
proposed. In order to successfully
exchange interoperable EHI, the health
IT must be able to access it, and in order
to incorporate a type of data, the health
IT must be able to record it.
Comments. The majority of comments
received specifically referencing the
proposed inclusion of public health
criteria in the real world testing
requirement in § 170.405(a) support the
importance and inclusion of the public
health criteria in the scope of real world
testing requirements. One commenter
questioned the inclusion of the public
health criteria in § 170.315(f), stating the
commenter’s perception that extensive
variation between registries would make
this a challenging functionality to
demonstrate.
Response. Variations in system
configurations across different public
health agencies’ infrastructures may
suggest different real world testing
strategies may be most appropriate, or
most relevant to customers, compared to
what might be the case for some other
criteria within the scope of real world
testing. However, as noted below about
testing tools, we are aware of a wide
variety of resources and opportunities to
test real world interoperability
performance of Health IT Modules
certified to the public health criteria in
§ 170.315(f). Because interoperability
performance in actual production
environments is an important feature of
health IT certified to the public health
criteria in § 170.315(f), and noting the
support for its inclusion expressed by
most commenters, and we have
determined that the most appropriate
course is to finalize the inclusion of the
public health criteria in§ 170.315(f) in
the scope of real world testing in
§ 170.405(a).
Comments. One commenter expressed
concern that some of the criteria
proposed for inclusion in § 170.405(a)
be re-examined because they do not
include all three of the characteristics
our Proposed Rule described as being
demonstrated through real world
testing. Examples offered included that
some criteria proposed for inclusion in
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
§ 170.405(a) require exporting but do
not require receipt and use of electronic
health information by the certified
health IT.
Response. We appreciate commenters’
bringing to our attention that additional
discussion about the requirements
would be helpful to the community. For
the criteria proposed and finalized in
the real world testing scope in
§ 170.405(a), such real world testing
needs to address the interoperability
characteristics and all other
functionalities and capabilities
applicable based on the specific criteria
to which the Health IT Module is
certified. For example, even if a Health
IT Module is not certified to any
criterion that specifically requires it to
demonstrate, in order to be certified,
that the Health IT Module has the
capability to incorporate and use data
received directly from sources outside
the production environment in which it
is deployed, that Health IT Module will
still need to demonstrate conformance
to the full scope of each criterion to
which it is certified. This includes,
though it is not limited to, the technical
standards and vocabulary codes sets
included in each criterion to which it
certified.
c. Testing Plans, Methods, and Results
Reporting
We proposed (84 FR 7496) that a
health IT developers must submit an
annual real world testing plan to its
ONC–ACB via a publicly accessible
hyperlink no later than December 15, of
each calendar year for each of its
certified Health IT Modules that include
certification criteria specified for this
Condition of Certification. We proposed
(84 FR 7497) that a health IT developer
must submit an annual real world
testing plan to its ONC–ACB via a
publicly accessible hyperlink no later
than January 31, of each calendar year
for the preceding calendar year’s real
world testing.
We proposed that the real world
testing plan, which will be required to
be available to ONC and the public via
the CHPL no later than December 15 of
each year once this final rule is
effective, will need to address the health
IT developer’s real world testing that
will be conducted the upcoming
calendar year and must include, for
each of the certification criteria in scope
for real world testing in § 170.405(a) and
each Health IT Module certified to one
or more of these criteria (84 FR 7496):
• The testing method(s)/
methodology(ies) that will be used to
demonstrate real world interoperability,
including a mandatory focus on
scenario- and use case-focused testing;
PO 00000
Frm 00129
Fmt 4701
Sfmt 4700
25769
• The care and practice setting(s) that
will be tested for real world
interoperability, including conformance
to the full scope of the certification
criteria requirements, and an
explanation for the health IT
developer’s choice of care setting(s) to
test; 109
• The timeline and plans for
voluntary updates to standards and
implementation specifications that ONC
has approved (further discussed below);
• A schedule of key real world testing
milestones;
• A description of the expected
outcomes of real world testing;
• At least one measurement/metric
associated with the real world testing
for each certification in scope; and
• A justification for the health IT
developer’s real world testing approach.
We sought comment (84 FR 7497) on
whether we should specify a minimum
‘‘core’’ set of metrics/measurements and
examples of suggested metrics/
measurements as well as on the timing
of required real world testing results
reporting. We also invited comment on
the annual frequency and timing of
required real world testing results
reporting.
Comments. Most comments received
supported the proposed requirement for
Health IT Modules to undergo real
world testing. In addition, commenters
indicated that real world testing should
occur on a regular basis to ensure
various types of changes in the Health
IT Modules or production environments
have not affected functionality required
by the certification. Several commenters
recommended development of more
specific minimum requirements for test
plans and measurement of results. They
further recommended that ONC provide
additional guidance about what will
constitute a minimally acceptable
testing plan with explicit content
depicting the minimum requirements
for each component of the testing plan.
Response. We thank commenters for
their feedback. As discussed in the
Proposed Rule and above, we believe
health IT developers are in the best
position to design and facilitate
implementation of real world testing
approaches that balance the burdens of
this statutory requirement with its
intended assurances that certified health
109 We do not specifically define or limit the care
settings and leave it to the health IT developer to
determine. As an example, health IT developers can
consider categories, including but not limited to,
those used in the EHR Incentive Programs (https://
www.cms.gov/Regulations-and-Guidance/
Legislation/EHRIncentivePrograms/Downloads/
UserGuide_QNetHospitalObjectivesCQMs.pdf);
long-term and post-acute care; pediatrics;
behavioral health; and small, rural, and
underserved settings.
E:\FR\FM\01MYR3.SGM
01MYR3
25770
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
IT meets Program requirements,
including interoperability performance,
applicable under the certification it
holds. We have therefore finalized
requirements in § 170.405(b)(1)
designed to avoid the risk of a ‘‘one size
fits all’’ set of testing tools (discussed at
84 FR 7496) that might not fully address
the concerns raised or provide the
assurances of interoperability
performance sought across the various
types of care settings. By establishing in
§ 170.405(b)(1)(iii) the topics and
considerations every developer must
address in its required real world testing
plan but not specifying how they must
address these required aspects we have
provided health IT developers with a
requirement that at the same time
provides them with the flexibility to
develop and implement successful real
world testing plans that will best
balance burden and value for the
customers of each of their products. The
ONC–ACBs will be responsible for
assessing real world testing plans and
results reports for completeness in
comparison to what § 171.405(b)(1)
requires the plan and results reports to
include or address, but will otherwise
not be formally evaluating the testing
approach for quality as a testing
approach. We note for clarity that while
ONC–ACB’s will not be judging a
developer’s real world testing
approaches as planned or as executed,
the contents of a developer’s publicly
available real world testing results could
be used by an ONC–ACB as part of its
ongoing surveillance of certified health
IT. Additionally, we have finalized our
proposed requirement in § 170.405(a)
and (b) that requires developers subject
to the real world testing Condition and
Maintenance of Certification
requirements (see § 170.405(b)(2)(i))
who discover in the course of their real
world testing any non-conformities with
the standards, functionalities, or other
requirements of any certification
criterion under the Program, to address
these non-conformities in order for their
Health IT Modules to remain certified.
This requirement will apply in the same
manner to Health IT Modules certified
under the SVAP flexibility in
§ 170.405(b)(8) or (9) as to Health IT
Modules not certified under the SVAP
flexibility. Thus, developers who
discover non-conformity to any Program
requirement(s) will be required to report
those non-conformities to their ONC–
ACB(s). In order to provide a clear
threshold for determining whether a
developer has acted on this requirement
in a timely manner, we have finalized
the requirement to report nonconformities within 30 days of
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
discovering them (see § 170.405(b)(2)(i)).
We believe 30 days is an appropriate
timeframe to allow developers the
opportunity to gather all facts and report
to their ONC–ACBs the details and
nature of the non-conformity.
Furthermore, we believe more than the
30 days would extend beyond the
timeframe by which a non-conformity
should be investigated by an ONC–ACB
and corrective action implemented, if
necessary.
We are aware that by choosing not to
specify particular methods, tools, or
checklists of activities that must be
included in real world testing, and
providing instead extensive flexibility
for developers to select tools and design
overall methodologies based on their
knowledge of their products and
customers, we are asking developers to
apply innovation and problem solving
skills to their real world testing. We
believe that the alternative of
developing a catalog of detailed
specifications and checklists, as some
commenters suggested, would be
undesirably complex, less supportive of
ongoing innovation in the market, and
not ultimately less burdensome for
developers or their customers. As we
have noted in the context of prior
Program rulemaking actions, we often
make additional information resources
and non-binding guidance regarding
real world testing available through
familiar communications channels, such
as the HealthIT.gov website.
Comments. Several commenters
expressed concerns about the burden of
real world testing in specific reference
to ONC–ACB processes for in-the-field
surveillance of certified products’
continued conformance to applicable
certification criteria. Some comments
raised concerns about the burden that
could be placed on developers’
customers should developers choose to
rely heavily on the procedures used by
ONC–ACBs for randomized or reactive
in-the-field surveillance. Some
comments indicated concern that ONC
would expect, encourage, or view more
favorably real world testing approaches
that rely heavily or exclusively on use
of ONC–ACB in-the-field surveillance
protocols.
Response. In the Proposed Rule, we
stated that ‘‘developers may consider
working with an ONC–ACB and have
the ONC–ACB oversee the execution of
the health IT developer’s real world
testing plans, which could include inthe-field surveillance per § 170.556, as
an acceptable approach to meet the
requirements of the real world testing
Condition of Certification’’ requirement
(84 FR 7497). Having considered all
comments received, we have decided
PO 00000
Frm 00130
Fmt 4701
Sfmt 4700
not to finalize the flexibility for
developers to use ONC–ACBs’ in-thefield surveillance as part of the
developer’s real world testing plan. We
do not believe that use or replication of
methods or protocols used by ONC–
ACBs for in-the-field surveillance of
certified Health IT Modules would be
the most effective or the least
burdensome approach available to
health IT developers and are concerned
accepting real world testing approaches
that rely on ONC–ACB in-the-field
surveillance could slow rather than
accelerate development of more
innovative approaches to real world
testing. We are also concerned that
inclusion of ONC–ACB execution of inthe-field surveillance within a
developer’s real world testing approach
could lead to confusion as to whether
the organization that is an ONC–ACB
was applying in-the-field surveillance
protocols in its capacity as an ONC–
ACB as part of its oversight
responsibilities on behalf of ONC or in
its private capacity on behalf of the
health IT developer. We believe it is
important, to protect HIPAA covered
health care providers and other HIPAA
covered entities and their business
associates from inadvertently violating
requirements related to disclosure of
health information, to maintain a clear
distinction of when an organization that
is an ONC–ACB is acting in the ONC–
ACB capacity and when it is acting in
its private capacity. We note and
emphasize this because, in the event a
developer may choose to engage
services in support of developing or
implementing the developer’s real
world testing plans from an organization
or entity that also happens to be an
ONC–ACB, all activities undertaken by
the organization or entity to develop,
execute, or support the development or
execution of the developer’s real world
testing plan would be activities outside
the ONC–ACB role. In such
circumstances, the organization that is
an ONC–ACB would be acting in a
separate, private capacity. Note that an
organization providing such private
services that involve ePHI would likely
be characterized under the HIPAA Rules
as a business associate to the health care
provider and subject to the HIPAA
Rules. The oversight authorities
attached to its ONC–ACB role would not
apply to the organization’s requests to
gain access to health care provider
facilities or to EHI for purposes of
providing these separate support
services to health IT developers for
conduct of the developers’ real world
testing.
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
Comments. Several commenters
sought confirmation that a test server
could be used for real world testing
instead of a production environment,
given the permissible use of synthetic
data.
Response. After considering the
totality of comments received, we have
decided to finalize that a test server
could be used for real world testing and
provide the flexibility included in the
Proposed Rule that allows for real world
testing to occur in a production setting
using real patient data in accordance
with applicable laws as well as in an
environment that mirrors a specific
production environment used in a type
of clinical setting for which the health
IT is marketed. We have also decided to
finalize the flexibility for the developer
to use synthetic patient data in lieu of
or in addition to real patient data in real
or simulated/test scenarios executed in
environments that mirror production
environments where the health IT is
deployed. However, we emphasize that
the purpose of real world testing is to
demonstrate that the Health IT
Module(s) work as expected in real-life
clinical settings. We note, as a point of
potential interest for such consideration,
that real world testing plans that meet
the Program requirement might include
observation or measurement of the
health IT’s interoperability performance
while actual scenarios and use cases are
executed by end users on real patient
data in actual operational contexts. If a
developer chooses to use synthetic data,
non-production (mirrored)
environments, or a combination of real
and synthetic data or production and
mirrored environments, to complete any
portion of their annual real world
testing requirements, the developer
must include in their real world testing
plan and results submissions a specific
explanation justifying how the synthetic
data, mirrored environment, or both are
appropriate and adequate to meet the
real world testing requirement(s) for
which they will be or were used.
Comments. Several commenters
sought confirmation that a product
serving multiple care settings could
complete a single test relevant to all
settings and ask ONC to provide a list
of eligible care settings for reference.
Response. The finalized real world
testing Condition and Maintenance of
Certification requirements include
testing each criterion listed in
§ 170.405(a) to which any Health IT
Module(s) within the product are
certified, and testing in each type of
setting to which it is marketed. To
satisfy these Condition and
Maintenance of Certification
requirements as finalized, a single
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
testing plan, protocol, or approach must
address all the types of settings to which
the product, with all its included Health
IT Module(s), is marketed and do so
with traceability to each Health IT
Module of its real world performance in
each type of setting for which it is
marketed. We believe it is possible to
construct a real world use scenario or
use case that tests more than one type
of setting applicable to the Health IT
Module, and confirm that a developer is
not required to develop unnecessarily or
artificially separate scenarios or use
cases across multiple types of settings to
which a given developer markets its
applicable Health IT Module(s). With
respect to the types of settings required
to be addressed by a given developer’s
plan, we do not believe that additional
specification is necessary because we
believe each developer is well situated
to know for what types of settings the
developer (or its authorized resellers)
has marketed, is marketing, or intends
to market its Health IT Modules. For
purposes of this Condition and
Maintenance of Certification
requirement as finalized, there is no
exclusion for settings or health care
provider types based on their inclusion
or lack of inclusion in, or eligibility or
ineligibility for, and particular Federal
health care program or initiative.
Therefore, the types of settings eligible
to be addressed in a developer’s real
world testing plan for a given year
include all those to which product(s)
including one or more Health IT
Modules certified to one or more of the
criteria listed at § 170.405(a) as of
August 31 of the year in which that
specific annual real world testing plan
is due have been or are marketed when
the real world testing plan is submitted,
and/or the types of settings for which
the developer anticipates marketing
such product(s) in time to include them
in a specific year’s real world testing
activities.
Comments. Several commenters
requested ONC ensure that real world
testing requirements do not create
infrastructure for testing of public
health transactions without public
health involvement. Several
commenters noted that public health
organizations and many public health
agencies already offer resources and
processes used in onboarding processes
for public health reporting connections
and suggested these resources and
processes could be used more broadly to
test health IT’s real world performance
on public health interoperability criteria
rather than requiring creation of new or
different tools.
Response. We would tend to agree
that relying for specific use cases on
PO 00000
Frm 00131
Fmt 4701
Sfmt 4700
25771
testing infrastructures developed
without appropriate involvement of key
participants in the use case would not
be an optimal approach. Also, we
reiterate that we encourage developers
to consider a variety of options and
approaches before finalizing their
annual real world testing plans. We
would encourage developers to consider
the real world testing potential of
resources, tooling, and infrastructure
already offered by public health
organizations and agencies before
embarking on efforts to develop
additional tooling. We also note that, for
the interoperability-focused public
health criteria, alternatives that would
avoid both overuse of simulation
environments and asking public health
agencies to engage in work unique to
developers’ real world testing plans
might include structured observation
and measurement of interoperability
performance in actual public health data
reporting/exchange as well as the testing
ordinarily conducted for onboarding/
confirming connectivity of newly
deployed/upgraded implementations to
public health data exchange
infrastructures.
Comments. A number of commenters
expressed support of requiring the use
of metrics/measurements for real world
testing. One commenter stated that ONC
should not allow just one measurement
to suffice for real world testing of
interoperability of a Health IT Module.
Several commenters recommended ONC
include a description of
‘‘measurement,’’ provide clarity on the
role of measurement, and provide a
‘‘sample’’ or suggested set of metrics/
measurements to help foster alignment
of reporting around meaningful
common metrics/measurements across
developers. Some commenters
recommended ONC identify a core set of
metrics/measures that developers would
be required to include, or from which
developers would be required to select
specific metrics/measures to include, in
their real world testing plans. Other
commenters advocated against
developers being required to submit
testing results for a minimum ‘‘core’’ set
of general metrics, providing the
rationale that not all metrics will be
available to all systems uniformly and
suggesting that many metrics are
retained in the provider’s locally
integrated production systems and
unavailable to the developer of any
given Module(s) without considerable
effort to retrieve the data. One
commenter recommended requiring that
each developer’s real world test plan
include measures addressing all of the
domains of the NQF report:
E:\FR\FM\01MYR3.SGM
01MYR3
25772
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
Measurement Framework to Assess
Nationwide Progress Related to
Interoperable Health Information
Exchange to Support the National
Quality Strategy.110
Response. The comments on real
world testing did not show clear,
widespread support for any specific
subset of available metrics as a ‘‘core’’
set or catalog that a significant portion
of the affected communities (health IT
developers, health care providers, and
public health agencies) would generally
agree should be consistently used across
all developers’ real world testing plans.
Thus, we have finalized the real world
testing plan requirements (see
§ 170.405(b)(1)(iii) and real world
testing results reporting requirements
(see § 170.405(b)(2)(ii)) without
identifying a minimum set of measures
that must be used or a catalog of
suggested measures from which a
developer would be expected to choose
in constructing its real world testing
plans. We reiterate that each developer
must choose a measurement approach,
including at least one measurement/
metric per applicable criterion, for use
in each year’s real world testing and
explain the selection and relevance of
its selected measures/metrics within its
justification for its real world testing
approach in that year’s plan and results
report.
Comments. Comments were received
on the frequency and timing of real
world testing. One commenter stated the
policy should not require annual testing
if the capability certified for a given
criterion remains unchanged year to
year, offering the example that if a
Health IT Module is certified for both
§ 170.315(b)(1) and (b)(2) and the
developer is planning to release material
updates to the capabilities specific to
§ 170.315(b)(1), but not make any
material changes specific to the
Module’s certification to § 170.315(b)(2),
this commenter would prefer that the
Health IT Module would need to submit
a testing plan and subsequent results
addressing only the § 170.315(b)(1)
criterion for the year the change is
made. Another commenter expressed
skepticism regarding the value of annual
real world testing requirements,
expressing a preference for an approach
that developers would, after an initial
cycle of post-certification real world
testing of a Health IT Module, be
required to re-test only when updating
to National Coordinator-approved newer
versions of adopted standards included
in applicable criteria or when making
110 https://www.qualityforum.org/Projects/i-m/
Interoperability_2016–2017/Key_Informant_
Summary_Report.aspx (last accessed 12/17/2019).
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
major functional updates to the certified
Health IT Module. One commenter who
was overall not supportive of the real
world testing requirement stated that
developers would need a two-year cycle
instead of a one-year cycle in order to
adequately demonstrate compliance
with full functionality testing. One
commenter specifically expressed
support for the annual frequency and
timing of required real world testing
results reporting.
Response. We thank the commenters
for their feedback regarding the
frequency and timing of real world
testing. We have finalized the
requirement for annual testing in
§ 170.405(b)(1). Ongoing annual testing
is needed to ensure that Health IT
Module(s) continue to perform as
intended in the types of settings where
patients and health care providers
continue to rely on it to meet their
interoperability needs.
Comments. Several commenters
expressed support of the proposed real
world testing plan requirements and
requested we strengthen this provision
to require that developers test their
products within each clinical specialty
to which the technology would be
marketed. One commenter requested
that we define with more particularity
what is expected of developers during
the testing to account for the differing
conditions under which Health IT
Modules are deployed, and how for
example, the system works particular
conditions like server degradation.
Several other commenters suggested we
provide a standardized template for use
in developing test plans. Commenters
described a template would include all
required testing elements and promote
greater consistency in the way the test
plans are written by the various
developers.
Response. For reasons stated in the
Proposed Rule (84 FR 7496) and above,
we do not believe a centrally developed
or standardized approach for real world
testing plans is the most appropriate
solution at this time. By centrally
mandating or endorsing a single
template in the interest of consistently
formatted documentation, we are
concerned that we might inadvertently
discourage innovation in both testing
approaches and their communication to
the customer community. What the plan
must include or address for each
applicable criterion to which the
developer’s Health IT Module(s) are
certified is outlined in
§ 170.405(b)(1)(iii), as finalized by this
rule. We believe the plan requirements
finalized in the plan requirements in
§ 170.405(b) are specific enough to
ensure the plans can be completed by
PO 00000
Frm 00132
Fmt 4701
Sfmt 4700
developers and effectively reviewed for
completeness by ONC–ACBs, and that
both the substance and clarity or
efficacy of presentation can both be
examined and considered by any
interested parties—from health care
providers to informatics and
interoperability researchers. Because
individual circumstances and needs
may vary even within the same type of
setting or clinician specialty, it would
be not be possible at this time to define
a real world testing regime that
eliminated all of the variability
developers may have in implementing
their real world testing plans.
Comments. One commenter sought
clarification on the total minimum
number of metrics required for a
developer’s real world testing plan to be
considered complete and in compliance
with the requirement.
Response. A developer’s real world
testing plan must include at least one
metric for each applicable certification
criteria. To ensure that we are providing
clear guidance, we offer the following
illustrative example: A developer with
one Health IT Module that is certified to
five criteria would need to include in its
real world testing plan at least one
specific measurement/metric associated
with the real world testing for each of
those five criteria. Depending on the
specific criteria and the developer’s real
world testing approach, this could call
for up to five different measurements/
metrics, or could be addressed with
fewer different measurements/metrics
but a specific measurement/metric
would need to be identified/attributed
within the plan to each of the applicable
certification criteria.
Comments. A few commenters stated
concerns regarding our mandatory focus
on scenario- and use case-focused
testing. One commenter expressed a
view that this would be expensive and
time consuming, stating that this
expense limits scenario- and use casefocused testing in the number of settings
that can realistically be tested in any
given year. One commenter noted that
as more settings are tested, fewer
scenarios can be run per setting. Two
commenters sought more information
on the mandatory scenario- and use
case-focused testing that will be
required, recommending that Health
Information Service Providers (HISPs)
be able to attest to the relevant use cases
and provide the proper evidence of
testing associated to those scenarios.
Response. In light of comments
received, we can see how our use of
terms that are also used in the context
of ONC–ATL laboratory or ONC–ACB
surveillance testing, and our reference
in one instance to in-the-field
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
surveillance, could have led to an
inference that our use of these terms
implied we would expect to see the
same or similar testing protocols used in
real world testing. However, we did not
propose that real world testing would
require developers to set up and execute
artificial scenarios or activities solely for
purposes of testing. In fact, we do not
encourage use of the laboratory testing
or ONC–ACB in-the-field surveillance
protocols to conduct real world testing,
as those particular test methods, tools,
and surveillance protocols were not
designed and should not be relied upon
for real world testing. The testing
methods/methodologies need to address
realistic scenarios, use cases, and
workflows associated with
interoperability, and we do expect
developers to consider such factors as
the size of the organization that
production systems support, the type of
organization and setting, the number of
patient records and users, system
components and integrations, and the
volume and types of data exchange in
planning for real world testing.
Comments. One commenter expressed
agreement that the developer is best
situated to determine the most effective
real world testing plan for their
products. One commenter requested
developers be allowed to work together
with their customers to define what real
world tests are.
Response. The requirements we
proposed and finalized provide
developers the opportunity to identify,
potentially in partnership with their
customers, the real-life scenarios, use
cases, and work flows applicable to the
customer’s day-to-day use of the Health
IT Module(s) to meet their
interoperability needs in their
production environments.
d. Submission Dates
We proposed that a health IT
developer must submit an annual real
world testing plan to its ONC–ACB via
a publicly accessible hyperlink for
availability to ONC and the public no
later than December 15, of each calendar
year, and that the plan must address all
of its Health IT Modules certified to the
2015 Edition certification criteria listed
in proposed in § 170.405(a) and (84 FR
7496). We proposed requiring that prior
to submission to the ONC–ACB, the
plan will need to be approved by a
health IT developer authorized
representative capable of binding the
health IT developer for execution of the
plan and include the representative’s
contact information. We proposed that
the plan due in any given year will need
to include all health IT certified to the
2015 Edition through August 31 of that
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
year (in other words, the August 31 that
immediately preceded the December 15
due date).
We further proposed that a health IT
developer would submit annual real
world testing results to their ONC–ACBs
via a publicly accessible hyperlink no
later than January 31 of each calendar
year for the real world testing conducted
in the preceding calendar year (84 FR
7497). We proposed that real world
testing results for each certification
criterion listed in § 170.405(a) would be
required to address the elements
required in the previous year’s testing
plan, describe the outcomes of real
world testing with any challenges
encountered, and provide at least one
measurement or metric associated with
the real world testing.
Comments. Some commenters
expressed concerns that the annual real
world testing plan due date falls in
December, noting that in addition to
multiple holidays widely celebrated in
the U.S., December can be a busy time
for many health IT developers due to
various year-end requirements and
necessary preparations to support
customers’ quality measurement data
submissions for CMS programs.
Response. We understand the
commenters’ concern that the proposed
real world testing plan publication due
date falls in the preparatory run-up to
year-end deadlines, including for many
developers completing preparations to
support their customers’ successful
clinical quality measurement data
submission during CMS program
windows that typically open on the first
Federal business day in January. In
consideration of comments received, we
have made edits to the phrasing of the
CFR text in § 170.405(b) to convey with
more precise clarity that under the
policy we have finalized, the developer
is required to submit its real world
testing plans so that the ONC–ACB can
conduct its completeness review and
publish the plan hyperlink on CHPL no
later than December 15 of each year.
This allows for the ONC–ACB and
developer to identify and agree on the
date by which the developer will
actually submit its plan to the ONC–
ACB, which could be well in advance of
December. One practical implication of
the single-deadline feature of the policy
as proposed is that in order for the plans
to be submitted to ONC and made
publicly available by the single
deadline, the ONC–ACB’s requirement
to review plans for completeness per
Program requirements will in many
cases mean that the ONC–ACB will
need the developer to submit the plan
to the ONC–ACB in advance of the
single deadline. We have finalized the
PO 00000
Frm 00133
Fmt 4701
Sfmt 4700
25773
December 15 due date for real world
testing plan publication on CHPL as
proposed. We have also made clarifying
edits to the finalized regulation text (see
§ 170.405(b)(1)) in comparison to the
proposed text to more explicitly
recognize the practical implication that
the developers’ and ONC–ACBs’
responsibility for a single publication
date for the plans means that the plan
must be submitted by the developer to
the ONC–ACB on a date agreed between
them that allows for publication by the
deadline. We encourage developers and
ONC–ACBs to consider allowing at least
one calendar month so that the
December 15 due date for ONC–ACBs’
publication of real world testing plans
will be consistently met. We also note
that nothing in § 170.405 as finalized
precludes a developer and ONC–ACB
from agreeing on the developer
submitting its annual real world testing
plan to the ONC–ACB more than one
month prior to December 15. We have
finalized the single plan publication
deadline as proposed.
We did not receive comments specific
to August 31 as the annual date when
a Health IT Module must be certified by
in order to be required to be included
in the real world testing plan due that
year. We have finalized this aspect of
our policy as proposed in
§ 170.405(b)(1)(ii). Thus, developers can
submit their real world testing plans as
early as September 1 and on a rolling
basis thereafter for products in scope for
the following year, which also addresses
commenter concerns.
We did not receive comments specific
to this point, but have removed from
§ 170.405(b) as finalized the language
that would have specifically required
the initial submission of the plan to the
ONC–ACB by the developer must be by
a publicly accessible hyperlink. While
this remains an option, and could be the
most efficient one for developers and
ONC–ACBs in many instances, we
believe this is an unnecessarily limiting
specification of the manner of
interaction between developers and
ONC–ACBs in these instances. The URL
or hyperlink in CHPL will not be
published on CHPL until the ONC–ACB
takes action to publish it, and the ONC–
ACB is required to review the plan and
ensure it is complete before publishing
the plan link on CHPL.
Comments. We received some
comments that appeared to construe our
intent to be that real world testing for all
Health IT Modules certified as of August
31 of a given year would need to be
planned, conducted, and reported
within five months of that date.
Comments that appeared to be based on
this interpretation also expressed
E:\FR\FM\01MYR3.SGM
01MYR3
25774
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
concern that this would be too much to
accomplish on such an annual schedule.
Response. We proposed that each
developer’s annual real world testing
plan required to be published by
December 15 of a given year would need
to address all of the developer’s Health
IT Modules certified to criteria listed in
§ 170.405(a) as of August 31 of that year
(84 FR 7496). We also proposed that this
annual real world testing plan would
pertain to real world testing activities to
be conducted in the year following the
December 15 plan publication due date.
In light of comments received, we can
see how we might have been more
precise in how we stated that the annual
results report would be due early in the
year following the year in which the
testing it reported was conducted. The
full cycle of real world testing for a
given year was never specifically
proposed to be contained within a
single year, considering that the plan is
due in the year prior and the results
report was proposed to be due in the
year following the one in which a given
annual round of real world testing
activity occurs.
Comments. Comments raised
concerns that the January 31 publication
deadline might not leave enough time
for developers who do not or cannot
complete their annual testing activities
until late in the testing year to submit
their results reports, and ONC–ACBs
complete their required reviews, prior to
the publication deadline. One
commenter raised a specific concern
that the proposed January 31 due date
for real world testing results falls in the
submission window for several CMS
programs for which developers’
customers need to submit their clinical
quality measurement data for the
preceding year. One commenter
recommended leveraging the existing
quarterly update attestation process and
asking developers to conduct real world
testing on those items identified as
major changes.
Response. As with the plan due date,
the practical implication of this
proposal is that each developer will
need to submit their results reports to
their ONC–ACB sufficiently in advance
of the due date for publication for the
ONC–ACB to be able to complete its
pre-publication responsibilities for all of
the results reports and still publish no
later than that due date. In theory, this
means that in some cases developers
could complete their real world testing
relatively early in a given testing year
and submit their results report for that
year before the CMS submission
window for that year’s measurement
data even opens for the developer’s
customers. However, considering the
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
comments received, we do recognize it
is possible developers may for various
reasons not be able to complete their
annual real world testing activities until
fairly late in any given testing (calendar)
year. We also recognize that the data
submission window for CMS programs
can be a busy time for developers, and
would not wish to disadvantage newer
or smaller developers who may not have
separate resources available to finalize a
report of real world testing not
concluded until late in the testing year
while simultaneously supporting
customers’ data submissions. In light of
these comments, we have decided to
finalize a deadline for publication on
the CHPL of the publicly accessible
hyperlink to developers’ report of real
world testing conducted in the prior
year at March 15 of each year (see
§ 170.405(b)(2)(ii)). This finalized date
gives an additional six weeks for
finalization and submission by
developers compared to the date
originally proposed. It also implements
a single deadline, to which the
developers and ONC–ACBs are
mutually accountable, in parallel to the
annual real world testing plan
submission requirement in
§ 170.405(b)(1). We believe this strikes
an appropriate balance between timely
availability of annual real world testing
results and recognition that some
developers may need to devote a
substantial amount of focus to the CMS
quality measures data submission
windows at the beginning of each year.
Although we have opted not to mandate
developers submit their results reports
to their ONC–ACBs by a date providing
a minimum required lead time for ONC–
ACBs’ required review of the report, we
would suggest that ONC–ACBs and
developers consider the potential merits
of allowing at least one calendar month
between the developer’s initial
submission of their real world testing
results report to the ONC–ACB and the
March 15 publication deadline.
e. Real World Testing Pilot Year
We acknowledged in the Proposed
Rule that a subsequent final rule for that
may not provide sufficient time for
health IT developers to develop and
submit plans for a full year of real world
testing in 2020 (84 FR 7497). Therefore,
we indicated in the Proposed Rule that
we expected to provide an appropriate
period of time for developers to submit
their plans, and potentially treat 2020 as
a ‘‘pilot’’ year for real world testing. We
expected that the pilot testing of real
world testing would match up to the
fullest extent practicable with our
proposed real world testing
requirements (e.g., same criteria but for
PO 00000
Frm 00134
Fmt 4701
Sfmt 4700
a shorter duration and without the same
consequences for noncompliance). We
welcomed comments on this potential
approach.
Comments. The majority of comments
specifically addressing this point were
in support of 2020 being treated as a
pilot year. One commenter agreed that
deferring the implementation or
constructing a pilot year for the Program
would be appropriate and stated their
belief that 2020 may be too early even
to conduct a pilot.
Response. We thank commenters for
their thoughts on potential piloting of
real world testing and the timing of
initiating real world testing
requirements. In consideration of the
timing of the final rule, we have decided
not to finalize 2020 as a pilot year since
developers will now have the majority
of calendar year 2020 to develop a
prospective plan for real world testing
that would begin in 2021. However, we
recognize that this first ‘‘performance’’
year of real world testing in 2021
presents unique challenges with respect
to the development of initial plans, and
we fully intend to approach both the
submission of initial plans and
submission of retrospective testing
results for those plans (i.e., 2021 real
world testing results) as learning
experiences for developers that can be
used to inform future iterations of real
world test plans. As noted in the
proposed rule (84 FR 7497), the due
date for the first annual real world
testing plan would be finalized based in
part on the timing of the final rule.
Because this final rule is publishing
well in advance of the December 15
annual due date for publication of
developers’ plans of real world testing
activities to be conducted in the
following year, we have concluded it is
reasonable to require the first annual
real world testing plan be published via
a publicly accessible hyperlink on the
CHPL no later than December 15, 2020.
This initial real world testing plan must
address any and all of the developer’s
Health IT Modules that hold a current,
valid certificate under the Program as of
August 31, 2020. The real world testing
plan due to be published in December
2020, will need to address the real
world testing activities that will occur
during calendar year 2021. The report of
results for this initial (2021) annual real
world test cycle will be due to be
published on the CHPL no later than
March 15, 2022.
f. Health IT Modules Certified But Not
Yet Deployed
We proposed (84 FR 7497) that even
if a health IT developer does not have
customers or has not deployed their
E:\FR\FM\01MYR3.SGM
01MYR3
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
certified Health IT Module(s) at the time
the real world testing plan is due, the
health IT developer would still need to
submit a plan that prospectively
addresses its plans for real world testing
that would occur in the coming year for
those Health IT Modules that had been
certified on or before August 31 of the
calendar year in which the plan is due
(the calendar year immediately
preceding the calendar year during
which testing addressed by any given
annual real world testing plan will take
place). If a health IT developer has not
yet deployed their certified Health IT
Module to any real world users when
the annual real world testing results are
due for that module, we proposed that
the developer would need to report as
such to meet the proposed Maintenance
of Certification requirement.
Comments. We received no comments
on this proposal.
Response. We have finalized this
proposal. Any Health IT Module
certified to at least one criterion within
the scope of real world testing as of
August 31 of a given year must be
addressed by its developer’s real world
testing plan for the subsequent year that
must be published via publicly
accessible hyperlink on the CHPL by the
December 15 due date (see § 170.405(a)).
This requirement applies regardless of
whether that Health IT Module is in
actual real world use prior to December
15 (or the earlier date by which the
developer and ONC–ACB agree the
developer will submit its annual real
world testing plan to the ONC–ACB to
ensure the developer and ONC–ACB
meet single, December 15, deadline for
the plan to have been reviewed for
completeness and published on CHPL).
To ensure precise clarity about the effect
of the August 31 reference date for
purposes of real world testing
requirements, we reiterate that if a
developer has at least one Health IT
Module certified to at least any one
criterion within the real world testing
scope of applicability as of August 31 of
a given year, the real world testing
Condition and Maintenance of
Certification requirements apply to that
developer and the developer must
submit an annual real world testing plan
for that year, addressing each of their
Health IT Module(s) certified to any
(one or more) criteria listed in
§ 170.405(a) and that plan must meet the
requirements in § 170.405(b)(1)(iii) for
each module and criterion. Only
developers who have no Health IT
Module(s) certified to any criterion
within the real world testing scope of
applicability as of August 31 of a given
year need not submit a real world
testing plan that year and would not be
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
required to perform real world testing in
the subsequent year.
g. Standards Version Advancement
Process (SVAP)
As discussed in the Proposed Rule (84
FR 7497), as newer versions 111 become
available for adopted standards and
implementation specifications included
in the certification criteria subject to the
real world testing Condition and
Maintenance of Certification
requirements, we believe that a health
IT developer’s ability to conduct
ongoing maintenance on its certified
Health IT Module(s) to incorporate these
newer versions of Secretary-adopted
standards and implementation
specifications (‘‘standards’’) is essential
to support interoperability in the real
world. Updated versions of standards
reflect insights gained from real-world
implementation and use. They also
reflect industry stakeholders’ interests
to improve the capacity, capability, and
clarity of such standards to meet new,
innovative business needs, which
earlier standards versions cannot
support. Therefore, as part of the real
world testing Condition of Certification,
we proposed a Maintenance of
Certification flexibility that we refer to
as the Standards Version Advancement
Process (SVAP).112 This flexibility
would permit health IT developers to
voluntarily use in their certified Health
IT Modules newer versions of adopted
standards so long as certain conditions
are met. As we stated in the Proposed
Rule, these conditions are not limited to
but notably include successful real
world testing of the Health IT Module
using the new version(s) subsequent to
the inclusion of these newer standards
and implementation specification
versions in the Health IT Module’s
certification. We proposed to establish
the SVAP not only to meet the Cures
Act’s goals for interoperability, but also
in response to the continuous
stakeholder feedback that ONC has
received through prior rulemakings and
engagements, which requested that ONC
establish a predictable and timely
approach within the Program to keep
111 We note that standards developing
organizations and consensus standards bodies use
various nomenclature, such as ‘‘versions’’ or
‘‘releases,’’ to identify updates to standards and
implementation specifications.
112 Regulation text implementing the real world
testing Condition and Maintenance of Certification
requirement was proposed in § 170.405, including
but not limited to SVAP-specific provisions
proposed in § 170.405(b)(5). The SVAP-specific
provisions have now been finalized in
§ 170.405(b)(8) and (9) (see section VII.B.5.g of this
final rule).
PO 00000
Frm 00135
Fmt 4701
Sfmt 4700
25775
pace with the industry’s standards
development efforts.
The SVAP we proposed, with
corresponding proposed revisions for
§§ 170.500 and 170.555, introduces two
types of administrative flexibility for
health IT developers participating in the
Program (84 FR 7498). First, for those
health IT developers with existing
certified Health IT Module(s), such
Health IT Modules could be upgraded to
a new version of an adopted standard
within the scope of the certification and
have support for that updated version of
the standard reflected on the Health IT
Module’s certificate so long as: Such
version was approved by the National
Coordinator for use in the Program; and
the developer satisfied all requirements
of the SVAP including demonstration of
conformance through an acceptable
means (84 FR 7498 through 7500). For
purposes of the SVAP as applied to
updates to Health IT Modules with
certificates to criteria listed in
§ 170.405(a) that include prior
version(s) 113 of the standards,
acceptable means of demonstrating
conformance include but are not
necessarily limited to self-declaration of
conformance, as proposed in 84 FR 7499
and finalized in this final rule. Second,
for those health IT developers
presenting health IT for certification to
a criterion listed in § 170.405(a), a
National Coordinator-approved newer
version of a standard included in one of
these criteria could be used in lieu of or
in addition to the version of that
standard incorporated by reference in
§ 170.299 (84 FR 7498). However, for
purposes of the SVAP as applied to
health IT that is presented for
certification to any criterion listed in
§ 170.405(a), developer self-declaration
is an acceptable means of demonstrating
conformance only where there is not yet
another conformance method available
that can be validly used for that version
of that standard (84 FR 7499 through
7500). The regulation text codifying
requirements for health IT developers to
avail themselves of each of the proposed
types of administrative flexibility was
proposed (84 FR 7595 through 7596) in
§ 170.405(b)(5). Corresponding revisions
to § 170.550 and § 170.555 were
proposed in 84 FR 7598.
We proposed that the SVAP would be
available only for National Coordinatorapproved newer versions of standards
and implementation specifications
(‘‘standards’’) that have already been
113 Prior versions for this purpose could include
those incorporated by reference in § 170.299,
National Coordinator approved newer versions, or
a mix of such versions for any or all of the
standards adopted by the Secretary in subpart B of
part 170 that are included in a given criterion.
E:\FR\FM\01MYR3.SGM
01MYR3
25776
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations
adopted into the Program by the
Secretary through rulemaking in
accordance with applicable law
including the Administrative
Procedures Act (5 U.S.C. 553) and
sections 3001 and 3004 of the Public
Health Service Act (PHSA) (42 U.S.C.
300jj–1 and 42 U.S.C. 300jj–11) (84 FR
7498). We have finalized this aspect of
the standards version advancement
flexibility as proposed. Under current
law and the finalized SVAP flexibility,
a standard must be initially adopted by
the Secretary through rulemaking before
the National Coordinator can approve
the use of newer updated versions of
that standard in the Program.
We also proposed that a health IT
developer would be able to choose
which of the updated standards versions
approved by the National Coordinator
for use in certification to include in its
updated certified Health IT Module and
would be able to do so on an itemized
basis (84 FR 7499).
We stated in the Proposed Rule that
we welcomed comments on any and all
aspects of our proposed SVAP as an
option available to developers through
maintenance requirements as part of the
real world testing Condition and
Maintenance of Certification
requirements (84 FR 7500). We also
invited comments on our proposal to
allow in conjunction with this
maintenance flexibility the opportunity
for developers to elect to present health
IT for initial testing and certification
either to more advanced versions or to
the prior adopted versions of the
standards included in regulatory text as
of the date the Health IT Modules are
presented for certification.
Comments. Comments were strongly
supportive of the SVAP. Several
commenters recommended the
description of this process include
recognition of the fact that developers
and systems might need to maintain
operational support for previously
adopted versions of standards to avoid
potential adverse effects on data access,
exchange, and use.
Response. We have finalized the
SVAP in § 170.405(b)(8) and (9) to
provide the flexibility for which
stakeholders’ comments expressed
support. This flexibility includes the
option for a Health IT Module to be
certified to the standards versions
incorporated by reference in § 170.299
and/or one or more National
Coordinator-approved updated versions
of standards included in the criteria
listed in § 170.405(a). Thus, once the
National Coordinator has approved for
use in the Program more advanced
version(s) of any standard(s) applicable
to any of the criteria listed in
VerDate Sep<11>2014
09:23 May 01, 2020
Jkt 250001
§ 170.405(a), a health IT developer will
have flexibility to choose on an itemized
basis which of the National Coordinatorapproved updated standards versions
they wish to have included in their
Health IT Module certification(s). Using
the SVAP flexibility does not require a
developer cease supporting prior
version releases of standards referenced
by applicable certification criteria.
Comments. Several commenters
expressed concerns about the effect of
an uneven pace of advanced version
implementatio