5 Key Impacts of ONC’s 2015 Cures Update

Introduction

The Office of the National Coordinator for Health IT (ONC) has recently released the final rule to the NPRM released in 2019 for the 21st Century Cures Act. You can read about the major changes proposed in that rule in CitiusTech blog.

This final rule accepts most of the changes in the proposed rule except for a few revisions such as not adopting a consent management criteria, adding a new exception for information blocking, defining scope of EHI as ePHI as per the HIPAA Privacy rule, no adoption of FDA pre-certification program at this time and formal adoption of FHIR R4 for APIs.

We are going to look at the major revisions and their impact in this blog, as many of the Cures changes had been covered as part of our blog on NPRM earlier in 2019 and there are very few modifications from that rule. The core of the rule lies in three sections - Information blocking, changes to the 2015 certification program and Conditions & Maintenance of Certification. We’ll look at these 3 sections in more detail.

Summary of Major Changes

1. Timelines: A detailed timeline has been established for all changes to take effect from the date of publication of the final rule - which was March 9th, 2020. Some changes are expected to take effect within 60 days (Some 2015 module removals), some within 6 months (information blocking provisions), some are scoped for 24 months (FHIR API criterion) while others can take up to 36 months (addition of EHI export module) from the final rule date. So, there’s a lot of flexibility in the final rule timelines which have been based on the complexity of the changes.

2. Deregulatory Actions: As was proposed in the NPRM, ONC has gone ahead with several deregulatory actions to reduce burden on ONC and Health IT developers. These actions include - removal of certain 2015 modules to consolidate module functions, removal of mandatory randomized surveillance in favor of a reactive approach, removal of the position of ONC Approved Accreditor entirely in favor of direct ONC oversight, removal of certain mandatory disclosures for Health IT developers and removal of 2014 Certification entirely from the FR to just support 2015 updates.

3. ONC 2015 Certification Changes: The major changes to the certification program as follows:

• • New name: The 2015 program will be called ONC 2015 Cures Update once Health IT certify to all the changes
  • Removed modules: Many modules like “Problem List”, “Medication List”, “Medication Allergy List”, “Smoking Status” have been removed, while others like patient Specific Education Resources will be removed after 1 Jan 2022, to maintain compatibility with CMS Medicaid programs. The full list of changes is summarized at the end in Table 1.
  • New data set USCDI v1: A new data set United States Core Data for Interoperability will replace the Common Clinical Data Set (CCDS), which was earlier MU Data Set. This new data set contains all clinical elements from CCDS, while including new elements such as Clinical Notes (Consultation, Discharge Summary etc. and should be raw text), new demographics elements (address, phone etc.), provenance of data (organization etc.) and pediatric vital signs. Many of the modules retired from 2015 edition (Problem List, Medication List etc.) are still included as part of the USCDI v1 and hence Health IT must continue to possess these functionalities. Additionally, all six 2015 edition modules which required the export or use of the CCDS i.e. Transitions of Care, View, Download, Transmit, etc. have been updated to require the USCDI v1 data set.
  • EHI Export Module: A new module to allow all Electronic Health Information, or EHI, stored as part of the Health IT module to be exported in any electronic and computable format (which is not specified) for a single patient or bulk transfer. This EHI follows the definition of ePHI from HIPAA Privacy Rule. The scope of EHI is not to be confused with USCDI v1 data set. EHI can be greater than what is included in the USCDI data set and hence, Health IT must be able to export all such information when required. To reduce the burden on Health IT, ONC has agreed to limit the scope of EHI to USCDI v1 elements up till 24 months from the release of this final rule i.e. till March 2022, post which EHI definition will be broader.
  • API Export Module: A new module to allow Health IT to export all elements of the USCDI v1 data set using FHIR R4.0.1 standard APIs – either for a single patient or bulk transfer. Several standards and Implementation Guides have been prescribed (US FHIR Core IG, Bulk Data Access IG, SMART App Launch IG, SMART Backend Services Authorization Guide, OpenID Connect standard etc.), along with guidelines for security, token management, API documentation, pricing restrictions and 3rd party App access management.
  • Revised Standards: Several existing standards have been updated, such as: NCPDP SCRIPT 2017071 for ePrescribing, CCDA R2.1 for interoperability modules, ASTM E2147–18 for audit procedures, HL7 DS4P for 3 level security tagging (Document, Section & Entry) in the Summary of Care modules and use of only CMS QRDA IG for CQM reporting (removed HL7 QRDA)
  • Standards Version Advancement Process: As part of this SVAP, Health IT developers can certify to a newer ONC approved standard (such as USCDI v2 when it comes) for any of the standards mentioned in the final rule without waiting for subsequent rulemaking and notify their ONC-ACB of the changes.

4. ONC 2015 Cures Conditions & Maintenance of Certification: A new section for constant performance overview of Health IT in the field has been adopted (same as the NPRM). Conditions of certification are certain procedures which must be performed to ensure Health IT modules are certified to ONC, whereas Maintenance criteria must be followed throughout the life of the edition to prevent decertification. Maintenance criteria are part of certain Conditions of Certification. The 6 conditions are as follows:

