2020 ONC Cures Act Final Rule: What You Need to Know

Earlier this week (Monday, March 9, 2020) ONC released the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Final Rule (often referred to now as simply the “Cures Act”), a follow up to their earlier proposed rule (you can review our comments on the proposed rule here). Note that at the same time CMS also released their “Interoperability and Patient Access” final rule (which we’ll review in a subsequent blog post).

In this blog post, we’ll summarize some of the key provisions in the Cures Act 1,244-page rule and offer comments and suggestions along the way.

What is the Cures Act, and Why is It Important?

The Cures Act has two key components: Information Blocking, and supporting ONC Certification criteria, and ONC has made a concerted effort to try to approach this as a unified whole, where new and revised certification criteria are designed to directly support the Information Blocking provisions of the rule.

With this rule, ONC is attempting to balance multiple competing priorities – of primary concern is patient access to their Electronic Health Information (EHI) while protecting their privacy and providing security for that data. Yet ONC also would like to provide transparency and stimulate innovation in health care by minimizing API development and maintenance costs, while at the same time protecting the intellectual property of software developers. And finally, they want to reduce the burden on providers and health systems by making physician chart requests easy and allowing providers to easily switch health systems and software vendors. Standardization vs. innovation, privacy and security vs. interoperability – it’s quite a balancing act.

Background and Definitions

ONC has recognized that some conflicts exist in current legislation (for example between HIPAA and other privacy and security statutes) and ONC is leveraging the Cures Act to help establish common definitions and standards to help alleviate these inconsistencies.

Information Blocking

A practice that is likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information.

Two legal knowledge standards

Developers, HIE/HINs: defined as “know or should know” they are engaged in information blocking–a higher legal standard than for providers.

Providers: only defined as “know” they are engaged in information blocking

Three Categories of “Actors”

• Health Care Providers – Covers hospitals, health systems, and other facilities (such as nursing homes and pharmacies), as well as individual clinicians. (A full list is available in the final rule).
• Health IT Developers of Certified Health IT – Essentially synonymous with software developers (with some caveats) that are certified through ONC. Note that self-developers are excluded.
• Health Information Exchanges and/or Health Information Networks – An individual or entity that controls/administers the exchange, or use of electronic health information, for a treatment, payment, or health care operations purpose. Requires at least three exchange participants that are able to exchange health information to qualify.

Definition of Electronic Health Information (EHI)

EHI is defined to mean Electronic Protected Health Information (ePHI) to the extent that the ePHI is included in a Designated Record Set (DRS), as defined for HIPAA.

This is applicable whether or not the actor is a covered entity.

Until 24 months after the publication date of the final rule, EHI will be limited to the data elements of the USCDI standard.

Legal Considerations

The Office of the Inspector General (OIG) has been designated as the HHS office that will investigate claims of Information Blocking.

The Cures Act prescribes specific Civil Monetary Penalties (CMPs) for Information Blocking of up to $1 million per violation.

Enforcement will not begin sooner than the compliance date of the final rule, which is at least six months after publication of the final rule in the Federal Register. The final enforcement specifics (including the final enforcement date) will be established by future rulemaking from OIG.

Offending Developers can be Banned from Certification, as information blocking is a Condition of Certification, and banned (and terminated) actors will be publicly listed on ONC’s website.

Exceptions to Information Blocking

In the Cures Act, ONC provides guidance on Information Blocking by defining eight specific exceptions. Note that compliance is not required until six months after publication in the Federal Register.

1) Preventing Harm Exception

It will not be information blocking for an actor to engage in practices that are reasonable and necessary to prevent harm to a patient or another person, provided certain conditions are met:

• The actor must hold a reasonable belief that the practice will substantially reduce a risk of harm.
• The actor’s practice must be no broader than necessary.
• The actor’s practice must satisfy at least one condition from each of the following categories:
  • Type of risk
  • Type of harm
  • Implementation basis
• The practice must satisfy the condition concerning a patient right to request review of an individualized determination of risk of harm.

2) Privacy Exception

