[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. http://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 http://www.regulations.gov.
Docket: For access to the docket to read background documents or
comments received, go to http://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: http://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