• • Compliance with the Information Blocking provisions: Health IT Developers must attest to not engage in information blocking, besides the 8 exceptions defined in the final rule.
  • Giving Assurances: Assurances that the Health IT will remain in full compliance to all the certified modules as expected in a real-world setting, certifying to EHI export criterion within 36 months (also a Maintenance criterion) and retaining records of certification for a period of 10 years (also a Maintenance criterion) must be provided to the secretary.
  • Not Blocking Communications: Health IT developers must not block any communication about the performance, interoperability, security, business practice and usability of their product (subject to IP disclosure restrictions). Health IT developers must notify their customers, within 6 months, that any terms in their contracts contrary to this condition will not be enforced (also a Maintenance criterion) and eventually remove such terms within 2 years (also a maintenance criterion)
  • Following API guidelines: Health IT developers certifying any API modules must ensure compliance to standards such as FHIR R4, availability of technical documentation, public hyperlinks and no fees related to the API services. An API developer must ensure an application can use the API within one business day (also a Maintenance criterion), publish FHIR service base URLs (also a Maintenance criterion) and must certify to the 2015 API modules within 24 months.
  • Real-World Testing: Health IT developers must submit and follow real-world testing plans for their Health IT to measure performance in a typical use environment (with respect to 6 prescribed ONC 2015 modules - Care coordination, CQM, VDT, Public Health, API and Transport & Other method module), starting from 15th December 2020 (also a Maintenance criterion)
  • Attestation to above conditions: Health IT developers must attest bi-annually to abide by all the above Conditions of Certification, starting from 4th Jan 2021 (also a Maintenance criterion)

5. Information Blocking: Health IT developer will not take any action that constitutes information blocking as defined by ONC in 170.401 and by section 3022(a) of the Public Health Service Act (PHSA). However, ONC also specifies 8 exceptions where information blocking is acceptable which are:

• • Preventing Harm: Information can be blocked if it will result in physical harm to an individual
  • EHI Privacy: Information can be blocked if it means violation of HIPAA Privacy Controls / is for improper or self-interested purpose
  • EHI Security: Information can be blocked if it violates security practices or conflicts the Confidentiality, Integrity or availability of EHI
  • Recovery of Costs: An EHI provider/health IT developer can expect a reasonable fee for making EHI available (technology development, etc.) if it’s non-discriminatory and related to costs of providing access, exchange, or use of EHI
  • Infeasible requests: Information can be blocked if it’d mean a substantial burden (actor size, available resources, etc.) The actor must however respond to the request and work towards an alternate method
  • Protecting IP: An actor controlling technology or other interoperability elements that are necessary to enable access to EHI will not be information blocking so long as it licenses such elements on reasonable and non-discriminatory terms
  • Maintenance of Health IT: An actor may make health IT temporarily unavailable in order to perform maintenance or improvements activities, which must be time-bound and reasonable
  • Content and Manner Exception: Allowed to limit the content of a response to a request to access, exchange, or use EHI or the manner in which it fulfils a request to access, exchange, or use EHI, provided certain conditions are met.

Key Impacts

1. Impact on Healthcare Market

• • True Global Interoperability: ONC has setup a backbone for all future interoperability regulations and frameworks including ONC’s TEFCA. With severe penalties for information blocking, mandatory use of a well-defined and accepted FHIR API, an expanded USCDI dataset (with version advancements), and maintenance of certification requirements, ONC is ensuring that Health IT will remain as much interoperable in real-world as it is in theory. This rule combined with CMS’s final rule - Condition of Participation (CoP) to send electronic notifications to another healthcare provider when a patient is admitted, discharged, or transferred will enable true transference of patients across the US without redundancies and errors.
  • FHIR Officially Supported: The acceptance of FHIR R4 now removes any ambiguity of the future interoperability standard for healthcare. With ONC and CMS backing FHIR, the standard itself should see rapid adoption and support of more clinical use cases.

2. Impact on EHR/HIT vendors

• • Certifications Risks increase: Earlier the certification process was static with Health IT certification remaining for their lifecycle. Now, Health IT still must comply with new maintenance criteria which include real-world testing and reporting to ONC. This ensures information blocking and interoperability are always a priority for Health IT developers but also increases their risks for decertification, although ONC has established a collaborative enforcement approach including audits, Corrective Action Plans (CAPs), wherein decertification will be a last resort
  • Certification Overheads also increase: With real-world testing plans, Health IT must constantly be evaluated against interoperability parameters and reported to ONC-ACBs, increasing costs. Another condition of maintenance i.e. EHR reporting to be notified in future rulemaking will further increase this. Development overheads for FHIR API, EHI export, additional elements in USCDI v1, along with multiple changes to existing standards i.e. CCDA R2.1, NCPDP SCRIPT 2017071, security tags (DS4P) etc. Overheads increases associated with staff support during implementation, workflow mapping and redesign, content development and customization, project management, other technical deployment including networking, training etc. Records retention for 10 years will add to archival costs.
  • More flexibility: Health IT vendors now have more flexibility in choosing a recent version of a standard without waiting for ONC to update rulemaking under the Standards version Advancement Process (SVAP). Vendors also have complete flexibility in choosing a standard and format for EHI export, as well as reasonable timelines for implementing new 2015 Cures modules (24-26 months).

3. Impacts on Patients

• • Maximum control on their data: With strict information blocking and EHI export mandates, patients can now have complete control over their data being shared with mandated privacy controls under existing HIPAA regulations and OAuth2 authorization for apps.
  • Improved long-term care prospects: With clinical data availability ensured for uses in analytics and continuity of care, patients stand to gain in the long-term from supportive research and AI based solutions to early detection, accurate diagnoses and better treatments.

4. Impact on Providers

• • Transparency on Health IT: Providers now have more transparency on Health IT capabilities and business contracts. Also, ONC specifies valid reporting criteria, including using screenshots & video, for any Health IT issues under the Communication Conditions of Certification, ensuring the products work as expected in the clinical setting as advertised.
  • More Options for Patient Engagement: API enabled accesses using FHIR has enable providers to choose from a multitude of partner API apps for their Health IT, without additional implementation efforts, to support their goals for patient care, care coordination and quality of care

Table 1: Summary of ONC 2015 Cures Changes