2020-24376. 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 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).

On January 30, 2020, the International Health Regulations Emergency Committee of the World Health Organization (WHO) declared the outbreak a “Public Health Emergency of international concern.” On January 31, 2020, pursuant to section 319 of the Public Health Service Act (PHSA), Health and Human Services Secretary, Alex M. Azar II, determined that a Public Health Emergency (PHE) exists for the United States to aid the nation's health care community in responding to COVID-19. On March 11, 2020, the WHO publicly declared COVID-19 a pandemic. On March 13, 2020, the President of the United States declared the COVID-19 pandemic a national emergency. Effective October 23, 2020, Secretary Azar renewed the January 31, 2020 determination that was previously renewed on April 21, 2020 and July 23, 2020 that a PHE for COVID-19 exists and has existed since January 27, 2020.

As the health care community establishes and implements recommended infection prevention and control practices, regulatory agencies—under appropriate waiver authority granted by the declaration of the COVID-19 PHE—are also working to revise regulations to allow the health care community to focus on the PHE. We believe that the ONC Cures Act Final Rule should be revised to offer the health care system additional flexibilities in furnishing services to combat the COVID-19 pandemic. On April 21, 2020, concurrent with Secretary Azar's first renewal of the determination of a PHE, ONC announced a policy of enforcement discretion to allow compliance flexibilities regarding the implementation of the ONC Cures Act Final Rule in response to the COVID-19 PHE.^[2] We stated our intention to exercise enforcement discretion for three months at the end of certain ONC Health IT Certification Program (Program) compliance dates associated with the ONC Cures Act Final Rule to provide flexibility while ensuring the goals of the rule remain on track. In this IFC, we are extending the applicability date for the information blocking provisions and some compliance dates in the Program, including dates for certain updated 2015 Edition health IT certification criteria and Conditions and Maintenance of Certification requirements. The extensions in this IFC for information blocking and the Program are longer than the three month extension that was announced in the April 21, 2020 enforcement discretion statement for the Program. These additional flexibilities for development and implementation enable our health care system to focus on addressing the COVID-19 PHE, while still maintaining a trajectory that will advance patients' access to their health information, reduce the cost of care, and improve the quality of care. This IFC also updates certain standards in the Program, and makes necessary corrections and clarifications to the ONC Cures Act Final Rule, which was published in the Federal Register on May 1, 2020 (85 FR 25642), and became effective on June 30, 2020.

II. Provisions of the Interim Final Rule With Comment Period

A. Extension of Compliance Dates and Timeframes

The ONC Cures Act Final Rule fosters innovation in health care to deliver better information, more conveniently, to patients and their providers. It also promotes transparency through technology, providing opportunities for the American public to gain visibility into the services, quality, and costs of health care.

The ONC Cures Act Final Rule includes provisions that require support for modern computing standards and application programming interfaces (APIs). These technical provisions will inject competition into health care by promoting an entrepreneurial economy and new business models using smartphone apps to provide novel services and choices in care. The ONC Cures Act Final Rule will also make sure health information follows a patient by preventing industrywide information blocking practices and other anti-competitive behavior by those entrusted to hold patients' electronic health information (EHI).

In the ONC Cures Act Final Rule, we set applicability and compliance dates for certain provisions of the regulations. In light of the COVID-19 PHE, in this IFC, ONC is extending the applicability date for the information blocking provisions and compliance dates and timeframes for certain Program requirements, including compliance dates for certain 2015 Edition health IT certification criteria and Conditions and Maintenance of Certification requirements. These additional flexibilities for development and implementation will enable our health care system to focus on addressing the COVID-19 PHE, while continuing to advance policies that will promote patients' access to their EHI and enable greater data exchange.

We have also heard from stakeholders and organizations representing clinicians, hospitals, health systems and health information technology developers requesting an extension for the applicability and compliance dates. These stakeholders expressed concern over meeting the information blocking applicability date of November 2, 2020. They stated that the COVID-19 PHE continues to monopolize their time and attention, and has strained resources, drastically limiting their ability to prepare for the November 2nd information blocking date.

In an effort to minimize any burden or confusion for developers and providers, we have aligned the extensions around three distinct dates. For ease of comparison, in Table 1 below, we have added the dates from the ONC Cures Act Final Rule, the dates in the April 21, 2020 enforcement discretion announcement, and the dates in this IFC.

Table 1—Applicability and Compliance Dates

Provision	Final rule	Enforcement discretion announcement	Interim final rule with comment period
Information Blocking Overall Applicability Date—(45 CFR part 171) 3	November 2, 2020	N/A—No Change	April 5, 2021.
Condition of Certification (CoC)—Information Blocking—(§ 170.401)	November 2, 2020	3 months after the compliance timeframe
CoC—Assurances—(§ 170.402(a)(1))—Will not take any action that constitutes information blocking or actions that inhibit access, exchange, and use of electronic health information (EHI)	November 2, 2020	3 months after the compliance timeframe
CoC—Assurances—(§ 170.402(a)(2) and (3), and (b)(1))—Other	Effective date: June 30, 2020	Enforcement discretion expired 3 months after the effective date of the final rule
CoC—Communications—(§ 170.403)—Communications requirements, except for § 170.403(b)(1) where we removed the notice requirement for 2020	Effective date: June 30, 2020	Enforcement discretion expired 3 months after the effective date of the final rule
CoC—API—(§ 170.404(b)(4))—Compliance for current API criteria	November 2, 2020	3 months after the compliance timeframe
CoC—API—(§ 170.404(b)(3))—Rollout of new standardized API functionality	May 2, 2022	3 months after the compliance timeframe	December 31, 2022.
CoC—Real World Testing—2015 Edition health IT certification criteria with standards updates	May 2, 2022	3 months after the compliance timeframe
CoC—Assurances—(§ 170.402(a)(4) and (b)(2))—EHI Export Rollout	May 1, 2023	3 months after the compliance timeframe	December 31, 2023.
CoC—Communications—(§ 170.403(b)(1))—Notice to all customers with which developer has contracts or agreements containing provisions that contravene Communications CoC	Annually beginning in calendar year 2020	Notice can be made until March 31, 2021, for the 2020 calendar year	Begin annual cycle 1 year later. CY 2021.
CoC—Initial Attestations—(§ 170.406)	April 1-30, 2021 attestation window for attestation period running June 30, 2020, through March 31, 2021	Generally remains the same except for the initial attestation, which will now be accepted through July 30, 2021	Begin annual cycle 1 year later. CY 2022.
CoC—Real World Testing—(§ 170.405(b)(1) and (2)) Submit initial plan and initial results submission	Plan: December 15, 2020 Results: March 15, 2022.	Initial Plan: Initial RWT plans (i.e., 2021 RWT plans) may be submitted through March 15, 2021 Initial Results: Initial RWT results from the 2021 performance year may be submitted up through June 2022.	Begin annual cycle 1 year later. Initial Plan: December 15, 2021. Initial Results: March 15, 2023.

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 § 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 § 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 while still providing adequate notice in a reasonable amount of time. We have finalized the deadline for the notice requirement in § 170.403(b)(1) to be annually, beginning in calendar year 2021.

Other extensions are limited because of the positive outcomes we anticipate from certain provisions. For example, the information blocking provisions in 45 CFR 171 are critical to ensuring patients are able to access their EHI when and where they need it. Therefore, the extensions for most of the information blocking provisions are limited to April 5, 2021, for two reasons. First and foremost, we must balance the need to provide actors with more time to address the PHE with the ultimate goal of making EHI more accessible to improve the cost and quality of care. Second, unlike some of the 2015 Edition Cures Update certification criteria, the information blocking provisions do not explicitly require actors to purchase or update certified health IT, so there is less of a concern about technology resource allocations in the near term.

In other instances, a close review of the ONC Cures Act Final Rule in light of the PHE led us to conclude that some provisions would be better served by lengthier extensions. For example, we are extending until December 31, 2022, the compliance date for the 2015 Edition Cures Update certification criteria (85 FR 25666 through 25667). The updated certification criteria require health IT developers to upgrade their current technology in order to maintain or earn their certified status. Developers have been allocating resources to ensure their technology meets the new needs of their customers (e.g., health care providers and health care systems) including, for example, the ability to collect and report COVID-19 data. However, health IT developers are also not currently in a situation to be able to successfully rollout and test the certification criteria with their customers because the health care system has been focused on fighting the COVID-19 PHE. Developers, therefore, should have greater leeway to ensure the costs of meeting the 2015 Edition Cures Update certification criteria compliance dates do not impair efforts to fight the COVID-19 PHE. Further, certified health IT serves an important public good: Hospitals, patients and public health networks rely on certified health IT. If ONC does not grant an appropriate extension for developers to comply with the 2015 Edition Cures Update, some health IT developers may decide not to seek re-certification, or forego certification altogether, if they determine they do not have the 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 (§ 171.103) and the Content and Manner Exception (§ 171.301(a)) narrowed the scope of the EHI definition to include only the EHI identified by the data elements represented in the United States Core Data for Interoperability (USCDI) for the first 18 months after the compliance date for 45 CFR part 171. Therefore, in addition to the six-month 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 § 171.103 and the Content and Manner Exception in § 171.301(a), if an actor did not, in the first 24 months after the ONC Cures Act Final Rule's publication date, enable access, exchange, or use of data outside the USCDI, or did not appropriately apply an exception to data outside the USCDI, such practice or “error” would not be considered information blocking because that data would not be considered “EHI” during that time period (85 FR 25792).

We also stated that the compliance dates for the Information Blocking Condition of Certification requirement in § 170.401 and the Assurances Condition of Certification requirement in § 170.402(a)(1) would be six months after the publication date of the final rule in the Federal Register, i.e., November 2, 2020.