It will not be information blocking if an actor does not fulfill a request to access, exchange, or use EHI in order to protect an individual’s privacy, provided at least one of the following conditions are met:

• Precondition not satisfied: If required by a state or federal law to satisfy a precondition (such as a patient consent or authorization), an actor may choose not to provide EHI if the precondition has not been satisfied under certain circumstances.
• Health IT developer of certified health IT not covered by HIPAA: If an actor is not required to comply with the HIPAA Privacy Rule, the actor may choose to interfere with EHI exchange for a privacy-protective purpose if certain conditions are met.
• Denial of an individual’s request for their EHI consistent with HIPAA: An actor that is a covered entity or business associate may deny an individual’s request for access to his or her EHI in the circumstances provided under 45 CFR 164.524(a)(1) and (2) of the HIPAA Privacy Rule.
• Respecting an individual’s request not to share information: An actor may choose not to provide access, exchange, or use of an individual’s EHI if doing so fulfills the wishes of the individual, provided certain conditions are met.

3) Security Exception

It will not be information blocking for an actor to interfere with the access, exchange, or use of EHI in order to protect the security of EHI, provided certain conditions are met:

• The practice must be:
  • Directly related to safeguarding the confidentiality, integrity and availability of EHI.
  • Tailored to specific security risks.
  • Implemented in a consistent and non-discriminatory manner.
• The practice must either implement a qualifying organizational security policy or implement a qualifying security determination.

4) Infeasibility Exception

It will not be information blocking if an actor does not fulfill a request to access, exchange, or use EHI due to the infeasibility of the request, provided certain conditions are met:

• The practice must meet one of the following conditions:
  • Uncontrollable events: The actor cannot fulfill the request for access, exchange, or use of electronic health information due to a natural or human-made disaster, public health emergency, public safety incident, war, terrorist attack, civil insurrection, strike or other labor unrest, telecommunication or internet service interruption, or act of military, civil or regulatory authority.
  • Segmentation: The actor cannot fulfill the request for access, exchange, or use of EHI because the actor cannot unambiguously segment the requested EHI.
  • Infeasibility under the circumstances: The actor demonstrates through a contemporaneous written record or other documentation its consistent and non-discriminatory consideration of certain factors that led to its determination that complying with the request would be infeasible under the circumstances.
• The actor must provide a written response to the requestor within 10 business days of receipt of the request with the reason(s) why the request is infeasible.

5) Health IT Performance Exception

It will not be information blocking for an actor to make health IT temporarily unavailable or to degrade the health IT’s performance, provided certain conditions are met:

• The practice must:
  • Be implemented for a period of time no longer than necessary to achieve the maintenance or improvements for which the health IT was made unavailable or the health IT’s performance degraded.
  • Be implemented in a consistent and non-discriminatory manner.
  • Meet certain requirements if the unavailability or degradation is initiated by a health IT developer of certified health IT, HIE, or HIN.
• An actor may take action against a third-party app that is negatively impacting the health IT’s performance, provided that the practice is:
  • For a period of time no longer than necessary to resolve any negative impacts.
  • Implemented in a consistent and non-discriminatory manner.
  • Consistent with existing service level agreements, where applicable.
• If the unavailability is in response to a risk of harm or security risk, the actor must only comply with the Preventing Harm or Security Exception, as applicable.

6) Content and Manner Exception

It will not be information blocking for an actor to limit the content of its response to a request to access, exchange, or use EHI or the manner in which it fulfills a request to access, exchange, or use EHI, provided certain conditions are met:

• Content Condition: Establishes the content an actor must provide in response to a request to access, exchange, or use EHI in order to satisfy the exception.
  • Up to 24 months after the publication date of the Cures Act final rule, an actor must respond to a request to access, exchange, or use EHI with, at a minimum, the EHI identified by the data elements represented in the United States Core Data for Interoperability (USCDI) standard.
  • On and after 24 months after the publication date of the Cures Act final rule, an actor must respond to a request to access, exchange, or use EHI with EHI as defined in u00a7 171.102.
