CMS ONCs Cures Act Final Rule

On March 9, 2020, ONC released its Cures Act Final Rule, and it was published in the Federal Register on May 1, 2021. The Final Rule implements key provisions outlined in the 21st Century Cures Act to advance interoperability, support seamless exchange, access, and use of Electronic Health Information (EHI), and address information blocking.

Read on to learn about:

• Changes to Information Blocking
• Exceptions to Information Blocking
• Changes to Health IT Certification Program
• Electronic Health Information (EHI) Export
• ONC’s Cures Act Final Rule - Timelines
• Information to Be Made Available to Clinicians Upon Request

Changes to Information Blocking

Information blocking was generally prohibited and defined by the Cures Act by covered actors, such as - health IT developers of certified products, healthcare providers, Health Information Networks (HINs), and Health Information Exchanges (HIE). However, there are exceptions to this rule.

1. Exceptions that involve not fulfilling exchange, access, or EHI use-related requests
2. Exceptions that involve procedures for fulfilling the exchange, access, or EHI use-related requests

Exceptions to Information Blocking

Exceptions that involve not fulfilling the exchange, access, or EHI use-related requests cover the following:

1. Preventing harm exception

2. Privacy exception

3. Security exception

4. Infeasibility exception

5. Health IT performance exception

6. Content and manner exception

7. Fees exception

8. Licensing exception

Changes to Health IT Certification Program

There are several changes that have been made to the ONC’s Health IT Certification Program by the Cures Act Final Rule. This involves adding new criteria and re-establishing the initial requirements that are needed to be met by the IT developers and their modules for getting certified. Apart from that, revisiting existing certification criteria and defining requirements that are ongoing and need to be met by the developers and their modules for maintaining certification, are also included.

The health IT developers are strictly prohibited from information blocking. In fact, if they are found to be involved in information blocking related to subjects like interoperability, usability, security, experiences, or practices related to Electronic Health Information (EHI) exports, they could face strict consequences such as getting removed from the program.

Real World Testing is another important aspect to be noted. This requires the health IT developers to test the real-world technology used successfully for interoperability purposes in the setting type, where such technology would get the chance of getting marketed.

Electronic Health Information (EHI) Export

1. Single Patient EHI Export ((170.315(b)(10)(i)): The functionality of single patient EHI export involves the use capability of executing a single patient report. It must be limited to at least one of the following ways:

• To a set of specifically identified users
• As a system administrative function

2. Patient Population EHI Export ((170.315(b)(10)(ii)): The functionality of patient population EHI export supports the transition of patient data in instances of the providers of healthcare, switching the systems of health IT.

3. Standard / Format: The criterion of certification does not require any specific standard of format to be used. Both the patient population EHI export functionalities files and the single patient export files must be in a computable and electronic format. It must also include the up-to-date hyperlink of the export format, which is publicly accessible and would allow any person to access the information directly without any additional preconditions.

4. Stored Data: This applies to all the EHI and is agnostic whether the EHI is stored by or in the certified health IT module, or whether they are by any other “non-certified” health IT product capabilities. This includes the certified health IT module as a part of it.

5. Image Data: For conformance, any imaging formation, images, and elements of the image which fall under the EHI scope for this criterion of certification would be required to be exported unless images or imaging data links (and not just the image themselves, which might remain in a PACS) are the only EHI which are stored by or in the product to which this criterion of certification applies. In this case, only the links would be required to be part of the export.

6. Timeframe: Neither of the export types would require the health IT module to support a user-defined or specific timeframe range or time limit for demonstrating conformance.

7. “Direct-to-patient” Functionality: This is a criterion of certification which do not require the “direct-to-patient” functionality for demonstrating conformance.

8. Data Retention: The developers of health IT retain much of the EHI records for demonstrating compliance for ten years as per the Cures Act section 4002.

The new EHI export criterion 170.315(b)(10) was finalized by the ONC, which required a certified module of health IT to export all of the EHI electronically, as defined in § 171.102, that could be stored at the time of the product certification, which includes the health IT module as a part of it.

New application program interfaces were established by the ONC Cures Act Final Rule for the health IT developers. Starting from May 1, 2022, the new criterion of API certification, § 170.315(g)(10), would replace the “application access—data category request” certification criterion (§ 170.315(g)(8)). This new criterion would require standardized access to API for a single patient and population service and is limited to the ‘read-only’ services, which are API-enabled, using the HL7 or Health Level 7 Fast Healthcare Interoperability Resources (FHIR^®) standard.

The following requirements have been outlined by the ONC for certified health IT developers and their certified API technologies for the meeting:

• Base standard: ONC requires the use of HL7 FHIR^® Standard Release 4.0.1.
   
• Data access and search: For both the population and single services, it is required that the API technology responds to data specified requests in the USCDI version 1, according to the US FHIR® Core Implementation Guide (US FHIR^® Core IG) for FHIR^® Release 4. According to the implementation guide of the bulk data access, the API technology must support the “group-level export” for multiple data of patients. Additionally, the API technology would need to support all the required search criteria that are specified in the US FHIR^® Core IG for access requests with the user and patient scope.
   
• Software application (app) registration: Apps would be required to register the “authorization server” of the API technology prior to interaction with the API.
   
• Publicly accessible technical documentation: The certified technology of API must be making all the necessary technical documentation that is required by developers for app registration and designing purposes that interact with the available API via a hyperlink that is publicly accessible.
   
• Security: The API technology is required by the ONC for establishing a secure and trusted connection with apps using the Transport Layer Security or TLS version of 1.2 or higher for all transmissions. The API technology is required to perform additional authorization and authentication functions by making use of specified implementations before the providers can make use of the app for clinical uses or before an app gets authorized for any patient to receive their data. The functions are as follows:
  
  a. API technology-connected apps must support authorization and authentication according to the SMART App launch implementation guide (including “patient” and “user” scopes) and the OpenID Connect standard.
  
  b. A refreshed token must be issued by the API technology for at least three months to apps, that are capable of maintaining a “client secret."
  
  c. When using the “system scopes” for requesting access to multiple data of patients, the API technology must perform the authorization and authentication during the process of granting the app access to patient data according to the “SMART Backend Services Authorization Guide” section of the Bulk Data Access Implementation Guide.
   
• Patient authorization revocation: The authorization server of the API technology, when directed by a patient, must be able to revoke the access of an authorized app to that of a patient’s data.
   
• Token introspection: The authorization server of the API technology must be able to provide the capability of validating and receiving tokens that it has issued.
   
• Permitted fees: The permitted fees which could be charged are outlined by the ONC. Generally, any fees which are not outlined are as follows:
  
  a. The developers of health IT with certified technology of API are permitted to charge fees to healthcare organizations that deploy the API for the purpose of upgrading, deploying, and developing their certified technology and recovering costs of API usage (if applicable).
  
  b. The developers of health IT, which have a certified API technology, are also permitted to charge app developers for value-added services which are related to the certified technologies, so long as the services are not effectively and efficiently deployed and developed to production-ready software which interacts with the certified API technology.
   
• Pro-competitiveness and openness: There are practices that are established by the ONC, which must be followed by the health IT developers with certified technology of API to enable a competitive and open marketplace. For example, certified API developers are generally required by the ONC to grant healthcare organizations that deploy independent ability to the API for permitting apps to interact with the certified API, which is further deployed by the healthcare organization.
   
• Developers of health IT with certified technology of API are also permitted to charge healthcare organizations with fees that deploy the API for development, deployment, and upgrade purposes of their certified API technology and recover API usage costs (if applicable).
   
• Developers of health IT that have certified the API technology are also given the permission to charge app developers for value-added services which are related to the certified technicians of the API, as long as such services are not necessarily required for effectively and efficiently developing and deploying production-ready software which interacts with the certified API technology.
   

ONC’s Cures Act Final Rule - Timelines

I. Certification timeline:

1. 30/06/2020: General effective date, which includes the Cures Update Certification criteria
2. 05/04/2021: i) Health IT developers were prohibited from restricting certain communications ii) Specific compliance requirements started for several conditions of certification, including information blocking, assurances, and APIs
3. 15/12/2021: Submission of initial Real World Testing plans
4. 01/04/2022: First attestation to the conditions of required certification
5. 31/12/2022: New HL7 FHIR^® API capability and other Cures Update criteria availability must be made mandatory
6. 15/03/2023: Submission of Real World Testing results
7. 31/12/2023: EHI export capability must be made available