In light of the PHE, we believe it is necessary to offer additional flexibilities. Therefore, in this IFC, we are extending the date for 45 CFR part 171 from November 2, 2020, to April 5, 2021. We also believe it is more precise to refer to this date as the applicability date for 45 CFR part 171 instead of the compliance date. Accordingly, in section II.C.7 of this IFC, we are revising § 171.101(b) to state that actors “are subject to” 45 CFR part 171 on and after April 5, 2021. We believe the additional five months will enable actors to focus on the PHE, provide sufficient additional time to thoroughly read and understand the ONC Cures Act Final Rule, and educate their workforce about information blocking and the exceptions contained in the final rule. However, at this time, we do not believe the applicability date for 45 CFR part 171 should extend beyond April 5, 2021. We believe this timeframe appropriately balances the additional flexibility necessary due to the PHE with ONC's sense of urgency in addressing information blocking. We emphasized the urgency of addressing information blocking in the ONC Cures Act Final Rule. We explained that, based on our findings from our 2015 Report to Congress,^[4] we concluded that information blocking is a serious problem and recommended that Congress prohibit information blocking and provide penalties and enforcement mechanisms to deter these harmful practices (85 FR 25652). Congress responded by enacting the Cures Act on December 13, 2016, with many provisions specifying a need for swift implementation. Implementation of the information blocking provisions in the ONC Cures Act Final Rule will increase information sharing, improve patient care, and ensure that a patient's health information follows the patient—all of which are urgent goals, particularly during a PHE. In addition, we also believe the applicability date should not extend beyond April 5, 2021, because the information blocking provisions do not contain any technical upgrade requirements that necessitate a longer extension.

We have revised § 171.101(b) to codify the extended applicability date for 45 CFR part 171. Section 171.101(b) now states that health care providers, health IT developers of certified health IT, health information exchanges, and health information networks are subject to this part on and after April 5, 2021. Because we are extending the applicability date for 45 CFR part 171 generally, we are also updating the date by which actors must provide all EHI in response to a request, rather than responding with only the data elements represented in the USCDI. Consistent with our original intent to narrow the scope of the EHI definition to just the data elements represented in the USCDI for the first 18 months after the applicability date for 45 CFR part 171, in this IFC, we are also extending the end date for this narrowed definition by 5 months. Therefore, for the 18-month period on and after the April 5, 2021, applicability date and before October 6, 2022, the EHI required in § 171.101(b) will be limited to the data represented in the USCDI. Thus actors will have additional time to gain experience applying the exceptions with the narrower definition of EHI, as compared to the full scope of EHI, which will apply on and after October 6, 2022.

Therefore, we have revised § 171.103(b) of the information blocking definition to extend the period of time for which the EHI is limited to the data elements represented in the USCDI. We state in § 171.103(b) that for the period before October 6, 2022, at a minimum, the EHI identified for the purposes of the information blocking definition in § 171.103(a) is limited to the EHI identified by the data elements represented in the USCDI standard adopted in § 170.213. Similarly, we revised and finalized the same date in two paragraphs of the Content and Manner exception (§ 171.301(a)(1) and (2)). We find good cause to waive the notice and comment procedures and delayed effective date requirements of the APA as impracticable and contrary to the public interest due to the COVID-19 PHE (5 U.S.C. 553(b)(B), (d)(3)). Please see sections II.C and III of this IFC for further discussions of our good cause finding.

We have also revised § 170.401 and § 170.402. The ONC Cures Act Final Rule required health IT developers of certified health IT to comply with the Information Blocking Condition of Certification requirement in § 170.401, and the Assurances Condition of Certification requirement related to information blocking in § 170.402(a)(1), beginning on November 2, 2020. For the reasons stated above, we have also provided an extension to these compliance dates. Now, health IT developers must comply with the Condition of Certification requirements in § 170.401 and § 170.402(a)(1) beginning on April 5, 2021. We find good cause to waive the notice and comment procedures and delayed effective date requirements of the APA as impracticable and contrary to the public interest due to the COVID-19 PHE (5 U.S.C. 553(b)(B), (d)(3)). Please see section III of this IFC for further discussion of our good cause finding. This IFC finalizes the extensions and we seek comment on the information blocking dates and extensions that we adopt in this IFC.

2. Certain 2015 Edition Health IT Certification Criteria Updates

In light of the COVID-19 PHE, we are extending compliance dates and timeframes for certain 2015 Edition certification criteria under 45 CFR part 170. In the ONC Cures Act Final Rule, in general, we provided that health IT developers of certified health IT have 24 months from the publication date of the final rule to make technology certified to the updated criteria available to their customers. We noted that, during this time, developers could continue supporting technology certified to the prior version of certification criteria for use by their customers (85 FR 25666).

To allow the health care system time to focus on the COVID-19 PHE, we are extending the timeline for certain 2015 Edition certification criteria (please see Table 2 below) until December 31, 2022, and until December 31, 2023, for § 170.315(b)(10), “EHI export”. This represents an extension of nearly eight months beyond the original compliance dates finalized in the ONC Cures Act Final Rule and nearly an additional five months beyond the period of enforcement discretion ONC announced on April 21, 2020.^[5] As discussed above, we considered several factors as we determined the appropriate date to which to extend the compliance dates.

To determine that December 31, 2022, as well as December 31, 2023, for “EHI Export” (§ 170.315(b)(10)), are appropriate compliance dates for updating certain 2015 Edition Cures Update certification criteria, we considered a number of factors. The updated certification criteria require health IT developers to upgrade their current technology in order to maintain or earn their certified status. Some of the upgrades may require training staff or providers on how to operationalize the updated certification criteria. We want to provide additional flexibilities for the health care system to respond to the public health threats posed by the COVID-19 PHE, and to reduce the burden in administrative efforts associated with staff attending any necessary trainings or with incorporating the updated technology into their operations. Accordingly, we are delaying the compliance date for developers to transition to the updated standards in the 2015 Edition Cures Update certification criteria. This extension will delay the burden that health IT developers would incur from being required to make the updated health IT available to their customers. This delay will enable these providers 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

Certification criteria	Reference	2015 Edition cures update—timing	Impact on CMS Promoting Interoperability (PI) programs
Transitions of Care	§ 170.315(b)(1)	Update to adopted USCDI/C-CDA companion guide by December 31, 2022	PI Measures: —Support Electronic Referral Loops by Sending Health Information. —Support Electronic Referral Loops by Receiving and Incorporating Health Information.
Clinical information reconciliation and incorporation	§ 170.315(b)(2)	Update to adopted USCDI/C-CDA companion guide by December 31, 2022	PI Measures: Support Electronic Referral Loops by Receiving and Incorporating Health Information.
Electronic prescribing	§ 170.315(b)(3)	Update to adopted NCPDP SCRIPT standard version 2017071 by December 31, 2022	PI Measures: —e-Prescribing. —Query of PDMP.
Data Export	§ 170.315(b)(6)	ONC-ACBs may only issue certificates for this criterion for the period before December 31, 2023	Removed from 2015 Edition Base EHR definition effective date of the final rule (60 days after publication).
Security tags—summary of care—send	§ 170.315(b)(7)	Document, section, and entry (data element) level; or Document level for the period before December 31, 2022
Security tags—summary of care—receive	§ 170.315(b)(8)	Document, section, and entry (data element) level; or Document level for the period before December 31, 2022
Care plan	§ 170.315(b)(9)	Update to C-CDA companion guide referenced in § 170.205(a)(4) and § 170.205(a)(5) by December 31, 2022
EHI export	§ 170.315(b)(10)	Certify to new criterion by December 31, 2023
Clinical quality measures (CQMs)—report	§ 170.315(c)(3)	Update to CMS QRDA Category I/III IG by December 31, 2022	PI Programs.
Auditable events and tamper-resistance	§ 170.315(d)(2)	Update to ASTM 2147-18 standard by December 31, 2022
Audit report(s)	§ 170.315(d)(3)	Update to ASTM 2147-18 standard by December 31, 2022
Auditing actions on health information	§ 170.315(d)(10)	Update to ASTM 2147-18 standard by December 31, 2022
View, Download, and Transmit to 3rd Party	§ 170.315(e)(1)	Update to USCDI referenced in § 170.213 and C-CDA companion guide referenced in § 170.205(a)(4) and § 170.205(a)(5) by December 31, 2022	PI Measure: Provide Patients Electronic Access to Their Health Information.
Transmission to public health agencies—electronic case reporting	§ 170.315(f)(5)	Update to USCDI referenced in § 170.213 by December 31, 2022	PI Measure: Electronic Case Reporting.
Consolidated CDA creation performance	§ 170.315(g)(6)	Update to USCDI referenced in § 170.213 and C-CDA companion guide referenced in § 170.205(a)(4) and § 170.205(a)(5) by December 31, 2022
Application Access—Data Category Request	§ 170.315(g)(8)	ONC-ACBs may only issue certificates for this criterion for the period before December 31, 2022	PI Measure: Provide Patients Electronic Access to Their Health Information.
Application Access—All Data Request	§ 170.315(g)(9)	Update to USCDI referenced in § 170.213 and C-CDA companion guide referenced in § 170.205(a)(4) and § 170.205(a)(5) by December 31, 2022	PI Measure: Provide Patients Electronic Access to Their Health Information.
Standardized API for patient and population services	§ 170.315(g)(10)	Certify to new criterion by December 31, 2022	Added to the 2015 Edition Base EHR 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 § 170.402(a) and accompanying Maintenance of Certification requirements, which are set forth in § 170.402(b). We stated in the final rule that the Assurances Condition and Maintenance of Certification requirements had an effective date of June 30, 2020. We exercised enforcement discretion on April 21, 2020, to extend the compliance date an additional three months to September 30, 2020.^[6] While we have not made a public announcement that we would be extending our enforcement discretion for an additional period of time, we have not taken any actions to enforce the Assurance Condition and Maintenance of Certification requirements since September 30, 2020. In this IFC, we are extending the compliance date and timeframe for the Assurances Condition and Maintenance of Certification requirements until April 5, 2021, to provide maximum flexibilities for our health care system to 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.

As we noted above, we have also extended the compliance date related to § 170.402 until April 5, 2021, except for § 170.402(b)(2). In § 170.402(b)(2), we extended the compliance date to meet the requirement that a health IT developer must provide all of its customers of certified health IT with health IT certified to the “EHI export” certification criterion in § 170.315(b)(10) to December 31, 2023.

b. Communications