• Manner Condition: Establishes the manner in which an actor must fulfill a request to access, exchange, or use EHI in order to satisfy this exception.
  • An actor may need to fulfill a request in an alternative manner when the actor is:
    • Technically unable to fulfill the request in any manner requested.
    • Cannot reach agreeable terms with the requestor to fulfill the request.
  • If an actor fulfills a request in an alternative manner, such fulfillment must comply with the order of priority described in the manner condition and must satisfy the Fees Exception and Licensing Exception, as applicable.

7) Fees Exception

It will not be information blocking for an actor to charge fees, including fees that result in a reasonable profit margin, for accessing, exchanging, or using EHI, provided certain conditions are met:

The practice must:

• Meet the basis for fees condition.
  • For instance, the fees an actor charges must:
    • Be based on objective and verifiable criteria that are uniformly applied for all similarly situated classes of persons or entities and requests.
    • Be reasonably related to the actor’s costs of providing the type of access, exchange, or use of EHI.
    • Not be based on whether the requestor or other person is a competitor, potential competitor, or will be using the EHI in a way that facilitates competition with the actor.
• Not be specifically excluded.
  • For instance, the exception does not apply to:
    • A fee based in any part on the electronic access by an individual, their personal representative, or another person or entity designated by the individual to access the individual’s EHI.
    • A fee to perform an export of electronic health information via the capability of health IT certified to u00a7 170.315(b)(10).
• Comply with Conditions of Certification in u00a7 170.402(a)(4) (Assurances – certification to “EHI Export” criterion) or u00a7 170.404 (API).

8) Licensing Exception

It will not be information blocking for an actor to license interoperability elements for EHI to be accessed, exchanged, or used, provided certain conditions are met:

The practice must meet:

• The negotiating a license conditions: An actor must begin license negotiations with the requestor within 10 business days from receipt of the request and negotiate a license within 30 business days from receipt of the request.
• The licensing conditions:
  • Scope of rights
  • Reasonable royalty
  • Non-discriminatory terms
  • Collateral terms
  • Non-disclosure agreement
• Additional conditions relating to the provision of interoperability elements.

The USCDI – The New Standard for Interoperability

One of the most important changes in the Cures Act is the shift from the Common Clinical Data Set (CCDS) to the United States Core Data for Interoperability (USCDI).

• The deadline for Health IT developers to update their software to the USCDI standard is 24 months after publication of the Cures Act in the Federal Register. This will mean the USCDI and the CCDS will coexist in some fashion for the next two years.
• The USCDI will receive regular annual updates, expanding the data set standard for exchange.
• The USCCI includes new data classes and elements, including support for:
  – Provenance of data
  – Clinical notes
  – Pediatric vital signs
  – Address, email and phone number

This will likely mean workflow changes for providers in order to accurately capture and document these new data elements, and annual updates to software from developers to accommodate an ever-expanding USCDI data set.

Note that the USCDI will also be included in the Standards Version Advancement Process (SVAP) which is intended to streamline development and implementation to newer versions of the USCDI as the standard evolves.

Updates to the 2015 Edition Certification Criteria

With this rule, ONC has chosen to make changes to the existing 2015 Edition Certification Criteria, yet will maintain the existing name (which may prove confusing).

Note that there will be a 24-month transition period for the implementation of these updates.

Removed Criteria

A number of existing 2015 certification criteria will be removed because they will no longer support specific measures within the Promoting Interoperability programs of Medicare and Medicaid, yet ONC clearly feels these measures retain clinical value, and should not be removed from health IT systems simply because they are no longer required for certification.

Revised Criteria

The Cures Act also revised a number of standards referenced by several existing 2015 Edition certification criteria. In addition, the Cures Act also officially replaced the Common Clinical Data Set with the United States Core Data for Interoperability (USCDI) standard.

New Criteria

The Cures Act introduced two new technical certification criteria designed to facilitate interoperability between systems, as well as two new privacy and security certification criteria requiring transparency attestations from developers.

Conditions of Maintenance for Certification

The Cures Act establishes seven Conditions of Certification with Maintenance of Certification Requirements. We’ll briefly examine some of the key provisions for each.

1) Information Blocking