II. Information blocking timeline:

1. 05/04/2021: Applicability date for information blocking provisions
2. 05/04/2021 through 05/10/2022: EHI definition is limited to the EHI identified by the data elements represented in the USCDI
3. On and after 06/10/2022: the EHI definition is no longer limited to the EHI identified by the data elements represented in the USCDI

III. Real World Testing plan timeline:

Real World Testing plans are intended to describe approaches of measurement for the year immediately following the submission of the plan. The plan should be able to address any health IT modules that are certified before or by August 31 of the year in which the plan is submitted. This process requires an ongoing, yearly basis for all modules of health IT that are certified to applicable criteria of certification.

The timeline for the Real World Testing plan is as follows:

• June 2021: Module-1 completes certification
• August 2021: Certification deadline for 2022 Real World Testing
• October 2021: Module-2 completes certification
• December 2021: 2022 Real World Testing plan for module-1 available on CHPL
• December 2022: 2023 Real World Testing plan due for module-2
• March 2023: 2022 Real World Testing results are due for module-1
• December 2023: Submission of 2024 Real World Testing plan
• March 2024: 2023 Real World Testing results are due for module-2

Information to Be Made Available to Clinicians Upon Request

Until October 5, 2022, EHI is limited to the subset of data elements that are represented in the US core data for Interoperability (USCDI) v.1. This includes the right types of clinical notes that must be shared if requested. After October 5, 2022, actors must make sure that all the requested EHI have been made available. This involves not only the represented EHI subset but also the data elements that have been identified in the USCDI v.1.

The data elements that are represented in the USCDI v.1 are as follows:

• Allergies and intolerances
• Laboratory
• Procedures
• Assessment and plan of treatment
• Care team members
• Unique device identifiers for implantable devices
• Problems
• Vital signs
• Patient goals
• Health concerns
• Medications
• Provenance
• Immunizations
• Smoking status
• Clinical notes
• Patient demographics

The above provision is meant to ease the actors into these new requirements and does not require the data elements to be recorded using any specific content or vocabulary standards. The actor has to simply make the data elements that are listed in the USCDI v. 1 available at the request of the patient, only if the actor has that specific EHI in the designated set of records. It must be kept in mind that limiting the information blocking definition to the data elements represented in the USCDI v.1 is the minimum requirement at the moment. However, the ONC has strongly encouraged the regulatory community to make all the EHI available.