In the ONC Cures Act Final Rule, we finalized in § 170.403 provisions that permit developers to impose on communications certain types of limited 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 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.

In the ONC Cures Act Final Rule, we also adopted Maintenance of Certification requirements for health IT developers of certified health IT in § 170.403(b). Section 170.403(b)(2) states that a health IT developer must not impose or enforce any contractual requirement that contravenes the requirements of paragraph (a) of § 170.403, the Communications Condition of Certification. Furthermore, if a health IT developer has contracts or agreements in existence that contravene the requirements of the Condition of Certification, the developer must notify all affected customers, other persons, or entities that the prohibition or restriction within the contract or agreement will not be enforced by the health IT developer (§ 170.403(b)(1)). In the ONC Cures Act Final Rule, we stated that the developer must notify all affected customers annually, beginning in 2020. Due to the COVID-19 PHE, we are suspending the notice requirement in § 170.403(b)(1) for 2020 only. Health IT developers of certified health IT with such contracts or agreements must provide notice to all customers beginning in 2021 and annually thereafter so long as those contracts or agreements remain in place.

This limited suspension ensures that health IT developers will still notify the users and customers of certified health IT in a timely manner, and also relieves pressure on the developers to immediately devote portions of their workforce to review contracts. We believe the annual requirement, beginning with notification in calendar year 2021, will simplify compliance for health IT developers while still providing adequate notice in a reasonable amount of time. We have finalized the deadline for the notice requirement in § 170.403(b)(1) to be annually, beginning in calendar year 2021.

c. Application Programming Interfaces

A Condition of Certification requirement in section 4002 of the Cures Act requires health IT developers to publish APIs that allow “health information from such technology to be accessed, exchanged, and used without special effort through the use of APIs or successor technology or standards, as provided for under applicable law.” The Cures Act's API Condition of Certification requirement also states that a developer must, through an API, “provide access to all data elements of a patient's electronic health record to the extent permissible under applicable privacy laws.” The Cures Act's API Condition of Certification requirement in section 4002 includes several key phrases and requirements for health IT developers that go beyond the technical functionality of the Health IT Modules they present for certification. The ONC Cures Act Final Rule captures both the technical functionality and behaviors necessary to implement the Cures Act API Condition of Certification requirement. Specifically, we adopted new standards, new implementation specifications, a new certification criterion, and modified the Base EHR definition. In addition, we finalized detailed Condition and Maintenance of Certification requirements for health IT developers.

For instance, in the ONC Cures Act Final Rule, we adopted a requirement in § 170.404(b)(4) that a Certified API Developer with Health IT Module(s) certified to the certification criteria in § 170.315(g)(7), (8), or (9) (ONC Certification Program API criteria) must comply with § 170.404(a) (API Condition of Certification requirements) by no later than November 2, 2020 (85 FR 25765). We exercised enforcement discretion on April 21, 2020, to extend compliance for an additional three months.^[8] In this IFC, we are extending the compliance date until April 5, 2021, so that the health care system can focus on addressing the COVID-19 PHE. We align the new compliance date for this provision with other dates that had a November 2, 2020 compliance date in the ONC Cures Act Final Rule. Setting a more delayed compliance date would have unreasonably delayed and ultimately diminished the benefits of the Program requirements we have finalized in the ONC Cures Act Final Rule.

We also stated in the ONC Cures Act Final Rule in § 170.404(b)(3) that Certified API Developers with API technology previously certified to the criterion in § 170.315(g)(8) must provide API technology certified to § 170.315(g)(10) to all API Information Sources deployed with certified API technology by no later than May 1, 2022 (85 FR 25765). In this IFC, we are extending the compliance timeline for that rollout of new standardized API functionality under § 170.404(b)(3) to December 31, 2022. We are also revising the dates in § 170.102, in the definition of 2015 Edition Base EHR, to be consistent with this extension.

As stated above, we believe extending the compliance date for this requirement by eight months is appropriate so that health IT developers and health care providers may adequately allocate time and resources to address the COVID-19 PHE.

d. Real World Testing

The Cures Act also added a new Condition and Maintenance of Certification requirement that health IT developers must successfully test the real world use of health IT for interoperability in the type(s) of setting(s) in which such technology would be marketed. This provision is critical to advancing transparency regarding Health IT Modules' performance and to users having information that could be crucial to their decisions to acquire certified health IT.

In the ONC Cures Act Final Rule, we established in § 170.405 real world testing requirements that include Maintenance of Certification requirements to update Health IT Modules certified to certain certification criteria (see § 170.405(b)(3) through (7) and (10)) to ensure the technology meets its users' needs for widespread and continued interoperability. We provide details on the 2015 Edition Cures Update certification criteria in section II.A.2 above. We are extending the compliance dates for updating these criteria until December 31, 2022 (and until December 31, 2023, for § 170.315(b)(10), “EHI export”).

Under real world testing Condition and Maintenance of Certification requirements, health IT developers must also submit publicly available annual real world testing plans and results for health IT certified to the criteria identified in § 170.405(a). In the ONC 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 § 170.406, we stated that health IT developers must attest twice a year to compliance with the Conditions and Maintenance of Certification requirements (except for the EHR reporting criteria submission requirement) (85 FR 25648). We believe requiring attestations every six months under § 170.406(b) will properly balance the need to support appropriate enforcement with our desire to minimize the burden on health IT developers. In light of the COVID-19 PHE and extensions provided for other Conditions and Maintenance of Certification requirements, in this IFC, we are extending our annual cycle for attestations by one year, to calendar year 2022. To clarify, due to the extensions provided for other Conditions and Maintenance of Certification requirements in this IFC, the first attestation window will continue to cover an irregular time period from the effective date of the final rule through the extended date of March 31, 2022. Subsequently, a regular six-month period will commence with the next attestation window.

We believe that delaying the implementation of these Condition and Maintenance of Certification requirements will allow health IT developers additional time to comply with the requirements and provides appropriate flexibility so that our health care system may adequately respond to the current COVID-19 PHE.

4. Updates to ONC-ACB Dates and Timeframes

In the ONC Cures Act Final Rule, we finalized several certification criteria changes that were accompanied by compliance dates and timeframes. As we stated previously, due to the COVID-19 PHE, this IFC extends certain compliance dates and timeframes for those new and updated certification criteria and Condition and Maintenance of Certification Requirements. Consequently, for purposes of coordination, we are also extending compliance dates and timeframes for the appropriate provisions applicable to the ONC—Authorized Certification Bodies (ACBs).

In the ONC Cures Act Final Rule, we finalized in § 170.523(p)(3) that ONC-ACBs must submit real world testing plans by December 15 of each calendar year and results by March 15 of each calendar year to ONC for public availability. Because we are now extending those dates for health IT developers, we are also extending the dates by which ONC-ACBs must submit the real world testing plans and results to ONC for public availability. ONC-ACBs must now submit initial plans to ONC by December 15, 2021, and initial results by March 15, 2023.

We had also finalized in § 170.550(m)(2) and (3) a time-limited certification status for certain 2015 Edition certification criteria. We finalized that an ONC-ACB may only issue a certification to a Health IT Module and permit continued certified status for § 170.315(b)(6) and (g)(8) until May 1, 2023, and May 2, 2022, respectively. To reflect the extension of compliance dates and timeframes, we are now finalizing in § 170.550(m)(2) and (3) that an ONC-ACB may only issue a certification to a Health IT Module and permit continued certified status for § 170.315(b)(6) and (g)(8) until December 31, 2023, and December 31, 2022, respectively.

Lastly, in the ONC Cures Act Final Rule, we finalized that for criteria being updated from the Common Clinical Data Set (CCDS) to the USCDI, a transition from the CCDS to the USCDI must occur no later than 24 months after the publication date of the final rule. We stated that for the period up to 24 months after the publication date of the ONC Cures Act Final Rule, the CCDS remains permissible for certified Health IT Modules until such Health IT Modules are updated to the USCDI. Due to the extension of compliance dates for certain 2015 Edition Cures Update certification criteria (we refer readers to section II.A.2), we are also providing an extension such that for certified Health IT Modules, the CCDS may remain applicable up to December 31, 2022, when such Health IT Modules are updated to the USCDI.

We believe these revisions are appropriate and align with the extended compliance dates and timelines for related certification criteria and Program requirements.

B. Standards Updates

1. USCDI

In the ONC Cures Act Final Rule, we published the USCDI version 1 (v1) to replace the CCDS as the standard patient data set in several ONC certification criteria.^[9] Through the USCDI v1 we added new data classes, including Allergies and Intolerances, Clinical Notes, and Provenance; and added data elements to Patient Demographics and Vital Signs. In USCDI v1, we also defined applicable terminology standards to represent respective data elements, where appropriate. In the ONC Cures Act Final Rule, we adopted into the USCDI additional data classes and data elements, with the applicable standards thus replacing CCDS. With the exception of the Medication class and Medication Allergies data element, we neither proposed nor intended to change applicable standards relevant to the CCDS data elements. However, we included in the USCDI v1 ^[10] new applicable terminology standards that were neither previously required for the CCDS nor presented for addition or change through the rulemaking process. Several stakeholders commented on and objected to these unexpected changes to the applicable standards, and ONC concurred with these comments. Therefore, we published the USCDI v1 (July 2020 Errata) ^[11] to address these concerns, to make the necessary corrections to the standards, and to describe the changes over the original USCDI v1. We are adopting and incorporating by reference the updated standard USCDI v1 (July 2020 Errata) in this IFC.

2. US Core Implementation Guide

We adopted the HL7® FHIR® US Core Implementation Guide STU3 Release 3.1.0 (US Core IG 3.1.0) as part of the ONC Cures Act Final Rule testing and certification requirements for the §  170.315(g)(10) standardized API for patient and population services certification criterion. Since publication of the ONC Cures Act Final Rule, the health IT standards community has identified and resolved several technical issues, editorial copy/paste errors, omissions, and places in need of minor clarification in the US Core IG 3.1.0. The health IT standards community has also published a revised HL7 FHIR US Core Implementation Guide STU3 Release 3.1.1 (US Core IG 3.1.1) with technical errata to address these updates. We are adopting the US Core IG 3.1.1 in §  170.215(a)(2) in order to support industry standardization around the latest version of the US Core IG.

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 § 170.102 in the ONC Cures Act Final Rule (85 FR 25733). However, in § 170.101 and § 170.200, we neglected to update the language to say “health information technology.” Instead, we erroneously kept the reference to “Health IT Modules.” We, therefore, are updating this language in this IFC. As these are clarifications and not substantive corrections, we find good cause to waive the notice and comment procedures of the APA as unnecessary (5 U.S.C. 553(b)(B)).

