[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