Health IT Developers may not take any actions that constitute “information blocking” as defined in section 3022(a) of the Public Health Service Act (PHSA) and u00a7 171.103. Applies to certified health IT developers only.

Deadline for compliance is six months from the rule publication date.

2) Assurances

Health IT developers must provide assurances they will not take any action that constitutes information blocking or any other action that may inhibit the appropriate exchange, access and use of electronic health information (EHI).

Requires EHI export functionality 36 months after the publication date in the Federal Register.

Developers much retain records to demonstrate compliance for 10 years.

Note that while compliance with TEFCA is not in this final rule, ONC has hinted that required participation in TEFCA is likely in future rulemaking.

3) Communications

Health IT developers may not prohibit or restrict communication of:

• Usability
• Interoperability
• Security
• User’s experiences when using the health IT
• Business practices of developers related to exchanging EHI
• Manner in which a user of health IT has used such technology

Developers must also notify customers that any current contract provisions limiting communication will not be enforced. This notice must be provided annually until contracts are updated.

Unqualified Protection for Certain Communications

• Disclosures required by law
• Adverse events
• Cybersecurity threats
• Unlawful practices
• Failure to comply with Conditions of Certification

Permitted Prohibitions and Restrictions

• Developer employees and contractors
• Non-user-facing aspects of health IT
• Intellectual property (under certain conditions)
• Screenshots and video (under certain conditions)
• Pre-market testing and development

Of particular interest is the sharing of screenshots and video of EHR systems – this is now expressly permitted under this rule. Some protections exist for intellectual property (IP), but any restrictions must be “no broader than necessary.”

4) Application Programming Interfaces (APIs)

The current scope of data that must be accessible via API is limited to the USCDI data set, and ONC specifies three Conditions of Certification for APIs:

• Transparency – Specifies the publication requirements for API developers’ required documentation.
• Fees – Sets criteria for allowable fees API developers would be permitted to charge, and to whom those fees could be charged.
• Openness and Pro-Competitive – Sets business requirements for API developers to promote an open and competitive marketplace.

ONC also formally defines the following as part of this section: Certified API Developer, Certified API Technology, API Information Source, API User.

Of particular interest in this section is the discussion of fees. ONC allows recovery of costs and a “reasonable profit margin” to be recovered in fees.

Developers have 24 months from publication date to become certified and provide this functionality to customers.

5) Real-World Testing

Health IT developers must successfully test the real-world use of technology in the type of setting where it is marketed. This includes:

• Submission of real-world testing plans to ONC (where the plans will be published on the CHPL website) no later than December 15 of each calendar year.
• Submission of real-world testing results to ONC (again, published on CHPL) no later than March 15 of each calendar year.
• Notify ONC of any non-conformity with program requirements.

Additionally, ONC intends to leverage its “Standards Version Advancement Process” (SVAP) allowing developers to choose among various Secretary-approved standards for more flexible implementation and testing. See the final rule and ONC’s SVAP website for more information.

6) Attestations

Health IT developers must provide an attestation to compliance with the Conditions and Maintenance of Certification. Note that this excludes the “EHR reporting criteria submission” Condition of Certification, which does not require attestation.

Health IT developers must submit their attestations every six months (April and October), and the attestation window will be open for 30 days. The first attestation period opens April 1, 2021.

Note that ONC will actively provide direct review and enforcement of the Conditions and Maintenance of Certification, and has the authority to ban developers who do not comply with certification.

7) EHR Reporting Criteria Submission (future requirement)

ONC will address this criteria in future rulemaking.

Health IT for Pediatric Care and Practice Settings

ONC has developed 10 recommendations for the voluntary certification of health IT for pediatric care, and not as a separate certification program.

Current and new 2015 Edition certification criteria that support pediatric care have been identified, based on practice settings and clinical priorities.

Informational resources and other focused nonregulatory initiatives will be developed to support setting-specific implementation and alignment with ONC’s Health IT Certification Program

Compliance Timeline

Note that most timeline items start from the publication date of the final rule in the Federal Register, and as of the dgate of this blog post, this has not yet been determined.