2. Standards for Health Information Technology To Protect Electronic Health Information Created, Maintained, and Exchanged

a. Record Actions Related to Electronic Health Information, Audit Log Status, and Encryption of End-User Devices

In the ONC Cures Act Final Rule (85 FR 25708), we inadvertently referred to the auditable events and 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 § 170.210(e)(2)(i) and (e)(3) (85 FR 25940). Because we updated the standard in § 170.210(h) to ASTM E2147-18, we have also updated the requirements in § 170.210(e) to align with the new numbering sequence of the updated standard. However, we inadvertently neglected to update the same reference language for the ASTM data elements in § 170.210(e)(2)(i) and (e)(3). Therefore, we are correcting § 170.210(e)(2)(i) and (e)(3) by replacing “7.2 and 7.4,” which referred to the previous ASTM standard, with “7.1.1 and 7.1.7,” which refers to the updated ASTM E2147-18 standard. This does not constitute a change in requirements, but simply a change to where those requirements are referenced within the updated ASTM E2147-18 standard. The correction of typographic errors does not constitute a substantive change, and we, therefore, find good cause to waive the public notice and comment procedures of the APA as unnecessary (5 U.S.C. 553(b)(B)).

In addition, the new numbering of the ASTM data elements led to another error. The ONC Cures Act Final Rule included the requirement for Health IT Modules to support 7.1.3 Duration of Access in the ASTM E2147-18 standard. However, we have determined this will not be a requirement for testing and certifying to 2015 Edition Cures Update certification and we are removing it from the regulatory text. The requirement added a significant burden for health IT developers and it was not our intent to add burden beyond the requirements to update to the new ASTM E2147-18 standard. Our intent, as proposed and stated in the preamble, was simply to update the standards' numbering in our Program for certification and testing to conform with the new numbering set by the standards organization itself (“. . . the updated standard reinforces what we have previously required and maintained with previous certification requirements and note that there is no substantial change to the standard” 85 FR 25708). After publication of the ONC Cures Act Final Rule, we heard from health IT developers who noted that we had errantly included 7.1.3 Duration of Access, a requirement we did not intend to include as part of the Program at this time. In fact, requiring developers of certified health IT to certify to 7.1.3 would substantially increase the development costs and time. While the other related requirements for auditable events and tamper resistance require basic data like “date and time of access,” the duration of access certification criteria would require substantial updates to all health technology to record and preserve more data than previously required. In response, we immediately clarified in sub-regulatory guidance (the certification companion guide for auditable events and tamper-resistance) that this requirement will not be in scope for certification or testing. Since our intent, as proposed and discussed, was to incorporate requirements similar to those previously required, 7.1.3 Duration of Access in the ASTM E2147-18 was errantly included. The correction of typographic errors does not constitute a substantive change, and we, therefore, find that there is good cause to waive the notice and comment procedures of the APA as unnecessary (5 U.S.C. § 553(b)(B)).

b. Synchronized Clocks

Section 170.210(g) (Synchronized clocks) included a reference to Request for Comment (RFC) 1305 Network Time Protocol, a standard maintained by the Internet Engineering Task Force (IETF). However, prior to the release of the ONC Cures Act NPRM, IETF obsoleted RFC 1305 and replaced it with RFC 5905, which is backward compatible with RFC 1305. In this IFC, we removed the reference to RFC 1305 in § 170.210(g). Because the obsolete standard is no longer maintained by its standard organization and is therefore no longer publically recognized as the current standard for common internet protocols, and because the removal of the RFC 1305 standard and the replacement with the current RFC 5905 standard were both previously available for public input through IETF's open standards process, we find good cause to waive the notice and comment procedures of the APA as unnecessary (5 U.S.C. § 553(b)(B)). To note, RFC 5905 Network Time Protocol Version 4 (incorporated by reference in § 170.299) was already approved for § 170.210 on September 4, 2012.

3. Applicability of Certification Criteria for Health Information Technology

In the ONC Cures Act Final Rule, we removed the 2014 Edition from the CFR (85 FR 25656). We also finalized removal of terms and definitions specific to the 2014 Edition from § 170.102, including the “2014 Edition Base EHR,” “2014 Edition EHR certification criteria,” and “Complete EHR, 2014 Edition” definitions (85 FR 25655). As explained in the 2015 Edition final rule (80 FR 62719), the “Complete EHR” concept was discontinued for the 2015 Edition. Therefore, in conjunction with the removal of the 2014 Edition, we also removed references to “Complete EHR” from the regulation text. In the ONC Cures Act Final Rule, consistent with our intent to remove all terms specific to the 2014 Edition, we neglected to include the removal of the term “EHR Module.” The term should have been corrected to say “Health IT Module.” We, therefore, now correct this error in § 170.300(a) and (c). The correction of typographic errors does not constitute a substantive change, and we, therefore, find that there is good cause to waive the notice and comment procedures of the APA as unnecessary (5 U.S.C. § 553(b)(B)).

Consistent with our intent above to remove the 2014 Edition, in § 170.300(d), we neglected to remove the reference to § 170.314. We corrected this error in this IFC by only referencing § 170.315 in § 170.300(d). Since we removed and reserved § 170.314, referring to § 170.314 in this section is misleading and meaningless. The correction of typographic errors does not constitute a substantive change, and we, therefore, find that there is good cause to waive the notice and comment procedures of the APA as unnecessary (5 U.S.C. § 553(b)(B)).

4. Electronic Prescribing

As discussed in the ONC Cures Act Final Rule, an RxFillIndicatorChange is sent by a prescriber to a pharmacy to indicate to the pharmacy that the prescriber is changing the types of RxFill transactions that were previously requested, modifying their status, or canceling future transactions (85 FR 25682). We requested comment on this transaction in the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Proposed Rule (84 FR 7444) and ultimately adopted it as optional in the ONC Cures Act Final Rule. However, in the regulation text, we inadvertently used the transaction “RxFillIndicator” (85 FR 25942). Therefore, in § 170.315(b)(3)(ii)(B)(2), we are correcting the transaction to “RxFillIndicatorChange.” The correction of typographic errors does not constitute a substantive change, and we, therefore, find that there is good cause to waive the notice and comment procedures of the APA as unnecessary (5 U.S.C. § 553(b)(B)).

5. Clinical Quality Measures—Report Criterion

In the “Updates to the 2015 Edition Certification Criteria” section of the ONC Cures Act Final Rule, we noted that we only adopted two new technical certification criteria in §  170.315(b)(10) (EHI export) and §  170.315(g)(10) (Standardized API for patient and population services) to which health IT developers seeking to upgrade their products will need to present Health IT Modules for certification (85 FR 25665). We also included §  170.315(c)(3) (Clinical quality measures—report) in the list of criteria that currently apply to certified Health IT Modules that CMS program participants use. We stated that, in general, health IT developers of certified health IT have 24 months from the publication date of the ONC Cures Act Final Rule to make technology certified to these updated certification criteria available to their customers, and during this time developers may continue supporting technology certified to the prior version of the ONC certification criteria for use by their customers (85 FR 25666). We intended for §  170.315(c)(3) to also have a compliance timeline of 24 months, but we erroneously omitted it from the “clinical quality measures—report” criterion section of the preamble and the real world testing regulatory text.

For all of the other criteria we revised due to standards updates, we allowed a 24-month compliance timeline. In Table 1—2015 Edition Cures Update of the ONC Cures Act Final Rule (85 FR 25667), we incorrectly included the timing for the revised criterion “clinical quality measures—report” to be the effective date of the final rule, which was 60 days after it was published in the Federal Register. Our intent, as evidenced above in our description of the overarching approach for all of the standards updates to the 2015 Edition criteria, was to make the compliance timelines consistent for all of the revised criteria and allow health IT developers 24 months from the date of publication to update to the new standards. Therefore, to align with the other revised criteria to relieve an impractical burden on stakeholders and to allow for the extension that we discuss in section II.A.2, the correct compliance timeline for the “clinical quality measures—report” criterion is December 31, 2022. We reflect this change in § 170.405(b)(10) of the real world testing Maintenance of Certification requirements, stating that health IT developers with health IT certified to § 170.315(c)(3) as of June 30, 2020, would have to update such certified health IT to the revisions by December 31, 2022. The correction of typographic errors does not constitute a substantive change, and we, therefore, find that there is good cause to waive the notice and comment procedures of the APA as unnecessary (5 U.S.C. 553(b)(B)). Even if this change constituted a substantive rulemaking subject to notice and comment procedures or delayed effective date requirements, because it would be impractical and unnecessary to request comment on such a change, we find good cause to waive notice and comment procedures and delayed effective date requirements of the APA (5 U.S.C. 553(b)(B), (d)).

CMS Quality Reporting Document Architecture Implementation Guides

