[vc_row][vc_column][vc_column_text]The Office of the National Coordinator for Health Information Technology (ONC) recently released an Interim Final Rule (IFR) providing additional flexibility enabling the healthcare community to effectively respond to the public health emergency related to COVID-19. The IFR – Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency – extends compliance dates and timeframes for information blocking and certain 2015 Edition health IT criteria and Conditions and Maintenance of Certification requirements. The IFR also addresses additional updates, clarifications and corrections.
Although compliance deadlines have been extended, the momentum to deliver patients access to their health information continues to be a driving force for the health IT industry. Over the past several months, Drummond heard from many health IT developers regarding the impact of the Cures updates. We know many of you are choosing to continue testing and certification in 2021 as planned for several of the Cures requirements. We encourage all customers to stay the course and continue planning for the Cures updates to ensure compliance is achieved well before the deadline.
Real World Testing
We know many are awaiting additional guidance regarding real world testing (RWT). The IFR delayed the initial plan and initial results submission by one year, which means Dec. 15, 2021, is the new deadline to have initial plans available on the CHPL. Drummond will require submission by no later than Nov. 15, 2021, to ensure your plan is accepted.
Due to the new compliance deadline, Drummond is not currently accepting test plans for review, but will continue to work with the ONC to provide developers with additional information. Plans are in the works to release additional guidance documents during the first two quarters in 2021 prior to opening our submission process.
These tables highlight the updated timelines, adopted standards, as well as pertinent corrections and clarifications from the IFR. In addition, the ONC has released several helpful documents here.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][movedo_title]
[/movedo_title][movedo_single_image image=”22973″][/vc_column][/vc_row][vc_row desktop_visibility=”hide” tablet_visibility=”hide” tablet_sm_visibility=”hide” mobile_visibility=”hide”][vc_column][vc_column_text]
|Provision||Final Rule||Interim Final Rule|
|Condition of Certification (CoC) – Information Blocking – (§ 170.401)||Nov. 2, 2020||April 5, 2021|
|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)||Nov. 2, 2020||April 5, 2021|
|CoC – Assurances – (§ 170.402(a)(2) and (3), and (b)(1)) – Other||June 30, 2020||April 5, 2021|
|CoC – Communications – (§ 170.403) – Communications requirements, except for § 170.403(b)(1) where ONC removed the notice requirement for 2020||June 30, 2020||April 5, 2021|
|CoC – API – (§ 170.404(b)(4)) – Compliance for current API criteria||Nov. 2, 2020||April 5, 2021|
|CoC – API – (§ 170.404(b)(3)) – Rollout of new standardized API functionality certified to § 170.315(g)(10)||May 2, 2022||Dec. 31, 2022|
|CoC – Real World Testing – 2015 Edition health IT certification criteria updates – EHI export. See Assurances below||May 2, 2022||Dec. 31, 2022|
|CoC – Assurances – (§ 170.402(a)(4) and (b)(2)) – EHI Export Rollout § 170.315(b)(10)||May 1, 2023||Dec. 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 CY 2020||Annually beginning in CY 2021|
|CoC – Initial Attestations – (§ 170.406)||April 1-30, 2021 attestation window for attestation period running June 30, 2020 through March 31, 2021||April 1-30, 2022
(annual Cycle begins 1 year later)
|CoC – Real World Testing – (§ 170.405(b)(1) and (2)) – Submit initial plan and initial results submission||Plan: Dec.15, 2020
Results: March 15, 2022
|Plan: Dec. 15, 2021
Results: March 15, 2023
|USCDI – Update to the USCDI standard for § 170.315 (b)(1), (b)(2), (e)(1), (f)(5), (g)(6), (g)(9), and (g)(10)||May 2, 2022||Dec. 31, 2022|
|New and Revised Certification Criteria – Update standards or implement for § 170.315 (b)(3), (b)(7), (b)(8), (c)(3), (d)(2), (d)(3), (d)(10), (d)(12), and (d)(13)||May 2, 2022||Dec. 31, 2022|
|Current Standard||New Standard Adopted in IFR
|USCDI v1||§170.213 USCDI, July 2020 Errata, Version 1 (v1)
|Corrections to applicable standards|
|US Core Implementation Guide||§170.215 HL7 FHIR US Core IG STU Release 3.1.1, August 28, 2020
|Technical corrections and minor clarifications|
|CMS QRDA Implementation Guide (latest available at time of FR publication)||§170.205(h)(3) and §170.205(k)(3) 2020 CMS QRDA I and QRDA III Implementation Guides
|Adopting most recent version of CMS QRDA IGs|
|2015 Cures Criteria||Correction/Clarification
|170.315(b.3) E-Prescribing||Corrected typo “RxFillIndicator” to “RxFillIndicatorChange”
|170.315(d.2) Auditable Events, 170.315(d.3) Audit Reports, and 170.315(d.10) Auditing Actions
|Remove “7.1.3 Duration of Access” (E2147-18) requirement from 2015 certification criteria|
|170.315(f.5) Electronic Case Reporting||Error identified stating developers were required to conform to HL7 Clinical Document Architecture standard and companion guide in 170.205(a)(4) and (5). It was only Intended for developers certifying to (f.5) required to conform to data classes expressed in standards in USCDI or CCDS for the period before 12/31/2022.
|170.315(g.10) Standardized API for Patient and Population Services||Clarified health IT modules must:
§ Support the issuance of an initial refresh token to native applications that are capable of securing a refresh token;
§ “For subsequent connections, an application capable of storing a client secret must be issued a refresh token valid for a new period of no less than three months”. Replaced earlier wording of “new refresh token” and clarified that the “new period” applies to the extended or renewed duration of the “refreshed” refresh token; and
§ Issue a refresh token that is valid for a new period of no less than 3 months to only applications that are capable of storing a client secret.
|170.210(g) Synchronized Clocks||Removed reference to obsolete standard RFC 1305. Clarifies RFC 5905 and NTP v4 was already approved for §170.210 on September 4, 2012.