Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency, 70064-70085 [2020-24376]
Download as PDF
<![CDATA[
70064
Federal Register / Vol. 85, No. 214 / Wednesday, November 4, 2020 / Rules and Regulations
khammond on DSKJM1Z7X2PROD with RULES
its metabolites and degradates, in or on
sugarcane, cane at 1.5 ppm, and
sugarcane, molasses at 5 ppm.
VI. Statutory and Executive Order
Reviews
This action modifies existing
tolerances under FFDCA section 408(d)
in response to a petition submitted to
the Agency. The Office of Management
and Budget (OMB) has exempted these
types of actions from review under
Executive Order 12866, entitled
‘‘Regulatory Planning and Review’’ (58
FR 51735, October 4, 1993). Because
this action has been exempted from
review under Executive Order 12866,
this action is not subject to Executive
Order 13211, entitled ‘‘Actions
Concerning Regulations That
Significantly Affect Energy Supply,
Distribution, or Use’’ (66 FR 28355, May
22, 2001) or Executive Order 13045,
entitled ‘‘Protection of Children from
Environmental Health Risks and Safety
Risks’’ (62 FR 19885, April 23, 1997),
nor is it considered a regulatory action
under Executive Order 13771, entitled
‘‘Reducing Regulations and Controlling
Regulatory Costs’’ (82 FR 9339, February
3, 2017). This action does not contain
any information collections subject to
OMB approval under the Paperwork
Reduction Act (PRA) (44 U.S.C. 3501 et
seq.), nor does it require any special
considerations under Executive Order
12898, entitled ‘‘Federal Actions to
Address Environmental Justice in
Minority Populations and Low-Income
Populations’’ (59 FR 7629, February 16,
1994).
Since tolerances and exemptions that
are established on the basis of a petition
under FFDCA section 408(d), such as
the tolerance in this final rule, do not
require the issuance of a proposed rule,
the requirements of the Regulatory
Flexibility Act (RFA) (5 U.S.C. 601 et
seq.), do not apply.
This action directly regulates growers,
food processors, food handlers, and food
retailers, not States or Tribes, nor does
this action alter the relationships or
distribution of power and
responsibilities established by Congress
in the preemption provisions of FFDCA
section 408(n)(4). As such, the Agency
has determined that this action will not
have a substantial direct effect on States
or Tribal Governments, on the
relationship between the National
Government and the States or Tribal
Governments, or on the distribution of
power and responsibilities among the
various levels of government or between
the Federal Government and Indian
Tribes. Thus, the Agency has
determined that Executive Order 13132,
entitled ‘‘Federalism’’ (64 FR 43255,
VerDate Sep<11>2014
16:30 Nov 03, 2020
Jkt 253001
August 10, 1999) and Executive Order
13175, entitled ‘‘Consultation and
Coordination with Indian Tribal
Governments’’ (65 FR 67249, November
9, 2000) do not apply to this action. In
addition, this action does not impose
any enforceable duty or contain any
unfunded mandate as described under
Title II of the Unfunded Mandates
Reform Act (UMRA) (2 U.S.C. 1501 et
seq.).
This action does not involve any
technical standards that would require
Agency consideration of voluntary
consensus standards pursuant to section
12(d) of the National Technology
Transfer and Advancement Act
(NTTAA) (15 U.S.C. 272 note).
VII. Congressional Review Act
Pursuant to the Congressional Review
Act (5 U.S.C. 801 et seq.), EPA will
submit a report containing this rule and
other required information to the U.S.
Senate, the U.S. House of
Representatives, and the Comptroller
General of the United States prior to
publication of the rule in the Federal
Register. This action is not a ‘‘major
rule’’ as defined by 5 U.S.C. 804(2).
List of Subjects in 40 CFR Part 180
Environmental protection,
Administrative practice and procedure,
Agricultural commodities, Pesticides
and pests, Reporting and recordkeeping
requirements.
Dated: September 16, 2020.
Marietta Echeverria,
Acting Director, Registration Division, Office
of Pesticide Programs.
Therefore, for the reasons stated in the
preamble, EPA amends 40 CFR chapter
I as follows:
PART 180—TOLERANCES AND
EXEMPTIONS FOR PESTICIDE
CHEMICAL RESIDUES IN FOOD
1. The authority citation for part 180
continues to read as follows:
■
Authority: 21 U.S.C. 321(q), 346a and 371.
2. In § 180.662, amend paragraph (a)
by:
■ i. Revising the Introductory text.
■ ii. Revising the existing entries in the
table for ‘‘Sugarcane, cane’’ and
‘‘Sugarcane, molasses’’.
The revisions read as follows:
■
§ 180.662 Trinexapac-ethyl; tolerances for
residues.
(a) General. Tolerances are
established for residues of the plant
growth regulator, trinexapac-ethyl,
including its metabolites and
degradates, in or on the commodities in
the table below. Compliance with the
PO 00000
Frm 00022
Fmt 4700
Sfmt 4700
tolerance levels specified below is to be
determined by measuring only the free
and conjugated forms of both
trinexapac-ethyl, ethyl 4(cyclopropylhydroxymethylene)-3,5dioxocyclohexanecarboxylate and
trinexapac, 4(cyclopropylhydroxymethylene)-3,5dioxocyclohexanecarboxylic acid,
calculated as the stoichiometric
equivalent of trinexapac-ethyl, in or on
the commodity.
Parts per
million
Commodity
*
*
*
*
Sugarcane, cane ......................
Sugarcane, molasses ...............
*
*
*
*
*
*
*
*
*
1.5
5
*
*
[FR Doc. 2020–23040 Filed 11–3–20; 8:45 am]
BILLING CODE 6560–50–P
DEPARTMENT OF HEALTH AND
HUMAN SERVICES
Office of the Secretary
45 CFR Parts 170 and 171
RIN 0955–AA02
Information Blocking and the ONC
Health IT Certification Program:
Extension of Compliance Dates and
Timeframes in Response to the
COVID–19 Public Health Emergency
Office of the National
Coordinator for Health Information
Technology (ONC), Department of
Health and Human Services (HHS).
ACTION: Interim final rule with comment
period.
AGENCY:
This interim final rule with
comment period (IFC) gives health IT
developers and health care providers
flexibilities to effectively respond to the
public health threats posed by the
spread of the coronavirus disease 2019
(COVID–19). Recognizing the urgency of
this situation, and understanding that
caring for patients with COVID–19 is of
utmost importance, ONC is issuing this
IFC to extend certain compliance dates
and timeframes adopted in the 21st
Century Cures Act: Interoperability,
Information Blocking, and the ONC
Health IT Certification Program Final
Rule (ONC Cures Act Final Rule),
including compliance and applicability
dates for the information blocking
provisions, certain 2015 Edition health
IT certification criteria, and Conditions
and Maintenance of Certification
SUMMARY:
E:\FR\FM\04NOR1.SGM
04NOR1
khammond on DSKJM1Z7X2PROD with RULES
Federal Register / Vol. 85, No. 214 / Wednesday, November 4, 2020 / Rules and Regulations
requirements under the ONC Health IT
Certification Program (Program). In this
IFC, we are also making programmatic
changes to the Program by updating
standards. In addition, we are making
corrections and clarifications to the
ONC Cures Act Final Rule, which was
published in the Federal Register on
May 1, 2020.
DATES:
Effective date: This interim final rule
is effective on December 4, 2020 except
for 45 CFR 170.401, 170.402(a)(1), and
the amendments to 45 CFR part 171
which are effective on November 4,
2020.
Incorporation by reference: The
incorporation by reference of certain
publications listed in the rule is
approved by the Director of the Federal
Register as of November 4, 2020. The
incorporation by reference of certain
other publications listed in the rule was
approved by the Director of the Federal
Register as of September 4, 2012.
Comment date: To be assured
consideration, written or electronic
comments must be received at one of
the addresses provided below, no later
than 5 p.m. on January 4, 2021.
ADDRESSES: You may submit comments,
identified by RIN 0955–AA02, by any of
the following methods (please do not
submit duplicate comments). Because of
staff and resource limitations, we cannot
accept comments by facsimile (FAX)
transmission.
• Federal eRulemaking Portal: Follow
the instructions for submitting
comments. Attachments should be in
Microsoft Word, Microsoft Excel, or
Adobe PDF; however, we prefer
Microsoft Word. https://
www.regulations.gov.
• Regular, Express, or Overnight Mail:
Department of Health and Human
Services, Office of the National
Coordinator for Health Information
Technology, Attention: Information
Blocking and the ONC Health IT
Certification Program: Extension of
Compliance Dates and Timeframes in
Response to the COVID–19 Public
Health Emergency, Mary E. Switzer
Building, Mail Stop: 7033A, 330 C
Street SW, Washington, DC 20201.
Please submit one original and two
copies.
• Hand Delivery or Courier: Office of
the National Coordinator for Health
Information Technology, Attention:
Information Blocking and the ONC
Health IT Certification Program:
Extension of Compliance Dates and
Timeframes in Response to the COVID–
19 Public Health Emergency, Mary E.
Switzer Building, Mail Stop: 7033A, 330
C Street SW, Washington, DC 20201.
VerDate Sep<11>2014
16:30 Nov 03, 2020
Jkt 253001
Please submit one original and two
copies. (Because access to the interior of
the Mary E. Switzer Building is not
readily available to persons without
Federal Government identification,
commenters are encouraged to leave
their comments in the mail drop slots
located in the main lobby of the
building.)
Inspection of Public Comments: All
comments received before the close of
the comment period will be available for
public inspection, including any
personally identifiable or confidential
business information that is included in
a comment. Please do not include
anything in your comment submission
that you do not wish to share with the
general public. Such information
includes, but is not limited to: A
person’s social security number; date of
birth; driver’s license number; state
identification number or foreign country
equivalent; passport number; financial
account number; credit or debit card
number; any personal health
information; or any business
information that could be considered
proprietary. We will post all comments
that are received before the close of the
comment period at https://
www.regulations.gov.
Docket: For access to the docket to
read background documents or
comments received, go to https://
www.regulations.gov or the Department
of Health and Human Services, Office of
the National Coordinator for Health
Information Technology, Mary E.
Switzer Building, Mail Stop: 7033A, 330
C Street SW, Washington, DC 20201
(call ahead to the contact listed below
to arrange for inspection).
FOR FURTHER INFORMATION CONTACT:
Michael Lipinski, Office of Policy,
Office of the National Coordinator for
Health Information Technology, 202–
690–7151.
SUPPLEMENTARY INFORMATION:
Table of Contents
I. Background
II. Provisions of the Interim Final Rule With
Comment Period
A. Extension of Compliance Dates and
Timeframes
1. Information Blocking Provisions and
Related Condition and Maintenance of
Certification Requirements
2. Certain 2015 Edition Health IT
Certification Criteria Updates
3. Conditions and Maintenance of
Certification Requirements Under the
ONC Health IT Certification Program
a. Assurances
b. Communications
c. Application Programming Interfaces
d. Real World Testing
e. Attestations
PO 00000
Frm 00023
Fmt 4700
Sfmt 4700
70065
4. Updates to ONC–ACB Dates and
Timeframes
B. Standards Updates
1. USCDI
2. U.S. Core Implementation Guide
C. Corrections and Clarifications to the
ONC Cures Act Final Rule
1. General Applicability and Applicability
of Standards and Implementation
Specifications for Health Information
Technology
2. Standards for Health Information
Technology To Protect Electronic Health
Information Created, Maintained, and
Exchanged
a. Record Actions Related to Electronic
Health Information, Audit Log Status,
and Encryption of End-User Devices
b. Synchronized Clocks
3. Applicability of Certification Criteria for
Health Information Technology
4. Electronic Prescribing
5. Clinical Quality Measures—Report
Criterion
6. Multi-Factor Authentication
7. Transmission to Public Health
Agencies—Electronic Case Reporting
8. Conditions and Maintenance of
Certification Requirements for Health IT
Developers
a. Assurances
b. Application Programming Interfaces—
Clarification for Native Applications and
Refresh Tokens
9. Principles of Proper Conduct for ONC–
ACBs
10. Applicability of the Information
Blocking Provisions
11. Information Blocking Definition and
Security Exception
12. Content and Manner Exception
13. Licensing Exception
III. Waiver of Proposed Rulemaking,
Comment Period, and Delay in Effective
Date
IV. Incorporation by Reference
V. Response to Comments
VI. Collection of Information Requirements
VII. Regulatory Impact Analysis
A. Executive Orders 12866 and 13563
B. Regulatory Flexibility Act
C. Executive Order 13771
D. Executive Order 13132—Federalism
E. Unfunded Mandates Reform Act
List of Subjects
I. Background
The United States is responding to an
outbreak of respiratory disease caused
by a novel (new) coronavirus that has
now been detected in more than 235 1
countries internationally, and all 50
States and the District of Columbia. The
virus has been named ‘‘severe acute
respiratory syndrome coronavirus 2’’
(SARS–CoV–2) and the disease it causes
has been named ‘‘coronavirus disease
2019’’ (COVID–19).
On January 30, 2020, the International
Health Regulations Emergency
Committee of the World Health
Organization (WHO) declared the
1 https://www.who.int/emergencies/diseases/
novel-coronavirus-2019 (Accessed on 10/22/2020).
E:\FR\FM\04NOR1.SGM
04NOR1
70066
Federal Register / Vol. 85, No. 214 / Wednesday, November 4, 2020 / Rules and Regulations
outbreak a ‘‘Public Health Emergency of
international concern.’’ On January 31,
2020, pursuant to section 319 of the
Public Health Service Act (PHSA),
Health and Human Services Secretary,
Alex M. Azar II, determined that a
Public Health Emergency (PHE) exists
for the United States to aid the nation’s
health care community in responding to
COVID–19. On March 11, 2020, the
WHO publicly declared COVID–19 a
pandemic. On March 13, 2020, the
President of the United States declared
the COVID–19 pandemic a national
emergency. Effective October 23, 2020,
Secretary Azar renewed the January 31,
2020 determination that was previously
renewed on April 21, 2020 and July 23,
2020 that a PHE for COVID–19 exists
and has existed since January 27, 2020.
As the health care community
establishes and implements
recommended infection prevention and
control practices, regulatory agencies—
under appropriate waiver authority
granted by the declaration of the
COVID–19 PHE—are also working to
revise regulations to allow the health
care community to focus on the PHE.
We believe that the ONC Cures Act
Final Rule should be revised to offer the
health care system additional
flexibilities in furnishing services to
combat the COVID–19 pandemic. On
April 21, 2020, concurrent with
Secretary Azar’s first renewal of the
determination of a PHE, ONC
announced a policy of enforcement
discretion to allow compliance
flexibilities regarding the
implementation of the ONC Cures Act
Final Rule in response to the COVID–19
PHE.2 We stated our intention to
exercise enforcement discretion for
three months at the end of certain ONC
Health IT Certification Program
(Program) compliance dates associated
with the ONC Cures Act Final Rule to
provide flexibility while ensuring the
goals of the rule remain on track. In this
IFC, we are extending the applicability
date for the information blocking
provisions and some compliance dates
in the Program, including dates for
certain updated 2015 Edition health IT
certification criteria and Conditions and
Maintenance of Certification
requirements. The extensions in this IFC
for information blocking and the
Program are longer than the three month
extension that was announced in the
April 21, 2020 enforcement discretion
statement for the Program. These
additional flexibilities for development
and implementation enable our health
care system to focus on addressing the
COVID–19 PHE, while still maintaining
a trajectory that will advance patients’
access to their health information,
reduce the cost of care, and improve the
quality of care. This IFC also updates
certain standards in the Program, and
makes necessary corrections and
clarifications to the ONC Cures Act
Final Rule, which was published in the
Federal Register on May 1, 2020 (85 FR
25642), and became effective on June
30, 2020.
II. Provisions of the Interim Final Rule
With Comment Period
A. Extension of Compliance Dates and
Timeframes
The ONC Cures Act Final Rule fosters
innovation in health care to deliver
better information, more conveniently,
to patients and their providers. It also
promotes transparency through
technology, providing opportunities for
the American public to gain visibility
into the services, quality, and costs of
health care.
The ONC Cures Act Final Rule
includes provisions that require support
for modern computing standards and
application programming interfaces
(APIs). These technical provisions will
inject competition into health care by
promoting an entrepreneurial economy
and new business models using
smartphone apps to provide novel
services and choices in care. The ONC
Cures Act Final Rule will also make
sure health information follows a
patient by preventing industrywide
information blocking practices and
other anti-competitive behavior by those
entrusted to hold patients’ electronic
health information (EHI).
In the ONC Cures Act Final Rule, we
set applicability and compliance dates
for certain provisions of the regulations.
In light of the COVID–19 PHE, in this
IFC, ONC is extending the applicability
date for the information blocking
provisions and compliance dates and
timeframes for certain Program
requirements, including compliance
dates for certain 2015 Edition health IT
certification criteria and Conditions and
Maintenance of Certification
requirements. These additional
flexibilities for development and
implementation will enable our health
care system to focus on addressing the
COVID–19 PHE, while continuing to
advance policies that will promote
patients’ access to their EHI and enable
greater data exchange.
We have also heard from stakeholders
and organizations representing
clinicians, hospitals, health systems and
health information technology
developers requesting an extension for
the applicability and compliance dates.
These stakeholders expressed concern
over meeting the information blocking
applicability date of November 2, 2020.
They stated that the COVID–19 PHE
continues to monopolize their time and
attention, and has strained resources,
drastically limiting their ability to
prepare for the November 2nd
information blocking date.
In an effort to minimize any burden
or confusion for developers and
providers, we have aligned the
extensions around three distinct dates.
For ease of comparison, in Table 1
below, we have added the dates from
the ONC Cures Act Final Rule, the dates
in the April 21, 2020 enforcement
discretion announcement, and the dates
in this IFC.
khammond on DSKJM1Z7X2PROD with RULES
TABLE 1—APPLICABILITY AND COMPLIANCE DATES
Provision
Final rule
Enforcement discretion announcement
Information Blocking Overall Applicability Date—(45 CFR part 171) 3.
Condition of Certification (CoC)—Information Blocking—(§ 170.401).
November 2, 2020 ................................
N/A—No Change ..................................
November 2, 2020 ................................
3 months after the compliance timeframe.
2 https://www.healthit.gov/curesrule/resources/
enforcement-discretion.
3 Note that for the Content and Manner Exception,
in § 171.301(a), for the period before October 6,
VerDate Sep<11>2014
16:30 Nov 03, 2020
Jkt 253001
2022, the definition of EHI is limited to, at a
minimum, the data elements represented in the
USCDI standard; and, for the period on and after
Oct 6, 2022, EHI is defined as it is in § 171.102.
PO 00000
Frm 00024
Fmt 4700
Sfmt 4700
Interim final rule
with comment
period
April 5, 2021.
These dates reflect the extension from May 2, 2022,
which was the compliance date included in the
ONC Cures Act Final Rule. These dates are
discussed in more detail in section II.A.1.
E:\FR\FM\04NOR1.SGM
04NOR1
Federal Register / Vol. 85, No. 214 / Wednesday, November 4, 2020 / Rules and Regulations
70067
TABLE 1—APPLICABILITY AND COMPLIANCE DATES—Continued
Provision
Final rule
Enforcement discretion announcement
CoC—Assurances—(§ 170.402(a)(1))—
Will not take any action that constitutes information blocking or actions that inhibit access, exchange,
and use of electronic health information (EHI).
CoC—Assurances—(§ 170.402(a)(2)
and (3), and (b)(1))—Other.
November 2, 2020 ................................
3 months after the compliance timeframe.
Effective date: June 30, 2020 ...............
CoC—Communications—(§ 170.403)—
Communications requirements, except for § 170.403(b)(1) where we removed the notice requirement for
2020.
CoC—API—(§ 170.404(b)(4))—Compliance for current API criteria.
CoC—API—(§ 170.404(b)(3))—Rollout
of new standardized API functionality.
CoC—Real World Testing—2015 Edition health IT certification criteria with
standards updates.
CoC—Assurances—(§ 170.402(a)(4)
and (b)(2))—EHI Export Rollout.
CoC—Communications—
(§ 170.403(b)(1))—Notice to all customers with which developer has
contracts or agreements containing
provisions that contravene Communications CoC.
CoC—Initial Attestations—(§ 170.406) ..
Effective date: June 30, 2020 ...............
Enforcement
months after
final rule.
Enforcement
months after
final rule.
khammond on DSKJM1Z7X2PROD with RULES
CoC—Real
World
Testing—
(§ 170.405(b)(1) and (2)) Submit initial plan and initial results submission.
November 2, 2020 ................................
May 2, 2022 ..........................................
May 2, 2022 ..........................................
May 1, 2023 ..........................................
Annually beginning in calendar year
2020.
April 1–30, 2021 attestation window for
attestation period running June 30,
2020, through March 31, 2021.
Plan: December 15, 2020 .....................
Results: March 15, 2022.
In selecting these dates, we carefully
considered a number of factors,
including the possibility that health IT
developers of certified health IT and
other actors would divert resources
needed to respond to the COVID–19
PHE in order to meet requirements of
the ONC Cures Act Final Rule. In
particular, we considered whether the
requirements placed a current
conflicting resource burden on
developers and whether the ongoing
PHE necessitates greater lead time prior
to compliance. We considered whether
affected parties’ workforces would need
more time for education and training
due to the round-the-clock need to
respond to the PHE. Further, we note
that effective October 23, 2020,
Secretary Azar renewed the
determination that a PHE exists,
demonstrating a Department-wide
commitment to a unified effort against
the COVID–19 PHE. Given these
considerations, we concluded that the
VerDate Sep<11>2014
16:30 Nov 03, 2020
Jkt 253001
Frm 00025
Fmt 4700
Sfmt 4700
discretion expired 3
the effective date of the
discretion expired 3
the effective date of the
3 months after the compliance timeframe.
3 months after the compliance timeframe.
3 months after the compliance timeframe.
December 31,
2022.
3 months after the compliance timeframe.
Notice can be made until March 31,
2021, for the 2020 calendar year.
December 31,
2023.
Begin annual cycle
1 year later. CY
2021.
Generally remains the same except for
the initial attestation, which will now
be accepted through July 30, 2021.
Initial Plan: Initial RWT plans (i.e.,
2021 RWT plans) may be submitted
through March 15, 2021.
Initial Results: Initial RWT results from
the 2021 performance year may be
submitted up through June 2022.
Begin annual cycle
1 year later. CY
2022.
Begin annual cycle
1 year later.
Initial Plan: December 15, 2021.
Initial Results:
March 15, 2023.
extensions and flexibilities finalized in
this IFC are appropriate and necessary.
Once we concluded that the
extensions were appropriate, we
balanced those factors against the
overall policy and purpose of the ONC
Cures Act Final Rule. ONC takes
seriously the responsibility to
implement key provisions of the Cures
Act and Executive Order 13813. In this
IFC, we strived to ensure that our
attention to the demands of the PHE is
balanced with our commitment to
advance interoperability and support
the access, exchange, and use of EHI
through implementation and
enforcement of the information blocking
provisions. Therefore, we sought to
limit the extensions to no longer than
reasonably necessary, given the
concerns cited above.
Extensions can be shorter where fewer
technological demands are placed on
stakeholders. For example, in
§ 170.403(b), a health IT developer must
not impose or enforce any contractual
PO 00000
Interim final rule
with comment
period
requirement that contravenes the
requirements of the Communications
Condition of Certification. Furthermore,
if a health IT developer has contracts/
agreements in existence that contravene
the requirements of the
Communications 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 this IFC, we
suspended the annual notice
requirement in § 170.403(b)(1) for just
the 2020 year. This limited suspension
ensures that the users and customers of
certified health IT will still be notified
in a timely manner by health IT
developers, while also relieving
pressure on the developers to
immediately devote portions of their
workforce to review contracts. We
believe the annual requirement will
lessen compliance obligations for health
IT developers of certified health IT
E:\FR\FM\04NOR1.SGM
04NOR1
khammond on DSKJM1Z7X2PROD with RULES
70068
Federal Register / Vol. 85, No. 214 / Wednesday, November 4, 2020 / Rules and Regulations
while still providing adequate notice in
a reasonable amount of time. We have
finalized the deadline for the notice
requirement in § 170.403(b)(1) to be
annually, beginning in calendar year
2021.
Other extensions are limited because
of the positive outcomes we anticipate
from certain provisions. For example,
the information blocking provisions in
45 CFR 171 are critical to ensuring
patients are able to access their EHI
when and where they need it. Therefore,
the extensions for most of the
information blocking provisions are
limited to April 5, 2021, for two reasons.
First and foremost, we must balance the
need to provide actors with more time
to address the PHE with the ultimate
goal of making EHI more accessible to
improve the cost and quality of care.
Second, unlike some of the 2015 Edition
Cures Update certification criteria, the
information blocking provisions do not
explicitly require actors to purchase or
update certified health IT, so there is
less of a concern about technology
resource allocations in the near term.
In other instances, a close review of
the ONC Cures Act Final Rule in light
of the PHE led us to conclude that some
provisions would be better served by
lengthier extensions. For example, we
are extending until December 31, 2022,
the compliance date for the 2015
Edition Cures Update certification
criteria (85 FR 25666 through 25667).
The updated certification criteria
require health IT developers to upgrade
their current technology in order to
maintain or earn their certified status.
Developers have been allocating
resources to ensure their technology
meets the new needs of their customers
(e.g., health care providers and health
care systems) including, for example,
the ability to collect and report COVID–
19 data. However, health IT developers
are also not currently in a situation to
be able to successfully rollout and test
the certification criteria with their
customers because the health care
system has been focused on fighting the
COVID–19 PHE. Developers, therefore,
should have greater leeway to ensure
the costs of meeting the 2015 Edition
Cures Update certification criteria
compliance dates do not impair efforts
to fight the COVID–19 PHE. Further,
certified health IT serves an important
public good: Hospitals, patients and
public health networks rely on certified
health IT. If ONC does not grant an
appropriate extension for developers to
comply with the 2015 Edition Cures
Update, some health IT developers may
decide not to seek re-certification, or
forego certification altogether, if they
determine they do not have the
VerDate Sep<11>2014
16:30 Nov 03, 2020
Jkt 253001
resources required to meet tight
deadlines. While the new and revised
certification criteria in the 2015 Edition
Cures Update will further advance the
policy goals of the Cures Act, we are
confident the current certification
criteria promote interoperability and
support the access, exchange and use of
EHI. Therefore, in balancing these
interests, we concluded it would be
contrary to the public interest if we did
not extend the compliance date for the
2015 Edition Cures Update certification
criteria.
Finally, some of the extensions are
related to the actions of other
components of HHS. For example, the
Centers for Medicare & Medicaid
Services (CMS) works closely with ONC
because some CMS programs require
technology to be certified under the
Program. As discussed in the ONC
Cures Act Final Rule, ONC considers
these impacts when establishing
policies for health IT developers that
may also affect health care providers
participating in CMS programs (85 FR
25665). Because of the cyclical nature of
CMS reporting requirements each
calendar year, including the 90-day
reporting period that is self-selected by
CMS Promoting Interoperability
Program participants, ONC regularly
works to ensure that our own
certification timelines complement the
schedules inherent to this program and
other CMS programs. In the interest of
clarity and cohesion among HHS
components, we have aligned some of
our dates to the calendar year for
instances that may impact CMS program
participants. Aligning these related
compliance dates to the calendar year
also aligns them to the CMS program
annual cycle. This approach will avoid
confusion and best serve the public
interest. This approach also extends
existing flexibility, rather than creating
a new restriction or requirement, and
minimizes the impact on health care
providers. While we are finalizing more
flexible compliance dates, we continue
to encourage developers to implement
these updates and make them available
to customers as soon as practicable
under the circumstances.
1. Information Blocking Provisions and
Related Condition and Maintenance of
Certification Requirements
In the ONC Cures Act Final Rule, the
compliance date for 45 CFR part 171,
which contains the information
blocking provisions of the final rule, is
November 2, 2020 (85 FR 25642). This
is six months after the publication date
of the final rule in the Federal Register.
Section 171.101(b) provides that health
care providers, health IT developers of
PO 00000
Frm 00026
Fmt 4700
Sfmt 4700
certified health IT, health information
exchanges, and health information
networks must comply with 45 CFR part
171 on and after November 2, 2020. We
established the six-month-delayed
compliance date to provide actors with
time to thoroughly read and understand
the final rule and educate their
workforces in order to apply the
exceptions in an appropriate manner (85
FR 25792). We also noted that the
finalized definition of information
blocking (§ 171.103) and the Content
and Manner Exception (§ 171.301(a))
narrowed the scope of the EHI
definition to include only the EHI
identified by the data elements
represented in the United States Core
Data for Interoperability (USCDI) for the
first 18 months after the compliance
date for 45 CFR part 171. Therefore, in
addition to the six-month postpublication compliance date for 45 CFR
part 171, the ONC Cures Act Final Rule
granted actors an additional 18 months
to gain experience applying the
exceptions with only the EHI identified
by the data elements represented in the
USCDI, as compared to the full scope of
EHI, which would apply thereafter (85
FR 25792).
In the ONC Cures Act Final Rule, we
encouraged actors, during this
combined period of 24 months, to apply
the exceptions to all EHI as if the scope
was not limited to EHI identified by the
data elements represented in the USCDI.
However, given the initial scope of EHI
identified in the information blocking
definition in § 171.103 and the Content
and Manner Exception in § 171.301(a), if
an actor did not, in the first 24 months
after the ONC Cures Act Final Rule’s
publication date, enable access,
exchange, or use of data outside the
USCDI, or did not appropriately apply
an exception to data outside the USCDI,
such practice or ‘‘error’’ would not be
considered information blocking
because that data would not be
considered ‘‘EHI’’ during that time
period (85 FR 25792).
We also stated that the compliance
dates for the Information Blocking
Condition of Certification requirement
in § 170.401 and the Assurances
Condition of Certification requirement
in § 170.402(a)(1) would be six months
after the publication date of the final
rule in the Federal Register, i.e.,
November 2, 2020.
In light of the PHE, we believe it is
necessary to offer additional
flexibilities. Therefore, in this IFC, we
are extending the date for 45 CFR part
171 from November 2, 2020, to April 5,
2021. We also believe it is more precise
to refer to this date as the applicability
date for 45 CFR part 171 instead of the
E:\FR\FM\04NOR1.SGM
04NOR1
khammond on DSKJM1Z7X2PROD with RULES
Federal Register / Vol. 85, No. 214 / Wednesday, November 4, 2020 / Rules and Regulations
compliance date. Accordingly, in
section II.C.7 of this IFC, we are revising
§ 171.101(b) to state that actors ‘‘are
subject to’’ 45 CFR part 171 on and after
April 5, 2021. We believe the additional
five months will enable actors to focus
on the PHE, provide sufficient
additional time to thoroughly read and
understand the ONC Cures Act Final
Rule, and educate their workforce about
information blocking and the exceptions
contained in the final rule. However, at
this time, we do not believe the
applicability date for 45 CFR part 171
should extend beyond April 5, 2021. We
believe this timeframe appropriately
balances the additional flexibility
necessary due to the PHE with ONC’s
sense of urgency in addressing
information blocking. We emphasized
the urgency of addressing information
blocking in the ONC Cures Act Final
Rule. We explained that, based on our
findings from our 2015 Report to
Congress,4 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 (85 FR 25652). Congress
responded by enacting the Cures Act on
December 13, 2016, with many
provisions specifying a need for swift
implementation. Implementation of the
information blocking provisions in the
ONC Cures Act Final Rule will increase
information sharing, improve patient
care, and ensure that a patient’s health
information follows the patient—all of
which are urgent goals, particularly
during a PHE. In addition, we also
believe the applicability date should not
extend beyond April 5, 2021, because
the information blocking provisions do
not contain any technical upgrade
requirements that necessitate a longer
extension.
We have revised § 171.101(b) to
codify the extended applicability date
for 45 CFR part 171. Section 171.101(b)
now states that health care providers,
health IT developers of certified health
IT, health information exchanges, and
health information networks are subject
to this part on and after April 5, 2021.
Because we are extending the
applicability date for 45 CFR part 171
generally, we are also updating the date
by which actors must provide all EHI in
response to a request, rather than
responding with only the data elements
represented in the USCDI. Consistent
with our original intent to narrow the
scope of the EHI definition to just the
data elements represented in the USCDI
4 https://www.healthit.gov/sites/default/files/
reports/info_blocking_040915.pdf.
VerDate Sep<11>2014
16:30 Nov 03, 2020
Jkt 253001
for the first 18 months after the
applicability date for 45 CFR part 171,
in this IFC, we are also extending the
end date for this narrowed definition by
5 months. Therefore, for the 18-month
period on and after the April 5, 2021,
applicability date and before October 6,
2022, the EHI required in § 171.101(b)
will be limited to the data represented
in the USCDI. Thus actors will have
additional time to gain experience
applying the exceptions with the
narrower definition of EHI, as compared
to the full scope of EHI, which will
apply on and after October 6, 2022.
Therefore, we have revised
§ 171.103(b) of the information blocking
definition to extend the period of time
for which the EHI is limited to the data
elements represented in the USCDI. We
state in § 171.103(b) that for the period
before October 6, 2022, at a minimum,
the EHI identified for the purposes of
the information blocking definition in
§ 171.103(a) is limited to the EHI
identified by the data elements
represented in the USCDI standard
adopted in § 170.213. Similarly, we
revised and finalized the same date in
two paragraphs of the Content and
Manner exception (§ 171.301(a)(1) and
(2)). We find good cause to waive the
notice and comment procedures and
delayed effective date requirements of
the APA as impracticable and contrary
to the public interest due to the COVID–
19 PHE (5 U.S.C. 553(b)(B), (d)(3)).
Please see sections II.C and III of this
IFC for further discussions of our good
cause finding.
We have also revised § 170.401 and
§ 170.402. The ONC Cures Act Final
Rule required health IT developers of
certified health IT to comply with the
Information Blocking Condition of
Certification requirement in § 170.401,
and the Assurances Condition of
Certification requirement related to
information blocking in § 170.402(a)(1),
beginning on November 2, 2020. For the
reasons stated above, we have also
provided an extension to these
compliance dates. Now, health IT
developers must comply with the
Condition of Certification requirements
in § 170.401 and § 170.402(a)(1)
beginning on April 5, 2021. We find
good cause to waive the notice and
comment procedures and delayed
effective date requirements of the APA
as impracticable and contrary to the
public interest due to the COVID–19
PHE (5 U.S.C. 553(b)(B), (d)(3)). Please
see section III of this IFC for further
discussion of our good cause finding.
This IFC finalizes the extensions and we
seek comment on the information
blocking dates and extensions that we
adopt in this IFC.
PO 00000
Frm 00027
Fmt 4700
Sfmt 4700
70069
2. Certain 2015 Edition Health IT
Certification Criteria Updates
In light of the COVID–19 PHE, we are
extending compliance dates and
timeframes for certain 2015 Edition
certification criteria under 45 CFR part
170. In the ONC Cures Act Final Rule,
in general, we provided that health IT
developers of certified health IT have 24
months from the publication date of the
final rule to make technology certified
to the updated criteria available to their
customers. We noted that, during this
time, developers could continue
supporting technology certified to the
prior version of certification criteria for
use by their customers (85 FR 25666).
To allow the health care system time
to focus on the COVID–19 PHE, we are
extending the timeline for certain 2015
Edition certification criteria (please see
Table 2 below) until December 31, 2022,
and until December 31, 2023, for
§ 170.315(b)(10), ‘‘EHI export’’. This
represents an extension of nearly eight
months beyond the original compliance
dates finalized in the ONC Cures Act
Final Rule and nearly an additional five
months beyond the period of
enforcement discretion ONC announced
on April 21, 2020.5 As discussed above,
we considered several factors as we
determined the appropriate date to
which to extend the compliance dates.
To determine that December 31, 2022,
as well as December 31, 2023, for ‘‘EHI
Export’’ (§ 170.315(b)(10)), are
appropriate compliance dates for
updating certain 2015 Edition Cures
Update certification criteria, we
considered a number of factors. The
updated certification criteria require
health IT developers to upgrade their
current technology in order to maintain
or earn their certified status. Some of
the upgrades may require training staff
or providers on how to operationalize
the updated certification criteria. We
want to provide additional flexibilities
for the health care system to respond to
the public health threats posed by the
COVID–19 PHE, and to reduce the
burden in administrative efforts
associated with staff attending any
necessary trainings or with
incorporating the updated technology
into their operations. Accordingly, we
are delaying the compliance date for
developers to transition to the updated
standards in the 2015 Edition Cures
Update certification criteria. This
extension will delay the burden that
health IT developers would incur from
being required to make the updated
health IT available to their customers.
This delay will enable these providers
5 https://www.healthit.gov/curesrule/resources/
enforcement-discretion.
E:\FR\FM\04NOR1.SGM
04NOR1
70070
Federal Register / Vol. 85, No. 214 / Wednesday, November 4, 2020 / Rules and Regulations
and developers to continue using
technology certified to the current
versions of the certification criteria with
which they are already familiar for an
extended period, allowing for greater
flexibility in choosing when to
implement updated technology.
Developers should have greater leeway
to ensure the costs of meeting the 2015
Edition Cures Update certification
criteria compliance dates do not impair
efforts to fight the COVID–19 PHE.
We have included in Table 2 (below)
the 2015 Edition Cures Update
certification criteria with new
compliance dates. Note that ‘‘ONC–
ACBs’’ refers to ONC-Authorized
Certification Bodies.
khammond on DSKJM1Z7X2PROD with RULES
TABLE 2—2015 EDITION CURES UPDATE
Certification criteria
Reference
2015 Edition cures update—timing
Transitions of Care ...............................
§ 170.315(b)(1) ........
Update to adopted USCDI/C–CDA
companion guide by December 31,
2022.
Clinical information reconciliation and
incorporation.
§ 170.315(b)(2) ........
Electronic prescribing ...........................
§ 170.315(b)(3) ........
Data Export ...........................................
§ 170.315(b)(6) ........
Security tags—summary of care—send
§ 170.315(b)(7) ........
Security tags—summary of care—receive.
§ 170.315(b)(8) ........
Care plan ..............................................
§ 170.315(b)(9) ........
EHI export .............................................
§ 170.315(b)(10) ......
Clinical quality measures (CQMs)—report.
Auditable events and tamper-resistance.
Audit report(s) .......................................
§ 170.315(c)(3) ........
Auditing actions on health information
§ 170.315(d)(10) ......
View, Download, and Transmit to 3rd
Party.
§ 170.315(e)(1) ........
Transmission to public health agencies—electronic case reporting.
Consolidated CDA creation performance.
§ 170.315(f)(5) .........
Application
Request.
§ 170.315(g)(8) ........
Update to adopted USCDI/C–CDA
companion guide by December 31,
2022.
Update to adopted NCPDP SCRIPT
standard version 2017071 by December 31, 2022.
ONC–ACBs may only issue certificates for this criterion for the period
before December 31, 2023.
Document, section, and entry (data
element) level; or Document level
for the period before December 31,
2022.
Document, section, and entry (data
element) level; or Document level
for the period before December 31,
2022.
Update to C–CDA companion guide
referenced in § 170.205(a)(4) and
§ 170.205(a)(5) by December 31,
2022.
Certify to new criterion by December
31, 2023.
Update to CMS QRDA Category I/III
IG by December 31, 2022.
Update to ASTM 2147–18 standard by
December 31, 2022.
Update to ASTM 2147–18 standard by
December 31, 2022.
Update to ASTM 2147–18 standard by
December 31, 2022.
Update to USCDI referenced in
§ 170.213 and C–CDA companion
guide referenced in § 170.205(a)(4)
and § 170.205(a)(5) by December
31, 2022.
Update to USCDI referenced in
§ 170.213 by December 31, 2022.
Update to USCDI referenced in
§ 170.213 and C–CDA companion
guide referenced in § 170.205(a)(4)
and § 170.205(a)(5) by December
31, 2022.
ONC–ACBs may only issue certificates for this criterion for the period
before December 31, 2022.
Update to USCDI referenced in
§ 170.213 and C–CDA companion
guide referenced in § 170.205(a)(4)
and § 170.205(a)(5) by December
31, 2022.
Access—Data
Category
Application Access—All Data Request
VerDate Sep<11>2014
16:30 Nov 03, 2020
§ 170.315(d)(2) ........
§ 170.315(d)(3) ........
§ 170.315(g)(6) ........
§ 170.315(g)(9) ........
Jkt 253001
PO 00000
Frm 00028
Fmt 4700
Sfmt 4700
E:\FR\FM\04NOR1.SGM
Impact on CMS
Promoting
Interoperability (PI) programs
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.
—Query of PDMP.
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.
PI Measure: Electronic Case Reporting.
PI Measure: Provide Patients
tronic Access to Their Health
mation.
PI Measure: Provide Patients
tronic Access to Their Health
mation.
04NOR1
ElecInforElecInfor-
Federal Register / Vol. 85, No. 214 / Wednesday, November 4, 2020 / Rules and Regulations
70071
TABLE 2—2015 EDITION CURES UPDATE—Continued
Certification criteria
Reference
2015 Edition cures update—timing
Standardized API for patient and population services.
§ 170.315(g)(10) ......
Certify to new criterion by December
31, 2022.
3. Conditions and Maintenance of
Certification Requirements Under the
ONC Health IT Certification Program
We have also extended compliance
dates and timeframes for other
Conditions and Maintenance of
Certification requirements in the ONC
Cures Act Final Rule to allow adequate
time for our health care system to
address the COVID–19 PHE.
khammond on DSKJM1Z7X2PROD with RULES
a. Assurances
Section 4002 of the Cures Act 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
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. In the ONC
Cures Act Final Rule, we finalized
implementation of this provision
through several Conditions of
Certification in § 170.402(a) and
accompanying Maintenance of
Certification requirements, which are
set forth in § 170.402(b). We stated in
the final rule that the Assurances
Condition and Maintenance of
Certification requirements had an
effective date of June 30, 2020. We
exercised enforcement discretion on
April 21, 2020, to extend the
compliance date an additional three
months to September 30, 2020.6 While
we have not made a public
announcement that we would be
extending our enforcement discretion
for an additional period of time, we
have not taken any actions to enforce
the Assurance Condition and
Maintenance of Certification
requirements since September 30, 2020.
In this IFC, we are extending the
compliance date and timeframe for the
Assurances Condition and Maintenance
of Certification requirements until April
5, 2021, to provide maximum
flexibilities for our health care system to
6 https://www.healthit.gov/curesrule/resources/
enforcement-discretion.
VerDate Sep<11>2014
16:30 Nov 03, 2020
Jkt 253001
respond to the public health threats
posed by the COVID–19 PHE. We find
good cause to waive the notice and
comment procedures of the APA due to
the COVID–19 PHE (as discussed in
section III of this IFC) (5 U.S.C.
553(b)(B)). Additionally, because
affected parties are best served by
reducing the uncertainty that could
result from different compliance and
applicability dates (information
blocking-related Conditions of
Certification requirements and the
information blocking provisions (45
CFR part 171)) and because an
immediate effective date serves to
reduce a burden on the regulated party
by allowing developers of health
technology to immediately certify their
technology without meeting this new
requirement, we find good cause to
waive the delayed effective date
requirements (5 U.S.C. 553(d)). We are
also announcing that any actions or
omissions of developers of certified
health IT that may have not been in
compliance with these Condition and
Maintenance of Certification
requirements since either the effective
date of the final rule or since the
expiration of the prior enforcement
discretion period would not be subject
to non-compliance enforcement for
those actions and omissions that
occurred during those time periods. In
other words, we do not intend to engage
in Program enforcement for noncompliance between June 30, 2020, and
April 5, 2021.
As we noted above, we have also
extended the compliance date related to
§ 170.402 until April 5, 2021, except for
§ 170.402(b)(2). In § 170.402(b)(2), we
extended the compliance date to meet
the requirement that a health IT
developer must provide all of its
customers of certified health IT with
health IT certified to the ‘‘EHI export’’
certification criterion in § 170.315(b)(10)
to December 31, 2023.
b. Communications
In the ONC Cures Act Final Rule, we
finalized in § 170.403 provisions that
permit developers to impose on
communications certain types of limited
PO 00000
Frm 00029
Fmt 4700
Sfmt 4700
Impact on CMS
Promoting
Interoperability (PI) programs
Added to the 2015 Edition Base EHR
definition.
PI Measure: Provide Patients Electronic Access to Their Health Information.
prohibitions and restrictions that strike
a balance between the need to promote
open communication about certified
health IT and related developer business
practices, and the need to protect the
legitimate business interests of health IT
developers and others. The provisions
identify certain narrowly-defined 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. We also
finalized provisions that allow health IT
developers certified under the Program
to place limitations on certain types of
communications, including screenshots
and video. In the ONC Cures Act Final
Rule, the compliance date for the
Communications Condition of
Certification requirements was the
effective date of the final rule, June 30,
2020. We exercised enforcement
discretion on April 21, 2020, to extend
compliance for an additional three
months to September 30, 2020.7 While
we have not made a public
announcement that we would be
extending our enforcement discretion
for an additional period of time, we
have not taken any actions to enforce
the Communications Condition and
Maintenance of Certification
requirements since September 30, 2020.
In this IFC, we are extending the
compliance date until April 5, 2021, to
allow additional time for the health care
system to respond to public health
threats posed by the COVID–19 PHE.
We find good cause to waive the notice
and comment procedures of the APA
due to the COVID–19 PHE (as discussed
in section III of this IFC) (5 U.S.C.
553(b)(B)). Additionally, because
affected parties are best served by
reducing the uncertainty that could
result from different compliance and
applicability dates (information
7 https://www.healthit.gov/curesrule/resources/
enforcement-discretion.
E:\FR\FM\04NOR1.SGM
04NOR1
khammond on DSKJM1Z7X2PROD with RULES
70072
Federal Register / Vol. 85, No. 214 / Wednesday, November 4, 2020 / Rules and Regulations
blocking-related Conditions of
Certification requirements and the
information blocking provisions (45
CFR part 171)) and because an
immediate effective date serves to
reduce a burden on the regulated party
by allowing developers of health
technology to immediately certify their
technology without meeting this new
requirement, we find good cause to
waive the delayed effective date
requirements (5 U.S.C. 553(d)). We are
also announcing that any actions or
omissions of developers of certified
health IT that may have not been in
compliance with these Condition and
Maintenance of Certification
requirements since either the effective
date of the final rule or since the
expiration of the prior enforcement
discretion period would not be subject
to non-compliance enforcement for
those actions and omissions that
occurred during those time periods. In
other words, we do not intend to engage
in Program enforcement for noncompliance between June 30, 2020, and
April 5, 2021.
In the ONC Cures Act Final Rule, we
also adopted Maintenance of
Certification requirements for health IT
developers of certified health IT in
§ 170.403(b). Section 170.403(b)(2)
states that a health IT developer must
not impose or enforce any contractual
requirement that contravenes the
requirements of paragraph (a) of
§ 170.403, the Communications
Condition of Certification. Furthermore,
if a health IT developer has contracts or
agreements in existence that contravene
the requirements of the Condition of
Certification, the developer must notify
all affected customers, other persons, or
entities that the prohibition or
restriction within the contract or
agreement will not be enforced by the
health IT developer (§ 170.403(b)(1)). In
the ONC Cures Act Final Rule, we stated
that the developer must notify all
affected customers annually, beginning
in 2020. Due to the COVID–19 PHE, we
are suspending the notice requirement
in § 170.403(b)(1) for 2020 only. Health
IT developers of certified health IT with
such contracts or agreements must
provide notice to all customers
beginning in 2021 and annually
thereafter so long as those contracts or
agreements remain in place.
This limited suspension ensures that
health IT developers will still notify the
users and customers of certified health
IT in a timely manner, and also relieves
pressure on the developers to
immediately devote portions of their
workforce to review contracts. We
believe the annual requirement,
beginning with notification in calendar
VerDate Sep<11>2014
16:30 Nov 03, 2020
Jkt 253001
year 2021, will simplify compliance for
health IT developers while still
providing adequate notice in a
reasonable amount of time. We have
finalized the deadline for the notice
requirement in § 170.403(b)(1) to be
annually, beginning in calendar year
2021.
c. Application Programming Interfaces
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. The ONC
Cures Act Final Rule captures both the
technical functionality and behaviors
necessary to implement the Cures Act
API Condition of Certification
requirement. Specifically, we adopted
new standards, new implementation
specifications, a new certification
criterion, and modified the Base EHR
definition. In addition, we finalized
detailed Condition and Maintenance of
Certification requirements for health IT
developers.
For instance, in the ONC Cures Act
Final Rule, we adopted a requirement in
§ 170.404(b)(4) that a Certified API
Developer with Health IT Module(s)
certified to the certification criteria in
§ 170.315(g)(7), (8), or (9) (ONC
Certification Program API criteria) must
comply with § 170.404(a) (API
Condition of Certification requirements)
by no later than November 2, 2020 (85
FR 25765). We exercised enforcement
discretion on April 21, 2020, to extend
compliance for an additional three
months.8 In this IFC, we are extending
the compliance date until April 5, 2021,
so that the health care system can focus
on addressing the COVID–19 PHE. We
align the new compliance date for this
provision with other dates that had a
November 2, 2020 compliance date in
the ONC Cures Act Final Rule. Setting
a more delayed compliance date would
8 https://www.healthit.gov/curesrule/resources/
enforcement-discretion.
PO 00000
Frm 00030
Fmt 4700
Sfmt 4700
have unreasonably delayed and
ultimately diminished the benefits of
the Program requirements we have
finalized in the ONC Cures Act Final
Rule.
We also stated in the ONC Cures Act
Final Rule in § 170.404(b)(3) that
Certified API Developers with API
technology previously certified to the
criterion in § 170.315(g)(8) must provide
API technology certified to
§ 170.315(g)(10) to all API Information
Sources deployed with certified API
technology by no later than May 1, 2022
(85 FR 25765). In this IFC, we are
extending the compliance timeline for
that rollout of new standardized API
functionality under § 170.404(b)(3) to
December 31, 2022. We are also revising
the dates in § 170.102, in the definition
of 2015 Edition Base EHR, to be
consistent with this extension.
As stated above, we believe extending
the compliance date for this
requirement by eight months is
appropriate so that health IT developers
and health care providers may
adequately allocate time and resources
to address the COVID–19 PHE.
d. 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
their decisions to acquire certified
health IT.
In the ONC Cures Act Final Rule, we
established in § 170.405 real world
testing 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 (10)) to ensure the technology meets
its users’ needs for widespread and
continued interoperability. We provide
details on the 2015 Edition Cures
Update certification criteria in section
II.A.2 above. We are extending the
compliance dates for updating these
criteria until December 31, 2022 (and
until December 31, 2023, for
§ 170.315(b)(10), ‘‘EHI export’’).
Under real world testing Condition
and Maintenance of Certification
requirements, health IT developers must
also submit publicly available annual
real world testing plans and results for
health IT certified to the criteria
identified in § 170.405(a). In the ONC
E:\FR\FM\04NOR1.SGM
04NOR1
Federal Register / Vol. 85, No. 214 / Wednesday, November 4, 2020 / Rules and Regulations
Cures Act Final Rule, we stated that
developers must submit plans by
December 15 of each calendar year and
results by March 15 of each calendar
year to ONC for public availability (85
FR 25773 and 25774). Due to the
COVID–19 PHE, developers are
modifying their technology in ways that
are needed to support the health care
system in this country. Rather than
taking resources from that essential
work, in this IFC, we are extending the
compliance dates for submitting initial
real world testing plans to December 15,
2021, and initial real world testing
results to March 15, 2023.
khammond on DSKJM1Z7X2PROD with RULES
e. Attestations
In the ONC Cures Act Final Rule, in
§ 170.406, we stated that health IT
developers must attest twice a year to
compliance with the Conditions and
Maintenance of Certification
requirements (except for the EHR
reporting criteria submission
requirement) (85 FR 25648). We believe
requiring attestations every six months
under § 170.406(b) will properly balance
the need to support appropriate
enforcement with our desire to
minimize the burden on health IT
developers. In light of the COVID–19
PHE and extensions provided for other
Conditions and Maintenance of
Certification requirements, in this IFC,
we are extending our annual cycle for
attestations by one year, to calendar year
2022. To clarify, due to the extensions
provided for other Conditions and
Maintenance of Certification
requirements in this IFC, the first
attestation window will continue to
cover an irregular time period from the
effective date of the final rule through
the extended date of March 31, 2022.
Subsequently, a regular six-month
period will commence with the next
attestation window.
We believe that delaying the
implementation of these Condition and
Maintenance of Certification
requirements will allow health IT
developers additional time to comply
with the requirements and provides
appropriate flexibility so that our health
care system may adequately respond to
the current COVID–19 PHE.
4. Updates to ONC–ACB Dates and
Timeframes
In the ONC Cures Act Final Rule, we
finalized several certification criteria
changes that were accompanied by
compliance dates and timeframes. As
we stated previously, due to the
COVID–19 PHE, this IFC extends certain
compliance dates and timeframes for
those new and updated certification
criteria and Condition and Maintenance
VerDate Sep<11>2014
16:30 Nov 03, 2020
Jkt 253001
of Certification Requirements.
Consequently, for purposes of
coordination, we are also extending
compliance dates and timeframes for the
appropriate provisions applicable to the
ONC—Authorized Certification Bodies
(ACBs).
In the ONC Cures Act Final Rule, we
finalized in § 170.523(p)(3) that ONC–
ACBs must submit real world testing
plans by December 15 of each calendar
year and results by March 15 of each
calendar year to ONC for public
availability. Because we are now
extending those dates for health IT
developers, we are also extending the
dates by which ONC–ACBs must submit
the real world testing plans and results
to ONC for public availability. ONC–
ACBs must now submit initial plans to
ONC by December 15, 2021, and initial
results by March 15, 2023.
We had also finalized in
§ 170.550(m)(2) and (3) a time-limited
certification status for certain 2015
Edition certification criteria. We
finalized that an ONC–ACB may only
issue a certification to a Health IT
Module and permit continued certified
status for § 170.315(b)(6) and (g)(8) until
May 1, 2023, and May 2, 2022,
respectively. To reflect the extension of
compliance dates and timeframes, we
are now finalizing in § 170.550(m)(2)
and (3) that an ONC–ACB may only
issue a certification to a Health IT
Module and permit continued certified
status for § 170.315(b)(6) and (g)(8) until
December 31, 2023, and December 31,
2022, respectively.
Lastly, in the ONC Cures Act Final
Rule, we finalized that for criteria being
updated from the Common Clinical Data
Set (CCDS) to the USCDI, a transition
from the CCDS to the USCDI must occur
no later than 24 months after the
publication date of the final rule. We
stated that for the period up to 24
months after the publication date of the
ONC Cures Act Final Rule, the CCDS
remains permissible for certified Health
IT Modules until such Health IT
Modules are updated to the USCDI. Due
to the extension of compliance dates for
certain 2015 Edition Cures Update
certification criteria (we refer readers to
section II.A.2), we are also providing an
extension such that for certified Health
IT Modules, the CCDS may remain
applicable up to December 31, 2022,
when such Health IT Modules are
updated to the USCDI.
We believe these revisions are
appropriate and align with the extended
compliance dates and timelines for
related certification criteria and Program
requirements.
PO 00000
Frm 00031
Fmt 4700
Sfmt 4700
70073
B. Standards Updates
1. USCDI
In the ONC Cures Act Final Rule, we
published the USCDI version 1 (v1) to
replace the CCDS as the standard
patient data set in several ONC
certification criteria.9 Through the
USCDI v1 we added new data classes,
including Allergies and Intolerances,
Clinical Notes, and Provenance; and
added data elements to Patient
Demographics and Vital Signs. In
USCDI v1, we also defined applicable
terminology standards to represent
respective data elements, where
appropriate. In the ONC Cures Act Final
Rule, we adopted into the USCDI
additional data classes and data
elements, with the applicable standards
thus replacing CCDS. With the
exception of the Medication class and
Medication Allergies data element, we
neither proposed nor intended to
change applicable standards relevant to
the CCDS data elements. However, we
included in the USCDI v1 10 new
applicable terminology standards that
were neither previously required for the
CCDS nor presented for addition or
change through the rulemaking process.
Several stakeholders commented on and
objected to these unexpected changes to
the applicable standards, and ONC
concurred with these comments.
Therefore, we published the USCDI v1
(July 2020 Errata) 11 to address these
concerns, to make the necessary
corrections to the standards, and to
describe the changes over the original
USCDI v1. We are adopting and
incorporating by reference the updated
standard USCDI v1 (July 2020 Errata) in
this IFC.
2. US Core Implementation Guide
We adopted the HL7® FHIR® US Core
Implementation Guide STU3 Release
3.1.0 (US Core IG 3.1.0) as part of the
ONC Cures Act Final Rule testing and
certification requirements for the
§ 170.315(g)(10) standardized API for
patient and population services
certification criterion. Since publication
of the ONC Cures Act Final Rule, the
health IT standards community has
identified and resolved several technical
issues, editorial copy/paste errors,
omissions, and places in need of minor
clarification in the US Core IG 3.1.0.
The health IT standards community has
also published a revised HL7 FHIR US
9 https://www.healthit.gov/cures/sites/default/
files/cures/2020-03/USCDI.pdf.
10 https://www.healthit.gov/isa/sites/isa/files/
2020-03/USCDI-Version1-2020-Final-Standard.pdf.
11 https://www.healthit.gov/isa/sites/isa/files/
2020-07/USCDI-Version-1-July-2020-ErrataFinal.pdf.
E:\FR\FM\04NOR1.SGM
04NOR1
70074
Federal Register / Vol. 85, No. 214 / Wednesday, November 4, 2020 / Rules and Regulations
Core Implementation Guide STU3
Release 3.1.1 (US Core IG 3.1.1) with
technical errata to address these
updates. We are adopting the US Core
IG 3.1.1 in § 170.215(a)(2) in order to
support industry standardization
around the latest version of the US Core
IG.
khammond on DSKJM1Z7X2PROD with RULES
C. Corrections and Clarifications to the
ONC Cures Act Final Rule
In Federal Register document 2020–
07419 (85 FR 25642), the ONC Cures
Act Final Rule, we identified certain
inadvertent errors following publication
in the Federal Register on May 1, 2020.
In this IFC, we are correcting these
errors and providing clarification. As we
discuss in further detail below, we find
good cause to waive the notice and
comment (and, for certain corrections,
the delayed effective date) requirements
of the Administrative Procedure Act
(APA), 5 U.S.C. 553(b) and (d). We
believe adherence to these APA
requirements would be impracticable,
unnecessary, or contrary to the public
interest for these corrections and
clarifications, and explain below our
reasoning for each.
It is important for our final rules to be
written clearly and accurately, and to
reflect the final policies we adopted
after considering the public comments
we received on our proposals.
Inadvertent errors such as these could
be confusing to regulated individuals
and entities that are subject to the ONC
Cures Act Final Rule. Failure to correct
these errors and provide clarifications
could place unnecessary burden on
regulated parties as they attempt to
comply with the final rule. We
summarize and correct these errors and
offer the necessary clarifications below.
1. General Applicability and
Applicability of Standards and
Implementation Specifications for
Health Information Technology
As noted in the ONC Cures Act Final
Rule, the Cures Act amended title XXX
of the PHSA to establish the
‘‘Communications’’ condition of
certification, which applies to ‘‘health
information technology’’ (85 FR 25733).
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
VerDate Sep<11>2014
16:30 Nov 03, 2020
Jkt 253001
health information. We adopted this
definition of ‘‘health information
technology’’ in § 170.102 in the ONC
Cures Act Final Rule (85 FR 25733).
However, in § 170.101 and § 170.200,
we neglected to update the language to
say ‘‘health information technology.’’
Instead, we erroneously kept the
reference to ‘‘Health IT Modules.’’ We,
therefore, are updating this language in
this IFC. As these are clarifications and
not substantive corrections, we find
good cause to waive the notice and
comment procedures of the APA as
unnecessary (5 U.S.C. 553(b)(B)).
2. Standards for Health Information
Technology To Protect Electronic Health
Information Created, Maintained, and
Exchanged
a. Record Actions Related to Electronic
Health Information, Audit Log Status,
and Encryption of End-User Devices
In the ONC Cures Act Final Rule (85
FR 25708), we inadvertently referred to
the auditable events and tamperresistance standard as ‘‘ASTM E1247–
18’’. The error occurs twice on that
page. The correct standard is ASTM
E2147–18, which is what we included
in the relevant regulatory text.
We also inadvertently omitted
amendatory text for § 170.210(e)(2)(i)
and (e)(3) (85 FR 25940). Because we
updated the standard in § 170.210(h) to
ASTM E2147–18, we have also updated
the requirements in § 170.210(e) to align
with the new numbering sequence of
the updated standard. However, we
inadvertently neglected to update the
same reference language for the ASTM
data elements in § 170.210(e)(2)(i) and
(e)(3). Therefore, we are correcting
§ 170.210(e)(2)(i) and (e)(3) by replacing
‘‘7.2 and 7.4,’’ which referred to the
previous ASTM standard, with ‘‘7.1.1
and 7.1.7,’’ which refers to the updated
ASTM E2147–18 standard. This does
not constitute a change in requirements,
but simply a change to where those
requirements are referenced within the
updated ASTM E2147–18 standard. The
correction of typographic errors does
not constitute a substantive change, and
we, therefore, find good cause to waive
the public notice and comment
procedures of the APA as unnecessary
(5 U.S.C. 553(b)(B)).
In addition, the new numbering of the
ASTM data elements led to another
error. The ONC Cures Act Final Rule
included the requirement for Health IT
Modules to support 7.1.3 Duration of
Access in the ASTM E2147–18
standard. However, we have determined
this will not be a requirement for testing
and certifying to 2015 Edition Cures
Update certification and we are
PO 00000
Frm 00032
Fmt 4700
Sfmt 4700
removing it from the regulatory text.
The requirement added a significant
burden for health IT developers and it
was not our intent to add burden
beyond the requirements to update to
the new ASTM E2147–18 standard. Our
intent, as proposed and stated in the
preamble, was simply to update the
standards’ numbering in our Program
for certification and testing to conform
with the new numbering set by the
standards organization itself (‘‘. . . the
updated standard reinforces what we
have previously required and
maintained with previous certification
requirements and note that there is no
substantial change to the standard’’ 85
FR 25708). After publication of the ONC
Cures Act Final Rule, we heard from
health IT developers who noted that we
had errantly included 7.1.3 Duration of
Access, a requirement we did not intend
to include as part of the Program at this
time. In fact, requiring developers of
certified health IT to certify to 7.1.3
would substantially increase the
development costs and time. While the
other related requirements for auditable
events and tamper resistance require
basic data like ‘‘date and time of
access,’’ the duration of access
certification criteria would require
substantial updates to all health
technology to record and preserve more
data than previously required. In
response, we immediately clarified in
sub-regulatory guidance (the
certification companion guide for
auditable events and tamper-resistance)
that this requirement will not be in
scope for certification or testing. Since
our intent, as proposed and discussed,
was to incorporate requirements similar
to those previously required, 7.1.3
Duration of Access in the ASTM E2147–
18 was errantly included. The
correction of typographic errors does
not constitute a substantive change, and
we, therefore, find that there is good
cause to waive the notice and comment
procedures of the APA as unnecessary
(5 U.S.C. § 553(b)(B)).
b. Synchronized Clocks
Section 170.210(g) (Synchronized
clocks) included a reference to Request
for Comment (RFC) 1305 Network Time
Protocol, a standard maintained by the
Internet Engineering Task Force (IETF).
However, prior to the release of the ONC
Cures Act NPRM, IETF obsoleted RFC
1305 and replaced it with RFC 5905,
which is backward compatible with RFC
1305. In this IFC, we removed the
reference to RFC 1305 in § 170.210(g).
Because the obsolete standard is no
longer maintained by its standard
organization and is therefore no longer
publically recognized as the current
E:\FR\FM\04NOR1.SGM
04NOR1
Federal Register / Vol. 85, No. 214 / Wednesday, November 4, 2020 / Rules and Regulations
khammond on DSKJM1Z7X2PROD with RULES
standard for common internet protocols,
and because the removal of the RFC
1305 standard and the replacement with
the current RFC 5905 standard were
both previously available for public
input through IETF’s open standards
process, we find good cause to waive
the notice and comment procedures of
the APA as unnecessary (5 U.S.C.
§ 553(b)(B)). To note, RFC 5905 Network
Time Protocol Version 4 (incorporated
by reference in § 170.299) was already
approved for § 170.210 on September 4,
2012.
3. Applicability of Certification Criteria
for Health Information Technology
In the ONC Cures Act Final Rule, we
removed the 2014 Edition from the CFR
(85 FR 25656). We also finalized
removal of terms and definitions
specific to the 2014 Edition from
§ 170.102, including the ‘‘2014 Edition
Base EHR,’’ ‘‘2014 Edition EHR
certification criteria,’’ and ‘‘Complete
EHR, 2014 Edition’’ definitions (85 FR
25655). 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
removed references to ‘‘Complete EHR’’
from the regulation text. In the ONC
Cures Act Final Rule, consistent with
our intent to remove all terms specific
to the 2014 Edition, we neglected to
include the removal of the term ‘‘EHR
Module.’’ The term should have been
corrected to say ‘‘Health IT Module.’’
We, therefore, now correct this error in
§ 170.300(a) and (c). The correction of
typographic errors does not constitute a
substantive change, and we, therefore,
find that there is good cause to waive
the notice and comment procedures of
the APA as unnecessary (5 U.S.C.
§ 553(b)(B)).
Consistent with our intent above to
remove the 2014 Edition, in
§ 170.300(d), we neglected to remove
the reference to § 170.314. We corrected
this error in this IFC by only referencing
§ 170.315 in § 170.300(d). Since we
removed and reserved § 170.314,
referring to § 170.314 in this section is
misleading and meaningless. The
correction of typographic errors does
not constitute a substantive change, and
we, therefore, find that there is good
cause to waive the notice and comment
procedures of the APA as unnecessary
(5 U.S.C. § 553(b)(B)).
4. Electronic Prescribing
As discussed in the ONC Cures Act
Final Rule, an RxFillIndicatorChange is
sent by a prescriber to a pharmacy to
indicate to the pharmacy that the
VerDate Sep<11>2014
16:30 Nov 03, 2020
Jkt 253001
prescriber is changing the types of
RxFill transactions that were previously
requested, modifying their status, or
canceling future transactions (85 FR
25682). We requested comment on this
transaction in the 21st Century Cures
Act: Interoperability, Information
Blocking, and the ONC Health IT
Certification Program Proposed Rule (84
FR 7444) and ultimately adopted it as
optional in the ONC Cures Act Final
Rule. However, in the regulation text,
we inadvertently used the transaction
‘‘RxFillIndicator’’ (85 FR 25942).
Therefore, in § 170.315(b)(3)(ii)(B)(2),
we are correcting the transaction to
‘‘RxFillIndicatorChange.’’ The
correction of typographic errors does
not constitute a substantive change, and
we, therefore, find that there is good
cause to waive the notice and comment
procedures of the APA as unnecessary
(5 U.S.C. § 553(b)(B)).
5. Clinical Quality Measures—Report
Criterion
In the ‘‘Updates to the 2015 Edition
Certification Criteria’’ section of the
ONC Cures Act Final Rule, we noted
that we only adopted two new technical
certification criteria in § 170.315(b)(10)
(EHI export) and § 170.315(g)(10)
(Standardized API for patient and
population services) to which health IT
developers seeking to upgrade their
products will need to present Health IT
Modules for certification (85 FR 25665).
We also included § 170.315(c)(3)
(Clinical quality measures—report) in
the list of criteria that currently apply to
certified Health IT Modules that CMS
program participants use. We stated
that, in general, health IT developers of
certified health IT have 24 months from
the publication date of the ONC Cures
Act Final Rule to make technology
certified to these updated certification
criteria available to their customers, and
during this time developers may
continue supporting technology
certified to the prior version of the ONC
certification criteria for use by their
customers (85 FR 25666). We intended
for § 170.315(c)(3) to also have a
compliance timeline of 24 months, but
we erroneously omitted it from the
‘‘clinical quality measures—report’’
criterion section of the preamble and the
real world testing regulatory text.
For all of the other criteria we revised
due to standards updates, we allowed a
24-month compliance timeline. In Table
1—2015 Edition Cures Update of the
ONC Cures Act Final Rule (85 FR
25667), we incorrectly included the
timing for the revised criterion ‘‘clinical
quality measures—report’’ to be the
effective date of the final rule, which
was 60 days after it was published in
PO 00000
Frm 00033
Fmt 4700
Sfmt 4700
70075
the Federal Register. Our intent, as
evidenced above in our description of
the overarching approach for all of the
standards updates to the 2015 Edition
criteria, was to make the compliance
timelines consistent for all of the
revised criteria and allow health IT
developers 24 months from the date of
publication to update to the new
standards. Therefore, to align with the
other revised criteria to relieve an
impractical burden on stakeholders and
to allow for the extension that we
discuss in section II.A.2, the correct
compliance timeline for the ‘‘clinical
quality measures—report’’ criterion is
December 31, 2022. We reflect this
change in § 170.405(b)(10) of the real
world testing Maintenance of
Certification requirements, stating that
health IT developers with health IT
certified to § 170.315(c)(3) as of June 30,
2020, would have to update such
certified health IT to the revisions by
December 31, 2022. The correction of
typographic errors does not constitute a
substantive change, and we, therefore,
find that there is good cause to waive
the notice and comment procedures of
the APA as unnecessary (5 U.S.C.
553(b)(B)). Even if this change
constituted a substantive rulemaking
subject to notice and comment
procedures or delayed effective date
requirements, because it would be
impractical and unnecessary to request
comment on such a change, we find
good cause to waive notice and
comment procedures and delayed
effective date requirements of the APA
(5 U.S.C. 553(b)(B), (d)).
CMS Quality Reporting Document
Architecture Implementation Guides
In the ONC Cures Act Final Rule, we
also failed to adopt the latest versions of
the CMS Quality Reporting Document
Architecture (QRDA) Implementation
Guides (IGs) as we stated we would do
in the Proposed Rule (84 FR 7446). In
the Proposed Rule, we stated at 85 FR
25687 that ‘‘we propose to incorporate
by reference in § 170.299 the latest
annual CMS QRDA IGs’’ and in the
Cures Act Final Rule we stated at 85 FR
25689 that ‘‘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.’’ In
order to align with our proposals and
requirements in the ONC Cures Act
Final Rule, in this IFC, we are adopting
the standards for CMS clinical quality
measure reporting in § 170.205(h)(3) and
§ 170.205(k)(3) to the latest CMS QRDA
standards available at the time of the
ONC Cures Act Final Rule publication
(May 1, 2020), which are included in
the certification criterion at
E:\FR\FM\04NOR1.SGM
04NOR1
70076
Federal Register / Vol. 85, No. 214 / Wednesday, November 4, 2020 / Rules and Regulations
§ 170.315(c)(3). The 2020 CMS QRDA
IGs we are adopting for testing and
certification align with changes CMS
already requires health care providers to
use. We incorporate by reference at
§ 170.299 the CMS QRDA IGs,
specifically the 2020 CMS QRDA I IG
for Hospital Quality Reporting,12 which
published on December 3, 2019, and the
2020 CMS QRDA III IG for Eligible
Clinicians and Eligible Professionals,13
which published on April 30, 2020.
These IGs were available prior to the
publication of the ONC Cures Act Final
Rule, but we erroneously included prior
QRDA IGs. Specifically, in this IFC, we
are adopting the 2020 CMS QRDA
category I for inpatient measures at
§ 170.205(h)(3) and 2020 CMS QRDA
category III for ambulatory measures at
§ 170.205(k)(3). We waive the notice and
comment period for this change as it is
unnecessary, because the change
ensures that the regulations accurately
reflect the policies we proposed, the
public commented on, and that we then
finalized in the ONC Cures Act Final
Rule. We note that CMS programs may
independently require the
implementation and use of the most upto-date CMS QRDA specifications prior
to the December 31, 2022 deadline.
khammond on DSKJM1Z7X2PROD with RULES
6. Multi-Factor Authentication
In § 170.315(d)(13)(ii), we mistakenly
used the word ‘‘identify’’ in the
regulatory text related to multi-factor
authentication (85 FR 25943). We are
correcting § 170.315(d)(13)(ii) by
replacing ‘‘identify’’ with the word
‘‘identity.’’ The correction of
typographic errors does not constitute a
substantive change, and we therefore
find that there is good cause to waive
the notice and comment procedures of
the APA as unnecessary (5 U.S.C.
§ 553(b)(B)).
7. Transmission to Public Health
Agencies—Electronic Case Reporting
We erroneously included a
requirement in the ONC Cures Act Final
Rule that health IT developers certifying
to § 170.315(f)(5) were required to
conform to the HL7 Clinical Document
Architecture standard and companion
guide adopted in § 170.205(a)(4) and (5).
We did not propose this change for
§ 170.315(f)(5) in the ONC Cures Act
Proposed Rule (84 FR 7443 and 7591),
and intended only to finalize a
requirement that health IT developers
certifying to § 170.315(f)(5) are required
to conform to data classes expressed in
12 https://ecqi.healthit.gov/sites/default/files/
QRDA-HQR-2020-CMS-IG-v1.1-508.pdf.
13 https://ecqi.healthit.gov/sites/default/files/
2020-CMS-QRDA-III-Eligible-Clinicians-and-EP-IGv1.2.1-508.pdf.
VerDate Sep<11>2014
16:30 Nov 03, 2020
Jkt 253001
the standards in § 170.213 or the
Common Clinical Data Set for the period
before December 31, 2022 (see 84 FR
7441). Because the application of these
standards would completely change the
certification requirements to the
‘‘electronic case reporting’’ criterion and
impose a significant development
burden for developers, and because the
standards were not proposed, we are
revising the regulation text in
§ 170.315(f)(5) and § 170.405(b)(3) to
correct this clear error. Specifically, we
have removed the words ‘‘and in
accordance with § 170.205(a)(4) and
(5),’’ from § 170.315(f)(5)(iii)(B)(1) and
‘‘in accordance with § 170.205(a)(4)’’
from § 170.315(f)(5)(iii)(B)(2), and
corrected the real world testing
regulation text in § 170.405(b)(3) by
removing the words ‘‘for C–CDA’’ from
the title of the paragraph to
accommodate the corrections to
§ 170.315(f)(5). As these revisions do not
constitute substantive changes to what
we proposed, received comment on, and
intended to finalize, we find good cause
to waive the public notice and comment
procedures of the APA as unnecessary.
8. Conditions and Maintenance of
Certification Requirements for Health IT
Developers
a. Assurances
In § 170.402(a)(4) of the ONC Cures
Act Final Rule, there was a typo: ‘‘heath
IT product’’ (85 FR 25946). We are
correcting the typo ‘‘heath IT product’’
to ‘‘health IT product.’’ The correction
of typographic errors does not constitute
a substantive change, and we, therefore,
find that there is good cause to waive
the notice and commend procedures of
the APA as unnecessary (5 U.S.C.
§ 553(b)(B)).
b. Application Programming
Interfaces—Clarification for Native
Applications and Refresh Tokens
In the ONC Cures Act Final Rule, we
established an approach that required
Health IT Modules to issue refresh
tokens to applications that are ‘‘capable
of storing a client secret’’ (85 FR 25945).
We based our approach on the standards
and implementation specifications we
adopted for the § 170.315(g)(10)
certification criterion. After the
publication of the Cures Act Final Rule,
health IT developers preparing for
testing and certification to the
§ 170.315(g)(10) certification criterion,
as well as third-party application
developers, requested that we clarify
this requirement.
Stakeholders identified that we had
not fully explained how our policy
would apply to ‘‘native applications,’’
PO 00000
Frm 00034
Fmt 4700
Sfmt 4700
which, according to IETF RFC 6749, are
‘‘clients installed and executed on the
device used by the resource owner (i.e.,
desktop application, native mobile
application)’’ and their interactions with
OAuth 2.0 authorization servers.14
These stakeholders noted that a strict
interpretation of the final rule could
exclude native applications that use or
are capable of using additional
technology that make them ‘‘capable of
storing a client secret,’’ or native
applications that are capable of securely
handling a refresh token without
needing a client secret. Consequently,
stakeholders indicated that the technical
ambiguity around native applications
would negatively impact testing and
certification. Further, stakeholders
contended that without timely and
explicit clarifications to native
applications, health IT developers’
support for native applications would
vary widely.
We agree with these concerns and that
timely and additional clarification is
necessary. In our assessment, if such
variation were to occur, it would greatly
affect the types of applications
supported by certified API technology
in the next two years as compliance
timelines come into effect. Moreover,
such a result would be contrary to the
public interest because it would
contradict the intent of the Cures Act
and our implementation of the API
Condition of Certification, would
negatively impact market competition,
and would especially disadvantage and
limit patients’ ability to access their
electronic health information without
special effort. In the ONC Cures Act
Proposed Rule (84 FR 7481), we stated,
‘‘The SMART Guide specifies the use of
‘refresh tokens’ as optional. We believe
that this requirement is necessary in
order to enable persistent access by
apps, especially in a patient access
context. Thus, we propose to make their
use mandatory with a minimum refresh
token life of three months . . . we wish
to emphasize that implementing refresh
token support is directly intended to
enable a patient’s ‘persistent access’ to
their electronic health information
without special effort (i.e., without
having to frequently re-authenticate and
re-authorize while using their preferred
app).’’ Recognizing that patients will
largely use smartphone applications
(native applications) to access their
health information, we would
substantially limit patients’ ability to
access their electronic health
information without special effort if
native applications were categorically
14 IETF RFC 6749: https://tools.ietf.org/html/
rfc6749.
E:\FR\FM\04NOR1.SGM
04NOR1
Federal Register / Vol. 85, No. 214 / Wednesday, November 4, 2020 / Rules and Regulations
khammond on DSKJM1Z7X2PROD with RULES
excluded from enabling ‘‘persistent
access.’’ By making this clarification
and revising the regulation text, we are
ensuring that the regulation best
matches the policies commented on and
then finalized in the ONC Cures Act
Final Rule. For these reasons, we find
good cause to waive the notice and
comment procedures of the APA as
contrary to the public interest and
unnecessary (5 U.S.C. 553(b)(B)).
Based on our analysis of the
applicable standards and industry
practices,15 including the HL7® SMART
Application Launch Framework
Implementation Guide Release 1.0.0
(SMART IG) (adopted in
§ 170.215(a)(3)), we identified that it is
possible for native applications to use
secure storage capabilities and
technologies on mobile platforms to
secure a refresh token, a client secret, or
both. Indeed, section 3.0.1 of the
SMART IG provides examples of native
applications that can meet either the
‘‘confidential app profile’’ or the
‘‘public app profile.’’ Examples of
technologies native applications can use
to secure a refresh token, a client secret,
or both include operating systemspecific features to register applicationclaimed, private-use Uniform Resource
Identifier (URI) schemes as OAuth 2.0
redirect URIs,16 and technologies that
enable applications to securely store
credentials through on-device storage.17
15 RFC 6749 (https://tools.ietf.org/html/rfc6749)
describes native applications as ‘‘clients installed
and executed on the device used by the resource
owner (i.e., desktop applications, and native mobile
applications).’’ IETF RFC 8252 (https://
tools.ietf.org/html/rfc8252), referenced by the HL7®
SMART Application Launch Framework
Implementation Guide Release 1.0.0 (SMART IG)
(adopted in § 170.215(a)(3)), updates RFC 6749 and
provides guidance for OAuth 2.0 authorization
requests from native applications. RFC 8252
describes technology and security practices that can
be used to enable native applications to securely
authenticate their identity and prevent welldocumented security threats. Notable examples
include Dynamic Client Registration Protocol (IETF
RFC 7591) (https://tools.ietf.org/html/rfc7591) to
enable native applications to receive per-instance
client secrets, private-use URI scheme redirect URIs
to support native apps to verify their identity, and
Proof Key for Code Exchange (PKCE) (IETF RFC
7636) (https://tools.ietf.org/html/rfc7636) to secure
the authorization code during the authorization
process.
16 For example, Android makes available ‘‘App
Links’’ (https://developer.android.com/training/
app-links) and iOS makes available ‘‘Universal
Links,’’ (https://developer.apple.com/
documentation/xcode/allowing_apps_and_
websites_to_link_to_your_content) which
applications can use to register application-claimed,
private URI schemes as OAuth 2.0 redirect URIs.
17 For example, Android enables third-party
application developers to use technologies like the
‘‘Keystore’’ (https://developer.android.com/
training/articles/keystore.html) for secure storage
on supported devices, and newer Apple devices
contain a ‘‘Secure Enclave’’ (https://
developer.apple.com/documentation/security/
VerDate Sep<11>2014
16:30 Nov 03, 2020
Jkt 253001
In response to these concerns, we
have clarified and made the regulation
text consistent by adding a new
paragraph in
§ 170.315(g)(10)(v)(A)(1)(iii) and
revising paragraphs
§ 170.315(g)(10)(v)(A)(1)(ii) and
§ 170.315(g)(10)(v)(A)(2)(ii). In the new
paragraph in
§ 170.315(g)(10)(v)(A)(1)(iii), we have
specified that Health IT Modules’
authorization servers must issue a
refresh token to native applications that
are capable of securing a refresh token.
In § 170.315(g)(10)(v)(A)(1)(ii) and
§ 170.315(g)(10)(v)(A)(2)(ii), we have
updated the regulation text to be
consistent with the paragraph we have
added in § 170.315(g)(10)(v)(A)(1)(iii) by
specifying that a ‘‘Health IT Module’s
authorization server’’ must issue a
refresh token to applications that are
capable of storing a client secret. And in
§ 170.315(g)(10)(v)(A)(2)(ii) we have
updated the regulation text by removing
the word ‘‘new’’ preceding ‘‘refresh
token’’. These updates make the
certification criterion clear and
consistent, and disambiguate the
implications for native applications.
The requirement we have finalized in
§ 170.315(g)(10)(v)(A)(1)(iii) addresses
the technical ambiguity regarding native
applications that we discussed
previously and clarifies that Health IT
Modules must support the issuance of
an initial refresh token to native
applications that are capable of securing
a refresh token. As part of the
requirements in
§ 170.315(g)(10)(v)(A)(1)(iii), health IT
developers must publish the method(s)
by which their Health IT Modules
support the secure issuance of an initial
refresh token to native applications
according to the technical
documentation requirements in
§ 170.315(g)(10)(viii) and transparency
conditions in § 170.404(a)(2).
Additionally, application developer
attestations to health IT developers
regarding the ability of their
applications to secure a refresh token, a
client secret, or both, must be treated in
a good faith manner consistent with the
provisions established in the openness
and pro-competitive conditions in
§ 170.404(a)(4).
We emphasize that health IT
developers can determine the method(s)
they use to support interactions with
native applications and we clarify that
health IT developers are not required to
support all methods that third-party
certificate_key_and_trust_services/keys/storing_
keys_in_the_secure_enclave) within their
processors, which third-party application
developers can use for secure storage.
PO 00000
Frm 00035
Fmt 4700
Sfmt 4700
70077
application developers seek to use.
Moreover, while we have not specified
that health IT developers use a
standards-based approach with respect
to interactions with native applications,
we encourage the industry to coalesce
around a single set of requirements
across all health IT developers.
In order to support the ability of endusers to persistently access health
information, we required in the ONC
Cures Act Final Rule in
§ 170.315(g)(10)(v)(A)(2)(ii) that for
subsequent connections, ‘‘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.’’ According to
stakeholder feedback, the double use of
‘‘new’’ in the regulation text has caused
confusion and unintended overinterpretation of the regulation text. As
a result, we have removed the first
‘‘new’’ preceding ‘‘refresh token,’’ and
clarify that the remaining ‘‘new’’ applies
to the extended or renewed duration of
the ‘‘refreshed’’ refresh token. The
additional revisions we have made in
§ 170.315(g)(10)(v)(A)(2)(ii) are simply
stylistic changes to match the language
in our revisions in
§ 170.315(g)(10)(v)(A)(1)(ii) and
§ 170.315(g)(10)(v)(A)(1)(iii). Such
corrections are not substantive,
therefore, we find good cause to waive
the notice and comment procedures of
the APA as unnecessary (5 U.S.C.
553(b)(B)).
Additionally, we clarify that the
paragraph focused on ‘‘First time
connections’’ in
§ 170.315(g)(10)(v)(A)(1) and the
paragraph focused on ‘‘Subsequent
connections’’ in
§ 170.315(g)(10)(v)(A)(2) are aligned and
that our policy for subsequent
connections remains unchanged. That
is, Health IT Modules must issue a
refresh token that is valid for a new
period of no less than three months to
only applications that are capable of
storing a client secret. While the new
paragraph in
§ 170.315(g)(10)(v)(A)(1)(iii) requires
Health IT Modules to issue an initial
refresh token to native applications,
Health IT Modules may require native
applications that can secure a refresh
token without a client secret to reauthenticate and re-authorize after the
initial refresh token expires. As this is
a clarification and not a substantive
correction, we find good cause to waive
the notice and comment procedures of
the APA as unnecessary (5 U.S.C.
553(b)(B)).
E:\FR\FM\04NOR1.SGM
04NOR1
70078
Federal Register / Vol. 85, No. 214 / Wednesday, November 4, 2020 / Rules and Regulations
9. Principles of Proper Conduct for
ONC–ACBs
In the ONC Cures Act Final Rule, we
discussed removing § 170.523(k)(2) (85
FR 25663). In the regulatory text, we
removed § 170.523(k)(2) to further
reduce administrative burden for health
IT developers and ONC–ACBs, and
included the instructions to do so (85
FR 25951). Because we removed
§ 170.523(k)(2), the requirement in
§ 170.523(f)(1)(xxi) that the ONC–ACB
include the attestation from that section
in its certified product listing should
also have been removed. We
inadvertently omitted that removal from
the amendatory instructions for
§ 170.523(f) (85 FR 25950). We are
correcting the error by removing the
requirement in § 170.523(f)(1)(xxi)
because the Principles of Proper
Conduct for ONC–ACBs should
accurately reflect the policies we
proposed, the public commented on,
and that we then finalized in the ONC
Cures Act Final Rule. Further, because
the remnant has no meaning in the
absence of the other provision, and can
impose no benefit or obligation, the
correction of such errors does not
constitute a substantive change. As
such, we therefore find that there is
good cause to waive the notice and
comment procedures of the APA as
unnecessary (5 U.S.C. § 553(b)(B)).
Additionally in the ONC Cures Act
Final Rule, in the amendatory
instructions for § 170.523, we instructed
in step h that the phrase ‘‘Complete EHR
or’’ be removed from paragraph (k)(1),
but the phrase specifically appeared in
(k)(1)(i) (85 FR 25950). We corrected the
error and removed the phrase
‘‘Complete EHR or’’ from
§ 170.523(k)(1)(i) in this IFC. Section
170.523(k)(1)(i) is also further revised to
remove the brackets before ‘‘Complete
EHR or’’ and after ‘‘Health IT Module’’
(85 FR 25950). We have made this
correction. The correction of
typographic errors does not constitute a
substantive change, and we therefore
find that there is good cause to waive
the notice and comment procedures of
the APA as unnecessary (5 U.S.C.
553(b)(B)).
khammond on DSKJM1Z7X2PROD with RULES
10. Applicability of the Information
Blocking Provisions
In the ONC Cures Act Final Rule
preamble, we inadvertently stated that
health care providers, health IT
developers of certified health IT, health
information exchanges, and health
information networks ‘‘must comply’’
with 45 CFR part 171 by a particular
date (85 FR 25793). We unintentionally
used the same language in the
VerDate Sep<11>2014
16:30 Nov 03, 2020
Jkt 253001
regulation text § 171.101(b) (85 FR
25955). Because part 171 defines
information blocking and provides a
series of voluntary exceptions to that
definition, it is more precise to say such
actors ‘‘are subject to’’ this part. We
corrected § 171.101(b) to replace ‘‘must
comply’’ with ‘‘are subject to.’’ Because
this is primarily a correction to an
inadvertent use of language, and not a
substantive change, we, therefore, find
that there is good cause to waive the
notice and comment procedures and
delayed effective date requirements of
the APA as unnecessary (5 U.S.C.
553(b)(B), (d)(3)). Further, even if this
constituted a substantive change, for the
reasons we stated previously in this
section II.C, we find good cause to
waive the notice and comment
rulemaking process and delayed
effective date for this correction,
because these requirements would be
impracticable and contrary to the public
interest.
11. Information Blocking Definition and
Security Exception
In the 21st Century Cures Act:
Interoperability, Information Blocking,
and the ONC Health IT Certification
Program Proposed Rule (Proposed Rule),
we considered a definition of
information blocking that included
actions that ‘‘interfere with, prevent or
materially discourage’’ access, exchange
or use of EHI, but ultimately we
proposed that the term ‘‘interfere with’’
was already inclusive of ‘‘prevent’’ and
‘‘materially discourage’’ (84 FR 7516).
Similarly, in the preamble to the ONC
Cures Act Final Rule, in discussing the
information blocking definition, we
determined that the terms ‘‘interfere
with’’ and ‘‘interference’’ are themselves
inclusive of both prevention and
material discouragement of access,
exchange or use of EHI (85 FR 25809).
Further, in § 171.102, we defined
‘‘Interfere with or interference’’ to
include both ‘‘prevent’’ and ‘‘materially
discourage’’ (85 FR 25956). The
definition of information blocking in
§ 171.103, therefore, should not include
‘‘prevent, or materially discourage.’’ It is
redundant and could confuse
stakeholders who read and commented
on the Proposed Rule and read in the
preamble of the ONC Cures Act Final
Rule that ‘‘interfere with’’ is inclusive of
those terms. We also failed to remove
the words from the regulatory text for
the ‘‘Security exception’’ in
§ 171.203(e)(2). Therefore, we have
corrected the definition of ‘‘information
blocking’’ in § 171.103 by removing the
redundant phrase ‘‘prevent, or
materially discourage’’ in two
instances—§ 171.103(a)(2) and (a)(3) (85
PO 00000
Frm 00036
Fmt 4700
Sfmt 4700
FR 25956). Further, in order to eliminate
the same redundancy and to promote
clarity, we have corrected
§ 171.203(e)(2) by removing the phrase
‘‘prevent, or materially discourage’’ (85
FR 25958). These corrections are
necessary to ensure the policies we
discussed in the Proposed Rule and
finalized in the preamble of the ONC
Cures Act Final Rule are accurately and
clearly reflected in the regulatory
framework we established. This
correction imposes no further burden or
obligation on any party, and does not
constitute a substantive change. For
these reasons, we find good cause to
waive the notice and comment
procedures and delayed effective date
requirements of the APA as unnecessary
(5 U.S.C. 553(b)(B), (d)(3)).
When defining the actors to whom the
definition of information blocking
would apply in the ONC Cures Act
Final Rule, we finalized a policy to use
the term ‘‘health IT developer of
certified health IT.’’ In doing so, we
considered the many comments we
received in response to our proposed
definition for that specific term in the
Proposed Rule. We extensively
discussed the term ‘‘health IT developer
of certified health IT,’’ as well as the
comments we received regarding the
proposed term and definition, in the
preamble of the ONC Cures Act Final
Rule (85 FR 25795 through 25797). We
finalized the definition of the term
‘‘health IT developer of certified health
IT’’ itself, in § 171.102 (85 FR 25956).
We referred to ‘‘health IT developers of
certified health IT’’ in 45 CFR
171.101(a) and (b) in stating the
applicability of 45 CFR part 171. Thus,
we made clear our explicit intent that
the definition of information blocking
would only apply to developers of
certified health IT, not all health IT
developers.
In the definition of information
blocking itself in § 171.103, however,
we erroneously used only the term
‘‘health IT developer’’ and omitted the
rest of the phrase (‘‘of certified health
IT’’). We proposed, received comment
on, discussed and finalized specific
policies in regards to the regulatory
definition of information blocking and
the meaning of ‘‘health IT developer’’
found in the statutory information
blocking definition. We finalized the
policy for the narrower definition
‘‘health IT developer of certified health
IT’’ based on comments we received and
for reasons we extensively discussed in
the preamble of the ONC Cures Act
Final Rule. Therefore, we have corrected
§ 171.103(a)(2) to include the full phrase
‘‘health IT developer of certified health
IT.’’ By erroneously omitting the full
E:\FR\FM\04NOR1.SGM
04NOR1
Federal Register / Vol. 85, No. 214 / Wednesday, November 4, 2020 / Rules and Regulations
khammond on DSKJM1Z7X2PROD with RULES
phrase, the regulation could have
caused confusion and been read as
creating a burden on all developers of
health IT, an expansion we explicitly
decided not to include in the ONC
Cures Act Final Rule. For the reasons
we stated previously in this section II.C;
and because this error does not correctly
reflect any policy proposed, commented
on, or finalized; and because it could be
read to impose an immediate,
unnecessary burden on a large number
of entities without notice, we find good
cause to waive the notice and comment
rulemaking process and delayed
effective date requirements of the APA
as unnecessary (5 U.S.C. 553(b)(B),
(d)(3)).
effective date requirements of the APA
as unnecessary (5 U.S.C. 553(b)(B),
(d)(3)).
12. Content and Manner Exception
In the ONC Cures Act Final Rule, we
discussed the manner in which actors
must fulfill a request to access,
exchange or use EHI. The action is best
characterized as ‘‘fulfilling a request,’’
which is how we described it
throughout the ONC Cures Act Final
Rule, except for one instance in the
preamble when we erroneously used the
word ‘‘response’’ instead (85 FR 25877).
For the purpose of consistency, we
clarify that when an actor fulfills a
request in any manner requested, any
fees charged by the actor in relation to
fulfilling the request are not required to
satisfy the Fees Exception in § 171.302.
We also made an error in the regulation
text in § 171.301(b)(1)(ii)(A), where we
inadvertently referred to an actor’s
practice of fulfilling a request for EHI as
‘‘fulfilling a response’’ which is
incorrect and an obvious error (85 FR
25959). Therefore, we have corrected
this phrase to read ‘‘fulfilling a request.’’
In addition, we clarify a typographical
error in the ONC Cures Act Final Rule
preamble. At 85 FR 25877, we
erroneously refer to § 171.301(b)(2)(i)(a);
the correct citation has a capitalized (A)
instead of lowercase (a).
The correction of these typographic
errors does not constitute a substantive
change, and we, therefore, find that
there is good cause to waive the notice
and comment procedures and delayed
effective date requirements of the APA
as unnecessary (5 U.S.C. 553(b)(B),
(d)(3)).
III. Waiver of Proposed Rulemaking,
Comment Period, and Delay in Effective
Date
Under the Administrative Procedure
Act (APA), 5 U.S.C. 553(b), an agency is
required to publish a notice of proposed
rulemaking in the Federal Register
before the provisions of a rule take
effect. In addition, § 553(d) mandates a
30-day delay in effective date after
issuance or publication of a rule.
Sections 553(b)(B) and 553(d)(3) provide
for exceptions from the notice and
comment and delay in effective date
requirements. Section 553(b)(B)
authorizes an agency to dispense with
normal rulemaking requirements when
the agency for good cause finds that the
notice and comment processes are
impracticable, unnecessary, or contrary
to the public interest. In addition,
§ 553(d)(3) allows the agency to waive
the 30-day delay in effective date for
‘‘otherwise provided by the agency for
good cause found and published with
the rule.’’
The nation is experiencing an
emergency of unprecedented
magnitude. This IFC directly supports
that goal by offering regulated
individuals and entities flexibilities in
complying with the ONC Cures Act
Final Rule while they are combating the
COVID–19 pandemic. The IFC also
helps to ensure that sufficient health IT
products and services are available to
meet the needs of affected health care
systems, health care providers, and
individuals.
On January 30, 2020, the International
Health Regulations Emergency
Committee of the WHO declared the
outbreak of COVID–19 to be a Public
Health Emergency of International
Concern.18 On January 31, 2020,
Secretary Azar declared a PHE 19 under
section 319 of the Public Health Service
Act (42 U.S.C. 247d), in response to
COVID–19. On March 11, 2020, the
WHO publicly declared COVID–19 to be
a pandemic.20 On March 13, 2020, the
President declared that the COVID–19
outbreak in the United States constitutes
a national emergency,21 beginning
13. Licensing Exception
In § 171.303(b)(2)(i), we erroneously
cross-referenced paragraph (c)(3) instead
of the correct paragraph, (b)(3) (85 FR
25960). We have corrected the error.
The correction of typographic errors
does not constitute a substantive
change, and we therefore find that there
is good cause to waive the notice and
comment procedures and delayed
18 https://www.who.int/news-room/detail/30-012020-statement-on-the-second-meeting-of-theinternational-health-regulations-(2005)-emergencycommittee-regarding-the-outbreak-of-novelcoronavirus-(2019-ncov).
19 https://www.phe.gov/emergency/news/
healthactions/phe/Pages/2019-nCoV.aspx.
20 https://www.who.int/dg/speeches/detail/whodirector-general-s-opening-remarks-at-the-mediabriefing-on-covid-19-11-march-2020.
21 https://www.whitehouse.gov/presidentialactions/proclamation-declaring-national-
VerDate Sep<11>2014
16:30 Nov 03, 2020
Jkt 253001
PO 00000
Frm 00037
Fmt 4700
Sfmt 4700
70079
March 1, 2020. Effective October 23,
2020, Secretary Azar renewed the
January 31, 2020 determination that was
previously renewed on April 21, 2020
and July 23, 2020 that a PHE for
COVID–19 exists and has existed since
January 27, 2020.
As we discussed in section II.A above,
it is critical that we extend our support
to the health care community,
specifically those who are affected by
the ONC Cures Act Final Rule. In
support of the imperative to contain and
combat the virus in the United States,
developers of health technology have
raced to update their technology, for
example, to create new codes for
COVID–19 and its associated illnesses.
Many developers are working to ensure
that critical data about infection rates,
testing outcomes, and hospitalization
rates are accurate and are transmitted
accurately to local, State and Federal
authorities. Further, health IT
developers of certified health IT are
responding to requests from public
health entities, health care providers,
and health care systems, asking for
updates to, or information about, the
technology to help them better track,
respond and treat illnesses caused by
COVID–19. Developers of certified
health IT are also exploring novel
methods to help address the PHE using
time and resources that might otherwise
have been used to upgrade their
technology. It is in the best interest of
the public to ensure that developers of
certified health IT are able to respond in
a dynamic and rapid manner in order to
assist the nation in confronting the PHE.
If these developers of certified health
IT were required to update their
technology according to the timeline
and deadlines in the ONC Cures Act
Final Rule, they would likely devote
more time and resources to ensuring
their technology was upgraded and
certified to avoid losing customers and
users. In doing so, they would have less
time and fewer resources to address the
urgent and constantly changing
technological needs of health care
providers, public health entities, and
health care systems dealing with the
COVID–19 PHE. Further, even if the
developers of certified health IT were
able to upgrade their technology to the
2015 Edition Cures Update by the
original compliance dates, their
customers may require training and time
to adapt to the new technology. This is
especially true for health care providers,
who may not have control over updates
to the technology used in their care
settings. It is in the best interest of the
emergency-concerning-novel-coronavirus-diseasecovid-19-outbreak/.
E:\FR\FM\04NOR1.SGM
04NOR1
70080
Federal Register / Vol. 85, No. 214 / Wednesday, November 4, 2020 / Rules and Regulations
khammond on DSKJM1Z7X2PROD with RULES
public that health care providers are
able to combat COVID–19 PHE without
also having to manage the potential
disruption that such updates at this time
could entail. Delaying the enforcement
deadlines and extending certain
timelines ensures that the technology
will be updated at a time when the
threat from the PHE has lessened and
both developers and health care
providers would have the time and
resources to devote to these technology
updates.
It is imperative that the health care
community, including developers of
certified health IT, remain focused on
addressing the grave threat to public
health posed by COVID–19. Therefore,
we find good cause to waive notice and
comment rulemaking as we believe it
would be impracticable and contrary to
the public interest for us to undertake
normal notice and comment rulemaking
procedures. Furthermore, because we
cannot afford any delay in effectuating
this IFC and do not want to create
unnecessary burdens on stakeholders
who would otherwise try to meet the
November 2, 2020 compliance and
applicability date for various provisions
of the ONC Cures Act Final Rule, we
find good cause to waive the 30-day
delayed effective date for the
information blocking provisions and the
Conditions and Maintenance of
Certification requirements related to
information blocking, communications,
and assurances.
We are providing a 60-day public
comment period for this IFC as specified
in the DATES section of this document.
IV. Incorporation by Reference
The Office of the Federal Register has
established requirements for materials
(e.g., standards and implementation
specifications) that agencies incorporate
by reference in the Code of Federal
Regulations (79 FR 66267; 1 CFR 51.5).
Specifically, § 51.5(b) requires agencies
to discuss, in the preamble of a final
rule, the ways that the materials they
incorporate by reference are reasonably
available to interested parties and how
interested parties can obtain the
materials, and to summarize, in the
preamble of the final rule, the material
they incorporate by reference.
To make the materials we are
incorporating by reference reasonably
available, we provide a uniform
resource locator (URL) for the standards.
These standards are directly accessible
through the URLs provided. As an
alternative, a copy of the standards may
be viewed for free at the U.S.
Department of Health and Human
Services, Office of the National
Coordinator for Health Information
VerDate Sep<11>2014
16:30 Nov 03, 2020
Jkt 253001
Technology, 330 C Street SW,
Washington, DC 20201. Please call (202)
690–7151 in advance to arrange
inspection.
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 require the use of,
wherever practical, technical standards
that are developed or adopted by
voluntary consensus standards bodies to
carry out policy objectives or activities,
with certain exceptions. The NTTAA
and OMB Circular A–119 provide
exceptions to selecting only standards
developed or adopted by voluntary
consensus standards bodies, namely
when doing so would be inconsistent
with applicable law or otherwise
impractical. As stated in the ONC Cures
Final Rule (85 FR 25668), we have
followed the NTTAA and OMB Circular
A–119 in adopting standards and
implementation specifications for
adoption, including describing any
exceptions in the adoption of standards
and implementation specifications.
As required by 1 CFR 51.5(b), we
provide a summary of the standards we
have adopted and incorporate by
reference in the Code of Federal
Regulations (CFR). We also provide
relevant information about the
standards throughout the preamble. We
previously adopted IETF’s Network
Time Protocol Version 4 (approved for
incorporation by reference as of
September 4, 2012), which we continue
to use without change.
We have organized the standards we
have adopted through this rulemaking
according to the sections of the CFR in
which they will be codified and crossreferenced for associated certification
criteria and requirements that we have
adopted.
Content Exchange Standards and
Implementation Specifications for
Exchanging Electronic Health
Information—45 CFR 170.205
• CMS Implementation Guide for
Quality Reporting Document
Architecture Category I Hospital
Quality Reporting Implementation
Guide for 2020, December 3, 2019
URL: https://ecqi.healthit.gov/sites/
default/files/QRDA-HQR-2020-CMS-IGv1.1-508.pdf.
This is a direct access link.
Summary: This guide is a CMS
Quality Reporting Document
Architecture Category I (QRDA I)
implementation guide to the HL7
Implementation Guide for CDA Release
2: Quality Reporting Document
Architecture Category I, Release 1,
Standards for Trial Use (STU) Release 5
PO 00000
Frm 00038
Fmt 4700
Sfmt 4700
(published December 2017), and
referred to as the HL7 QRDA IG STU R5
in this guide. This guide describes
additional conformance statements and
constraints for electronic health record
(EHR) data submissions that are
required for reporting information to the
CMS for the Hospital Inpatient Quality
Reporting Program 2020 Reporting
Period. The purpose of this guide is to
serve as a companion to the base HL7
QRDA I STU R5 for entities such as
Eligible Hospitals (EHs), CAHs, and
developers to submit QRDA I data for
consumption by CMS systems including
for Hospital Quality Reporting (HQR).
• CMS Implementation Guide for
Quality Reporting Document
Architecture: Category III; Eligible
Clinicians and Eligible Professionals
Programs; Implementation Guide for
2020, April 30, 2020
URL: https://ecqi.healthit.gov/sites/
default/files/2020-CMS-QRDA-IIIEligible-Clinicians-and-EP-IG-v1.2508.pdf.
This is a direct access link.
Summary: The Health Level Seven
International (HL7) Quality Reporting
Document Architecture (QRDA) defines
constraints on the HL7 Clinical
Document Architecture Release 2 (CDA
R2). QRDA is a standard document
format for the exchange of electronic
clinical quality measure (eCQM) data.
QRDA reports contain data extracted
from EHRs and other information
technology systems. The reports are
used for the exchange of eCQM data
between systems for quality
measurement and reporting programs.
This QRDA guide contains the CMS
supplemental implementation guide to
the HL7 Implementation Guide for CDA
Release 2: Quality Reporting Document
Architecture, Category III, STU Release
2.1 (June, 2017) for the 2020
performance period. This HL7 base
standard is referred to as the HL7
QRDA–III STU R2.1.
United States Core Data for
Interoperability—45 CFR 170.213
• The United States Core Data for
Interoperability (USCDI), July 2020
Errata, Version 1 (v1)
URL: https://www.healthit.gov/
USCDI.
This is a direct access link.
Summary: The United States Core
Data for Interoperability (USCDI)
establishes a minimum set of data
classes that are required to be
interoperable nationwide and is
designed to be expanded in an iterative
and predictable way over time. Data
classes listed in the USCDI are
E:\FR\FM\04NOR1.SGM
04NOR1
Federal Register / Vol. 85, No. 214 / Wednesday, November 4, 2020 / Rules and Regulations
represented in a technically agnostic
manner.
Application Programming Interface
Standards—45 CFR 170.215
• HL7 FHIR US Core Implementation
Guide STU Release 3.1.1, August 28,
2020
URL: https://hl7.org/fhir/us/core/
STU3.1.1/.
This is a direct access link.
Summary: The US Core
Implementation Guide is based on FHIR
Version R4 and defines the minimum
conformance requirements for accessing
patient data. The Argonaut pilot
implementations, ONC 2015 Edition
Common Clinical Data Set (CCDS), and
ONC U.S. Core Data for Interoperability
(USCDI) v1 provided the requirements
for this guide. The prior Argonaut
search and vocabulary requirements,
based on FHIR DSTU2, are updated in
this guide to support FHIR Version R4.
This guide was used as the basis for
further testing and guidance by the
Argonaut Project Team to provide
additional content and guidance
specific to Data Query Access for
purpose of ONC Certification testing.
These profiles are the foundation for
future US Realm FHIR implementation
guides. In addition to Argonaut, they are
used by DAF-Research, QI-Core, and
CIMI. Under the guidance of HL7 and
the HL7 US Realm Steering Committee,
the content will expand in future
versions to meet the needs specific to
the US Realm.
V. Response to Comments
Because of the large number of public
comments we normally receive on
Federal Register documents, we are not
able to acknowledge or respond to them
individually. We will consider all
comments we receive by the date and
time specified in the DATES section of
this preamble, and, when we proceed
with a subsequent document, we will
respond to the comments in the
preamble to that document.
khammond on DSKJM1Z7X2PROD with RULES
VI. Collection of Information
Requirements
This document does not impose
information collection and
recordkeeping requirements.
Consequently, it need not be reviewed
by the Office of Management and
Budget under the authority of the
Paperwork Reduction Act of 1995 (44
U.S.C. 3501–3521).
VII. Regulatory Impact Analysis
A. Executive Orders 12866 and 13563
Executive Orders 12866 and 13563
direct agencies to assess all costs and
VerDate Sep<11>2014
16:30 Nov 03, 2020
Jkt 253001
benefits of available regulatory
alternatives and, if regulation is
necessary, to select regulatory
approaches that maximize net benefits
(including potential economic,
environmental, and public health and
safety effects; distributive impacts; and
equity). A regulatory impact analysis
(RIA) must be prepared for major rules
with economically significant effects
($100 million or more in any 1 year).
To determine the impact of this rule,
we reviewed the costs and benefits in
the ONC Cures Act Final Rule
associated with the provisions in this
IFC. We did this to determine if
adjustments to the ONC Cures Act Final
Rule’s RIA were needed and should be
accounted for in this rule. We also
explored whether there are new
quantifiable and unquantifiable costs
and benefits as a direct result of the
delays proposed in the IFC.
The provisions in this IFC are limited
in nature: Applicability and compliance
date extensions, standards updates, and
regulatory clarifications and corrections.
Except as noted below, we were unable
to identify any new quantifiable costs or
benefits as a result of the provisions in
this IFC. However, we welcome
comments on the additional impacts
developers or other entities might
experience as a result of the delays
noted in this IFC.
There are unquantifiable costs and
benefits of this rule. The extensions in
this IFC are in response to developers’
need for additional time to meet the
deadlines due, in part, to external
factors, such as COVID–19. However,
we are unable to quantify the extent to
which such external factors including
but not limited to, temporary changes in
labor and other supply chain costs/
shortages due to the pandemic—would
affect the cost differential between
compliance according to the timeline set
forth in this IFC and (hypothetically)
according to the timeline set forth in the
ONC Cures Act Final Rule. We
acknowledge that we do not have any
evidence or information from the
regulated community that they have
been working to meet the applicability
and compliance dates identified in the
ONC Cures Act Final Rule. On April 21,
2020, we announced that we would
exercise our discretion in enforcing all
new requirements under 45 CFR part
170 that have compliance dates until 3
months after each initial compliance
date identified in the ONC Cures Act
Final Rule. In addition, we noted in the
ONC Cures Act Final Rule that
enforcement of information blocking
civil monetary penalties in section
3022(b)(2)(A) of the PHSA would not
begin until a final rule was issued by the
PO 00000
Frm 00039
Fmt 4700
Sfmt 4700
70081
Office of the Inspector General (OIG),
which has not occurred as of the
publication of this interim final rule. We
also acknowledged in the Proposed Rule
that any health care provider
determined by OIG to have committed
information blocking would, per the
Cures Act, be referred to the appropriate
agency to be subject to appropriate
disincentives using authorities under
applicable Federal law, as the Secretary
sets forth through notice and comment
rulemaking. In the Proposed Rule, we
requested comment on potential
disincentives (84 FR 7553). HHS has
not, however, issued a proposed rule to
begin the process of establishing such
disincentives. Since the publication of
the ONC Cures Act Final Rule, we are
not aware of any negative consequences
that health IT developers of certified
health IT or other types of actors have
experienced for not complying with 45
parts 170 or 171, respectively. We
request comment on whether
stakeholders did incur costs for trying to
meet the compliance dates in the ONC
Cures Act Final Rule. We also invite
feedback on whether the COVID–19
PHE may have an impact on costs of
complying with 45 parts 170 and 171 in
the future—taking into account the new
compliance and applicability dates
established by this interim final rule.
Additionally, we explored whether
the delays in the IFC will have a
significant impact on the 10 year cost/
benefit projections described in the
ONC Cures Act Final Rule. We note that
several IFC provisions implement a
delay of less than one year from its
original deadline. However, the
following IFC provisions have delays
that are one year or more:
Æ Submission of initial Attestations
(§ 170.406)
Æ Submission of initial plans and
results of real world testing
(§ 170.405(b)(1) and (2))
We previously estimated that the Year 1
quantifiable costs for these provisions
are $47,686,943 and the quantifiable
benefits are $310,450,000. Both the cost
and benefit estimates were estimated to
be perpetual. Because this impact is
over $100 million, it is sufficient to
make this IFC economically significant
under E.O. 12866. The IFC’s changes
have implications for the distribution of
the costs and benefits over time found
in the ONC Cures Act Final Rule as
described above.
B. Regulatory Flexibility Act
The Regulatory Flexibility Act (RFA)
requires agencies to analyze options for
regulatory relief of small businesses if a
rule has a significant impact on a
E:\FR\FM\04NOR1.SGM
04NOR1
70082
Federal Register / Vol. 85, No. 214 / Wednesday, November 4, 2020 / Rules and Regulations
substantial number of small entities. We
do not believe that the changes in this
IFC alter any of the prior analyses we
performed for the ONC Cures Act Final
Rule; and therefore, the Secretary
certifies that this IFC will not have a
significant impact on a substantial
number of small entities.
C. Executive Order 13771
The White House issued Executive
Order 13771 on Reducing Regulation
and Controlling Regulatory Costs on
January 30, 2017. This rule’s
designation under 13771 will be
informed by comments received.
D. Executive Order 13132—Federalism
Executive Order 13132 establishes
certain requirements that an agency
must meet when it promulgates a final
rule (including an interim final rule
with comment period) that imposes
substantial direct requirement costs on
state and local governments, preempts
state law, or otherwise has federalism
implications. Because this IFC does not
impose any costs on state or local
governments, the requirements of
Executive Order 13132 are not
applicable.
E. Unfunded Mandates Reform Act
Section 202 of the Unfunded
Mandates Reform Act of 1995
(Unfunded Mandates Act), 2 U.S.C.
1532, requires that covered agencies
prepare a budgetary impact statement
before promulgating a rule that includes
any federal mandate that may result in
the expenditure by state, local, and
tribal governments, in the aggregate, or
by the private sector, of $100 million in
1995 dollars, updated annually for
inflation. Currently, that threshold is
approximately $156 million. If a
budgetary impact statement is required,
section 205 of the Unfunded Mandates
Act also requires covered agencies to
identify and consider a reasonable
number of regulatory alternatives before
promulgating a rule. This IFC is not
expected to result in expenditures by
state, local, and tribal governments, or
by the private sector, of $156 million or
more in any one year.
khammond on DSKJM1Z7X2PROD with RULES
List of Subjects
45 CFR Part 170
Computer technology, Electronic
health record, Electronic information
system, Electronic transactions, Health,
Health care, Health information
technology, Health insurance, Health
records, Hospitals, Incorporation by
reference, Laboratories, Medicaid,
Medicare, Privacy, Reporting and
recordkeeping requirements, Public
health, Security.
VerDate Sep<11>2014
16:30 Nov 03, 2020
Jkt 253001
45 CFR Part 171
Computer technology, Electronic
health record, Electronic information
system, Electronic transactions, Health,
Health care, Health care provider,
Health information exchange, Health
information technology, Health
information network, Health insurance,
Health records, Hospitals, Privacy,
Reporting and recordkeeping
requirements, Public health, Security.
For the reasons set forth in the
preamble, 45 CFR subtitle A, subchapter
D, is amended as follows:
PART 170—HEALTH INFORMATION
TECHNOLOGY STANDARDS,
IMPLEMENTATION SPECIFICATIONS,
AND CERTIFICATION CRITERIA AND
CERTIFICATION PROGRAMS FOR
HEALTH INFORMATION
TECHNOLOGY
1. The authority citation for part 170
continues to read as follows:
■
Authority: 42 U.S.C. 300jj–11; 42 U.S.C
300jj–14
■
2. Revise § 170.101 to read as follows:
§ 170.101
Applicability.
The standards, implementation
specifications, and certification criteria
adopted in this part apply to health
information technology and the testing
and certification of Health IT Modules.
■ 3. Amend § 170.102 by revising
paragraphs (3)(ii) and (iii) in the
definition of ‘‘2015 Edition Base EHR’’
to read as follows:
§ 170.102
Definitions.
*
*
*
*
*
2015 Edition Base EHR * * *
(3) * * *
(ii) Section 170.315(g)(8) or (10) for
the period before December 31, 2022;
and
(iii) Section 170.315(g)(10) on and
after December 31, 2022.
*
*
*
*
*
■ 4. Revise § 170.200 to read as follows:
§ 170.200
Applicability.
The standards and implementation
specifications adopted in this part apply
with respect to Health Information
technology.
■ 5. Amend § 170.205 by revising
paragraphs (h)(3) and (k)(3) to read as
follows:
§ 170.205 Content exchange standards
and implementation specifications for
exchanging electronic health information.
*
*
*
*
*
(h) * * *
(3) Standard. CMS Implementation
Guide for Quality Reporting Document
PO 00000
Frm 00040
Fmt 4700
Sfmt 4700
Architecture: Category I; Hospital
Quality Reporting; Implementation
Guide for 2020 (incorporated by
reference in § 170.299).
*
*
*
*
*
(k) * * *
(3) Standard. CMS Implementation
Guide for Quality Reporting Document
Architecture: Category III; Eligible
Clinicians and Eligible Professionals
Programs; Implementation Guide for
2020 (incorporated by reference in
§ 170.299).
*
*
*
*
*
■ 6. Amend § 170.210:
■ a. In paragraph (e)(1)(i), by removing
the words ‘‘through 7.1.3’’ and adding
in its place the words ‘‘and 7.1.2’’;
■ b. In paragraphs (e)(2)(i) and (e)(3), by
removing the words ‘‘7.2 and 7.4,’’ and
adding in their place the words ‘‘7.1.1
and 7.1.7’’; and
■ c. By revising paragraph (g).
The revision reads as follows:
§ 170.210 Standards for health information
technology to protect electronic health
information created, maintained, and
exchanged.
*
*
*
*
*
(g) Synchronized clocks. The date and
time recorded utilize a system clock that
has been synchronized following (RFC
5905) Network Time Protocol Version 4,
(incorporated by reference in § 170.299).
*
*
*
*
*
■ 7. Revise § 170.213 to read as follows:
§ 170.213 United States Core Data for
Interoperability.
Standard. United States Core Data for
Interoperability (USCDI), July 2020
Errata, Version 1 (v1) (incorporated by
reference in § 170.299).
■ 8. Amend § 170.215 by revising (a)(2)
to read as follows:
§ 170.215 Application Programming
Interface Standards.
*
*
*
*
*
(a) * * *
(2) Implementation specification. HL7
FHIR® US Core Implementation Guide
STU 3.1.1 (incorporated by reference in
§ 170.299).
■ 9. Amend § 170.299 by revising
paragraphs (e)(4) and (5), (f)(34), and
(m)(5) to read as follows:
§ 170.299
Incorporation by reference.
*
*
*
*
*
(e) * * *
(4) CMS Implementation Guide for
Quality Reporting Document
Architecture: Category I; Hospital
Quality Reporting Implementation
Guide for 2020; published December 3,
2019, IBR approved for § 170.205(h).
(5) CMS Implementation Guide for
Quality Reporting Document
E:\FR\FM\04NOR1.SGM
04NOR1
Federal Register / Vol. 85, No. 214 / Wednesday, November 4, 2020 / Rules and Regulations
Architecture: Category III; Eligible
Clinicians and Eligible Professionals
Programs Implementation Guide for
2020; published April 30, 2020, IBR
approved for § 170.205(k).
*
*
*
*
*
(f) * * *
(34) HL7 FHIR® US Core
Implementation Guide STU3 Release
3.1.1, August 28, 2020, IBR approved for
§ 170.215(a).
*
*
*
*
*
(m) * * *
(5) United States Core Data for
Interoperability (USCDI), Version 1, July
2020 Errata, IBR approved for § 170.213;
available at https://www.healthit.gov/
USCDI.
*
*
*
*
*
■ 10. Amend § 170.300 by revising
paragraphs (a), (c), and (d) to read as
follows:
§ 170.300
Applicability.
(a) The certification criteria adopted
in this subpart apply to the testing and
certification of Health IT Modules.
*
*
*
*
*
(c) Health Modules are not required to
be compliant with certification criteria
or capabilities specified within a
certification criterion that are
designated as optional.
(d) In § 170.315, all certification
criteria and all capabilities specified
within a certification criterion have
general applicability (i.e., apply to any
health care setting) unless designated as
‘‘inpatient setting only’’ or ‘‘ambulatory
setting only.’’
*
*
*
*
*
■ 11. Amend § 170.315 by:
■ a. Revising paragraphs (b)(1)(iii)(A)(2),
(b)(2)(i), (b)(2)(iii)(D) introductory text,
(b)(2)(iv), (b)(3)(ii)(B)(2), (b)(7)(ii),
(b)(8)(i)(B), (b)(9)(ii), (c)(3), (d)(13)(ii),
(e)(1)(i)(A)(2), (f)(5)(iii)(B)(1) and (2),
(g)(6)(i)(B), (g)(9)(i)(A)(2),
(g)(10)(v)(A)(1)(ii), and
(g)(10)(v)(A)(2)(ii); and
■ b. Adding paragraph
(g)(10)(iv)(A)(1)(iii).
The revisions and addition read as
follows:
§ 170.315 2015 Edition health IT
certification criteria.
khammond on DSKJM1Z7X2PROD with RULES
*
*
*
*
*
(b) * * *
(1) * * *
(iii) * * *
(A) * * *
(2) The Common Clinical Data Set in
accordance with § 170.205(a)(4) and
paragraph (b)(1)(iii)(A)(3)(i) through (iv)
of this section for the period before
December 31, 2022, and
*
*
*
*
*
VerDate Sep<11>2014
16:30 Nov 03, 2020
Jkt 253001
(2) * * *
(i) General requirements. Paragraphs
(b)(2)(ii) and (iii) of this section must be
completed based on the receipt of a
transition of care/referral summary
formatted in accordance with the
standards adopted in § 170.205(a)(3)
through (5) using the Continuity of Care
Document, Referral Note, and (inpatient
setting only) Discharge Summary
document templates on and after
December 31, 2022.
*
*
*
*
*
(iii) * * *
(D) Upon a user’s confirmation,
automatically update the list, and
incorporate the following data
expressed according to the specified
standard(s) on and after December 31,
2022:
*
*
*
*
*
(iv) System verification. Based on the
data reconciled and incorporated, the
technology must be able to create a file
formatted according to the standard
specified in § 170.205(a)(4) using the
Continuity of Care Document template
and the standard specified in
§ 170.205(a)(5) on and after December
31, 2022.
(3) * * *
(ii) * * *
(B) * * *
(2) Send fill status notifications
(RxFillIndicatorChange).
*
*
*
*
*
(7) * * *
(ii) Document level for the period
before December 31, 2022.
(8) * * *
(i) * * *
(B) Document level for the period
before December 31, 2022; and
*
*
*
*
*
(9) * * *
(ii) The standard in § 170.205(a)(5) on
and after December 31, 2022.
*
*
*
*
*
(c) * * *
(3) Clinical quality measures—report.
Enable a user to electronically create a
data file for transmission of clinical
quality measurement data:
(i) 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 implementation guide for
QRDA, category III for ambulatory
measures in § 170.205 (k)(3); or
(ii) In accordance with the standards
specified in § 170.205(h)(2) and
§ 170.205(k)(1) and (2) for the period
before December 31, 2022.
*
*
*
*
*
PO 00000
Frm 00041
Fmt 4700
Sfmt 4700
70083
(d) * * *
(13) * * *
(ii) No—the Health IT Module does
not support authentication, through
multiple elements, of the user’s identity
with the use of industry-recognized
standards. When attesting ‘‘no,’’ the
health IT developer may explain why
the Health IT Module does not support
authentication, through multiple
elements, of the user’s identity with the
use of industry-recognized standards.
(e) * * *
(1) * * *
(i) * * *
(A) * * *
(2) The Common Clinical Data Set in
accordance with § 170.205(a)(4) and
paragraphs (e)(1)(i)(A)(3)(i) through (iv)
of this section for the period before
December 31, 2022.
*
*
*
*
*
(f) * * *
(5) * * *
(iii) * * *
(B) * * *
(1) The data classes expressed in the
standard in § 170.213, or
(2) The Common Clinical Data Set for
the period before December 31, 2022.
*
*
*
*
*
(g) * * *
(6) * * *
(i) * * *
(B) The Common Clinical Data Set in
accordance with § 170.205(a)(4) and
paragraphs (g)(6)(i)(C)(1) through (4) of
this section for the period before
December 31, 2022.
*
*
*
*
*
(9) * * *
(i) * * *
(A) * * *
(2) The Common Clinical Data Set in
accordance with paragraphs
(g)(9)(i)(A)(3)(i) through (iv) of this
section for the period before December
31, 2022, and
*
*
*
*
*
(10) * * *
(v) * * *
(A) * * *
(1) * * *
(ii) A Health IT Module’s
authorization server must issue a refresh
token valid for a period of no less than
three months to applications capable of
storing a client secret.
(iii) A Health IT Module’s
authorization server must issue a refresh
token for a period of no less than three
months to native applications capable of
securing a refresh token.
(2) * * *
(ii) A Health IT Module’s
authorization server must issue a refresh
token valid for a new period of no less
E:\FR\FM\04NOR1.SGM
04NOR1
70084
Federal Register / Vol. 85, No. 214 / Wednesday, November 4, 2020 / Rules and Regulations
than three months to applications
capable of storing a client secret.
*
*
*
*
*
■ 12. Amend § 170.401 by revising
paragraph (a) to read as follows:
§ 170.401
Information blocking.
(a) Condition of Certification
requirement. A health IT developer
must not take any action that constitutes
information blocking as defined in 42
U.S.C. 300jj–52 and § 171.103 on or after
April 5, 2021.
*
*
*
*
*
■ 13. Amend by revising § 170.402 by
revising paragraphs (a)(1), (4) and (b)(2)
to read as follows:
§ 170.402
Assurances.
(a) * * *
(1) A health IT developer must
provide assurances satisfactory to the
Secretary that the health IT developer
will not take any action that constitutes
information blocking as defined in 42
U.S.C. 300jj–52 and § 171.103 of this
chapter on and after April 5, 2021,
unless for legitimate purposes as
specified by the Secretary; or any other
action that may inhibit the appropriate
exchange, access, and use of electronic
health information.
*
*
*
*
*
(4) 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).
(b) * * *
(2)(i) By December 31, 2023, a health
IT developer that must comply with the
requirements of paragraph (a)(4) of this
section must provide all of its customers
of certified health IT with the health IT
certified to the certification criterion in
§ 170.315(b)(10).
(ii) On and after December 31, 2023,
a health IT developer that must comply
with the requirements of paragraph
(a)(4) of this section must provide all of
its customers of certified health IT with
the health IT certified to the
certification criterion in
§ 170.315(b)(10).
■ 14. Amend § 170.403 by revising (b)(1)
to read as follows:
§ 170.403
Communications.
khammond on DSKJM1Z7X2PROD with RULES
*
*
*
*
*
(b) * * *
(1) Notice. Health IT developers must
issue a written notice to all customers
and those with which it has contracts or
agreements containing provisions that
contravene paragraph (a) of this section
annually, beginning in calendar year
2021, until paragraph (b)(2)(ii) of this
section is fulfilled, stating that any
VerDate Sep<11>2014
16:30 Nov 03, 2020
Jkt 253001
communication or contract provision
that contravenes paragraph (a) of this
section will not be enforced by the
health IT developer.
*
*
*
*
*
■ 15. Amend § 170.404 by revising (b)(3)
and (4) to read as follows:
§ 170.404 Application programming
interfaces.
*
*
*
*
*
(b) * * *
(3) Rollout of (g)(10)-certified APIs. A
Certified API Developer with certified
API technology previously certified to
the certification criterion in
§ 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)
by no later than December 31, 2022.
(4) Compliance for existing certified
API technology. By no later than April
5, 2021, a Certified API Developer with
Health IT Module(s) certified to the
certification criteria in § 170.315(g)(7),
(8), or (9) must comply with paragraph
(a) of this section, including revisions to
their existing business and technical
API documentation and make such
documentation available via a publicly
accessible hyperlink that allows any
person to directly access the
information without any preconditions
or additional steps.
*
*
*
*
*
■ 16. Amend § 170.405 by:
■ a. Revising paragraphs (b)(1)
introductory text, (b)(2)(ii) introductory
text, (b)(3) introductory text, (b)(4)(ii),
(b)(5)(ii), (b)(6)(ii), and (b)(7)(ii); and
■ b. Adding paragraph (b)(10).
The revisions and addition read as
follows:
§ 170.405
Real world testing.
*
*
*
*
*
(b) * * *
(1) Real world testing plan
submission. A health IT developer with
Health IT Module(s) certified to any one
or more of the criteria referenced in
paragraph (a) of this section must
submit to its ONC–ACB an annual real
world testing plan addressing each of
those certified Health IT Modules by a
date determined by the ONC–ACB that
enables the ONC–ACB to publish a
publicly available hyperlink to the plan
on CHPL no later than December 15 of
each calendar year, beginning in 2021.
*
*
*
*
*
(2) * * *
(ii) For real world testing activities
conducted during the immediately
preceding calendar year, a health IT
developer must submit to its ONC–ACB
PO 00000
Frm 00042
Fmt 4700
Sfmt 4700
an annual real world testing results
report addressing each of its certified
Health IT Modules that include
certification criteria referenced in
paragraph (a) of this section by a date
determined by the ONC–ACB that
enables the ONC–ACB to publish a
publicly available hyperlink to the
results report on CHPL no later than
March 15 of each calendar year,
beginning in 2023. The real world
testing results must report the following
for each of the certification criteria
identified in paragraph (a) of this
section that are included in the Health
IT Module’s scope of certification:
*
*
*
*
*
(3) USCDI Updates. A health IT
developer with health IT certified to
§ 170.315(b)(1), (b)(2), (e)(1), (g)(6) and/
or (g)(9) on May 1, 2020, must:
*
*
*
*
*
(ii) Provide its customers of the
previously certified health IT with
certified health IT that meets paragraph
(b)(3)(i) of this section by December 31,
2022.
(4) * * *
(ii) Provide its customers of the
previously certified health IT with
certified health IT that meets paragraph
(b)(4)(i) of this section by December 31,
2022.
(5) * * *
(ii) Provide its customers of the
previously certified health IT with
certified health IT that meets paragraph
(b)(5)(i) of this section by December 31,
2022.
(6) * * *
(ii) Provide its customers of the
previously certified health IT with
certified health IT that meets paragraph
(b)(6)(i) of this section by December 31,
2022.
(7) * * *
(ii) Provide its customers of the
previously certified health IT with
certified health IT that meets paragraph
(b)(7)(i) of this section by December 31,
2022.
*
*
*
*
*
(10) Clinical quality measures—
report. A health IT developer with
health IT certified to § 170.315(c)(3)
prior to June 30, 2020, must:
(i) Update their certified health IT to
be compliant with the revised versions
of this criteria adopted in
§ 170.315(c)(3); and
(ii) Provide its customers of the
previously certified health IT with
certified health IT that meets paragraph
(b)(10)(i) of this section by December 31,
2022.
■ 17. Amend § 170.523 by:
■ a. Removing and reserving paragraph
(f)(1)(xxi); and
E:\FR\FM\04NOR1.SGM
04NOR1
Federal Register / Vol. 85, No. 214 / Wednesday, November 4, 2020 / Rules and Regulations
b. Revising paragraphs (k)(1)
introductory text and (k)(1)(i).
The revisions read as follows:
■
§ 170.523 Principles of proper conduct for
ONC–ACBs.
*
*
*
*
*
(k) * * *
(1) Mandatory Disclosures. A health
IT developer must conspicuously
include the following on its website and
in all marketing materials,
communications statements, and other
assertions related to the Health IT
Module’s certification:
(i) The disclaimer ‘‘This Health IT
Module is [specify Edition of health IT
certification criteria] compliant and has
been certified by an ONC–ACB in
accordance with the applicable
certification criteria adopted by the
Secretary of Health and Human
Services. This certification does not
represent an endorsement by the U.S.
Department of Health and Human
Services.’’
*
*
*
*
*
■ 18. Amend § 170.550 by revising
paragraphs (m)(1), (2), and (3) to read as
follows:
§ 170.550
Health IT Module certification.
*
*
*
*
*
(m) * * *
(1) Section 170.315(a)(10) and (13)
and § 170.315(e)(2) for the period before
January 1, 2022.
(2) Section 170.315(b)(6) for the
period before December 31, 2023.
(3) Section 170.315(g)(8) for the
period before December 31, 2022.
PART 171—INFORMATION BLOCKING
19. The authority citation for part 171
continues to read as follows:
■
20. Amend § 171.101 by revising
paragraph (b) to read as follows:
Applicability.
*
*
*
*
(b) Health care providers, health IT
developers of certified health IT, health
information exchanges, and health
information networks are subject to this
part on and after April 5, 2021.
■ 21. Amend § 171.103 by revising
paragraphs (a)(2), (a)(3) and (b) to read
as follows:
khammond on DSKJM1Z7X2PROD with RULES
*
§ 171.103
Information blocking.
(a) * * *
(2) If conducted by a health IT
developer of certified health IT, health
information network or health
information exchange, such developer,
network or exchange knows, or should
know, that such practice is likely to
VerDate Sep<11>2014
16:30 Nov 03, 2020
22. Amend § 171.203 by revising
paragraph (e)(2) to read as follows:
■
§ 171.203 Security exception—When will
an actor’s practice that is likely to interfere
with the access, exchange, or use of
electronic health information in order to
protect the security of electronic health
information not be considered information
blocking?
*
*
*
*
*
(e) * * *
(2) There are no reasonable and
appropriate alternatives to the practice
that address the security risk that are
less likely to interfere with access,
exchange or use of electronic health
information.
23. Amend § 171.301 by revising
paragraphs (a)(1), (a)(2) and (b)(1)(ii)(A)
to read as follows:
■
§ 171.301 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 electronic health
information not be considered information
blocking?
*
Authority: 42 U.S.C. 300jj–52
■
§ 171.101
interfere with access, exchange, or use
of electronic health information; or
(3) If conducted by a health care
provider, such provider knows that such
practice is unreasonable and is likely to
interfere with access, exchange, or use
of electronic health information.
*
*
*
*
*
(b) For the period before October 6,
2022, electronic health information for
the purposes of paragraph (a) of this
section is limited to the electronic
health information identified by the
data elements represented in the USCDI
standard adopted in § 170.213.
*
*
*
*
*
Jkt 253001
*
*
*
*
(a) * * *
(1) USCDI. For the period before
October 6, 2022, at a minimum, the
electronic health information identified
by the data elements represented in the
USCDI standard adopted in § 170.213.
(2) All electronic health information.
On and after October 6, 2022, electronic
health information as defined in
§ 171.102.
(b) * * *
(1) * * *
(ii) * * *
(A) Any fees charged by the actor in
relation to fulfilling the request are not
required to satisfy the exception in
§ 171.302; and
*
*
*
*
*
24. Amend § 171.303 by revising
paragraph (b)(2)(i) to read as follows:
■
PO 00000
Frm 00043
Fmt 4700
Sfmt 4700
70085
§ 171.303 Licensing exception—When will
an actor’s practice to license
interoperability elements in order for
electronic health information to be
accessed, exchanged, or used not be
considered information blocking?
*
*
*
*
*
(b) * * *
(2) * * *
(i) The royalty must be
nondiscriminatory, consistent with
paragraph (b)(3) of this section.
*
*
*
*
*
Alex M. Azar II,
Secretary, Department of Health and Human
Services.
[FR Doc. 2020–24376 Filed 11–2–20; 8:45 am]
BILLING CODE 4150–45–P
DEPARTMENT OF COMMERCE
National Oceanic and Atmospheric
Administration
50 CFR Part 622
[Docket No. 181009921–8999–02; RTID
0648–XA604]
Fisheries of the Caribbean, Gulf of
Mexico, and South Atlantic; 2020
Commercial Closure for Atlantic
Migratory Group Cobia
National Marine Fisheries
Service (NMFS), National Oceanic and
Atmospheric Administration (NOAA),
Commerce.
ACTION: Temporary rule; closure.
AGENCY:
NMFS implements a closure
for Atlantic migratory group cobia
(Atlantic cobia) that are sold
(commercial) and harvested from
Atlantic Federal waters off Georgia
through New York. NMFS projects that
commercial landings of Atlantic cobia
will reach the commercial quota on
November 6, 2020. Therefore, NMFS
closes the commercial sector for
Atlantic cobia in Federal waters from
November 6, 2020, until the start of the
next fishing year on January 1, 2021.
This closure is necessary to protect the
Atlantic cobia resource.
DATES: This temporary rule is effective
at 12:01 a.m. eastern time on November
6, 2020, until 12:01 a.m. eastern time on
January 1, 2021.
FOR FURTHER INFORMATION CONTACT:
Mary Vara, NMFS Southeast Regional
Office, telephone: 727–824–5305, email:
mary.vara@noaa.gov.
SUPPLEMENTARY INFORMATION: The
fishery for Atlantic cobia in Federal
waters is managed under the authority
of the Atlantic Coastal Fisheries
Cooperative Management Act (Atlantic
SUMMARY:
E:\FR\FM\04NOR1.SGM
04NOR1
]]>Agencies
[Federal Register Volume 85, Number 214 (Wednesday, November 4, 2020)]
[Rules and Regulations]
[Pages 70064-70085]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2020-24376]
=======================================================================
-----------------------------------------------------------------------
DEPARTMENT OF HEALTH AND HUMAN SERVICES
Office of the Secretary
45 CFR Parts 170 and 171
RIN 0955-AA02
Information Blocking and the ONC Health IT Certification Program:
Extension of Compliance Dates and Timeframes in Response to the COVID-
19 Public Health Emergency
AGENCY: Office of the National Coordinator for Health Information
Technology (ONC), Department of Health and Human Services (HHS).
ACTION: Interim final rule with comment period.
-----------------------------------------------------------------------
SUMMARY: This interim final rule with comment period (IFC) gives health
IT developers and health care providers flexibilities to effectively
respond to the public health threats posed by the spread of the
coronavirus disease 2019 (COVID-19). Recognizing the urgency of this
situation, and understanding that caring for patients with COVID-19 is
of utmost importance, ONC is issuing this IFC to extend certain
compliance dates and timeframes adopted in the 21st Century Cures Act:
Interoperability, Information Blocking, and the ONC Health IT
Certification Program Final Rule (ONC Cures Act Final Rule), including
compliance and applicability dates for the information blocking
provisions, certain 2015 Edition health IT certification criteria, and
Conditions and Maintenance of Certification
[[Page 70065]]
requirements under the ONC Health IT Certification Program (Program).
In this IFC, we are also making programmatic changes to the Program by
updating standards. In addition, we are making corrections and
clarifications to the ONC Cures Act Final Rule, which was published in
the Federal Register on May 1, 2020.
DATES:
Effective date: This interim final rule is effective on December 4,
2020 except for 45 CFR 170.401, 170.402(a)(1), and the amendments to 45
CFR part 171 which are effective on November 4, 2020.
Incorporation by reference: The incorporation by reference of
certain publications listed in the rule is approved by the Director of
the Federal Register as of November 4, 2020. The incorporation by
reference of certain other publications listed in the rule was approved
by the Director of the Federal Register as of September 4, 2012.
Comment date: To be assured consideration, written or electronic
comments must be received at one of the addresses provided below, no
later than 5 p.m. on January 4, 2021.
ADDRESSES: You may submit comments, identified by RIN 0955-AA02, by any
of the following methods (please do not submit duplicate comments).
Because of staff and resource limitations, we cannot accept comments by
facsimile (FAX) transmission.
Federal eRulemaking Portal: Follow the instructions for
submitting comments. Attachments should be in Microsoft Word, Microsoft
Excel, or Adobe PDF; however, we prefer Microsoft Word. https://www.regulations.gov.
Regular, Express, or Overnight Mail: Department of Health
and Human Services, Office of the National Coordinator for Health
Information Technology, Attention: Information Blocking and the ONC
Health IT Certification Program: Extension of Compliance Dates and
Timeframes in Response to the COVID-19 Public Health Emergency, Mary E.
Switzer Building, Mail Stop: 7033A, 330 C Street SW, Washington, DC
20201. Please submit one original and two copies.
Hand Delivery or Courier: Office of the National
Coordinator for Health Information Technology, Attention: Information
Blocking and the ONC Health IT Certification Program: Extension of
Compliance Dates and Timeframes in Response to the COVID-19 Public
Health Emergency, Mary E. Switzer Building, Mail Stop: 7033A, 330 C
Street SW, Washington, DC 20201. Please submit one original and two
copies. (Because access to the interior of the Mary E. Switzer Building
is not readily available to persons without Federal Government
identification, commenters are encouraged to leave their comments in
the mail drop slots located in the main lobby of the building.)
Inspection of Public Comments: All comments received before the
close of the comment period will be available for public inspection,
including any personally identifiable or confidential business
information that is included in a comment. Please do not include
anything in your comment submission that you do not wish to share with
the general public. Such information includes, but is not limited to: A
person's social security number; date of birth; driver's license
number; state identification number or foreign country equivalent;
passport number; financial account number; credit or debit card number;
any personal health information; or any business information that could
be considered proprietary. We will post all comments that are received
before the close of the comment period at https://www.regulations.gov.
Docket: For access to the docket to read background documents or
comments received, go to https://www.regulations.gov or the Department
of Health and Human Services, Office of the National Coordinator for
Health Information Technology, Mary E. Switzer Building, Mail Stop:
7033A, 330 C Street SW, Washington, DC 20201 (call ahead to the contact
listed below to arrange for inspection).
FOR FURTHER INFORMATION CONTACT: Michael Lipinski, Office of Policy,
Office of the National Coordinator for Health Information Technology,
202-690-7151.
SUPPLEMENTARY INFORMATION:
Table of Contents
I. Background
II. Provisions of the Interim Final Rule With Comment Period
A. Extension of Compliance Dates and Timeframes
1. Information Blocking Provisions and Related Condition and
Maintenance of Certification Requirements
2. Certain 2015 Edition Health IT Certification Criteria Updates
3. Conditions and Maintenance of Certification Requirements
Under the ONC Health IT Certification Program
a. Assurances
b. Communications
c. Application Programming Interfaces
d. Real World Testing
e. Attestations
4. Updates to ONC-ACB Dates and Timeframes
B. Standards Updates
1. USCDI
2. U.S. Core Implementation Guide
C. Corrections and Clarifications to the ONC Cures Act Final
Rule
1. General Applicability and Applicability of Standards and
Implementation Specifications for Health Information Technology
2. Standards for Health Information Technology To Protect
Electronic Health Information Created, Maintained, and Exchanged
a. Record Actions Related to Electronic Health Information,
Audit Log Status, and Encryption of End-User Devices
b. Synchronized Clocks
3. Applicability of Certification Criteria for Health
Information Technology
4. Electronic Prescribing
5. Clinical Quality Measures--Report Criterion
6. Multi-Factor Authentication
7. Transmission to Public Health Agencies--Electronic Case
Reporting
8. Conditions and Maintenance of Certification Requirements for
Health IT Developers
a. Assurances
b. Application Programming Interfaces--Clarification for Native
Applications and Refresh Tokens
9. Principles of Proper Conduct for ONC-ACBs
10. Applicability of the Information Blocking Provisions
11. Information Blocking Definition and Security Exception
12. Content and Manner Exception
13. Licensing Exception
III. Waiver of Proposed Rulemaking, Comment Period, and Delay in
Effective Date
IV. Incorporation by Reference
V. Response to Comments
VI. Collection of Information Requirements
VII. Regulatory Impact Analysis
A. Executive Orders 12866 and 13563
B. Regulatory Flexibility Act
C. Executive Order 13771
D. Executive Order 13132--Federalism
E. Unfunded Mandates Reform Act
List of Subjects
I. Background
The United States is responding to an outbreak of respiratory
disease caused by a novel (new) coronavirus that has now been detected
in more than 235 \1\ countries internationally, and all 50 States and
the District of Columbia. The virus has been named ``severe acute
respiratory syndrome coronavirus 2'' (SARS-CoV-2) and the disease it
causes has been named ``coronavirus disease 2019'' (COVID-19).
---------------------------------------------------------------------------
\1\ https://www.who.int/emergencies/diseases/novel-coronavirus-2019 (Accessed on 10/22/2020).
---------------------------------------------------------------------------
On January 30, 2020, the International Health Regulations Emergency
Committee of the World Health Organization (WHO) declared the
[[Page 70066]]
outbreak a ``Public Health Emergency of international concern.'' On
January 31, 2020, pursuant to section 319 of the Public Health Service
Act (PHSA), Health and Human Services Secretary, Alex M. Azar II,
determined that a Public Health Emergency (PHE) exists for the United
States to aid the nation's health care community in responding to
COVID-19. On March 11, 2020, the WHO publicly declared COVID-19 a
pandemic. On March 13, 2020, the President of the United States
declared the COVID-19 pandemic a national emergency. Effective October
23, 2020, Secretary Azar renewed the January 31, 2020 determination
that was previously renewed on April 21, 2020 and July 23, 2020 that a
PHE for COVID-19 exists and has existed since January 27, 2020.
As the health care community establishes and implements recommended
infection prevention and control practices, regulatory agencies--under
appropriate waiver authority granted by the declaration of the COVID-19
PHE--are also working to revise regulations to allow the health care
community to focus on the PHE. We believe that the ONC Cures Act Final
Rule should be revised to offer the health care system additional
flexibilities in furnishing services to combat the COVID-19 pandemic.
On April 21, 2020, concurrent with Secretary Azar's first renewal of
the determination of a PHE, ONC announced a policy of enforcement
discretion to allow compliance flexibilities regarding the
implementation of the ONC Cures Act Final Rule in response to the
COVID-19 PHE.\2\ We stated our intention to exercise enforcement
discretion for three months at the end of certain ONC Health IT
Certification Program (Program) compliance dates associated with the
ONC Cures Act Final Rule to provide flexibility while ensuring the
goals of the rule remain on track. In this IFC, we are extending the
applicability date for the information blocking provisions and some
compliance dates in the Program, including dates for certain updated
2015 Edition health IT certification criteria and Conditions and
Maintenance of Certification requirements. The extensions in this IFC
for information blocking and the Program are longer than the three
month extension that was announced in the April 21, 2020 enforcement
discretion statement for the Program. These additional flexibilities
for development and implementation enable our health care system to
focus on addressing the COVID-19 PHE, while still maintaining a
trajectory that will advance patients' access to their health
information, reduce the cost of care, and improve the quality of care.
This IFC also updates certain standards in the Program, and makes
necessary corrections and clarifications to the ONC Cures Act Final
Rule, which was published in the Federal Register on May 1, 2020 (85 FR
25642), and became effective on June 30, 2020.
---------------------------------------------------------------------------
\2\ https://www.healthit.gov/curesrule/resources/enforcement-discretion.
---------------------------------------------------------------------------
II. Provisions of the Interim Final Rule With Comment Period
A. Extension of Compliance Dates and Timeframes
The ONC Cures Act Final Rule fosters innovation in health care to
deliver better information, more conveniently, to patients and their
providers. It also promotes transparency through technology, providing
opportunities for the American public to gain visibility into the
services, quality, and costs of health care.
The ONC Cures Act Final Rule includes provisions that require
support for modern computing standards and application programming
interfaces (APIs). These technical provisions will inject competition
into health care by promoting an entrepreneurial economy and new
business models using smartphone apps to provide novel services and
choices in care. The ONC Cures Act Final Rule will also make sure
health information follows a patient by preventing industrywide
information blocking practices and other anti-competitive behavior by
those entrusted to hold patients' electronic health information (EHI).
In the ONC Cures Act Final Rule, we set applicability and
compliance dates for certain provisions of the regulations. In light of
the COVID-19 PHE, in this IFC, ONC is extending the applicability date
for the information blocking provisions and compliance dates and
timeframes for certain Program requirements, including compliance dates
for certain 2015 Edition health IT certification criteria and
Conditions and Maintenance of Certification requirements. These
additional flexibilities for development and implementation will enable
our health care system to focus on addressing the COVID-19 PHE, while
continuing to advance policies that will promote patients' access to
their EHI and enable greater data exchange.
We have also heard from stakeholders and organizations representing
clinicians, hospitals, health systems and health information technology
developers requesting an extension for the applicability and compliance
dates. These stakeholders expressed concern over meeting the
information blocking applicability date of November 2, 2020. They
stated that the COVID-19 PHE continues to monopolize their time and
attention, and has strained resources, drastically limiting their
ability to prepare for the November 2nd information blocking date.
In an effort to minimize any burden or confusion for developers and
providers, we have aligned the extensions around three distinct dates.
For ease of comparison, in Table 1 below, we have added the dates from
the ONC Cures Act Final Rule, the dates in the April 21, 2020
enforcement discretion announcement, and the dates in this IFC.
---------------------------------------------------------------------------
\3\ Note that for the Content and Manner Exception, in Sec.
171.301(a), for the period before October 6, 2022, the definition of
EHI is limited to, at a minimum, the data elements represented in
the USCDI standard; and, for the period on and after Oct 6, 2022,
EHI is defined as it is in Sec. 171.102. These dates reflect the
extension from May 2, 2022, which was the compliance date included
in the ONC Cures Act Final Rule. These dates are discussed in more
detail in section II.A.1.
Table 1--Applicability and Compliance Dates
----------------------------------------------------------------------------------------------------------------
Enforcement discretion Interim final rule with
Provision Final rule announcement comment period
----------------------------------------------------------------------------------------------------------------
Information Blocking Overall November 2, 2020....... N/A--No Change......... April 5, 2021.
Applicability Date--(45 CFR part
171) \3\.
Condition of Certification (CoC)-- November 2, 2020....... 3 months after the
Information Blocking--(Sec. compliance timeframe.
170.401).
[[Page 70067]]
CoC--Assurances--(Sec. November 2, 2020....... 3 months after the
170.402(a)(1))--Will not take any compliance timeframe.
action that constitutes information
blocking or actions that inhibit
access, exchange, and use of
electronic health information (EHI).
CoC--Assurances--(Sec. Effective date: June Enforcement discretion
170.402(a)(2) and (3), and (b)(1))-- 30, 2020. expired 3 months after
Other. the effective date of
the final rule.
CoC--Communications--(Sec. Effective date: June Enforcement discretion
170.403)--Communications 30, 2020. expired 3 months after
requirements, except for Sec. the effective date of
170.403(b)(1) where we removed the the final rule.
notice requirement for 2020.
CoC--API--(Sec. 170.404(b)(4))-- November 2, 2020....... 3 months after the
Compliance for current API criteria. compliance timeframe.
CoC--API--(Sec. 170.404(b)(3))-- May 2, 2022............ 3 months after the December 31, 2022.
Rollout of new standardized API compliance timeframe.
functionality.
CoC--Real World Testing--2015 Edition May 2, 2022............ 3 months after the
health IT certification criteria compliance timeframe.
with standards updates.
CoC--Assurances--(Sec. May 1, 2023............ 3 months after the December 31, 2023.
170.402(a)(4) and (b)(2))--EHI compliance timeframe.
Export Rollout.
CoC--Communications--(Sec. Annually beginning in Notice can be made Begin annual cycle 1
170.403(b)(1))--Notice to all calendar year 2020. until March 31, 2021, year later. CY 2021.
customers with which developer has for the 2020 calendar
contracts or agreements containing year.
provisions that contravene
Communications CoC.
CoC--Initial Attestations--(Sec. April 1-30, 2021 Generally remains the Begin annual cycle 1
170.406). attestation window for same except for the year later. CY 2022.
attestation period initial attestation,
running June 30, 2020, which will now be
through March 31, 2021. accepted through July
30, 2021.
CoC--Real World Testing--(Sec. Plan: December 15, 2020 Initial Plan: Initial Begin annual cycle 1
170.405(b)(1) and (2)) Submit Results: March 15, RWT plans (i.e., 2021 year later.
initial plan and initial results 2022.. RWT plans) may be Initial Plan: December
submission. submitted through 15, 2021.
March 15, 2021. Initial Results: March
Initial Results: 15, 2023.
Initial RWT results
from the 2021
performance year may
be submitted up
through June 2022..
----------------------------------------------------------------------------------------------------------------
In selecting these dates, we carefully considered a number of
factors, including the possibility that health IT developers of
certified health IT and other actors would divert resources needed to
respond to the COVID-19 PHE in order to meet requirements of the ONC
Cures Act Final Rule. In particular, we considered whether the
requirements placed a current conflicting resource burden on developers
and whether the ongoing PHE necessitates greater lead time prior to
compliance. We considered whether affected parties' workforces would
need more time for education and training due to the round-the-clock
need to respond to the PHE. Further, we note that effective October 23,
2020, Secretary Azar renewed the determination that a PHE exists,
demonstrating a Department-wide commitment to a unified effort against
the COVID-19 PHE. Given these considerations, we concluded that the
extensions and flexibilities finalized in this IFC are appropriate and
necessary.
Once we concluded that the extensions were appropriate, we balanced
those factors against the overall policy and purpose of the ONC Cures
Act Final Rule. ONC takes seriously the responsibility to implement key
provisions of the Cures Act and Executive Order 13813. In this IFC, we
strived to ensure that our attention to the demands of the PHE is
balanced with our commitment to advance interoperability and support
the access, exchange, and use of EHI through implementation and
enforcement of the information blocking provisions. Therefore, we
sought to limit the extensions to no longer than reasonably necessary,
given the concerns cited above.
Extensions can be shorter where fewer technological demands are
placed on stakeholders. For example, in Sec. 170.403(b), a health IT
developer must not impose or enforce any contractual requirement that
contravenes the requirements of the Communications Condition of
Certification. Furthermore, if a health IT developer has contracts/
agreements in existence that contravene the requirements of the
Communications 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 this IFC, we suspended the annual notice
requirement in Sec. 170.403(b)(1) for just the 2020 year. This limited
suspension ensures that the users and customers of certified health IT
will still be notified in a timely manner by health IT developers,
while also relieving pressure on the developers to immediately devote
portions of their workforce to review contracts. We believe the annual
requirement will lessen compliance obligations for health IT developers
of certified health IT
[[Page 70068]]
while still providing adequate notice in a reasonable amount of time.
We have finalized the deadline for the notice requirement in Sec.
170.403(b)(1) to be annually, beginning in calendar year 2021.
Other extensions are limited because of the positive outcomes we
anticipate from certain provisions. For example, the information
blocking provisions in 45 CFR 171 are critical to ensuring patients are
able to access their EHI when and where they need it. Therefore, the
extensions for most of the information blocking provisions are limited
to April 5, 2021, for two reasons. First and foremost, we must balance
the need to provide actors with more time to address the PHE with the
ultimate goal of making EHI more accessible to improve the cost and
quality of care. Second, unlike some of the 2015 Edition Cures Update
certification criteria, the information blocking provisions do not
explicitly require actors to purchase or update certified health IT, so
there is less of a concern about technology resource allocations in the
near term.
In other instances, a close review of the ONC Cures Act Final Rule
in light of the PHE led us to conclude that some provisions would be
better served by lengthier extensions. For example, we are extending
until December 31, 2022, the compliance date for the 2015 Edition Cures
Update certification criteria (85 FR 25666 through 25667). The updated
certification criteria require health IT developers to upgrade their
current technology in order to maintain or earn their certified status.
Developers have been allocating resources to ensure their technology
meets the new needs of their customers (e.g., health care providers and
health care systems) including, for example, the ability to collect and
report COVID-19 data. However, health IT developers are also not
currently in a situation to be able to successfully rollout and test
the certification criteria with their customers because the health care
system has been focused on fighting the COVID-19 PHE. Developers,
therefore, should have greater leeway to ensure the costs of meeting
the 2015 Edition Cures Update certification criteria compliance dates
do not impair efforts to fight the COVID-19 PHE. Further, certified
health IT serves an important public good: Hospitals, patients and
public health networks rely on certified health IT. If ONC does not
grant an appropriate extension for developers to comply with the 2015
Edition Cures Update, some health IT developers may decide not to seek
re-certification, or forego certification altogether, if they determine
they do not have the resources required to meet tight deadlines. While
the new and revised certification criteria in the 2015 Edition Cures
Update will further advance the policy goals of the Cures Act, we are
confident the current certification criteria promote interoperability
and support the access, exchange and use of EHI. Therefore, in
balancing these interests, we concluded it would be contrary to the
public interest if we did not extend the compliance date for the 2015
Edition Cures Update certification criteria.
Finally, some of the extensions are related to the actions of other
components of HHS. For example, the Centers for Medicare & Medicaid
Services (CMS) works closely with ONC because some CMS programs require
technology to be certified under the Program. As discussed in the ONC
Cures Act Final Rule, ONC considers these impacts when establishing
policies for health IT developers that may also affect health care
providers participating in CMS programs (85 FR 25665). Because of the
cyclical nature of CMS reporting requirements each calendar year,
including the 90-day reporting period that is self-selected by CMS
Promoting Interoperability Program participants, ONC regularly works to
ensure that our own certification timelines complement the schedules
inherent to this program and other CMS programs. In the interest of
clarity and cohesion among HHS components, we have aligned some of our
dates to the calendar year for instances that may impact CMS program
participants. Aligning these related compliance dates to the calendar
year also aligns them to the CMS program annual cycle. This approach
will avoid confusion and best serve the public interest. This approach
also extends existing flexibility, rather than creating a new
restriction or requirement, and minimizes the impact on health care
providers. While we are finalizing more flexible compliance dates, we
continue to encourage developers to implement these updates and make
them available to customers as soon as practicable under the
circumstances.
1. Information Blocking Provisions and Related Condition and
Maintenance of Certification Requirements
In the ONC Cures Act Final Rule, the compliance date for 45 CFR
part 171, which contains the information blocking provisions of the
final rule, is November 2, 2020 (85 FR 25642). This is six months after
the publication date of the final rule in the Federal Register. Section
171.101(b) provides that health care providers, health IT developers of
certified health IT, health information exchanges, and health
information networks must comply with 45 CFR part 171 on and after
November 2, 2020. We established the six-month-delayed compliance date
to provide actors with time to thoroughly read and understand the final
rule and educate their workforces in order to apply the exceptions in
an appropriate manner (85 FR 25792). We also noted that the finalized
definition of information blocking (Sec. 171.103) and the Content and
Manner Exception (Sec. 171.301(a)) narrowed the scope of the EHI
definition to include only the EHI identified by the data elements
represented in the United States Core Data for Interoperability (USCDI)
for the first 18 months after the compliance date for 45 CFR part 171.
Therefore, in addition to the six-month post-publication compliance
date for 45 CFR part 171, the ONC Cures Act Final Rule granted actors
an additional 18 months to gain experience applying the exceptions with
only the EHI identified by the data elements represented in the USCDI,
as compared to the full scope of EHI, which would apply thereafter (85
FR 25792).
In the ONC Cures Act Final Rule, we encouraged actors, during this
combined period of 24 months, to apply the exceptions to all EHI as if
the scope was not limited to EHI identified by the data elements
represented in the USCDI. However, given the initial scope of EHI
identified in the information blocking definition in Sec. 171.103 and
the Content and Manner Exception in Sec. 171.301(a), if an actor did
not, in the first 24 months after the ONC Cures Act Final Rule's
publication date, enable access, exchange, or use of data outside the
USCDI, or did not appropriately apply an exception to data outside the
USCDI, such practice or ``error'' would not be considered information
blocking because that data would not be considered ``EHI'' during that
time period (85 FR 25792).
We also stated that the compliance dates for the Information
Blocking Condition of Certification requirement in Sec. 170.401 and
the Assurances Condition of Certification requirement in Sec.
170.402(a)(1) would be six months after the publication date of the
final rule in the Federal Register, i.e., November 2, 2020.
In light of the PHE, we believe it is necessary to offer additional
flexibilities. Therefore, in this IFC, we are extending the date for 45
CFR part 171 from November 2, 2020, to April 5, 2021. We also believe
it is more precise to refer to this date as the applicability date for
45 CFR part 171 instead of the
[[Page 70069]]
compliance date. Accordingly, in section II.C.7 of this IFC, we are
revising Sec. 171.101(b) to state that actors ``are subject to'' 45
CFR part 171 on and after April 5, 2021. We believe the additional five
months will enable actors to focus on the PHE, provide sufficient
additional time to thoroughly read and understand the ONC Cures Act
Final Rule, and educate their workforce about information blocking and
the exceptions contained in the final rule. However, at this time, we
do not believe the applicability date for 45 CFR part 171 should extend
beyond April 5, 2021. We believe this timeframe appropriately balances
the additional flexibility necessary due to the PHE with ONC's sense of
urgency in addressing information blocking. We emphasized the urgency
of addressing information blocking in the ONC Cures Act Final Rule. We
explained that, based on our findings from our 2015 Report to
Congress,\4\ 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 (85 FR 25652). Congress responded by enacting the Cures Act
on December 13, 2016, with many provisions specifying a need for swift
implementation. Implementation of the information blocking provisions
in the ONC Cures Act Final Rule will increase information sharing,
improve patient care, and ensure that a patient's health information
follows the patient--all of which are urgent goals, particularly during
a PHE. In addition, we also believe the applicability date should not
extend beyond April 5, 2021, because the information blocking
provisions do not contain any technical upgrade requirements that
necessitate a longer extension.
---------------------------------------------------------------------------
\4\ https://www.healthit.gov/sites/default/files/reports/info_blocking_040915.pdf.
---------------------------------------------------------------------------
We have revised Sec. 171.101(b) to codify the extended
applicability date for 45 CFR part 171. Section 171.101(b) now states
that health care providers, health IT developers of certified health
IT, health information exchanges, and health information networks are
subject to this part on and after April 5, 2021. Because we are
extending the applicability date for 45 CFR part 171 generally, we are
also updating the date by which actors must provide all EHI in response
to a request, rather than responding with only the data elements
represented in the USCDI. Consistent with our original intent to narrow
the scope of the EHI definition to just the data elements represented
in the USCDI for the first 18 months after the applicability date for
45 CFR part 171, in this IFC, we are also extending the end date for
this narrowed definition by 5 months. Therefore, for the 18-month
period on and after the April 5, 2021, applicability date and before
October 6, 2022, the EHI required in Sec. 171.101(b) will be limited
to the data represented in the USCDI. Thus actors will have additional
time to gain experience applying the exceptions with the narrower
definition of EHI, as compared to the full scope of EHI, which will
apply on and after October 6, 2022.
Therefore, we have revised Sec. 171.103(b) of the information
blocking definition to extend the period of time for which the EHI is
limited to the data elements represented in the USCDI. We state in
Sec. 171.103(b) that for the period before October 6, 2022, at a
minimum, the EHI identified for the purposes of the information
blocking definition in Sec. 171.103(a) is limited to the EHI
identified by the data elements represented in the USCDI standard
adopted in Sec. 170.213. Similarly, we revised and finalized the same
date in two paragraphs of the Content and Manner exception (Sec.
171.301(a)(1) and (2)). We find good cause to waive the notice and
comment procedures and delayed effective date requirements of the APA
as impracticable and contrary to the public interest due to the COVID-
19 PHE (5 U.S.C. 553(b)(B), (d)(3)). Please see sections II.C and III
of this IFC for further discussions of our good cause finding.
We have also revised Sec. 170.401 and Sec. 170.402. The ONC Cures
Act Final Rule required health IT developers of certified health IT to
comply with the Information Blocking Condition of Certification
requirement in Sec. 170.401, and the Assurances Condition of
Certification requirement related to information blocking in Sec.
170.402(a)(1), beginning on November 2, 2020. For the reasons stated
above, we have also provided an extension to these compliance dates.
Now, health IT developers must comply with the Condition of
Certification requirements in Sec. 170.401 and Sec. 170.402(a)(1)
beginning on April 5, 2021. We find good cause to waive the notice and
comment procedures and delayed effective date requirements of the APA
as impracticable and contrary to the public interest due to the COVID-
19 PHE (5 U.S.C. 553(b)(B), (d)(3)). Please see section III of this IFC
for further discussion of our good cause finding. This IFC finalizes
the extensions and we seek comment on the information blocking dates
and extensions that we adopt in this IFC.
2. Certain 2015 Edition Health IT Certification Criteria Updates
In light of the COVID-19 PHE, we are extending compliance dates and
timeframes for certain 2015 Edition certification criteria under 45 CFR
part 170. In the ONC Cures Act Final Rule, in general, we provided that
health IT developers of certified health IT have 24 months from the
publication date of the final rule to make technology certified to the
updated criteria available to their customers. We noted that, during
this time, developers could continue supporting technology certified to
the prior version of certification criteria for use by their customers
(85 FR 25666).
To allow the health care system time to focus on the COVID-19 PHE,
we are extending the timeline for certain 2015 Edition certification
criteria (please see Table 2 below) until December 31, 2022, and until
December 31, 2023, for Sec. 170.315(b)(10), ``EHI export''. This
represents an extension of nearly eight months beyond the original
compliance dates finalized in the ONC Cures Act Final Rule and nearly
an additional five months beyond the period of enforcement discretion
ONC announced on April 21, 2020.\5\ As discussed above, we considered
several factors as we determined the appropriate date to which to
extend the compliance dates.
---------------------------------------------------------------------------
\5\ https://www.healthit.gov/curesrule/resources/enforcement-discretion.
---------------------------------------------------------------------------
To determine that December 31, 2022, as well as December 31, 2023,
for ``EHI Export'' (Sec. 170.315(b)(10)), are appropriate compliance
dates for updating certain 2015 Edition Cures Update certification
criteria, we considered a number of factors. The updated certification
criteria require health IT developers to upgrade their current
technology in order to maintain or earn their certified status. Some of
the upgrades may require training staff or providers on how to
operationalize the updated certification criteria. We want to provide
additional flexibilities for the health care system to respond to the
public health threats posed by the COVID-19 PHE, and to reduce the
burden in administrative efforts associated with staff attending any
necessary trainings or with incorporating the updated technology into
their operations. Accordingly, we are delaying the compliance date for
developers to transition to the updated standards in the 2015 Edition
Cures Update certification criteria. This extension will delay the
burden that health IT developers would incur from being required to
make the updated health IT available to their customers. This delay
will enable these providers
[[Page 70070]]
and developers to continue using technology certified to the current
versions of the certification criteria with which they are already
familiar for an extended period, allowing for greater flexibility in
choosing when to implement updated technology. Developers should have
greater leeway to ensure the costs of meeting the 2015 Edition Cures
Update certification criteria compliance dates do not impair efforts to
fight the COVID-19 PHE.
We have included in Table 2 (below) the 2015 Edition Cures Update
certification criteria with new compliance dates. Note that ``ONC-
ACBs'' refers to ONC-Authorized Certification Bodies.
Table 2--2015 Edition Cures Update
----------------------------------------------------------------------------------------------------------------
Impact on CMS
2015 Edition cures Promoting
Certification criteria Reference update--timing Interoperability (PI)
programs
----------------------------------------------------------------------------------------------------------------
Transitions of Care............... Sec. 170.315(b)(1)........... Update to adopted PI Measures:
USCDI/C-CDA --Support Electronic
companion guide by Referral Loops by
December 31, 2022. Sending Health
Information.
--Support Electronic
Referral Loops by
Receiving and
Incorporating Health
Information.
Clinical information Sec. 170.315(b)(2)........... Update to adopted PI Measures: Support
reconciliation and incorporation. USCDI/C-CDA Electronic Referral
companion guide by Loops by Receiving
December 31, 2022. and Incorporating
Health Information.
Electronic prescribing............ Sec. 170.315(b)(3)........... Update to adopted PI Measures:
NCPDP SCRIPT --e-Prescribing.
standard version --Query of PDMP.
2017071 by December
31, 2022.
Data Export....................... Sec. 170.315(b)(6)........... ONC-ACBs may only Removed from 2015
issue certificates Edition Base EHR
for this criterion definition effective
for the period date of the final
before December 31, rule (60 days after
2023. publication).
Security tags--summary of care-- Sec. 170.315(b)(7)........... Document, section,
send. and entry (data
element) level; or
Document level for
the period before
December 31, 2022.
Security tags--summary of care-- Sec. 170.315(b)(8)........... Document, section,
receive. and entry (data
element) level; or
Document level for
the period before
December 31, 2022.
Care plan......................... Sec. 170.315(b)(9)........... Update to C-CDA
companion guide
referenced in Sec.
170.205(a)(4) and
Sec.
170.205(a)(5) by
December 31, 2022.
EHI export........................ Sec. 170.315(b)(10).......... Certify to new
criterion by
December 31, 2023.
Clinical quality measures (CQMs)-- Sec. 170.315(c)(3)........... Update to CMS QRDA PI Programs.
report. Category I/III IG
by December 31,
2022.
Auditable events and tamper- Sec. 170.315(d)(2)........... Update to ASTM 2147-
resistance. 18 standard by
December 31, 2022.
Audit report(s)................... Sec. 170.315(d)(3)........... Update to ASTM 2147-
18 standard by
December 31, 2022.
Auditing actions on health Sec. 170.315(d)(10).......... Update to ASTM 2147-
information. 18 standard by
December 31, 2022.
View, Download, and Transmit to Sec. 170.315(e)(1)........... Update to USCDI PI Measure: Provide
3rd Party. referenced in Sec. Patients Electronic
170.213 and C-CDA Access to Their
companion guide Health Information.
referenced in Sec.
170.205(a)(4) and
Sec.
170.205(a)(5) by
December 31, 2022.
Transmission to public health Sec. 170.315(f)(5)........... Update to USCDI PI Measure:
agencies--electronic case referenced in Sec. Electronic Case
reporting. 170.213 by Reporting.
December 31, 2022.
Consolidated CDA creation Sec. 170.315(g)(6)........... Update to USCDI
performance. referenced in Sec.
170.213 and C-CDA
companion guide
referenced in Sec.
170.205(a)(4) and
Sec.
170.205(a)(5) by
December 31, 2022.
Application Access--Data Category Sec. 170.315(g)(8)........... ONC-ACBs may only PI Measure: Provide
Request. issue certificates Patients Electronic
for this criterion Access to Their
for the period Health Information.
before December 31,
2022.
Application Access--All Data Sec. 170.315(g)(9)........... Update to USCDI PI Measure: Provide
Request. referenced in Sec. Patients Electronic
170.213 and C-CDA Access to Their
companion guide Health Information.
referenced in Sec.
170.205(a)(4) and
Sec.
170.205(a)(5) by
December 31, 2022.
[[Page 70071]]
Standardized API for patient and Sec. 170.315(g)(10).......... Certify to new Added to the 2015
population services. criterion by Edition Base EHR
December 31, 2022. definition.
PI Measure: Provide
Patients Electronic
Access to Their
Health Information.
----------------------------------------------------------------------------------------------------------------
3. Conditions and Maintenance of Certification Requirements Under the
ONC Health IT Certification Program
We have also extended compliance dates and timeframes for other
Conditions and Maintenance of Certification requirements in the ONC
Cures Act Final Rule to allow adequate time for our health care system
to address the COVID-19 PHE.
a. Assurances
Section 4002 of the Cures Act 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 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. In the ONC Cures Act Final Rule, we finalized
implementation of this provision through several Conditions of
Certification in Sec. 170.402(a) and accompanying Maintenance of
Certification requirements, which are set forth in Sec. 170.402(b). We
stated in the final rule that the Assurances Condition and Maintenance
of Certification requirements had an effective date of June 30, 2020.
We exercised enforcement discretion on April 21, 2020, to extend the
compliance date an additional three months to September 30, 2020.\6\
While we have not made a public announcement that we would be extending
our enforcement discretion for an additional period of time, we have
not taken any actions to enforce the Assurance Condition and
Maintenance of Certification requirements since September 30, 2020. In
this IFC, we are extending the compliance date and timeframe for the
Assurances Condition and Maintenance of Certification requirements
until April 5, 2021, to provide maximum flexibilities for our health
care system to respond to the public health threats posed by the COVID-
19 PHE. We find good cause to waive the notice and comment procedures
of the APA due to the COVID-19 PHE (as discussed in section III of this
IFC) (5 U.S.C. 553(b)(B)). Additionally, because affected parties are
best served by reducing the uncertainty that could result from
different compliance and applicability dates (information blocking-
related Conditions of Certification requirements and the information
blocking provisions (45 CFR part 171)) and because an immediate
effective date serves to reduce a burden on the regulated party by
allowing developers of health technology to immediately certify their
technology without meeting this new requirement, we find good cause to
waive the delayed effective date requirements (5 U.S.C. 553(d)). We are
also announcing that any actions or omissions of developers of
certified health IT that may have not been in compliance with these
Condition and Maintenance of Certification requirements since either
the effective date of the final rule or since the expiration of the
prior enforcement discretion period would not be subject to non-
compliance enforcement for those actions and omissions that occurred
during those time periods. In other words, we do not intend to engage
in Program enforcement for non-compliance between June 30, 2020, and
April 5, 2021.
---------------------------------------------------------------------------
\6\ https://www.healthit.gov/curesrule/resources/enforcement-discretion.
---------------------------------------------------------------------------
As we noted above, we have also extended the compliance date
related to Sec. 170.402 until April 5, 2021, except for Sec.
170.402(b)(2). In Sec. 170.402(b)(2), we extended the compliance date
to meet the requirement that a health IT developer must provide all of
its customers of certified health IT with health IT certified to the
``EHI export'' certification criterion in Sec. 170.315(b)(10) to
December 31, 2023.
b. Communications
In the ONC Cures Act Final Rule, we finalized in Sec. 170.403
provisions that permit developers to impose on communications certain
types of limited prohibitions and restrictions that strike a balance
between the need to promote open communication about certified health
IT and related developer business practices, and the need to protect
the legitimate business interests of health IT developers and others.
The provisions identify certain narrowly-defined 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. We
also finalized provisions that allow health IT developers certified
under the Program to place limitations on certain types of
communications, including screenshots and video. In the ONC Cures Act
Final Rule, the compliance date for the Communications Condition of
Certification requirements was the effective date of the final rule,
June 30, 2020. We exercised enforcement discretion on April 21, 2020,
to extend compliance for an additional three months to September 30,
2020.\7\ While we have not made a public announcement that we would be
extending our enforcement discretion for an additional period of time,
we have not taken any actions to enforce the Communications Condition
and Maintenance of Certification requirements since September 30, 2020.
In this IFC, we are extending the compliance date until April 5, 2021,
to allow additional time for the health care system to respond to
public health threats posed by the COVID-19 PHE. We find good cause to
waive the notice and comment procedures of the APA due to the COVID-19
PHE (as discussed in section III of this IFC) (5 U.S.C. 553(b)(B)).
Additionally, because affected parties are best served by reducing the
uncertainty that could result from different compliance and
applicability dates (information
[[Page 70072]]
blocking-related Conditions of Certification requirements and the
information blocking provisions (45 CFR part 171)) and because an
immediate effective date serves to reduce a burden on the regulated
party by allowing developers of health technology to immediately
certify their technology without meeting this new requirement, we find
good cause to waive the delayed effective date requirements (5 U.S.C.
553(d)). We are also announcing that any actions or omissions of
developers of certified health IT that may have not been in compliance
with these Condition and Maintenance of Certification requirements
since either the effective date of the final rule or since the
expiration of the prior enforcement discretion period would not be
subject to non-compliance enforcement for those actions and omissions
that occurred during those time periods. In other words, we do not
intend to engage in Program enforcement for non-compliance between June
30, 2020, and April 5, 2021.
---------------------------------------------------------------------------
\7\ https://www.healthit.gov/curesrule/resources/enforcement-discretion.
---------------------------------------------------------------------------
In the ONC Cures Act Final Rule, we also adopted Maintenance of
Certification requirements for health IT developers of certified health
IT in Sec. 170.403(b). Section 170.403(b)(2) states that a health IT
developer must not impose or enforce any contractual requirement that
contravenes the requirements of paragraph (a) of Sec. 170.403, the
Communications Condition of Certification. Furthermore, if a health IT
developer has contracts or agreements in existence that contravene the
requirements of the Condition of Certification, the developer must
notify all affected customers, other persons, or entities that the
prohibition or restriction within the contract or agreement will not be
enforced by the health IT developer (Sec. 170.403(b)(1)). In the ONC
Cures Act Final Rule, we stated that the developer must notify all
affected customers annually, beginning in 2020. Due to the COVID-19
PHE, we are suspending the notice requirement in Sec. 170.403(b)(1)
for 2020 only. Health IT developers of certified health IT with such
contracts or agreements must provide notice to all customers beginning
in 2021 and annually thereafter so long as those contracts or
agreements remain in place.
This limited suspension ensures that health IT developers will
still notify the users and customers of certified health IT in a timely
manner, and also relieves pressure on the developers to immediately
devote portions of their workforce to review contracts. We believe the
annual requirement, beginning with notification in calendar year 2021,
will simplify compliance for health IT developers while still providing
adequate notice in a reasonable amount of time. We have finalized the
deadline for the notice requirement in Sec. 170.403(b)(1) to be
annually, beginning in calendar year 2021.
c. Application Programming Interfaces
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.
The ONC Cures Act Final Rule captures both the technical functionality
and behaviors necessary to implement the Cures Act API Condition of
Certification requirement. Specifically, we adopted new standards, new
implementation specifications, a new certification criterion, and
modified the Base EHR definition. In addition, we finalized detailed
Condition and Maintenance of Certification requirements for health IT
developers.
For instance, in the ONC Cures Act Final Rule, we adopted a
requirement in Sec. 170.404(b)(4) that a Certified API Developer with
Health IT Module(s) certified to the certification criteria in Sec.
170.315(g)(7), (8), or (9) (ONC Certification Program API criteria)
must comply with Sec. 170.404(a) (API Condition of Certification
requirements) by no later than November 2, 2020 (85 FR 25765). We
exercised enforcement discretion on April 21, 2020, to extend
compliance for an additional three months.\8\ In this IFC, we are
extending the compliance date until April 5, 2021, so that the health
care system can focus on addressing the COVID-19 PHE. We align the new
compliance date for this provision with other dates that had a November
2, 2020 compliance date in the ONC Cures Act Final Rule. Setting a more
delayed compliance date would have unreasonably delayed and ultimately
diminished the benefits of the Program requirements we have finalized
in the ONC Cures Act Final Rule.
---------------------------------------------------------------------------
\8\ https://www.healthit.gov/curesrule/resources/enforcement-discretion.
---------------------------------------------------------------------------
We also stated in the ONC Cures Act Final Rule in Sec.
170.404(b)(3) that Certified API Developers with API technology
previously certified to the criterion in Sec. 170.315(g)(8) must
provide API technology certified to Sec. 170.315(g)(10) to all API
Information Sources deployed with certified API technology by no later
than May 1, 2022 (85 FR 25765). In this IFC, we are extending the
compliance timeline for that rollout of new standardized API
functionality under Sec. 170.404(b)(3) to December 31, 2022. We are
also revising the dates in Sec. 170.102, in the definition of 2015
Edition Base EHR, to be consistent with this extension.
As stated above, we believe extending the compliance date for this
requirement by eight months is appropriate so that health IT developers
and health care providers may adequately allocate time and resources to
address the COVID-19 PHE.
d. 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 their decisions to acquire certified health IT.
In the ONC Cures Act Final Rule, we established in Sec. 170.405
real world testing requirements that include Maintenance of
Certification requirements to update Health IT Modules certified to
certain certification criteria (see Sec. 170.405(b)(3) through (7) and
(10)) to ensure the technology meets its users' needs for widespread
and continued interoperability. We provide details on the 2015 Edition
Cures Update certification criteria in section II.A.2 above. We are
extending the compliance dates for updating these criteria until
December 31, 2022 (and until December 31, 2023, for Sec.
170.315(b)(10), ``EHI export'').
Under real world testing Condition and Maintenance of Certification
requirements, health IT developers must also submit publicly available
annual real world testing plans and results for health IT certified to
the criteria identified in Sec. 170.405(a). In the ONC
[[Page 70073]]
Cures Act Final Rule, we stated that developers must submit plans by
December 15 of each calendar year and results by March 15 of each
calendar year to ONC for public availability (85 FR 25773 and 25774).
Due to the COVID-19 PHE, developers are modifying their technology in
ways that are needed to support the health care system in this country.
Rather than taking resources from that essential work, in this IFC, we
are extending the compliance dates for submitting initial real world
testing plans to December 15, 2021, and initial real world testing
results to March 15, 2023.
e. Attestations
In the ONC Cures Act Final Rule, in Sec. 170.406, we stated that
health IT developers must attest twice a year to compliance with the
Conditions and Maintenance of Certification requirements (except for
the EHR reporting criteria submission requirement) (85 FR 25648). We
believe requiring attestations every six months under Sec. 170.406(b)
will properly balance the need to support appropriate enforcement with
our desire to minimize the burden on health IT developers. In light of
the COVID-19 PHE and extensions provided for other Conditions and
Maintenance of Certification requirements, in this IFC, we are
extending our annual cycle for attestations by one year, to calendar
year 2022. To clarify, due to the extensions provided for other
Conditions and Maintenance of Certification requirements in this IFC,
the first attestation window will continue to cover an irregular time
period from the effective date of the final rule through the extended
date of March 31, 2022. Subsequently, a regular six-month period will
commence with the next attestation window.
We believe that delaying the implementation of these Condition and
Maintenance of Certification requirements will allow health IT
developers additional time to comply with the requirements and provides
appropriate flexibility so that our health care system may adequately
respond to the current COVID-19 PHE.
4. Updates to ONC-ACB Dates and Timeframes
In the ONC Cures Act Final Rule, we finalized several certification
criteria changes that were accompanied by compliance dates and
timeframes. As we stated previously, due to the COVID-19 PHE, this IFC
extends certain compliance dates and timeframes for those new and
updated certification criteria and Condition and Maintenance of
Certification Requirements. Consequently, for purposes of coordination,
we are also extending compliance dates and timeframes for the
appropriate provisions applicable to the ONC--Authorized Certification
Bodies (ACBs).
In the ONC Cures Act Final Rule, we finalized in Sec.
170.523(p)(3) that ONC-ACBs must submit real world testing plans by
December 15 of each calendar year and results by March 15 of each
calendar year to ONC for public availability. Because we are now
extending those dates for health IT developers, we are also extending
the dates by which ONC-ACBs must submit the real world testing plans
and results to ONC for public availability. ONC-ACBs must now submit
initial plans to ONC by December 15, 2021, and initial results by March
15, 2023.
We had also finalized in Sec. 170.550(m)(2) and (3) a time-limited
certification status for certain 2015 Edition certification criteria.
We finalized that an ONC-ACB may only issue a certification to a Health
IT Module and permit continued certified status for Sec. 170.315(b)(6)
and (g)(8) until May 1, 2023, and May 2, 2022, respectively. To reflect
the extension of compliance dates and timeframes, we are now finalizing
in Sec. 170.550(m)(2) and (3) that an ONC-ACB may only issue a
certification to a Health IT Module and permit continued certified
status for Sec. 170.315(b)(6) and (g)(8) until December 31, 2023, and
December 31, 2022, respectively.
Lastly, in the ONC Cures Act Final Rule, we finalized that for
criteria being updated from the Common Clinical Data Set (CCDS) to the
USCDI, a transition from the CCDS to the USCDI must occur no later than
24 months after the publication date of the final rule. We stated that
for the period up to 24 months after the publication date of the ONC
Cures Act Final Rule, the CCDS remains permissible for certified Health
IT Modules until such Health IT Modules are updated to the USCDI. Due
to the extension of compliance dates for certain 2015 Edition Cures
Update certification criteria (we refer readers to section II.A.2), we
are also providing an extension such that for certified Health IT
Modules, the CCDS may remain applicable up to December 31, 2022, when
such Health IT Modules are updated to the USCDI.
We believe these revisions are appropriate and align with the
extended compliance dates and timelines for related certification
criteria and Program requirements.
B. Standards Updates
1. USCDI
In the ONC Cures Act Final Rule, we published the USCDI version 1
(v1) to replace the CCDS as the standard patient data set in several
ONC certification criteria.\9\ Through the USCDI v1 we added new data
classes, including Allergies and Intolerances, Clinical Notes, and
Provenance; and added data elements to Patient Demographics and Vital
Signs. In USCDI v1, we also defined applicable terminology standards to
represent respective data elements, where appropriate. In the ONC Cures
Act Final Rule, we adopted into the USCDI additional data classes and
data elements, with the applicable standards thus replacing CCDS. With
the exception of the Medication class and Medication Allergies data
element, we neither proposed nor intended to change applicable
standards relevant to the CCDS data elements. However, we included in
the USCDI v1 \10\ new applicable terminology standards that were
neither previously required for the CCDS nor presented for addition or
change through the rulemaking process. Several stakeholders commented
on and objected to these unexpected changes to the applicable
standards, and ONC concurred with these comments. Therefore, we
published the USCDI v1 (July 2020 Errata) \11\ to address these
concerns, to make the necessary corrections to the standards, and to
describe the changes over the original USCDI v1. We are adopting and
incorporating by reference the updated standard USCDI v1 (July 2020
Errata) in this IFC.
---------------------------------------------------------------------------
\9\ https://www.healthit.gov/cures/sites/default/files/cures/2020-03/USCDI.pdf.
\10\ https://www.healthit.gov/isa/sites/isa/files/2020-03/USCDI-Version1-2020-Final-Standard.pdf.
\11\ https://www.healthit.gov/isa/sites/isa/files/2020-07/USCDI-Version-1-July-2020-Errata-Final.pdf.
---------------------------------------------------------------------------
2. US Core Implementation Guide
We adopted the HL7[supreg] FHIR[supreg] US Core Implementation
Guide STU3 Release 3.1.0 (US Core IG 3.1.0) as part of the ONC Cures
Act Final Rule testing and certification requirements for the Sec.
170.315(g)(10) standardized API for patient and population services
certification criterion. Since publication of the ONC Cures Act Final
Rule, the health IT standards community has identified and resolved
several technical issues, editorial copy/paste errors, omissions, and
places in need of minor clarification in the US Core IG 3.1.0. The
health IT standards community has also published a revised HL7 FHIR US
[[Page 70074]]
Core Implementation Guide STU3 Release 3.1.1 (US Core IG 3.1.1) with
technical errata to address these updates. We are adopting the US Core
IG 3.1.1 in Sec. 170.215(a)(2) in order to support industry
standardization around the latest version of the US Core IG.
C. Corrections and Clarifications to the ONC Cures Act Final Rule
In Federal Register document 2020-07419 (85 FR 25642), the ONC
Cures Act Final Rule, we identified certain inadvertent errors
following publication in the Federal Register on May 1, 2020. In this
IFC, we are correcting these errors and providing clarification. As we
discuss in further detail below, we find good cause to waive the notice
and comment (and, for certain corrections, the delayed effective date)
requirements of the Administrative Procedure Act (APA), 5 U.S.C. 553(b)
and (d). We believe adherence to these APA requirements would be
impracticable, unnecessary, or contrary to the public interest for
these corrections and clarifications, and explain below our reasoning
for each.
It is important for our final rules to be written clearly and
accurately, and to reflect the final policies we adopted after
considering the public comments we received on our proposals.
Inadvertent errors such as these could be confusing to regulated
individuals and entities that are subject to the ONC Cures Act Final
Rule. Failure to correct these errors and provide clarifications could
place unnecessary burden on regulated parties as they attempt to comply
with the final rule. We summarize and correct these errors and offer
the necessary clarifications below.
1. General Applicability and Applicability of Standards and
Implementation Specifications for Health Information Technology
As noted in the ONC Cures Act Final Rule, the Cures Act amended
title XXX of the PHSA to establish the ``Communications'' condition of
certification, which applies to ``health information technology'' (85
FR 25733). 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 adopted this definition of ``health
information technology'' in Sec. 170.102 in the ONC Cures Act Final
Rule (85 FR 25733). However, in Sec. 170.101 and Sec. 170.200, we
neglected to update the language to say ``health information
technology.'' Instead, we erroneously kept the reference to ``Health IT
Modules.'' We, therefore, are updating this language in this IFC. As
these are clarifications and not substantive corrections, we find good
cause to waive the notice and comment procedures of the APA as
unnecessary (5 U.S.C. 553(b)(B)).
2. Standards for Health Information Technology To Protect Electronic
Health Information Created, Maintained, and Exchanged
a. Record Actions Related to Electronic Health Information, Audit Log
Status, and Encryption of End-User Devices
In the ONC Cures Act Final Rule (85 FR 25708), we inadvertently
referred to the auditable events and tamper-resistance standard as
``ASTM E1247-18''. The error occurs twice on that page. The correct
standard is ASTM E2147-18, which is what we included in the relevant
regulatory text.
We also inadvertently omitted amendatory text for Sec.
170.210(e)(2)(i) and (e)(3) (85 FR 25940). Because we updated the
standard in Sec. 170.210(h) to ASTM E2147-18, we have also updated the
requirements in Sec. 170.210(e) to align with the new numbering
sequence of the updated standard. However, we inadvertently neglected
to update the same reference language for the ASTM data elements in
Sec. 170.210(e)(2)(i) and (e)(3). Therefore, we are correcting Sec.
170.210(e)(2)(i) and (e)(3) by replacing ``7.2 and 7.4,'' which
referred to the previous ASTM standard, with ``7.1.1 and 7.1.7,'' which
refers to the updated ASTM E2147-18 standard. This does not constitute
a change in requirements, but simply a change to where those
requirements are referenced within the updated ASTM E2147-18 standard.
The correction of typographic errors does not constitute a substantive
change, and we, therefore, find good cause to waive the public notice
and comment procedures of the APA as unnecessary (5 U.S.C. 553(b)(B)).
In addition, the new numbering of the ASTM data elements led to
another error. The ONC Cures Act Final Rule included the requirement
for Health IT Modules to support 7.1.3 Duration of Access in the ASTM
E2147-18 standard. However, we have determined this will not be a
requirement for testing and certifying to 2015 Edition Cures Update
certification and we are removing it from the regulatory text. The
requirement added a significant burden for health IT developers and it
was not our intent to add burden beyond the requirements to update to
the new ASTM E2147-18 standard. Our intent, as proposed and stated in
the preamble, was simply to update the standards' numbering in our
Program for certification and testing to conform with the new numbering
set by the standards organization itself (``. . . the updated standard
reinforces what we have previously required and maintained with
previous certification requirements and note that there is no
substantial change to the standard'' 85 FR 25708). After publication of
the ONC Cures Act Final Rule, we heard from health IT developers who
noted that we had errantly included 7.1.3 Duration of Access, a
requirement we did not intend to include as part of the Program at this
time. In fact, requiring developers of certified health IT to certify
to 7.1.3 would substantially increase the development costs and time.
While the other related requirements for auditable events and tamper
resistance require basic data like ``date and time of access,'' the
duration of access certification criteria would require substantial
updates to all health technology to record and preserve more data than
previously required. In response, we immediately clarified in sub-
regulatory guidance (the certification companion guide for auditable
events and tamper-resistance) that this requirement will not be in
scope for certification or testing. Since our intent, as proposed and
discussed, was to incorporate requirements similar to those previously
required, 7.1.3 Duration of Access in the ASTM E2147-18 was errantly
included. The correction of typographic errors does not constitute a
substantive change, and we, therefore, find that there is good cause to
waive the notice and comment procedures of the APA as unnecessary (5
U.S.C. Sec. 553(b)(B)).
b. Synchronized Clocks
Section 170.210(g) (Synchronized clocks) included a reference to
Request for Comment (RFC) 1305 Network Time Protocol, a standard
maintained by the Internet Engineering Task Force (IETF). However,
prior to the release of the ONC Cures Act NPRM, IETF obsoleted RFC 1305
and replaced it with RFC 5905, which is backward compatible with RFC
1305. In this IFC, we removed the reference to RFC 1305 in Sec.
170.210(g). Because the obsolete standard is no longer maintained by
its standard organization and is therefore no longer publically
recognized as the current
[[Page 70075]]
standard for common internet protocols, and because the removal of the
RFC 1305 standard and the replacement with the current RFC 5905
standard were both previously available for public input through IETF's
open standards process, we find good cause to waive the notice and
comment procedures of the APA as unnecessary (5 U.S.C. Sec.
553(b)(B)). To note, RFC 5905 Network Time Protocol Version 4
(incorporated by reference in Sec. 170.299) was already approved for
Sec. 170.210 on September 4, 2012.
3. Applicability of Certification Criteria for Health Information
Technology
In the ONC Cures Act Final Rule, we removed the 2014 Edition from
the CFR (85 FR 25656). We also finalized removal of terms and
definitions specific to the 2014 Edition from Sec. 170.102, including
the ``2014 Edition Base EHR,'' ``2014 Edition EHR certification
criteria,'' and ``Complete EHR, 2014 Edition'' definitions (85 FR
25655). 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
removed references to ``Complete EHR'' from the regulation text. In the
ONC Cures Act Final Rule, consistent with our intent to remove all
terms specific to the 2014 Edition, we neglected to include the removal
of the term ``EHR Module.'' The term should have been corrected to say
``Health IT Module.'' We, therefore, now correct this error in Sec.
170.300(a) and (c). The correction of typographic errors does not
constitute a substantive change, and we, therefore, find that there is
good cause to waive the notice and comment procedures of the APA as
unnecessary (5 U.S.C. Sec. 553(b)(B)).
Consistent with our intent above to remove the 2014 Edition, in
Sec. 170.300(d), we neglected to remove the reference to Sec.
170.314. We corrected this error in this IFC by only referencing Sec.
170.315 in Sec. 170.300(d). Since we removed and reserved Sec.
170.314, referring to Sec. 170.314 in this section is misleading and
meaningless. The correction of typographic errors does not constitute a
substantive change, and we, therefore, find that there is good cause to
waive the notice and comment procedures of the APA as unnecessary (5
U.S.C. Sec. 553(b)(B)).
4. Electronic Prescribing
As discussed in the ONC Cures Act Final Rule, an
RxFillIndicatorChange is sent by a prescriber to a pharmacy to indicate
to the pharmacy that the prescriber is changing the types of RxFill
transactions that were previously requested, modifying their status, or
canceling future transactions (85 FR 25682). We requested comment on
this transaction in the 21st Century Cures Act: Interoperability,
Information Blocking, and the ONC Health IT Certification Program
Proposed Rule (84 FR 7444) and ultimately adopted it as optional in the
ONC Cures Act Final Rule. However, in the regulation text, we
inadvertently used the transaction ``RxFillIndicator'' (85 FR 25942).
Therefore, in Sec. 170.315(b)(3)(ii)(B)(2), we are correcting the
transaction to ``RxFillIndicatorChange.'' The correction of typographic
errors does not constitute a substantive change, and we, therefore,
find that there is good cause to waive the notice and comment
procedures of the APA as unnecessary (5 U.S.C. Sec. 553(b)(B)).
5. Clinical Quality Measures--Report Criterion
In the ``Updates to the 2015 Edition Certification Criteria''
section of the ONC Cures Act Final Rule, we noted that we only adopted
two new technical certification criteria in Sec. 170.315(b)(10) (EHI
export) and Sec. 170.315(g)(10) (Standardized API for patient and
population services) to which health IT developers seeking to upgrade
their products will need to present Health IT Modules for certification
(85 FR 25665). We also included Sec. 170.315(c)(3) (Clinical quality
measures--report) in the list of criteria that currently apply to
certified Health IT Modules that CMS program participants use. We
stated that, in general, health IT developers of certified health IT
have 24 months from the publication date of the ONC Cures Act Final
Rule to make technology certified to these updated certification
criteria available to their customers, and during this time developers
may continue supporting technology certified to the prior version of
the ONC certification criteria for use by their customers (85 FR
25666). We intended for Sec. 170.315(c)(3) to also have a compliance
timeline of 24 months, but we erroneously omitted it from the
``clinical quality measures--report'' criterion section of the preamble
and the real world testing regulatory text.
For all of the other criteria we revised due to standards updates,
we allowed a 24-month compliance timeline. In Table 1--2015 Edition
Cures Update of the ONC Cures Act Final Rule (85 FR 25667), we
incorrectly included the timing for the revised criterion ``clinical
quality measures--report'' to be the effective date of the final rule,
which was 60 days after it was published in the Federal Register. Our
intent, as evidenced above in our description of the overarching
approach for all of the standards updates to the 2015 Edition criteria,
was to make the compliance timelines consistent for all of the revised
criteria and allow health IT developers 24 months from the date of
publication to update to the new standards. Therefore, to align with
the other revised criteria to relieve an impractical burden on
stakeholders and to allow for the extension that we discuss in section
II.A.2, the correct compliance timeline for the ``clinical quality
measures--report'' criterion is December 31, 2022. We reflect this
change in Sec. 170.405(b)(10) of the real world testing Maintenance of
Certification requirements, stating that health IT developers with
health IT certified to Sec. 170.315(c)(3) as of June 30, 2020, would
have to update such certified health IT to the revisions by December
31, 2022. The correction of typographic errors does not constitute a
substantive change, and we, therefore, find that there is good cause to
waive the notice and comment procedures of the APA as unnecessary (5
U.S.C. 553(b)(B)). Even if this change constituted a substantive
rulemaking subject to notice and comment procedures or delayed
effective date requirements, because it would be impractical and
unnecessary to request comment on such a change, we find good cause to
waive notice and comment procedures and delayed effective date
requirements of the APA (5 U.S.C. 553(b)(B), (d)).
CMS Quality Reporting Document Architecture Implementation Guides
In the ONC Cures Act Final Rule, we also failed to adopt the latest
versions of the CMS Quality Reporting Document Architecture (QRDA)
Implementation Guides (IGs) as we stated we would do in the Proposed
Rule (84 FR 7446). In the Proposed Rule, we stated at 85 FR 25687 that
``we propose to incorporate by reference in Sec. 170.299 the latest
annual CMS QRDA IGs'' and in the Cures Act Final Rule we stated at 85
FR 25689 that ``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.'' In order to align with our proposals and
requirements in the ONC Cures Act Final Rule, in this IFC, we are
adopting the standards for CMS clinical quality measure reporting in
Sec. 170.205(h)(3) and Sec. 170.205(k)(3) to the latest CMS QRDA
standards available at the time of the ONC Cures Act Final Rule
publication (May 1, 2020), which are included in the certification
criterion at
[[Page 70076]]
Sec. 170.315(c)(3). The 2020 CMS QRDA IGs we are adopting for testing
and certification align with changes CMS already requires health care
providers to use. We incorporate by reference at Sec. 170.299 the CMS
QRDA IGs, specifically the 2020 CMS QRDA I IG for Hospital Quality
Reporting,\12\ which published on December 3, 2019, and the 2020 CMS
QRDA III IG for Eligible Clinicians and Eligible Professionals,\13\
which published on April 30, 2020. These IGs were available prior to
the publication of the ONC Cures Act Final Rule, but we erroneously
included prior QRDA IGs. Specifically, in this IFC, we are adopting the
2020 CMS QRDA category I for inpatient measures at Sec. 170.205(h)(3)
and 2020 CMS QRDA category III for ambulatory measures at Sec.
170.205(k)(3). We waive the notice and comment period for this change
as it is unnecessary, because the change ensures that the regulations
accurately reflect the policies we proposed, the public commented on,
and that we then finalized in the ONC Cures Act Final Rule. We note
that CMS programs may independently require the implementation and use
of the most up-to-date CMS QRDA specifications prior to the December
31, 2022 deadline.
---------------------------------------------------------------------------
\12\ https://ecqi.healthit.gov/sites/default/files/QRDA-HQR-2020-CMS-IG-v1.1-508.pdf.
\13\ https://ecqi.healthit.gov/sites/default/files/2020-CMS-QRDA-III-Eligible-Clinicians-and-EP-IG-v1.2.1-508.pdf.
---------------------------------------------------------------------------
6. Multi-Factor Authentication
In Sec. 170.315(d)(13)(ii), we mistakenly used the word
``identify'' in the regulatory text related to multi-factor
authentication (85 FR 25943). We are correcting Sec.
170.315(d)(13)(ii) by replacing ``identify'' with the word
``identity.'' The correction of typographic errors does not constitute
a substantive change, and we therefore find that there is good cause to
waive the notice and comment procedures of the APA as unnecessary (5
U.S.C. Sec. 553(b)(B)).
7. Transmission to Public Health Agencies--Electronic Case Reporting
We erroneously included a requirement in the ONC Cures Act Final
Rule that health IT developers certifying to Sec. 170.315(f)(5) were
required to conform to the HL7 Clinical Document Architecture standard
and companion guide adopted in Sec. 170.205(a)(4) and (5). We did not
propose this change for Sec. 170.315(f)(5) in the ONC Cures Act
Proposed Rule (84 FR 7443 and 7591), and intended only to finalize a
requirement that health IT developers certifying to Sec. 170.315(f)(5)
are required to conform to data classes expressed in the standards in
Sec. 170.213 or the Common Clinical Data Set for the period before
December 31, 2022 (see 84 FR 7441). Because the application of these
standards would completely change the certification requirements to the
``electronic case reporting'' criterion and impose a significant
development burden for developers, and because the standards were not
proposed, we are revising the regulation text in Sec. 170.315(f)(5)
and Sec. 170.405(b)(3) to correct this clear error. Specifically, we
have removed the words ``and in accordance with Sec. 170.205(a)(4) and
(5),'' from Sec. 170.315(f)(5)(iii)(B)(1) and ``in accordance with
Sec. 170.205(a)(4)'' from Sec. 170.315(f)(5)(iii)(B)(2), and
corrected the real world testing regulation text in Sec. 170.405(b)(3)
by removing the words ``for C-CDA'' from the title of the paragraph to
accommodate the corrections to Sec. 170.315(f)(5). As these revisions
do not constitute substantive changes to what we proposed, received
comment on, and intended to finalize, we find good cause to waive the
public notice and comment procedures of the APA as unnecessary.
8. Conditions and Maintenance of Certification Requirements for Health
IT Developers
a. Assurances
In Sec. 170.402(a)(4) of the ONC Cures Act Final Rule, there was a
typo: ``heath IT product'' (85 FR 25946). We are correcting the typo
``heath IT product'' to ``health IT product.'' The correction of
typographic errors does not constitute a substantive change, and we,
therefore, find that there is good cause to waive the notice and
commend procedures of the APA as unnecessary (5 U.S.C. Sec.
553(b)(B)).
b. Application Programming Interfaces--Clarification for Native
Applications and Refresh Tokens
In the ONC Cures Act Final Rule, we established an approach that
required Health IT Modules to issue refresh tokens to applications that
are ``capable of storing a client secret'' (85 FR 25945). We based our
approach on the standards and implementation specifications we adopted
for the Sec. 170.315(g)(10) certification criterion. After the
publication of the Cures Act Final Rule, health IT developers preparing
for testing and certification to the Sec. 170.315(g)(10) certification
criterion, as well as third-party application developers, requested
that we clarify this requirement.
Stakeholders identified that we had not fully explained how our
policy would apply to ``native applications,'' which, according to IETF
RFC 6749, are ``clients installed and executed on the device used by
the resource owner (i.e., desktop application, native mobile
application)'' and their interactions with OAuth 2.0 authorization
servers.\14\ These stakeholders noted that a strict interpretation of
the final rule could exclude native applications that use or are
capable of using additional technology that make them ``capable of
storing a client secret,'' or native applications that are capable of
securely handling a refresh token without needing a client secret.
Consequently, stakeholders indicated that the technical ambiguity
around native applications would negatively impact testing and
certification. Further, stakeholders contended that without timely and
explicit clarifications to native applications, health IT developers'
support for native applications would vary widely.
---------------------------------------------------------------------------
\14\ IETF RFC 6749: https://tools.ietf.org/html/rfc6749.
---------------------------------------------------------------------------
We agree with these concerns and that timely and additional
clarification is necessary. In our assessment, if such variation were
to occur, it would greatly affect the types of applications supported
by certified API technology in the next two years as compliance
timelines come into effect. Moreover, such a result would be contrary
to the public interest because it would contradict the intent of the
Cures Act and our implementation of the API Condition of Certification,
would negatively impact market competition, and would especially
disadvantage and limit patients' ability to access their electronic
health information without special effort. In the ONC Cures Act
Proposed Rule (84 FR 7481), we stated, ``The SMART Guide specifies the
use of `refresh tokens' as optional. We believe that this requirement
is necessary in order to enable persistent access by apps, especially
in a patient access context. Thus, we propose to make their use
mandatory with a minimum refresh token life of three months . . . we
wish to emphasize that implementing refresh token support is directly
intended to enable a patient's `persistent access' to their electronic
health information without special effort (i.e., without having to
frequently re-authenticate and re-authorize while using their preferred
app).'' Recognizing that patients will largely use smartphone
applications (native applications) to access their health information,
we would substantially limit patients' ability to access their
electronic health information without special effort if native
applications were categorically
[[Page 70077]]
excluded from enabling ``persistent access.'' By making this
clarification and revising the regulation text, we are ensuring that
the regulation best matches the policies commented on and then
finalized in the ONC Cures Act Final Rule. For these reasons, we find
good cause to waive the notice and comment procedures of the APA as
contrary to the public interest and unnecessary (5 U.S.C. 553(b)(B)).
Based on our analysis of the applicable standards and industry
practices,\15\ including the HL7[supreg] SMART Application Launch
Framework Implementation Guide Release 1.0.0 (SMART IG) (adopted in
Sec. 170.215(a)(3)), we identified that it is possible for native
applications to use secure storage capabilities and technologies on
mobile platforms to secure a refresh token, a client secret, or both.
Indeed, section 3.0.1 of the SMART IG provides examples of native
applications that can meet either the ``confidential app profile'' or
the ``public app profile.'' Examples of technologies native
applications can use to secure a refresh token, a client secret, or
both include operating system-specific features to register
application-claimed, private-use Uniform Resource Identifier (URI)
schemes as OAuth 2.0 redirect URIs,\16\ and technologies that enable
applications to securely store credentials through on-device
storage.\17\
---------------------------------------------------------------------------
\15\ RFC 6749 (https://tools.ietf.org/html/rfc6749) describes
native applications as ``clients installed and executed on the
device used by the resource owner (i.e., desktop applications, and
native mobile applications).'' IETF RFC 8252 (https://tools.ietf.org/html/rfc8252), referenced by the HL7[supreg] SMART
Application Launch Framework Implementation Guide Release 1.0.0
(SMART IG) (adopted in Sec. 170.215(a)(3)), updates RFC 6749 and
provides guidance for OAuth 2.0 authorization requests from native
applications. RFC 8252 describes technology and security practices
that can be used to enable native applications to securely
authenticate their identity and prevent well-documented security
threats. Notable examples include Dynamic Client Registration
Protocol (IETF RFC 7591) (https://tools.ietf.org/html/rfc7591) to
enable native applications to receive per-instance client secrets,
private-use URI scheme redirect URIs to support native apps to
verify their identity, and Proof Key for Code Exchange (PKCE) (IETF
RFC 7636) (https://tools.ietf.org/html/rfc7636) to secure the
authorization code during the authorization process.
\16\ For example, Android makes available ``App Links'' (https://developer.android.com/training/app-links) and iOS makes available
``Universal Links,'' (https://developer.apple.com/documentation/xcode/allowing_apps_and_websites_to_link_to_your_content) which
applications can use to register application-claimed, private URI
schemes as OAuth 2.0 redirect URIs.
\17\ For example, Android enables third-party application
developers to use technologies like the ``Keystore'' (https://developer.android.com/training/articles/keystore.html) for secure
storage on supported devices, and newer Apple devices contain a
``Secure Enclave'' (https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/storing_keys_in_the_secure_enclave) within their processors, which
third-party application developers can use for secure storage.
---------------------------------------------------------------------------
In response to these concerns, we have clarified and made the
regulation text consistent by adding a new paragraph in Sec.
170.315(g)(10)(v)(A)(1)(iii) and revising paragraphs Sec.
170.315(g)(10)(v)(A)(1)(ii) and Sec. 170.315(g)(10)(v)(A)(2)(ii). In
the new paragraph in Sec. 170.315(g)(10)(v)(A)(1)(iii), we have
specified that Health IT Modules' authorization servers must issue a
refresh token to native applications that are capable of securing a
refresh token. In Sec. 170.315(g)(10)(v)(A)(1)(ii) and Sec.
170.315(g)(10)(v)(A)(2)(ii), we have updated the regulation text to be
consistent with the paragraph we have added in Sec.
170.315(g)(10)(v)(A)(1)(iii) by specifying that a ``Health IT Module's
authorization server'' must issue a refresh token to applications that
are capable of storing a client secret. And in Sec.
170.315(g)(10)(v)(A)(2)(ii) we have updated the regulation text by
removing the word ``new'' preceding ``refresh token''. These updates
make the certification criterion clear and consistent, and disambiguate
the implications for native applications.
The requirement we have finalized in Sec.
170.315(g)(10)(v)(A)(1)(iii) addresses the technical ambiguity
regarding native applications that we discussed previously and
clarifies that Health IT Modules must support the issuance of an
initial refresh token to native applications that are capable of
securing a refresh token. As part of the requirements in Sec.
170.315(g)(10)(v)(A)(1)(iii), health IT developers must publish the
method(s) by which their Health IT Modules support the secure issuance
of an initial refresh token to native applications according to the
technical documentation requirements in Sec. 170.315(g)(10)(viii) and
transparency conditions in Sec. 170.404(a)(2). Additionally,
application developer attestations to health IT developers regarding
the ability of their applications to secure a refresh token, a client
secret, or both, must be treated in a good faith manner consistent with
the provisions established in the openness and pro-competitive
conditions in Sec. 170.404(a)(4).
We emphasize that health IT developers can determine the method(s)
they use to support interactions with native applications and we
clarify that health IT developers are not required to support all
methods that third-party application developers seek to use. Moreover,
while we have not specified that health IT developers use a standards-
based approach with respect to interactions with native applications,
we encourage the industry to coalesce around a single set of
requirements across all health IT developers.
In order to support the ability of end-users to persistently access
health information, we required in the ONC Cures Act Final Rule in
Sec. 170.315(g)(10)(v)(A)(2)(ii) that for subsequent connections, ``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.''
According to stakeholder feedback, the double use of ``new'' in the
regulation text has caused confusion and unintended over-interpretation
of the regulation text. As a result, we have removed the first ``new''
preceding ``refresh token,'' and clarify that the remaining ``new''
applies to the extended or renewed duration of the ``refreshed''
refresh token. The additional revisions we have made in Sec.
170.315(g)(10)(v)(A)(2)(ii) are simply stylistic changes to match the
language in our revisions in Sec. 170.315(g)(10)(v)(A)(1)(ii) and
Sec. 170.315(g)(10)(v)(A)(1)(iii). Such corrections are not
substantive, therefore, we find good cause to waive the notice and
comment procedures of the APA as unnecessary (5 U.S.C. 553(b)(B)).
Additionally, we clarify that the paragraph focused on ``First time
connections'' in Sec. 170.315(g)(10)(v)(A)(1) and the paragraph
focused on ``Subsequent connections'' in Sec. 170.315(g)(10)(v)(A)(2)
are aligned and that our policy for subsequent connections remains
unchanged. That is, Health IT Modules must issue a refresh token that
is valid for a new period of no less than three months to only
applications that are capable of storing a client secret. While the new
paragraph in Sec. 170.315(g)(10)(v)(A)(1)(iii) requires Health IT
Modules to issue an initial refresh token to native applications,
Health IT Modules may require native applications that can secure a
refresh token without a client secret to re-authenticate and re-
authorize after the initial refresh token expires. As this is a
clarification and not a substantive correction, we find good cause to
waive the notice and comment procedures of the APA as unnecessary (5
U.S.C. 553(b)(B)).
[[Page 70078]]
9. Principles of Proper Conduct for ONC-ACBs
In the ONC Cures Act Final Rule, we discussed removing Sec.
170.523(k)(2) (85 FR 25663). In the regulatory text, we removed Sec.
170.523(k)(2) to further reduce administrative burden for health IT
developers and ONC-ACBs, and included the instructions to do so (85 FR
25951). Because we removed Sec. 170.523(k)(2), the requirement in
Sec. 170.523(f)(1)(xxi) that the ONC-ACB include the attestation from
that section in its certified product listing should also have been
removed. We inadvertently omitted that removal from the amendatory
instructions for Sec. 170.523(f) (85 FR 25950). We are correcting the
error by removing the requirement in Sec. 170.523(f)(1)(xxi) because
the Principles of Proper Conduct for ONC-ACBs should accurately reflect
the policies we proposed, the public commented on, and that we then
finalized in the ONC Cures Act Final Rule. Further, because the remnant
has no meaning in the absence of the other provision, and can impose no
benefit or obligation, the correction of such errors does not
constitute a substantive change. As such, we therefore find that there
is good cause to waive the notice and comment procedures of the APA as
unnecessary (5 U.S.C. Sec. 553(b)(B)).
Additionally in the ONC Cures Act Final Rule, in the amendatory
instructions for Sec. 170.523, we instructed in step h that the phrase
``Complete EHR or'' be removed from paragraph (k)(1), but the phrase
specifically appeared in (k)(1)(i) (85 FR 25950). We corrected the
error and removed the phrase ``Complete EHR or'' from Sec.
170.523(k)(1)(i) in this IFC. Section 170.523(k)(1)(i) is also further
revised to remove the brackets before ``Complete EHR or'' and after
``Health IT Module'' (85 FR 25950). We have made this correction. The
correction of typographic errors does not constitute a substantive
change, and we therefore find that there is good cause to waive the
notice and comment procedures of the APA as unnecessary (5 U.S.C.
553(b)(B)).
10. Applicability of the Information Blocking Provisions
In the ONC Cures Act Final Rule preamble, we inadvertently stated
that health care providers, health IT developers of certified health
IT, health information exchanges, and health information networks
``must comply'' with 45 CFR part 171 by a particular date (85 FR
25793). We unintentionally used the same language in the regulation
text Sec. 171.101(b) (85 FR 25955). Because part 171 defines
information blocking and provides a series of voluntary exceptions to
that definition, it is more precise to say such actors ``are subject
to'' this part. We corrected Sec. 171.101(b) to replace ``must
comply'' with ``are subject to.'' Because this is primarily a
correction to an inadvertent use of language, and not a substantive
change, we, therefore, find that there is good cause to waive the
notice and comment procedures and delayed effective date requirements
of the APA as unnecessary (5 U.S.C. 553(b)(B), (d)(3)). Further, even
if this constituted a substantive change, for the reasons we stated
previously in this section II.C, we find good cause to waive the notice
and comment rulemaking process and delayed effective date for this
correction, because these requirements would be impracticable and
contrary to the public interest.
11. Information Blocking Definition and Security Exception
In the 21st Century Cures Act: Interoperability, Information
Blocking, and the ONC Health IT Certification Program Proposed Rule
(Proposed Rule), we considered a definition of information blocking
that included actions that ``interfere with, prevent or materially
discourage'' access, exchange or use of EHI, but ultimately we proposed
that the term ``interfere with'' was already inclusive of ``prevent''
and ``materially discourage'' (84 FR 7516). Similarly, in the preamble
to the ONC Cures Act Final Rule, in discussing the information blocking
definition, we determined that the terms ``interfere with'' and
``interference'' are themselves inclusive of both prevention and
material discouragement of access, exchange or use of EHI (85 FR
25809). Further, in Sec. 171.102, we defined ``Interfere with or
interference'' to include both ``prevent'' and ``materially
discourage'' (85 FR 25956). The definition of information blocking in
Sec. 171.103, therefore, should not include ``prevent, or materially
discourage.'' It is redundant and could confuse stakeholders who read
and commented on the Proposed Rule and read in the preamble of the ONC
Cures Act Final Rule that ``interfere with'' is inclusive of those
terms. We also failed to remove the words from the regulatory text for
the ``Security exception'' in Sec. 171.203(e)(2). Therefore, we have
corrected the definition of ``information blocking'' in Sec. 171.103
by removing the redundant phrase ``prevent, or materially discourage''
in two instances--Sec. 171.103(a)(2) and (a)(3) (85 FR 25956).
Further, in order to eliminate the same redundancy and to promote
clarity, we have corrected Sec. 171.203(e)(2) by removing the phrase
``prevent, or materially discourage'' (85 FR 25958). These corrections
are necessary to ensure the policies we discussed in the Proposed Rule
and finalized in the preamble of the ONC Cures Act Final Rule are
accurately and clearly reflected in the regulatory framework we
established. This correction imposes no further burden or obligation on
any party, and does not constitute a substantive change. For these
reasons, we find good cause to waive the notice and comment procedures
and delayed effective date requirements of the APA as unnecessary (5
U.S.C. 553(b)(B), (d)(3)).
When defining the actors to whom the definition of information
blocking would apply in the ONC Cures Act Final Rule, we finalized a
policy to use the term ``health IT developer of certified health IT.''
In doing so, we considered the many comments we received in response to
our proposed definition for that specific term in the Proposed Rule. We
extensively discussed the term ``health IT developer of certified
health IT,'' as well as the comments we received regarding the proposed
term and definition, in the preamble of the ONC Cures Act Final Rule
(85 FR 25795 through 25797). We finalized the definition of the term
``health IT developer of certified health IT'' itself, in Sec. 171.102
(85 FR 25956). We referred to ``health IT developers of certified
health IT'' in 45 CFR 171.101(a) and (b) in stating the applicability
of 45 CFR part 171. Thus, we made clear our explicit intent that the
definition of information blocking would only apply to developers of
certified health IT, not all health IT developers.
In the definition of information blocking itself in Sec. 171.103,
however, we erroneously used only the term ``health IT developer'' and
omitted the rest of the phrase (``of certified health IT''). We
proposed, received comment on, discussed and finalized specific
policies in regards to the regulatory definition of information
blocking and the meaning of ``health IT developer'' found in the
statutory information blocking definition. We finalized the policy for
the narrower definition ``health IT developer of certified health IT''
based on comments we received and for reasons we extensively discussed
in the preamble of the ONC Cures Act Final Rule. Therefore, we have
corrected Sec. 171.103(a)(2) to include the full phrase ``health IT
developer of certified health IT.'' By erroneously omitting the full
[[Page 70079]]
phrase, the regulation could have caused confusion and been read as
creating a burden on all developers of health IT, an expansion we
explicitly decided not to include in the ONC Cures Act Final Rule. For
the reasons we stated previously in this section II.C; and because this
error does not correctly reflect any policy proposed, commented on, or
finalized; and because it could be read to impose an immediate,
unnecessary burden on a large number of entities without notice, we
find good cause to waive the notice and comment rulemaking process and
delayed effective date requirements of the APA as unnecessary (5 U.S.C.
553(b)(B), (d)(3)).
12. Content and Manner Exception
In the ONC Cures Act Final Rule, we discussed the manner in which
actors must fulfill a request to access, exchange or use EHI. The
action is best characterized as ``fulfilling a request,'' which is how
we described it throughout the ONC Cures Act Final Rule, except for one
instance in the preamble when we erroneously used the word ``response''
instead (85 FR 25877). For the purpose of consistency, we clarify that
when an actor fulfills a request in any manner requested, any fees
charged by the actor in relation to fulfilling the request are not
required to satisfy the Fees Exception in Sec. 171.302. We also made
an error in the regulation text in Sec. 171.301(b)(1)(ii)(A), where we
inadvertently referred to an actor's practice of fulfilling a request
for EHI as ``fulfilling a response'' which is incorrect and an obvious
error (85 FR 25959). Therefore, we have corrected this phrase to read
``fulfilling a request.''
In addition, we clarify a typographical error in the ONC Cures Act
Final Rule preamble. At 85 FR 25877, we erroneously refer to Sec.
171.301(b)(2)(i)(a); the correct citation has a capitalized (A) instead
of lowercase (a).
The correction of these typographic errors does not constitute a
substantive change, and we, therefore, find that there is good cause to
waive the notice and comment procedures and delayed effective date
requirements of the APA as unnecessary (5 U.S.C. 553(b)(B), (d)(3)).
13. Licensing Exception
In Sec. 171.303(b)(2)(i), we erroneously cross-referenced
paragraph (c)(3) instead of the correct paragraph, (b)(3) (85 FR
25960). We have corrected the error. The correction of typographic
errors does not constitute a substantive change, and we therefore find
that there is good cause to waive the notice and comment procedures and
delayed effective date requirements of the APA as unnecessary (5 U.S.C.
553(b)(B), (d)(3)).
III. Waiver of Proposed Rulemaking, Comment Period, and Delay in
Effective Date
Under the Administrative Procedure Act (APA), 5 U.S.C. 553(b), an
agency is required to publish a notice of proposed rulemaking in the
Federal Register before the provisions of a rule take effect. In
addition, Sec. 553(d) mandates a 30-day delay in effective date after
issuance or publication of a rule. Sections 553(b)(B) and 553(d)(3)
provide for exceptions from the notice and comment and delay in
effective date requirements. Section 553(b)(B) authorizes an agency to
dispense with normal rulemaking requirements when the agency for good
cause finds that the notice and comment processes are impracticable,
unnecessary, or contrary to the public interest. In addition, Sec.
553(d)(3) allows the agency to waive the 30-day delay in effective date
for ``otherwise provided by the agency for good cause found and
published with the rule.''
The nation is experiencing an emergency of unprecedented magnitude.
This IFC directly supports that goal by offering regulated individuals
and entities flexibilities in complying with the ONC Cures Act Final
Rule while they are combating the COVID-19 pandemic. The IFC also helps
to ensure that sufficient health IT products and services are available
to meet the needs of affected health care systems, health care
providers, and individuals.
On January 30, 2020, the International Health Regulations Emergency
Committee of the WHO declared the outbreak of COVID-19 to be a Public
Health Emergency of International Concern.\18\ On January 31, 2020,
Secretary Azar declared a PHE \19\ under section 319 of the Public
Health Service Act (42 U.S.C. 247d), in response to COVID-19. On March
11, 2020, the WHO publicly declared COVID-19 to be a pandemic.\20\ On
March 13, 2020, the President declared that the COVID-19 outbreak in
the United States constitutes a national emergency,\21\ beginning March
1, 2020. Effective October 23, 2020, Secretary Azar renewed the January
31, 2020 determination that was previously renewed on April 21, 2020
and July 23, 2020 that a PHE for COVID-19 exists and has existed since
January 27, 2020.
---------------------------------------------------------------------------
\18\ https://www.who.int/news-room/detail/30-01-2020-statement-on-the-second-meeting-of-the-international-health-regulations-
(2005)-emergency-committee-regarding-the-outbreak-of-novel-
coronavirus-(2019-ncov).
\19\ https://www.phe.gov/emergency/news/healthactions/phe/Pages/2019-nCoV.aspx.
\20\ https://www.who.int/dg/speeches/detail/who-director-general-s-opening-remarks-at-the-media-briefing-on-covid-19-11-march-2020.
\21\ https://www.whitehouse.gov/presidential-actions/proclamation-declaring-national-emergency-concerning-novel-coronavirus-disease-covid-19-outbreak/.
---------------------------------------------------------------------------
As we discussed in section II.A above, it is critical that we
extend our support to the health care community, specifically those who
are affected by the ONC Cures Act Final Rule. In support of the
imperative to contain and combat the virus in the United States,
developers of health technology have raced to update their technology,
for example, to create new codes for COVID-19 and its associated
illnesses. Many developers are working to ensure that critical data
about infection rates, testing outcomes, and hospitalization rates are
accurate and are transmitted accurately to local, State and Federal
authorities. Further, health IT developers of certified health IT are
responding to requests from public health entities, health care
providers, and health care systems, asking for updates to, or
information about, the technology to help them better track, respond
and treat illnesses caused by COVID-19. Developers of certified health
IT are also exploring novel methods to help address the PHE using time
and resources that might otherwise have been used to upgrade their
technology. It is in the best interest of the public to ensure that
developers of certified health IT are able to respond in a dynamic and
rapid manner in order to assist the nation in confronting the PHE.
If these developers of certified health IT were required to update
their technology according to the timeline and deadlines in the ONC
Cures Act Final Rule, they would likely devote more time and resources
to ensuring their technology was upgraded and certified to avoid losing
customers and users. In doing so, they would have less time and fewer
resources to address the urgent and constantly changing technological
needs of health care providers, public health entities, and health care
systems dealing with the COVID-19 PHE. Further, even if the developers
of certified health IT were able to upgrade their technology to the
2015 Edition Cures Update by the original compliance dates, their
customers may require training and time to adapt to the new technology.
This is especially true for health care providers, who may not have
control over updates to the technology used in their care settings. It
is in the best interest of the
[[Page 70080]]
public that health care providers are able to combat COVID-19 PHE
without also having to manage the potential disruption that such
updates at this time could entail. Delaying the enforcement deadlines
and extending certain timelines ensures that the technology will be
updated at a time when the threat from the PHE has lessened and both
developers and health care providers would have the time and resources
to devote to these technology updates.
It is imperative that the health care community, including
developers of certified health IT, remain focused on addressing the
grave threat to public health posed by COVID-19. Therefore, we find
good cause to waive notice and comment rulemaking as we believe it
would be impracticable and contrary to the public interest for us to
undertake normal notice and comment rulemaking procedures. Furthermore,
because we cannot afford any delay in effectuating this IFC and do not
want to create unnecessary burdens on stakeholders who would otherwise
try to meet the November 2, 2020 compliance and applicability date for
various provisions of the ONC Cures Act Final Rule, we find good cause
to waive the 30-day delayed effective date for the information blocking
provisions and the Conditions and Maintenance of Certification
requirements related to information blocking, communications, and
assurances.
We are providing a 60-day public comment period for this IFC as
specified in the DATES section of this document.
IV. Incorporation by Reference
The Office of the Federal Register has established requirements for
materials (e.g., standards and implementation specifications) that
agencies incorporate by reference in the Code of Federal Regulations
(79 FR 66267; 1 CFR 51.5). Specifically, Sec. 51.5(b) requires
agencies to discuss, in the preamble of a final rule, the ways that the
materials they incorporate by reference are reasonably available to
interested parties and how interested parties can obtain the materials,
and to summarize, in the preamble of the final rule, the material they
incorporate by reference.
To make the materials we are incorporating by reference reasonably
available, we provide a uniform resource locator (URL) for the
standards. These standards are directly accessible through the URLs
provided. As an alternative, a copy of the standards may be viewed for
free at the U.S. Department of Health and Human Services, Office of the
National Coordinator for Health Information Technology, 330 C Street
SW, Washington, DC 20201. Please call (202) 690-7151 in advance to
arrange inspection.
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 require the use of, wherever practical, technical
standards that are developed or adopted by voluntary consensus
standards bodies to carry out policy objectives or activities, with
certain exceptions. The NTTAA and OMB Circular A-119 provide exceptions
to selecting only standards developed or adopted by voluntary consensus
standards bodies, namely when doing so would be inconsistent with
applicable law or otherwise impractical. As stated in the ONC Cures
Final Rule (85 FR 25668), we have followed the NTTAA and OMB Circular
A-119 in adopting standards and implementation specifications for
adoption, including describing any exceptions in the adoption of
standards and implementation specifications.
As required by 1 CFR 51.5(b), we provide a summary of the standards
we have adopted and incorporate by reference in the Code of Federal
Regulations (CFR). We also provide relevant information about the
standards throughout the preamble. We previously adopted IETF's Network
Time Protocol Version 4 (approved for incorporation by reference as of
September 4, 2012), which we continue to use without change.
We have organized the standards we have adopted through this
rulemaking according to the sections of the CFR in which they will be
codified and cross-referenced for associated certification criteria and
requirements that we have adopted.
Content Exchange Standards and Implementation Specifications for
Exchanging Electronic Health Information--45 CFR 170.205
CMS Implementation Guide for Quality Reporting Document
Architecture Category I Hospital Quality Reporting Implementation Guide
for 2020, December 3, 2019
URL: https://ecqi.healthit.gov/sites/default/files/QRDA-HQR-2020-CMS-IG-v1.1-508.pdf.
This is a direct access link.
Summary: This guide is a CMS Quality Reporting Document
Architecture Category I (QRDA I) implementation guide to the HL7
Implementation Guide for CDA Release 2: Quality Reporting Document
Architecture Category I, Release 1, Standards for Trial Use (STU)
Release 5 (published December 2017), and referred to as the HL7 QRDA IG
STU R5 in this guide. This guide describes additional conformance
statements and constraints for electronic health record (EHR) data
submissions that are required for reporting information to the CMS for
the Hospital Inpatient Quality Reporting Program 2020 Reporting Period.
The purpose of this guide is to serve as a companion to the base HL7
QRDA I STU R5 for entities such as Eligible Hospitals (EHs), CAHs, and
developers to submit QRDA I data for consumption by CMS systems
including for Hospital Quality Reporting (HQR).
CMS Implementation Guide for Quality Reporting Document
Architecture: Category III; Eligible Clinicians and Eligible
Professionals Programs; Implementation Guide for 2020, April 30, 2020
URL: https://ecqi.healthit.gov/sites/default/files/2020-CMS-QRDA-III-Eligible-Clinicians-and-EP-IG-v1.2-508.pdf.
This is a direct access link.
Summary: The Health Level Seven International (HL7) Quality
Reporting Document Architecture (QRDA) defines constraints on the HL7
Clinical Document Architecture Release 2 (CDA R2). QRDA is a standard
document format for the exchange of electronic clinical quality measure
(eCQM) data. QRDA reports contain data extracted from EHRs and other
information technology systems. The reports are used for the exchange
of eCQM data between systems for quality measurement and reporting
programs. This QRDA guide contains the CMS supplemental implementation
guide to the HL7 Implementation Guide for CDA Release 2: Quality
Reporting Document Architecture, Category III, STU Release 2.1 (June,
2017) for the 2020 performance period. This HL7 base standard is
referred to as the HL7 QRDA-III STU R2.1.
United States Core Data for Interoperability--45 CFR 170.213
The United States Core Data for Interoperability (USCDI), July
2020 Errata, Version 1 (v1)
URL: https://www.healthit.gov/USCDI.
This is a direct access link.
Summary: The United States Core Data for Interoperability (USCDI)
establishes a minimum set of data classes that are required to be
interoperable nationwide and is designed to be expanded in an iterative
and predictable way over time. Data classes listed in the USCDI are
[[Page 70081]]
represented in a technically agnostic manner.
Application Programming Interface Standards--45 CFR 170.215
HL7 FHIR US Core Implementation Guide STU Release 3.1.1,
August 28, 2020
URL: https://hl7.org/fhir/us/core/STU3.1.1/.
This is a direct access link.
Summary: The US Core Implementation Guide is based on FHIR Version
R4 and defines the minimum conformance requirements for accessing
patient data. The Argonaut pilot implementations, ONC 2015 Edition
Common Clinical Data Set (CCDS), and ONC U.S. Core Data for
Interoperability (USCDI) v1 provided the requirements for this guide.
The prior Argonaut search and vocabulary requirements, based on FHIR
DSTU2, are updated in this guide to support FHIR Version R4. This guide
was used as the basis for further testing and guidance by the Argonaut
Project Team to provide additional content and guidance specific to
Data Query Access for purpose of ONC Certification testing. These
profiles are the foundation for future US Realm FHIR implementation
guides. In addition to Argonaut, they are used by DAF-Research, QI-
Core, and CIMI. Under the guidance of HL7 and the HL7 US Realm Steering
Committee, the content will expand in future versions to meet the needs
specific to the US Realm.
V. Response to Comments
Because of the large number of public comments we normally receive
on Federal Register documents, we are not able to acknowledge or
respond to them individually. We will consider all comments we receive
by the date and time specified in the DATES section of this preamble,
and, when we proceed with a subsequent document, we will respond to the
comments in the preamble to that document.
VI. Collection of Information Requirements
This document does not impose information collection and
recordkeeping requirements. Consequently, it need not be reviewed by
the Office of Management and Budget under the authority of the
Paperwork Reduction Act of 1995 (44 U.S.C. 3501-3521).
VII. Regulatory Impact Analysis
A. Executive Orders 12866 and 13563
Executive Orders 12866 and 13563 direct agencies to assess all
costs and benefits of available regulatory alternatives and, if
regulation is necessary, to select regulatory approaches that maximize
net benefits (including potential economic, environmental, and public
health and safety effects; distributive impacts; and equity). A
regulatory impact analysis (RIA) must be prepared for major rules with
economically significant effects ($100 million or more in any 1 year).
To determine the impact of this rule, we reviewed the costs and
benefits in the ONC Cures Act Final Rule associated with the provisions
in this IFC. We did this to determine if adjustments to the ONC Cures
Act Final Rule's RIA were needed and should be accounted for in this
rule. We also explored whether there are new quantifiable and
unquantifiable costs and benefits as a direct result of the delays
proposed in the IFC.
The provisions in this IFC are limited in nature: Applicability and
compliance date extensions, standards updates, and regulatory
clarifications and corrections. Except as noted below, we were unable
to identify any new quantifiable costs or benefits as a result of the
provisions in this IFC. However, we welcome comments on the additional
impacts developers or other entities might experience as a result of
the delays noted in this IFC.
There are unquantifiable costs and benefits of this rule. The
extensions in this IFC are in response to developers' need for
additional time to meet the deadlines due, in part, to external
factors, such as COVID-19. However, we are unable to quantify the
extent to which such external factors including but not limited to,
temporary changes in labor and other supply chain costs/shortages due
to the pandemic--would affect the cost differential between compliance
according to the timeline set forth in this IFC and (hypothetically)
according to the timeline set forth in the ONC Cures Act Final Rule. We
acknowledge that we do not have any evidence or information from the
regulated community that they have been working to meet the
applicability and compliance dates identified in the ONC Cures Act
Final Rule. On April 21, 2020, we announced that we would exercise our
discretion in enforcing all new requirements under 45 CFR part 170 that
have compliance dates until 3 months after each initial compliance date
identified in the ONC Cures Act Final Rule. In addition, we noted in
the ONC Cures Act Final Rule that enforcement of information blocking
civil monetary penalties in section 3022(b)(2)(A) of the PHSA would not
begin until a final rule was issued by the Office of the Inspector
General (OIG), which has not occurred as of the publication of this
interim final rule. We also acknowledged in the Proposed Rule that any
health care provider determined by OIG to have committed information
blocking would, per the Cures Act, be referred to the appropriate
agency to be subject to appropriate disincentives using authorities
under applicable Federal law, as the Secretary sets forth through
notice and comment rulemaking. In the Proposed Rule, we requested
comment on potential disincentives (84 FR 7553). HHS has not, however,
issued a proposed rule to begin the process of establishing such
disincentives. Since the publication of the ONC Cures Act Final Rule,
we are not aware of any negative consequences that health IT developers
of certified health IT or other types of actors have experienced for
not complying with 45 parts 170 or 171, respectively. We request
comment on whether stakeholders did incur costs for trying to meet the
compliance dates in the ONC Cures Act Final Rule. We also invite
feedback on whether the COVID-19 PHE may have an impact on costs of
complying with 45 parts 170 and 171 in the future--taking into account
the new compliance and applicability dates established by this interim
final rule.
Additionally, we explored whether the delays in the IFC will have a
significant impact on the 10 year cost/benefit projections described in
the ONC Cures Act Final Rule. We note that several IFC provisions
implement a delay of less than one year from its original deadline.
However, the following IFC provisions have delays that are one year or
more:
[cir] Submission of initial Attestations (Sec. 170.406)
[cir] Submission of initial plans and results of real world testing
(Sec. 170.405(b)(1) and (2))
We previously estimated that the Year 1 quantifiable costs for these
provisions are $47,686,943 and the quantifiable benefits are
$310,450,000. Both the cost and benefit estimates were estimated to be
perpetual. Because this impact is over $100 million, it is sufficient
to make this IFC economically significant under E.O. 12866. The IFC's
changes have implications for the distribution of the costs and
benefits over time found in the ONC Cures Act Final Rule as described
above.
B. Regulatory Flexibility Act
The Regulatory Flexibility Act (RFA) requires agencies to analyze
options for regulatory relief of small businesses if a rule has a
significant impact on a
[[Page 70082]]
substantial number of small entities. We do not believe that the
changes in this IFC alter any of the prior analyses we performed for
the ONC Cures Act Final Rule; and therefore, the Secretary certifies
that this IFC will not have a significant impact on a substantial
number of small entities.
C. Executive Order 13771
The White House issued Executive Order 13771 on Reducing Regulation
and Controlling Regulatory Costs on January 30, 2017. This rule's
designation under 13771 will be informed by comments received.
D. Executive Order 13132--Federalism
Executive Order 13132 establishes certain requirements that an
agency must meet when it promulgates a final rule (including an interim
final rule with comment period) that imposes substantial direct
requirement costs on state and local governments, preempts state law,
or otherwise has federalism implications. Because this IFC does not
impose any costs on state or local governments, the requirements of
Executive Order 13132 are not applicable.
E. Unfunded Mandates Reform Act
Section 202 of the Unfunded Mandates Reform Act of 1995 (Unfunded
Mandates Act), 2 U.S.C. 1532, requires that covered agencies prepare a
budgetary impact statement before promulgating a rule that includes any
federal mandate that may result in the expenditure by state, local, and
tribal governments, in the aggregate, or by the private sector, of $100
million in 1995 dollars, updated annually for inflation. Currently,
that threshold is approximately $156 million. If a budgetary impact
statement is required, section 205 of the Unfunded Mandates Act also
requires covered agencies to identify and consider a reasonable number
of regulatory alternatives before promulgating a rule. This IFC is not
expected to result in expenditures by state, local, and tribal
governments, or by the private sector, of $156 million or more in any
one year.
List of Subjects
45 CFR Part 170
Computer technology, Electronic health record, Electronic
information system, Electronic transactions, Health, Health care,
Health information technology, Health insurance, Health records,
Hospitals, Incorporation by reference, Laboratories, Medicaid,
Medicare, Privacy, Reporting and recordkeeping requirements, Public
health, Security.
45 CFR Part 171
Computer technology, Electronic health record, Electronic
information system, Electronic transactions, Health, Health care,
Health care provider, Health information exchange, Health information
technology, Health information network, Health insurance, Health
records, Hospitals, Privacy, Reporting and recordkeeping requirements,
Public health, Security.
For the reasons set forth in the preamble, 45 CFR subtitle A,
subchapter D, is amended as follows:
PART 170--HEALTH INFORMATION TECHNOLOGY STANDARDS, IMPLEMENTATION
SPECIFICATIONS, AND CERTIFICATION CRITERIA AND CERTIFICATION
PROGRAMS FOR HEALTH INFORMATION TECHNOLOGY
0
1. The authority citation for part 170 continues to read as follows:
Authority: 42 U.S.C. 300jj-11; 42 U.S.C 300jj-14
0
2. Revise Sec. 170.101 to read as follows:
Sec. 170.101 Applicability.
The standards, implementation specifications, and certification
criteria adopted in this part apply to health information technology
and the testing and certification of Health IT Modules.
0
3. Amend Sec. 170.102 by revising paragraphs (3)(ii) and (iii) in the
definition of ``2015 Edition Base EHR'' to read as follows:
Sec. 170.102 Definitions.
* * * * *
2015 Edition Base EHR * * *
(3) * * *
(ii) Section 170.315(g)(8) or (10) for the period before December
31, 2022; and
(iii) Section 170.315(g)(10) on and after December 31, 2022.
* * * * *
0
4. Revise Sec. 170.200 to read as follows:
Sec. 170.200 Applicability.
The standards and implementation specifications adopted in this
part apply with respect to Health Information technology.
0
5. Amend Sec. 170.205 by revising paragraphs (h)(3) and (k)(3) to read
as follows:
Sec. 170.205 Content exchange standards and implementation
specifications for exchanging electronic health information.
* * * * *
(h) * * *
(3) Standard. CMS Implementation Guide for Quality Reporting
Document Architecture: Category I; Hospital Quality Reporting;
Implementation Guide for 2020 (incorporated by reference in Sec.
170.299).
* * * * *
(k) * * *
(3) Standard. CMS Implementation Guide for Quality Reporting
Document Architecture: Category III; Eligible Clinicians and Eligible
Professionals Programs; Implementation Guide for 2020 (incorporated by
reference in Sec. 170.299).
* * * * *
0
6. Amend Sec. 170.210:
0
a. In paragraph (e)(1)(i), by removing the words ``through 7.1.3'' and
adding in its place the words ``and 7.1.2'';
0
b. In paragraphs (e)(2)(i) and (e)(3), by removing the words ``7.2 and
7.4,'' and adding in their place the words ``7.1.1 and 7.1.7''; and
0
c. By revising paragraph (g).
The revision reads as follows:
Sec. 170.210 Standards for health information technology to protect
electronic health information created, maintained, and exchanged.
* * * * *
(g) Synchronized clocks. The date and time recorded utilize a
system clock that has been synchronized following (RFC 5905) Network
Time Protocol Version 4, (incorporated by reference in Sec. 170.299).
* * * * *
0
7. Revise Sec. 170.213 to read as follows:
Sec. 170.213 United States Core Data for Interoperability.
Standard. United States Core Data for Interoperability (USCDI),
July 2020 Errata, Version 1 (v1) (incorporated by reference in Sec.
170.299).
0
8. Amend Sec. 170.215 by revising (a)(2) to read as follows:
Sec. 170.215 Application Programming Interface Standards.
* * * * *
(a) * * *
(2) Implementation specification. HL7 FHIR[supreg] US Core
Implementation Guide STU 3.1.1 (incorporated by reference in Sec.
170.299).
0
9. Amend Sec. 170.299 by revising paragraphs (e)(4) and (5), (f)(34),
and (m)(5) to read as follows:
Sec. 170.299 Incorporation by reference.
* * * * *
(e) * * *
(4) CMS Implementation Guide for Quality Reporting Document
Architecture: Category I; Hospital Quality Reporting Implementation
Guide for 2020; published December 3, 2019, IBR approved for Sec.
170.205(h).
(5) CMS Implementation Guide for Quality Reporting Document
[[Page 70083]]
Architecture: Category III; Eligible Clinicians and Eligible
Professionals Programs Implementation Guide for 2020; published April
30, 2020, IBR approved for Sec. 170.205(k).
* * * * *
(f) * * *
(34) HL7 FHIR[supreg] US Core Implementation Guide STU3 Release
3.1.1, August 28, 2020, IBR approved for Sec. 170.215(a).
* * * * *
(m) * * *
(5) United States Core Data for Interoperability (USCDI), Version
1, July 2020 Errata, IBR approved for Sec. 170.213; available at
https://www.healthit.gov/USCDI.
* * * * *
0
10. Amend Sec. 170.300 by revising paragraphs (a), (c), and (d) to
read as follows:
Sec. 170.300 Applicability.
(a) The certification criteria adopted in this subpart apply to the
testing and certification of Health IT Modules.
* * * * *
(c) Health Modules are not required to be compliant with
certification criteria or capabilities specified within a certification
criterion that are designated as optional.
(d) In Sec. 170.315, all certification criteria and all
capabilities specified within a certification criterion have general
applicability (i.e., apply to any health care setting) unless
designated as ``inpatient setting only'' or ``ambulatory setting
only.''
* * * * *
0
11. Amend Sec. 170.315 by:
0
a. Revising paragraphs (b)(1)(iii)(A)(2), (b)(2)(i), (b)(2)(iii)(D)
introductory text, (b)(2)(iv), (b)(3)(ii)(B)(2), (b)(7)(ii),
(b)(8)(i)(B), (b)(9)(ii), (c)(3), (d)(13)(ii), (e)(1)(i)(A)(2),
(f)(5)(iii)(B)(1) and (2), (g)(6)(i)(B), (g)(9)(i)(A)(2),
(g)(10)(v)(A)(1)(ii), and (g)(10)(v)(A)(2)(ii); and
0
b. Adding paragraph (g)(10)(iv)(A)(1)(iii).
The revisions and addition read as follows:
Sec. 170.315 2015 Edition health IT certification criteria.
* * * * *
(b) * * *
(1) * * *
(iii) * * *
(A) * * *
(2) The Common Clinical Data Set in accordance with Sec.
170.205(a)(4) and paragraph (b)(1)(iii)(A)(3)(i) through (iv) of this
section for the period before December 31, 2022, and
* * * * *
(2) * * *
(i) General requirements. Paragraphs (b)(2)(ii) and (iii) of this
section must be completed based on the receipt of a transition of care/
referral summary formatted in accordance with the standards adopted in
Sec. 170.205(a)(3) through (5) using the Continuity of Care Document,
Referral Note, and (inpatient setting only) Discharge Summary document
templates on and after December 31, 2022.
* * * * *
(iii) * * *
(D) Upon a user's confirmation, automatically update the list, and
incorporate the following data expressed according to the specified
standard(s) on and after December 31, 2022:
* * * * *
(iv) System verification. Based on the data reconciled and
incorporated, the technology must be able to create a file formatted
according to the standard specified in Sec. 170.205(a)(4) using the
Continuity of Care Document template and the standard specified in
Sec. 170.205(a)(5) on and after December 31, 2022.
(3) * * *
(ii) * * *
(B) * * *
(2) Send fill status notifications (RxFillIndicatorChange).
* * * * *
(7) * * *
(ii) Document level for the period before December 31, 2022.
(8) * * *
(i) * * *
(B) Document level for the period before December 31, 2022; and
* * * * *
(9) * * *
(ii) The standard in Sec. 170.205(a)(5) on and after December 31,
2022.
* * * * *
(c) * * *
(3) Clinical quality measures--report. Enable a user to
electronically create a data file for transmission of clinical quality
measurement data:
(i) 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
Sec. 170.205(h)(3) and CMS implementation guide for QRDA, category III
for ambulatory measures in Sec. 170.205 (k)(3); or
(ii) In accordance with the standards specified in Sec.
170.205(h)(2) and Sec. 170.205(k)(1) and (2) for the period before
December 31, 2022.
* * * * *
(d) * * *
(13) * * *
(ii) No--the Health IT Module does not support authentication,
through multiple elements, of the user's identity with the use of
industry-recognized standards. When attesting ``no,'' the health IT
developer may explain why the Health IT Module does not support
authentication, through multiple elements, of the user's identity with
the use of industry-recognized standards.
(e) * * *
(1) * * *
(i) * * *
(A) * * *
(2) The Common Clinical Data Set in accordance with Sec.
170.205(a)(4) and paragraphs (e)(1)(i)(A)(3)(i) through (iv) of this
section for the period before December 31, 2022.
* * * * *
(f) * * *
(5) * * *
(iii) * * *
(B) * * *
(1) The data classes expressed in the standard in Sec. 170.213, or
(2) The Common Clinical Data Set for the period before December 31,
2022.
* * * * *
(g) * * *
(6) * * *
(i) * * *
(B) The Common Clinical Data Set in accordance with Sec.
170.205(a)(4) and paragraphs (g)(6)(i)(C)(1) through (4) of this
section for the period before December 31, 2022.
* * * * *
(9) * * *
(i) * * *
(A) * * *
(2) The Common Clinical Data Set in accordance with paragraphs
(g)(9)(i)(A)(3)(i) through (iv) of this section for the period before
December 31, 2022, and
* * * * *
(10) * * *
(v) * * *
(A) * * *
(1) * * *
(ii) A Health IT Module's authorization server must issue a refresh
token valid for a period of no less than three months to applications
capable of storing a client secret.
(iii) A Health IT Module's authorization server must issue a
refresh token for a period of no less than three months to native
applications capable of securing a refresh token.
(2) * * *
(ii) A Health IT Module's authorization server must issue a refresh
token valid for a new period of no less
[[Page 70084]]
than three months to applications capable of storing a client secret.
* * * * *
0
12. Amend Sec. 170.401 by revising paragraph (a) to read as follows:
Sec. 170.401 Information blocking.
(a) Condition of Certification requirement. A health IT developer
must not take any action that constitutes information blocking as
defined in 42 U.S.C. 300jj-52 and Sec. 171.103 on or after April 5,
2021.
* * * * *
0
13. Amend by revising Sec. 170.402 by revising paragraphs (a)(1), (4)
and (b)(2) to read as follows:
Sec. 170.402 Assurances.
(a) * * *
(1) A health IT developer must provide assurances satisfactory to
the Secretary that the health IT developer will not take any action
that constitutes information blocking as defined in 42 U.S.C. 300jj-52
and Sec. 171.103 of this chapter on and after April 5, 2021, unless
for legitimate purposes as specified by the Secretary; or any other
action that may inhibit the appropriate exchange, access, and use of
electronic health information.
* * * * *
(4) 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 Sec. 170.315(b)(10).
(b) * * *
(2)(i) By December 31, 2023, a health IT developer that must comply
with the requirements of paragraph (a)(4) of this section must provide
all of its customers of certified health IT with the health IT
certified to the certification criterion in Sec. 170.315(b)(10).
(ii) On and after December 31, 2023, a health IT developer that
must comply with the requirements of paragraph (a)(4) of this section
must provide all of its customers of certified health IT with the
health IT certified to the certification criterion in Sec.
170.315(b)(10).
0
14. Amend Sec. 170.403 by revising (b)(1) to read as follows:
Sec. 170.403 Communications.
* * * * *
(b) * * *
(1) Notice. Health IT developers must issue a written notice to all
customers and those with which it has contracts or agreements
containing provisions that contravene paragraph (a) of this section
annually, beginning in calendar year 2021, until paragraph (b)(2)(ii)
of this section is fulfilled, stating that any communication or
contract provision that contravenes paragraph (a) of this section will
not be enforced by the health IT developer.
* * * * *
0
15. Amend Sec. 170.404 by revising (b)(3) and (4) to read as follows:
Sec. 170.404 Application programming interfaces.
* * * * *
(b) * * *
(3) Rollout of (g)(10)-certified APIs. A Certified API Developer
with certified API technology previously certified to the certification
criterion in Sec. 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 Sec.
170.315(g)(10) by no later than December 31, 2022.
(4) Compliance for existing certified API technology. By no later
than April 5, 2021, a Certified API Developer with Health IT Module(s)
certified to the certification criteria in Sec. 170.315(g)(7), (8), or
(9) must comply with paragraph (a) of this section, including revisions
to their existing business and technical API documentation and make
such documentation available via a publicly accessible hyperlink that
allows any person to directly access the information without any
preconditions or additional steps.
* * * * *
0
16. Amend Sec. 170.405 by:
0
a. Revising paragraphs (b)(1) introductory text, (b)(2)(ii)
introductory text, (b)(3) introductory text, (b)(4)(ii), (b)(5)(ii),
(b)(6)(ii), and (b)(7)(ii); and
0
b. Adding paragraph (b)(10).
The revisions and addition read as follows:
Sec. 170.405 Real world testing.
* * * * *
(b) * * *
(1) Real world testing plan submission. A health IT developer with
Health IT Module(s) certified to any one or more of the criteria
referenced in paragraph (a) of this section must submit to its ONC-ACB
an annual real world testing plan addressing each of those certified
Health IT Modules by a date determined by the ONC-ACB that enables the
ONC-ACB to publish a publicly available hyperlink to the plan on CHPL
no later than December 15 of each calendar year, beginning in 2021.
* * * * *
(2) * * *
(ii) For real world testing activities conducted during the
immediately preceding calendar year, a health IT developer must submit
to its ONC-ACB an annual real world testing results report addressing
each of its certified Health IT Modules that include certification
criteria referenced in paragraph (a) of this section by a date
determined by the ONC-ACB that enables the ONC-ACB to publish a
publicly available hyperlink to the results report on CHPL no later
than March 15 of each calendar year, beginning in 2023. The real world
testing results must report the following for each of the certification
criteria identified in paragraph (a) of this section that are included
in the Health IT Module's scope of certification:
* * * * *
(3) USCDI Updates. A health IT developer with health IT certified
to Sec. 170.315(b)(1), (b)(2), (e)(1), (g)(6) and/or (g)(9) on May 1,
2020, must:
* * * * *
(ii) Provide its customers of the previously certified health IT
with certified health IT that meets paragraph (b)(3)(i) of this section
by December 31, 2022.
(4) * * *
(ii) Provide its customers of the previously certified health IT
with certified health IT that meets paragraph (b)(4)(i) of this section
by December 31, 2022.
(5) * * *
(ii) Provide its customers of the previously certified health IT
with certified health IT that meets paragraph (b)(5)(i) of this section
by December 31, 2022.
(6) * * *
(ii) Provide its customers of the previously certified health IT
with certified health IT that meets paragraph (b)(6)(i) of this section
by December 31, 2022.
(7) * * *
(ii) Provide its customers of the previously certified health IT
with certified health IT that meets paragraph (b)(7)(i) of this section
by December 31, 2022.
* * * * *
(10) Clinical quality measures--report. A health IT developer with
health IT certified to Sec. 170.315(c)(3) prior to June 30, 2020,
must:
(i) Update their certified health IT to be compliant with the
revised versions of this criteria adopted in Sec. 170.315(c)(3); and
(ii) Provide its customers of the previously certified health IT
with certified health IT that meets paragraph (b)(10)(i) of this
section by December 31, 2022.
0
17. Amend Sec. 170.523 by:
0
a. Removing and reserving paragraph (f)(1)(xxi); and
[[Page 70085]]
0
b. Revising paragraphs (k)(1) introductory text and (k)(1)(i).
The revisions read as follows:
Sec. 170.523 Principles of proper conduct for ONC-ACBs.
* * * * *
(k) * * *
(1) Mandatory Disclosures. A health IT developer must conspicuously
include the following on its website and in all marketing materials,
communications statements, and other assertions related to the Health
IT Module's certification:
(i) The disclaimer ``This Health IT Module is [specify Edition of
health IT certification criteria] compliant and has been certified by
an ONC-ACB in accordance with the applicable certification criteria
adopted by the Secretary of Health and Human Services. This
certification does not represent an endorsement by the U.S. Department
of Health and Human Services.''
* * * * *
0
18. Amend Sec. 170.550 by revising paragraphs (m)(1), (2), and (3) to
read as follows:
Sec. 170.550 Health IT Module certification.
* * * * *
(m) * * *
(1) Section 170.315(a)(10) and (13) and Sec. 170.315(e)(2) for the
period before January 1, 2022.
(2) Section 170.315(b)(6) for the period before December 31, 2023.
(3) Section 170.315(g)(8) for the period before December 31, 2022.
PART 171--INFORMATION BLOCKING
0
19. The authority citation for part 171 continues to read as follows:
Authority: 42 U.S.C. 300jj-52
0
20. Amend Sec. 171.101 by revising paragraph (b) to read as follows:
Sec. 171.101 Applicability.
* * * * *
(b) Health care providers, health IT developers of certified health
IT, health information exchanges, and health information networks are
subject to this part on and after April 5, 2021.
0
21. Amend Sec. 171.103 by revising paragraphs (a)(2), (a)(3) and (b)
to read as follows:
Sec. 171.103 Information blocking.
(a) * * *
(2) If conducted by a health IT developer of certified health IT,
health information network or health information exchange, such
developer, network or exchange knows, or should know, that such
practice is likely to interfere with access, exchange, or use of
electronic health information; or
(3) If conducted by a health care provider, such provider knows
that such practice is unreasonable and is likely to interfere with
access, exchange, or use of electronic health information.
* * * * *
(b) For the period before October 6, 2022, electronic health
information for the purposes of paragraph (a) of this section is
limited to the electronic health information identified by the data
elements represented in the USCDI standard adopted in Sec. 170.213.
* * * * *
0
22. Amend Sec. 171.203 by revising paragraph (e)(2) to read as
follows:
Sec. 171.203 Security exception--When will an actor's practice that
is likely to interfere with the access, exchange, or use of electronic
health information in order to protect the security of electronic
health information not be considered information blocking?
* * * * *
(e) * * *
(2) There are no reasonable and appropriate alternatives to the
practice that address the security risk that are less likely to
interfere with access, exchange or use of electronic health
information.
0
23. Amend Sec. 171.301 by revising paragraphs (a)(1), (a)(2) and
(b)(1)(ii)(A) to read as follows:
Sec. 171.301 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 electronic
health information not be considered information blocking?
* * * * *
(a) * * *
(1) USCDI. For the period before October 6, 2022, at a minimum, the
electronic health information identified by the data elements
represented in the USCDI standard adopted in Sec. 170.213.
(2) All electronic health information. On and after October 6,
2022, electronic health information as defined in Sec. 171.102.
(b) * * *
(1) * * *
(ii) * * *
(A) Any fees charged by the actor in relation to fulfilling the
request are not required to satisfy the exception in Sec. 171.302; and
* * * * *
0
24. Amend Sec. 171.303 by revising paragraph (b)(2)(i) to read as
follows:
Sec. 171.303 Licensing exception--When will an actor's practice to
license interoperability elements in order for electronic health
information to be accessed, exchanged, or used not be considered
information blocking?
* * * * *
(b) * * *
(2) * * *
(i) The royalty must be nondiscriminatory, consistent with
paragraph (b)(3) of this section.
* * * * *
Alex M. Azar II,
Secretary, Department of Health and Human Services.
[FR Doc. 2020-24376 Filed 11-2-20; 8:45 am]
BILLING CODE 4150-45-P