In the ONC Cures Act Final Rule, we also failed to adopt the latest versions of the CMS Quality Reporting Document Architecture (QRDA) Implementation Guides (IGs) as we stated we would do in the Proposed Rule (84 FR 7446). In the Proposed Rule, we stated at 85 FR 25687 that “we propose to incorporate by reference in §  170.299 the latest annual CMS QRDA IGs” and in the Cures Act Final Rule we stated at 85 FR 25689 that “We thank commenters for their input and have adopted the latest CMS QRDA IG versions available at the time of publication of this final rule.” In order to align with our proposals and requirements in the ONC Cures Act Final Rule, in this IFC, we are adopting the standards for CMS clinical quality measure reporting in § 170.205(h)(3) and § 170.205(k)(3) to the latest CMS QRDA standards available at the time of the ONC Cures Act Final Rule publication (May 1, 2020), which are included in the certification criterion at § 170.315(c)(3). The 2020 CMS QRDA IGs we are adopting for testing and certification align with changes CMS already requires health care providers to use. We incorporate by reference at § 170.299 the CMS QRDA IGs, specifically the 2020 CMS QRDA I IG for Hospital Quality Reporting,^[12] which published on December 3, 2019, and the 2020 CMS QRDA III IG for Eligible Clinicians and Eligible Professionals,^[13] which published on April 30, 2020. These IGs were available prior to the publication of the ONC Cures Act Final Rule, but we erroneously included prior QRDA IGs. Specifically, in this IFC, we are adopting the 2020 CMS QRDA category I for inpatient measures at § 170.205(h)(3) and 2020 CMS QRDA category III for ambulatory measures at § 170.205(k)(3). We waive the notice and comment period for this change as it is unnecessary, because the change ensures that the regulations accurately reflect the policies we proposed, the public commented on, and that we then finalized in the ONC Cures Act Final Rule. We note that CMS programs may independently require the implementation and use of the most up-to-date CMS QRDA specifications prior to the December 31, 2022 deadline.

6. Multi-Factor Authentication

In § 170.315(d)(13)(ii), we mistakenly used the word “identify” in the regulatory text related to multi-factor authentication (85 FR 25943). We are correcting § 170.315(d)(13)(ii) by replacing “identify” with the word “identity.” The correction of typographic errors does not constitute a substantive change, and we therefore find that there is good cause to waive the notice and comment procedures of the APA as unnecessary (5 U.S.C. § 553(b)(B)).

7. Transmission to Public Health Agencies—Electronic Case Reporting

We erroneously included a requirement in the ONC Cures Act Final Rule that health IT developers certifying to § 170.315(f)(5) were required to conform to the HL7 Clinical Document Architecture standard and companion guide adopted in § 170.205(a)(4) and (5). We did not propose this change for § 170.315(f)(5) in the ONC Cures Act Proposed Rule (84 FR 7443 and 7591), and intended only to finalize a requirement that health IT developers certifying to § 170.315(f)(5) are required to conform to data classes expressed in the standards in § 170.213 or the Common Clinical Data Set for the period before December 31, 2022 (see 84 FR 7441). Because the application of these standards would completely change the certification requirements to the “electronic case reporting” criterion and impose a significant development burden for developers, and because the standards were not proposed, we are revising the regulation text in § 170.315(f)(5) and § 170.405(b)(3) to correct this clear error. Specifically, we have removed the words “and in accordance with § 170.205(a)(4) and (5),” from § 170.315(f)(5)(iii)(B)(1) and “in accordance with § 170.205(a)(4)” from § 170.315(f)(5)(iii)(B)(2), and corrected the real world testing regulation text in § 170.405(b)(3) by removing the words “for C-CDA” from the title of the paragraph to accommodate the corrections to § 170.315(f)(5). As these revisions do not constitute substantive changes to what we proposed, received comment on, and intended to finalize, we find good cause to waive the public notice and comment procedures of the APA as unnecessary.

8. Conditions and Maintenance of Certification Requirements for Health IT Developers

a. Assurances

In § 170.402(a)(4) of the ONC Cures Act Final Rule, there was a typo: “heath IT product” (85 FR 25946). We are correcting the typo “heath IT product” to “health IT product.” The correction of typographic errors does not constitute a substantive change, and we, therefore, find that there is good cause to waive the notice and commend procedures of the APA as unnecessary (5 U.S.C. § 553(b)(B)).

b. Application Programming Interfaces—Clarification for Native Applications and Refresh Tokens

In the ONC Cures Act Final Rule, we established an approach that required Health IT Modules to issue refresh tokens to applications that are “capable of storing a client secret” (85 FR 25945). We based our approach on the standards and implementation specifications we adopted for the § 170.315(g)(10) certification criterion. After the publication of the Cures Act Final Rule, health IT developers preparing for testing and certification to the § 170.315(g)(10) certification criterion, as well as third-party application developers, requested that we clarify this requirement.

Stakeholders identified that we had not fully explained how our policy would apply to “native applications,” which, according to IETF RFC 6749, are “clients installed and executed on the device used by the resource owner (i.e., desktop application, native mobile application)” and their interactions with OAuth 2.0 authorization servers.^[14] These stakeholders noted that a strict interpretation of the final rule could exclude native applications that use or are capable of using additional technology that make them “capable of storing a client secret,” or native applications that are capable of securely handling a refresh token without needing a client secret. Consequently, stakeholders indicated that the technical ambiguity around native applications would negatively impact testing and certification. Further, stakeholders contended that without timely and explicit clarifications to native applications, health IT developers' support for native applications would vary widely.

We agree with these concerns and that timely and additional clarification is necessary. In our assessment, if such variation were to occur, it would greatly affect the types of applications supported by certified API technology in the next two years as compliance timelines come into effect. Moreover, such a result would be contrary to the public interest because it would contradict the intent of the Cures Act and our implementation of the API Condition of Certification, would negatively impact market competition, and would especially disadvantage and limit patients' ability to access their electronic health information without special effort. In the ONC Cures Act Proposed Rule (84 FR 7481), we stated, “The SMART Guide specifies the use of `refresh tokens' as optional. We believe that this requirement is necessary in order to enable persistent access by apps, especially in a patient access context. Thus, we propose to make their use mandatory with a minimum refresh token life of three months . . . we wish to emphasize that implementing refresh token support is directly intended to enable a patient's `persistent access' to their electronic health information without special effort (i.e., without having to frequently re-authenticate and re-authorize while using their preferred app).” Recognizing that patients will largely use smartphone applications (native applications) to access their health information, we would substantially limit patients' ability to access their electronic health information without special effort if native applications were categorically excluded from enabling “persistent access.” By making this clarification and revising the regulation text, we are ensuring that the regulation best matches the policies commented on and then finalized in the ONC Cures Act Final Rule. For these reasons, we find good cause to waive the notice and comment procedures of the APA as contrary to the public interest and unnecessary (5 U.S.C. 553(b)(B)).

Based on our analysis of the applicable standards and industry practices,^[15] including the HL7® SMART Application Launch Framework Implementation Guide Release 1.0.0 (SMART IG) (adopted in § 170.215(a)(3)), we identified that it is possible for native applications to use secure storage capabilities and technologies on mobile platforms to secure a refresh token, a client secret, or both. Indeed, section 3.0.1 of the SMART IG provides examples of native applications that can meet either the “confidential app profile” or the “public app profile.” Examples of technologies native applications can use to secure a refresh token, a client secret, or both include operating 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]

In response to these concerns, we have clarified and made the regulation text consistent by adding a new paragraph in § 170.315(g)(10)(v)(A)(1)(iii) and revising paragraphs § 170.315(g)(10)(v)(A)(1)(ii) and § 170.315(g)(10)(v)(A)(2)(ii). In the new paragraph in § 170.315(g)(10)(v)(A)(1)(iii), we have specified that Health IT Modules' authorization servers must issue a refresh token to native applications that are capable of securing a refresh token. In § 170.315(g)(10)(v)(A)(1)(ii) and § 170.315(g)(10)(v)(A)(2)(ii), we have updated the regulation text to be consistent with the paragraph we have added in § 170.315(g)(10)(v)(A)(1)(iii) by specifying that a “Health IT Module's authorization server” must issue a refresh token to applications that are capable of storing a client secret. And in § 170.315(g)(10)(v)(A)(2)(ii) we have updated the regulation text by removing the word “new” preceding “refresh token”. These updates make the certification criterion clear and consistent, and disambiguate the implications for native applications.

The requirement we have finalized in § 170.315(g)(10)(v)(A)(1)(iii) addresses the technical ambiguity regarding native applications that we discussed previously and clarifies that Health IT Modules must support the issuance of an initial refresh token to native applications that are capable of securing a refresh token. As part of the requirements in § 170.315(g)(10)(v)(A)(1)(iii), health IT developers must publish the method(s) by which their Health IT Modules support the secure issuance of an initial refresh token to native applications according to the technical documentation requirements in § 170.315(g)(10)(viii) and transparency conditions in § 170.404(a)(2). Additionally, application developer attestations to health IT developers regarding the ability of their applications to secure a refresh token, a client secret, or both, must be treated in a good faith manner consistent with the provisions established in the openness and pro-competitive conditions in § 170.404(a)(4).

We emphasize that health IT developers can determine the method(s) they use to support interactions with native applications and we clarify that health IT developers are not required to support all methods that third-party 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 § 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 § 170.315(g)(10)(v)(A)(2)(ii) are simply stylistic changes to match the language in our revisions in § 170.315(g)(10)(v)(A)(1)(ii) and § 170.315(g)(10)(v)(A)(1)(iii). Such corrections are not substantive, therefore, we find good cause to waive the notice and comment procedures of the APA as unnecessary (5 U.S.C. 553(b)(B)).

Additionally, we clarify that the paragraph focused on “First time connections” in § 170.315(g)(10)(v)(A)(1) and the paragraph focused on “Subsequent connections” in § 170.315(g)(10)(v)(A)(2) are aligned and that our policy for subsequent connections remains unchanged. That is, Health IT Modules must issue a refresh token that is valid for a new period of no less than three months to only applications that are capable of storing a client secret. While the new paragraph in § 170.315(g)(10)(v)(A)(1)(iii) requires Health IT Modules to issue an initial refresh token to native applications, Health IT Modules may require native applications that can secure a refresh token without a client secret to 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)).

9. Principles of Proper Conduct for ONC-ACBs

In the ONC Cures Act Final Rule, we discussed removing § 170.523(k)(2) (85 FR 25663). In the regulatory text, we removed § 170.523(k)(2) to further reduce administrative burden for health IT developers and ONC-ACBs, and included the instructions to do so (85 FR 25951). Because we removed § 170.523(k)(2), the requirement in § 170.523(f)(1)(xxi) that the ONC-ACB include the attestation from that section in its certified product listing should also have been removed. We inadvertently omitted that removal from the amendatory instructions for § 170.523(f) (85 FR 25950). We are correcting the error by removing the requirement in § 170.523(f)(1)(xxi) because the Principles of Proper Conduct for ONC-ACBs should accurately reflect the policies we proposed, the public commented on, and that we then finalized in the ONC Cures Act Final Rule. Further, because the remnant has no meaning in the absence of the other provision, and can impose no benefit or obligation, the correction of such errors does not constitute a substantive change. As such, we therefore find that there is good cause to waive the notice and comment procedures of the APA as unnecessary (5 U.S.C. § 553(b)(B)).

Additionally in the ONC Cures Act Final Rule, in the amendatory instructions for § 170.523, we instructed in step h that the phrase “Complete EHR or” be removed from paragraph (k)(1), but the phrase specifically appeared in (k)(1)(i) (85 FR 25950). We corrected the error and removed the phrase “Complete EHR or” from § 170.523(k)(1)(i) in this IFC. Section 170.523(k)(1)(i) is also further revised to remove the brackets before “Complete EHR or” and after “Health IT Module” (85 FR 25950). We have made this correction. The correction of typographic errors does not constitute a substantive change, and we therefore find that there is good cause to waive the notice and comment procedures of the APA as unnecessary (5 U.S.C. 553(b)(B)).

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 § 171.101(b) (85 FR 25955). Because part 171 defines information blocking and provides a series of voluntary exceptions to that definition, it is more precise to say such actors “are subject to” this part. We corrected § 171.101(b) to replace “must comply” with “are subject to.” Because this is primarily a correction to an inadvertent use of language, and not a substantive change, we, therefore, find that there is good cause to waive the notice and comment procedures and delayed effective date requirements of the APA as unnecessary (5 U.S.C. 553(b)(B), (d)(3)). Further, even if this constituted a substantive change, for the reasons we stated previously in this section II.C, we find good cause to waive the notice and comment rulemaking process and delayed effective date for this correction, because these requirements would be impracticable and contrary to the public interest.

11. Information Blocking Definition and Security Exception

In the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Proposed Rule (Proposed Rule), we considered a definition of information blocking that included actions that “interfere with, prevent or materially discourage” access, exchange or use of EHI, but ultimately we proposed that the term “interfere with” was already inclusive of “prevent” and “materially discourage” (84 FR 7516). Similarly, in the preamble to the ONC Cures Act Final Rule, in discussing the information blocking definition, we determined that the terms “interfere with” and “interference” are themselves inclusive of both prevention and material discouragement of access, exchange or use of EHI (85 FR 25809). Further, in § 171.102, we defined “Interfere with or interference” to include both “prevent” and “materially discourage” (85 FR 25956). The definition of information blocking in § 171.103, therefore, should not include “prevent, or materially discourage.” It is redundant and could confuse stakeholders who read and commented on the Proposed Rule and read in the preamble of the ONC Cures Act Final Rule that “interfere with” is inclusive of those terms. We also failed to remove the words from the regulatory text for the “Security exception” in § 171.203(e)(2). Therefore, we have corrected the definition of “information blocking” in § 171.103 by removing the redundant phrase “prevent, or materially discourage” in two instances—§ 171.103(a)(2) and (a)(3) (85 FR 25956). Further, in order to eliminate the same redundancy and to promote clarity, we have corrected § 171.203(e)(2) by removing the phrase “prevent, or materially discourage” (85 FR 25958). These corrections are necessary to ensure the policies we discussed in the Proposed Rule and finalized in the preamble of the ONC Cures Act Final Rule are accurately and clearly reflected in the regulatory framework we established. This correction imposes no further burden or obligation on any party, and does not constitute a substantive change. For these reasons, we find good cause to waive the notice and comment procedures and delayed effective date requirements of the APA as unnecessary (5 U.S.C. 553(b)(B), (d)(3)).

When defining the actors to whom the definition of information blocking would apply in the ONC Cures Act Final Rule, we finalized a policy to use the term “health IT developer of certified health IT.” In doing so, we considered the many comments we received in response to our proposed definition for that specific term in the Proposed Rule. We extensively discussed the term “health IT developer of certified health IT,” as well as the comments we received regarding the proposed term and definition, in the preamble of the ONC Cures Act Final Rule (85 FR 25795 through 25797). We finalized the definition of the term “health IT developer of certified health IT” itself, in § 171.102 (85 FR 25956). We referred to “health IT developers of certified health IT” in 45 CFR 171.101(a) and (b) in stating the applicability of 45 CFR part 171. Thus, we made clear our explicit intent that the definition of information blocking would only apply to developers of certified health IT, not all health IT developers.

In the definition of information blocking itself in § 171.103, however, we erroneously used only the term “health IT developer” and omitted the rest of the phrase (“of certified health IT”). We proposed, received comment on, discussed and finalized specific policies in regards to the regulatory definition of information blocking and the meaning of “health IT developer” found in the statutory information blocking definition. We finalized the policy for the narrower definition “health IT developer of certified health IT” based on comments we received and for reasons we extensively discussed in the preamble of the ONC Cures Act Final Rule. Therefore, we have corrected § 171.103(a)(2) to include the full phrase “health IT developer of certified health IT.” By erroneously omitting the full 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 § 171.302. We also made an error in the regulation text in § 171.301(b)(1)(ii)(A), where we inadvertently referred to an actor's practice of fulfilling a request for EHI as “fulfilling a response” which is incorrect and an obvious error (85 FR 25959). Therefore, we have corrected this phrase to read “fulfilling a request.”

In addition, we clarify a typographical error in the ONC Cures Act Final Rule preamble. At 85 FR 25877, we erroneously refer to § 171.301(b)(2)(i)(a); the correct citation has a capitalized (A) instead of lowercase (a).

The correction of these typographic errors does not constitute a substantive change, and we, therefore, find that there is good cause to waive the notice and comment procedures and delayed effective date requirements of the APA as unnecessary (5 U.S.C. 553(b)(B), (d)(3)).

13. Licensing Exception

In § 171.303(b)(2)(i), we erroneously cross-referenced paragraph (c)(3) instead of the correct paragraph, (b)(3) (85 FR 25960). We have corrected the error. The correction of typographic errors does not constitute a substantive change, and we therefore find that there is good cause to waive the notice and comment procedures and delayed effective date requirements of the APA as unnecessary (5 U.S.C. 553(b)(B), (d)(3)).

III. Waiver of Proposed Rulemaking, Comment Period, and Delay in Effective Date

Under the Administrative Procedure Act (APA), 5 U.S.C. 553(b), an agency is required to publish a notice of proposed rulemaking in the Federal Register before the provisions of a rule take effect. In addition, § 553(d) mandates a 30-day delay in effective date after issuance or publication of a rule. Sections 553(b)(B) and 553(d)(3) provide for exceptions from the notice and comment and delay in effective date requirements. Section 553(b)(B) authorizes an agency to dispense with normal rulemaking requirements when the agency for good cause finds that the notice and comment processes are impracticable, unnecessary, or contrary to the public interest. In addition, § 553(d)(3) allows the agency to waive the 30-day delay in effective date for “otherwise provided by the agency for good cause found and published with the rule.”

The nation is experiencing an emergency of unprecedented magnitude. This IFC directly supports that goal by offering regulated individuals and entities flexibilities in complying with the ONC Cures Act Final Rule while they are combating the COVID-19 pandemic. The IFC also helps to ensure that sufficient health IT products and services are available to meet the needs of affected health care systems, health care providers, and individuals.

On January 30, 2020, the International Health Regulations Emergency Committee of the WHO declared the outbreak of COVID-19 to be a Public Health Emergency of International Concern.^[18] On January 31, 2020, Secretary Azar declared a PHE ^[19] under section 319 of the Public Health Service Act (42 U.S.C. 247d), in response to COVID-19. On March 11, 2020, the WHO publicly declared COVID-19 to be a pandemic.^[20] On March 13, 2020, the President declared that the COVID-19 outbreak in the United States constitutes a national emergency,^[21] beginning March 1, 2020. Effective October 23, 2020, Secretary Azar renewed the January 31, 2020 determination that was previously renewed on April 21, 2020 and July 23, 2020 that a PHE for COVID-19 exists and has existed since January 27, 2020.

As we discussed in section II.A above, it is critical that we extend our support to the health care community, specifically those who are affected by the ONC Cures Act Final Rule. In support of the imperative to contain and combat the virus in the United States, developers of health technology have raced to update their technology, for example, to create new codes for COVID-19 and its associated illnesses. Many developers are working to ensure that critical data about infection rates, testing outcomes, and hospitalization rates are accurate and are transmitted accurately to local, State and Federal authorities. Further, health IT developers of certified health IT are responding to requests from public health entities, health care providers, and health care systems, asking for updates to, or information about, the technology to help them better track, respond and treat illnesses caused by COVID-19. Developers of certified health IT are also exploring novel methods to help address the PHE using time and resources that might otherwise have been used to upgrade their technology. It is in the best interest of the public to ensure that developers of certified health IT are able to respond in a dynamic and rapid manner in order to assist the nation in confronting the PHE.

If these developers of certified health IT were required to update their technology according to the timeline and deadlines in the ONC Cures Act Final Rule, they would likely devote more time and resources to ensuring their technology was upgraded and certified to avoid losing customers and users. In doing so, they would have less time and fewer resources to address the urgent and constantly changing technological needs of health care providers, public health entities, and health care systems dealing with the COVID-19 PHE. Further, even if the developers of certified health IT were able to upgrade their technology to the 2015 Edition Cures Update by the original compliance dates, their customers may require training and time to adapt to the new technology. This is especially true for health care providers, who may not have control over updates to the technology used in their care settings. It is in the best interest of the public that health care providers are able to combat COVID-19 PHE without also having to manage the potential disruption that such updates at this time could entail. Delaying the enforcement deadlines and extending certain timelines ensures that the technology will be updated at a time when the threat from the PHE has lessened and both developers and health care providers would have the time and resources to devote to these technology updates.

It is imperative that the health care community, including developers of certified health IT, remain focused on addressing the grave threat to public health posed by COVID-19. Therefore, we find good cause to waive notice and comment rulemaking as we believe it would be impracticable and contrary to the public interest for us to undertake normal notice and comment rulemaking procedures. Furthermore, because we cannot afford any delay in effectuating this IFC and do not want to create unnecessary burdens on stakeholders who would otherwise try to meet the November 2, 2020 compliance and applicability date for various provisions of the ONC Cures Act Final Rule, we find good cause to waive the 30-day delayed effective date for the information blocking provisions and the Conditions and Maintenance of Certification requirements related to information blocking, communications, and assurances.

We are providing a 60-day public comment period for this IFC as specified in the DATES section of this document.

IV. Incorporation by Reference

The Office of the Federal Register has established requirements for materials (e.g., standards and implementation specifications) that agencies incorporate by reference in the Code of Federal Regulations (79 FR 66267; 1 CFR 51.5). Specifically, § 51.5(b) requires agencies to discuss, in the preamble of a final rule, the ways that the materials they incorporate by reference are reasonably available to interested parties and how interested parties can obtain the materials, and to summarize, in the preamble of the final rule, the material they incorporate by reference.

To make the materials we are incorporating by reference reasonably available, we provide a uniform resource locator (URL) for the standards. These standards are directly accessible through the URLs provided. As an alternative, a copy of the standards may be viewed for free at the U.S. Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, 330 C Street SW, Washington, DC 20201. Please call [phone] 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 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:

○ Submission of initial Attestations (§ 170.406)

○ Submission of initial plans and results of real world testing (§ 170.405(b)(1) and (2))

We previously estimated that the Year 1 quantifiable costs for these provisions are $47,686,943 and the quantifiable benefits are $310,450,000. Both the cost and benefit estimates were estimated to be perpetual. Because this impact is over $100 million, it is sufficient to make this IFC economically significant under E.O. 12866. The IFC's changes have implications for the distribution of the costs and benefits over time found in the ONC Cures Act Final Rule as described above.

B. Regulatory Flexibility Act

The Regulatory Flexibility Act (RFA) requires agencies to analyze options for regulatory relief of small businesses if a rule has a significant impact on a 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

1. The authority citation for part 170 continues to read as follows:

Authority: 42 U.S.C. 300jj-11; 42 U.S.C 300jj-14

2. Revise § 170.101 to read as follows:

§ 170.101

Applicability.

The standards, implementation specifications, and certification criteria adopted in this part apply to health information technology and the testing and certification of Health IT Modules.

3. Amend § 170.102 by revising paragraphs (3)(ii) and (iii) in the definition of “2015 Edition Base EHR” to read as follows:

§ 170.102

Definitions.

* * * * *

2015 Edition Base EHR * * *

(3) * * *

(ii) Section 170.315(g)(8) or (10) for the period before December 31, 2022; and

(iii) Section 170.315(g)(10) on and after December 31, 2022.

* * * * *

4. Revise § 170.200 to read as follows:

§ 170.200

Applicability.

The standards and implementation specifications adopted in this part apply with respect to Health Information technology.

5. Amend § 170.205 by revising paragraphs (h)(3) and (k)(3) to read as follows:

§ 170.205

Content exchange standards and implementation specifications for exchanging electronic health information.

* * * * *

(h) * * *

(3) Standard. CMS Implementation Guide for Quality Reporting Document Architecture: Category I; Hospital Quality Reporting; Implementation Guide for 2020 (incorporated by reference in § 170.299).

* * * * *

(k) * * *

(3) Standard. CMS Implementation Guide for Quality Reporting Document Architecture: Category III; Eligible Clinicians and Eligible Professionals Programs; Implementation Guide for 2020 (incorporated by reference in § 170.299).

* * * * *

6. Amend § 170.210:

a. In paragraph (e)(1)(i), by removing the words “through 7.1.3” and adding in its place the words “and 7.1.2”;

b. In paragraphs (e)(2)(i) and (e)(3), by removing the words “7.2 and 7.4,” and adding in their place the words “7.1.1 and 7.1.7”; and

c. By revising paragraph (g).

The revision reads as follows:

§ 170.210

Standards for health information technology to protect electronic health information created, maintained, and exchanged.

* * * * *

(g) Synchronized clocks. The date and time recorded utilize a system clock that has been synchronized following (RFC 5905) Network Time Protocol Version 4, (incorporated by reference in § 170.299).

* * * * *

7. Revise § 170.213 to read as follows:

§ 170.213

United States Core Data for Interoperability.

Standard. United States Core Data for Interoperability (USCDI), July 2020 Errata, Version 1 (v1) (incorporated by reference in § 170.299).

8. Amend § 170.215 by revising (a)(2) to read as follows:

§ 170.215

Application Programming Interface Standards.

* * * * *

(a) * * *

(2) Implementation specification. HL7 FHIR® US Core Implementation Guide STU 3.1.1 (incorporated by reference in § 170.299).

9. Amend § 170.299 by revising paragraphs (e)(4) and (5), (f)(34), and (m)(5) to read as follows:

§ 170.299

Incorporation by reference.

* * * * *

(e) * * *

(4) CMS Implementation Guide for Quality Reporting Document Architecture: Category I; Hospital Quality Reporting Implementation Guide for 2020; published December 3, 2019, IBR approved for § 170.205(h).

(5) CMS Implementation Guide for Quality Reporting Document Architecture: Category III; Eligible Clinicians and Eligible Professionals Programs Implementation Guide for 2020; published April 30, 2020, IBR approved for § 170.205(k).

* * * * *

(f) * * *

(34) HL7 FHIR® US Core Implementation Guide STU3 Release 3.1.1, August 28, 2020, IBR approved for §  170.215(a).

* * * * *

(m) * * *

(5) United States Core Data for Interoperability (USCDI), Version 1, July 2020 Errata, IBR approved for § 170.213; available at https://www.healthit.gov/​USCDI.

* * * * *

10. Amend § 170.300 by revising paragraphs (a), (c), and (d) to read as follows:

§ 170.300

Applicability.

(a) The certification criteria adopted in this subpart apply to the testing and certification of Health IT Modules.

* * * * *

(c) Health Modules are not required to be compliant with certification criteria or capabilities specified within a certification criterion that are designated as optional.

(d) In § 170.315, all certification criteria and all capabilities specified within a certification criterion have general applicability (i.e., apply to any health care setting) unless designated as “inpatient setting only” or “ambulatory setting only.”

* * * * *

11. Amend § 170.315 by:

a. Revising paragraphs (b)(1)(iii)(A)( 2), (b)(2)(i), (b)(2)(iii)(D) introductory text, (b)(2)(iv), (b)(3)(ii)(B)(2), (b)(7)(ii), (b)(8)(i)(B), (b)(9)(ii), (c)(3), (d)(13)(ii), (e)(1)(i)(A)(2), (f)(5)(iii)(B)(1) and (2), (g)(6)(i)(B), (g)(9)(i)(A)(2), (g)(10)(v)(A)(1)(ii), and (g)(10)(v)(A)(2)(ii); and

b. Adding paragraph (g)(10)(iv)(A)( 1)(iii).

The revisions and addition read as follows:

§ 170.315

2015 Edition health IT certification criteria.

* * * * *

(b) * * *

(1) * * *

(iii) * * *

(A) * * *

(2) The Common Clinical Data Set in accordance with § 170.205(a)(4) and paragraph (b)(1)(iii)(A)(3)(i) through (iv) of this section for the period before December 31, 2022, and

* * * * *

(2) * * *

(i) General requirements. Paragraphs (b)(2)(ii) and (iii) of this section must be completed based on the receipt of a transition of care/referral summary formatted in accordance with the standards adopted in § 170.205(a)(3) through (5) using the Continuity of Care Document, Referral Note, and (inpatient setting only) Discharge Summary document templates on and after December 31, 2022.

* * * * *

(iii) * * *

(D) Upon a user's confirmation, automatically update the list, and incorporate the following data expressed according to the specified standard(s) on and after December 31, 2022:

* * * * *

(iv) System verification. Based on the data reconciled and incorporated, the technology must be able to create a file formatted according to the standard specified in § 170.205(a)(4) using the Continuity of Care Document template and the standard specified in § 170.205(a)(5) on and after December 31, 2022.

(3) * * *

(ii) * * *

(B) * * *

(2) Send fill status notifications (RxFillIndicatorChange).

* * * * *

(7) * * *

(ii) Document level for the period before December 31, 2022.

(8) * * *

(i) * * *

(B) Document level for the period before December 31, 2022; and

* * * * *

(9) * * *

(ii) The standard in § 170.205(a)(5) on and after December 31, 2022.

* * * * *

(c) * * *

(3) Clinical quality measures—report. Enable a user to electronically create a data file for transmission of clinical quality measurement data:

(i) In accordance with the applicable implementation specifications specified by the CMS implementation guides for Quality Reporting Document Architecture (QRDA), category I, for inpatient measures in § 170.205(h)(3) and CMS implementation guide for QRDA, category III for ambulatory measures in § 170.205 (k)(3); or

(ii) In accordance with the standards specified in § 170.205(h)(2) and § 170.205(k)(1) and (2) for the period before December 31, 2022.

* * * * *

(d) * * *

(13) * * *

(ii) No—the Health IT Module does not support authentication, through multiple elements, of the user's identity with the use of industry-recognized standards. When attesting “no,” the health IT developer may explain why the Health IT Module does not support authentication, through multiple elements, of the user's identity with the use of industry-recognized standards.

(e) * * *

(1) * * *

(i) * * *

(A) * * *

(2) The Common Clinical Data Set in accordance with § 170.205(a)(4) and paragraphs (e)(1)(i)(A)(3)(i) through (iv) of this section for the period before December 31, 2022.

* * * * *

(f) * * *

(5) * * *

(iii) * * *

(B) * * *

(1) The data classes expressed in the standard in § 170.213, or

(2) The Common Clinical Data Set for the period before December 31, 2022.

* * * * *

(g) * * *

(6) * * *

(i) * * *

(B) The Common Clinical Data Set in accordance with § 170.205(a)(4) and paragraphs (g)(6)(i)(C)(1) through (4) of this section for the period before December 31, 2022.

* * * * *

(9) * * *

(i) * * *

(A) * * *

(2) The Common Clinical Data Set in accordance with paragraphs (g)(9)(i)(A)(3)(i) through (iv) of this section for the period before December 31, 2022, and

* * * * *

(10) * * *

(v) * * *

(A) * * *

(1) * * *

(ii) A Health IT Module's authorization server must issue a refresh token valid for a period of no less than three months to applications capable of storing a client secret.

(iii) A Health IT Module's authorization server must issue a refresh token for a period of no less than three months to native applications capable of securing a refresh token.

(2) * * *

(ii) A Health IT Module's authorization server must issue a refresh token valid for a new period of no less than three months to applications capable of storing a client secret.

* * * * *

12. Amend § 170.401 by revising paragraph (a) to read as follows:

§ 170.401

Information blocking.

(a) Condition of Certification requirement. A health IT developer must not take any action that constitutes information blocking as defined in 42 U.S.C. 300jj-52 and § 171.103 on or after April 5, 2021.

* * * * *

13. Amend by revising § 170.402 by revising paragraphs (a)(1), (4) and (b)(2) to read as follows:

§ 170.402

Assurances.

(a) * * *

(1) A health IT developer must provide assurances satisfactory to the Secretary that the health IT developer will not take any action that constitutes information blocking as defined in 42 U.S.C. 300jj-52 and § 171.103 of this chapter on and after April 5, 2021, unless for legitimate purposes as specified by the Secretary; or any other action that may inhibit the appropriate exchange, access, and use of electronic health information.

* * * * *

(4) A health IT developer of a certified Health IT Module that is part of a health IT product which electronically stores EHI must certify to the certification criterion in § 170.315(b)(10).

(b) * * *

(2)(i) By December 31, 2023, a health IT developer that must comply with the requirements of paragraph (a)(4) of this section must provide all of its customers of certified health IT with the health IT certified to the certification criterion in § 170.315(b)(10).

(ii) On and after December 31, 2023, a health IT developer that must comply with the requirements of paragraph (a)(4) of this section must provide all of its customers of certified health IT with the health IT certified to the certification criterion in § 170.315(b)(10).

14. Amend § 170.403 by revising (b)(1) to read as follows:

§ 170.403

Communications.

* * * * *

(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.

* * * * *

15. Amend § 170.404 by revising (b)(3) and (4) to read as follows:

§ 170.404

Application programming interfaces.

* * * * *

(b) * * *

(3) Rollout of (g)(10)-certified APIs. A Certified API Developer with certified API technology previously certified to the certification criterion in § 170.315(g)(8) must provide all API Information Sources with such certified API technology deployed with certified API technology certified to the certification criterion in § 170.315(g)(10) by no later than December 31, 2022.

(4) Compliance for existing certified API technology. By no later than April 5, 2021, a Certified API Developer with Health IT Module(s) certified to the certification criteria in § 170.315(g)(7), (8), or (9) must comply with paragraph (a) of this section, including revisions to their existing business and technical API documentation and make such documentation available via a publicly accessible hyperlink that allows any person to directly access the information without any preconditions or additional steps.

* * * * *

16. Amend § 170.405 by:

a. Revising paragraphs (b)(1) introductory text, (b)(2)(ii) introductory text, (b)(3) introductory text, (b)(4)(ii), (b)(5)(ii), (b)(6)(ii), and (b)(7)(ii); and

b. Adding paragraph (b)(10).

The revisions and addition read as follows:

§ 170.405

Real world testing.

* * * * *

(b) * * *

(1) Real world testing plan submission. A health IT developer with Health IT Module(s) certified to any one or more of the criteria referenced in paragraph (a) of this section must submit to its ONC-ACB an annual real world testing plan addressing each of those certified Health IT Modules by a date determined by the ONC-ACB that enables the ONC-ACB to publish a publicly available hyperlink to the plan on CHPL no later than December 15 of each calendar year, beginning in 2021.

* * * * *

(2) * * *

(ii) For real world testing activities conducted during the immediately preceding calendar year, a health IT developer must submit to its ONC-ACB an annual real world testing results report addressing each of its certified Health IT Modules that include certification criteria referenced in paragraph (a) of this section by a date determined by the ONC-ACB that enables the ONC-ACB to publish a publicly available hyperlink to the results report on CHPL no later than March 15 of each calendar year, beginning in 2023. The real world testing results must report the following for each of the certification criteria identified in paragraph (a) of this section that are included in the Health IT Module's scope of certification:

* * * * *

(3) USCDI Updates. A health IT developer with health IT certified to § 170.315(b)(1), (b)(2), (e)(1), (g)(6) and/or (g)(9) on May 1, 2020, must:

* * * * *

(ii) Provide its customers of the previously certified health IT with certified health IT that meets paragraph (b)(3)(i) of this section by December 31, 2022.

(4) * * *

(ii) Provide its customers of the previously certified health IT with certified health IT that meets paragraph (b)(4)(i) of this section by December 31, 2022.

(5) * * *

(ii) Provide its customers of the previously certified health IT with certified health IT that meets paragraph (b)(5)(i) of this section by December 31, 2022.

(6) * * *

(ii) Provide its customers of the previously certified health IT with certified health IT that meets paragraph (b)(6)(i) of this section by December 31, 2022.

(7) * * *

(ii) Provide its customers of the previously certified health IT with certified health IT that meets paragraph (b)(7)(i) of this section by December 31, 2022.

* * * * *

(10) Clinical quality measures—report. A health IT developer with health IT certified to § 170.315(c)(3) prior to June 30, 2020, must:

(i) Update their certified health IT to be compliant with the revised versions of this criteria adopted in § 170.315(c)(3); and

(ii) Provide its customers of the previously certified health IT with certified health IT that meets paragraph (b)(10)(i) of this section by December 31, 2022.

17. Amend § 170.523 by:

a. Removing and reserving paragraph (f)(1)(xxi); and

b. Revising paragraphs (k)(1) introductory text and (k)(1)(i).

The revisions read as follows:

§ 170.523

Principles of proper conduct for ONC-ACBs.

* * * * *

(k) * * *

(1) Mandatory Disclosures. A health IT developer must conspicuously include the following on its website and in all marketing materials, communications statements, and other assertions related to the Health IT Module's certification:

(i) The disclaimer “This Health IT Module is [specify Edition of health IT certification criteria] compliant and has been certified by an ONC-ACB in accordance with the applicable certification criteria adopted by the Secretary of Health and Human Services. This certification does not represent an endorsement by the U.S. Department of Health and Human Services.”

* * * * *

18. Amend § 170.550 by revising paragraphs (m)(1), (2), and (3) to read as follows:

§ 170.550

Health IT Module certification.

* * * * *

(m) * * *

(1) Section 170.315(a)(10) and (13) and § 170.315(e)(2) for the period before January 1, 2022.

(2) Section 170.315(b)(6) for the period before December 31, 2023.

(3) Section 170.315(g)(8) for the period before December 31, 2022.

PART 171—INFORMATION BLOCKING

19. The authority citation for part 171 continues to read as follows:

Authority: 42 U.S.C. 300jj-52

20. Amend § 171.101 by revising paragraph (b) to read as follows:

§ 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.

21. Amend § 171.103 by revising paragraphs (a)(2), (a)(3) and (b) to read as follows:

§ 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 § 170.213.

* * * * *

22. Amend § 171.203 by revising paragraph (e)(2) to read as follows:

§ 171.203

Security exception—When will an actor's practice that is likely to interfere with the access, exchange, or use of electronic health information in order to protect the security of electronic health information not be considered information blocking?

* * * * *

(e) * * *

(2) There are no reasonable and appropriate alternatives to the practice that address the security risk that are less likely to interfere with access, exchange or use of electronic health information.

23. Amend § 171.301 by revising paragraphs (a)(1), (a)(2) and (b)(1)(ii)(A) to read as follows:

§ 171.301

Content and manner exception—When will an actor's practice of limiting the content of its response to or the manner in which it fulfills a request to access, exchange, or use electronic health information not be considered information blocking?

* * * * *

(a) * * *

(1) USCDI. For the period before October 6, 2022, at a minimum, the electronic health information identified by the data elements represented in the USCDI standard adopted in § 170.213.

(2) All electronic health information. On and after October 6, 2022, electronic health information as defined in § 171.102.

(b) * * *

(1) * * *

(ii) * * *

(A) Any fees charged by the actor in relation to fulfilling the request are not required to satisfy the exception in § 171.302; and

* * * * *

24. Amend § 171.303 by revising paragraph (b)(2)(i) to read as follows:

§ 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.

Footnotes

1.  https://www.who.int/​emergencies/​diseases/​novel-coronavirus-2019 (Accessed on 10/22/2020).

2.  https://www.healthit.gov/​curesrule/​resources/​enforcement-discretion.

3.  Note that for the Content and Manner Exception, in § 171.301(a), for the period before October 6, 2022, the definition of EHI is limited to, at a minimum, the data elements represented in the USCDI standard; and, for the period on and after Oct 6, 2022, EHI is defined as it is in § 171.102. 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.

4.  https://www.healthit.gov/​sites/​default/​files/​reports/​info_​blocking_​040915.pdf.

5.  https://www.healthit.gov/​curesrule/​resources/​enforcement-discretion.

6.  https://www.healthit.gov/​curesrule/​resources/​enforcement-discretion.

7.  https://www.healthit.gov/​curesrule/​resources/​enforcement-discretion.

8.  https://www.healthit.gov/​curesrule/​resources/​enforcement-discretion.

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.

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.

14.  IETF RFC 6749: https://tools.ietf.org/​html/​rfc6749.

15.  RFC 6749 (https://tools.ietf.org/​html/​rfc6749) describes native applications as “clients installed and executed on the device used by the resource owner (i.e., desktop applications, and native mobile applications).” IETF RFC 8252 (https://tools.ietf.org/​html/​rfc8252), referenced by the HL7® SMART Application Launch Framework Implementation Guide Release 1.0.0 (SMART IG) (adopted in § 170.215(a)(3)), updates RFC 6749 and provides guidance for OAuth 2.0 authorization requests from native applications. RFC 8252 describes technology and security practices that can be used to enable native applications to securely authenticate their identity and prevent 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.

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/​.