The 21st Century Cures Act Final Rule

In March 2020, the Office of the National Coordinator for Health IT [Information Technology] (ONC) released the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Final Rule, to implement the provisions of the 21st Century Cures Act (the Cures Act). The Cures Act was signed into law in 2016 “to help accelerate medical product development and bring new innovations and advances to patients who need them faster and more efficiently.”* The Cures Act final rule focuses on supporting the use of modern technology and IT in health care. It aims to give patients essential data in the electronic health record (EHR) by removing barriers created by health IT developers, which often impede the sharing of information (also known as information blocking). The rule also requires the adoption of standardized processes for exchanging information, updates the requirements of the ONC health IT certification program, and more.

Why should surgeons be aware of the provisions in this rule?

Although many provisions finalized in this rule are highly technical and directed at health IT developers, the information-blocking provisions are more far-reaching and require physician compliance. It also is important to keep these updates in mind when purchasing or updating health IT to ensure that your systems have properly implemented the new requirements of the 2015 Edition Cures Update certification criteria, as it will be a participation requirement of most Medicare Quality Reporting and Promoting Interoperability programs in the near future, including participation in the Merit-based Incentive Payment System. As a reminder, when an EHR system meets the requirements for ONC health IT certification, the EHR may be referred to as certified EHR technology (CEHRT).

How will this rule increase patient and clinician access to EHI?

By implementing the policies within the Cures Act, the Department of Health and Human Services (HHS) is taking steps to make health data more easily exchangeable across health IT systems and provide patients with more control and access to their medical records. According to the ONC, the goal of the final rule is “to give patients access to their electronic medical record at no additional cost, and allow providers to choose the IT tools that allow them to best care for patients without excessive costs or technical barriers.”*

Key to achieving this goal is the implementation of a standards-based, application-based interface (API) to create a pathway for seamless exchange of electronic health information (EHI), establishing a competitive market that allows providers to choose the software that helps them provide better care. APIs can be thought of as a pathway for two different systems or applications to “talk” to each other. Implementing these capabilities within health IT systems such as EHRs will allow patients to request the information in their medical record on-demand through the applications of their choice with no additional costs and will support increased communication from clinician to clinician and clinician to patients. As health care continues to advance, these capabilities will become essential to providing transparent, high-value, patient-centered care.

How is EHI defined in the final rule?

The ONC defined EHI as the electronic protected health information in a designated record set as defined in the Health Insurance Portability and Accountability Act (HIPAA) regulations, regardless of whether the records are used or maintained by or for an entity covered under HIPAA. HIPAA defines a covered entity as an individual or entity that transmits protected health information for transactions for which the HHS has adopted a standard. Covered entities include health plans, health care providers, and health care clearinghouses.^†

This typically includes patient medical and billing records and other records used by physicians to make care decisions about patients.

What is information blocking?

The Cures Act defines information blocking as “a practice that interferes with, prevents, or materially discourages access, exchange, or use of electronic health information.”*

FIGURE 1. COMMON EXAMPLES OF INFORMATION BLOCKING

The ONC regulation defines an action that is likely to interfere with access, exchange, or use of EHI, as follows:

• If conducted by a health IT developer, health information network (HIN), or health information exchange (HIE), the developer, network, or exchange knows, or should know, that its practice is likely to interfere with access, exchange, or use of EHI; or
• If conducted by a health care provider, the clinician knows that its practice is unreasonable and likely to interfere with access, exchange, or use of EHI

Keep in mind, physicians are not required to proactively make data available to patients who have not requested it. But, if a patient requests their EHI, a delay in the release or availability of that information may be considered an interference under the information-blocking regulation. More detailed information about how ONC defines a delay in EHI release is included in later sections of this article.

Who must comply with the information-blocking requirements?

As specified by the Cures Act, the information-blocking restrictions apply to the following “actors”:

• Providers (including hospitals and physicians)
• Health IT developers
• HIEs and HINs

Are there exceptions to the information-blocking regulations?

The ONC designated eight exceptions to the information-blocking provisions. These exceptions apply to certain actions that are likely to interfere with, prevent, or materially discourage the access, exchange, or use of EHI, but would be reasonable and necessary if certain conditions are met. If an actor meets these conditions, these practices will not be subject to information-blocking enforcement and penalties. Although no formal mechanism is available to demonstrate compliance with these conditions, they provide guidance on ways for providers and other actors to internally document compliance should they be cited for a potential information-blocking violation. Brief descriptions of the eight exceptions are as follows:

• Preventing harm exception: This exception recognizes that the public interest in protecting patients and other persons against unreasonable risks of harm can justify practices that are likely to interfere with access, exchange, or use of EHI.
• Privacy exception: This exception recognizes that if an actor is permitted to provide access, exchange, or use of EHI under a privacy law, then the actor should provide that access, exchange, or use. However, an actor should not be required to use or disclose EHI in a way that is prohibited under state or federal privacy laws.
• Security exception: This exception is intended to cover all legitimate security practices but does not prescribe a maximum level of security or dictate a one-size-fits-all approach.
• Infeasibility exception: This exception recognizes that legitimate practical challenges may limit an actor’s ability to comply with requests for access, exchange, or use of EHI. An actor may not have—and may be unable to obtain—the requisite technological capabilities, legal rights, or other means necessary to enable access, exchange, or use.
• Health IT performance exception: This exception recognizes that for health IT to perform properly and efficiently, it must be maintained, and in some instances improved, which may require that health IT be taken offline temporarily. Actors should not be deterred from taking reasonable and necessary measures to make health IT temporarily unavailable or to degrade the health IT’s performance for the benefit of the overall performance of health IT.
• Content and manner exception: This exception provides clarity and flexibility to actors concerning the required content (that is, scope of EHI) of an actor’s response to a request to access, exchange, or use EHI and the manner in which the actor may fulfill the request. This exception supports innovation and competition by allowing actors the first attempt to reach and maintain market-negotiated terms for the access, exchange, and use of EHI.
• Fees exception: This exception enables actors to charge fees related to the development of technologies and provision of services that enhance interoperability, while not protecting rent-seeking, opportunistic fees, and exclusionary practices that interfere with access, exchange, or use of EHI.
• Licensing exception: This exception allows actors to protect the value of their innovations and charge reasonable royalties in order to earn returns on the investments they have made to develop, maintain, and update innovations.

Common examples of information blocking appear in Figure 1. More details about the information-blocking exceptions are available here.

Upon request, what information must clinicians make available?

Until October 5, 2022, EHI—for the purposes of the information-blocking definition—is limited to the subset of data elements represented in the United States Core Data for Interoperability (USCDI) v.1, which includes eight types of clinical notes that must be shared if requested.^‡ After October 5, 2022, actors must make available all requested EHI that they have, not just the subset of EHI represented by the data elements identified in the USCDI v.1 (see Table 1).

TABLE 1. DATA ELEMENTS REPRESENTED IN THE USCDI V.1

Note that this provision is meant to ease actors into these new requirements and does not require that data elements be recorded using specific content or vocabulary standards. The actor simply has to make the data elements listed in the USCDI v.1 available at a patient’s request and only if the actor has that specific EHI in the designated record set.

Keep in mind that limiting the information-blocking definition to data elements represented in the USCDI v.1 is the minimum requirement at this time. However, the ONC has strongly encouraged the regulated community to make all EHI available as if the scope of EHI were not currently limited.

How much time does a physician have to fulfill an EHI request?

Under the information-blocking regulations, actors are not required to proactively make any EHI available to patients or others who have not requested it. However, once a request to access, exchange, or use EHI is made, actors must respond in a timely manner. For example, this expectation could be fulfilled by making tests available to patients through a patient portal. In this circumstance, it is possible that the patient could have access to lab tests or diagnosis information before the clinician can share a diagnosis in person.

Delays in the fulfillment of an EHI request could implicate the information-blocking provisions. In these cases, information-blocking determinations would require a fact-based, case-by-case assessment. It is unlikely that a necessary delay to fulfill an EHI request would fall under the information-blocking definition. Examples of a necessary delay include ensuring that the release of the EHI complies with state law, or if EHI must be manually retrieved and moved from one system to another. In contrast, an action such as a health care provider instituting an organizational policy that imposes delays on the release of a lab result for any number of days to allow for physician review of the results would likely be considered information blocking.

The ONC has clarified that nonfinal clinical information, such as draft clinical notes and laboratory results pending confirmation, may be inappropriate to disclose or exchange until the documentation is finalized. However, should those data be used to make health care decisions about a patient, the data would fall within the “designated record set” and the definition of EHI. If the data point falls within the definition of EHI, any action that would interfere with legally permissiblhttp://ONC health IT certification criteria compliance datese access, exchange, or use of EHI could be considered information blocking.

What are the penalties for noncompliance with information-blocking regulations?

The Cures Act authorizes penalties for information blocking based on actor type, as follows:

• Health IT developers of certified health IT and HINs and HIEs will be subject to civil monetary penalties (CMPs) for engaging in information blocking. Although the Office of the Inspector General (OIG) has proposed a maximum penalty of up to $1 million per violation, it had yet to finalize these penalties in regulation as of July 2021.
• Also note that health IT developers of certified health IT are subject to an information-blocking condition of certification under the ONC Health IT Certification Program. In other words, they may lose their certification status if they engage in information blocking.
• Health care providers are treated differently under the law. A health care provider who engages in information blocking may be subject to “appropriate disincentives,” as set forth by the HHS Secretary. As of July 2021, the Secretary had yet to propose regulations to define or implement these disincentives.

Although the information blocking compliance date for all actors is April 5, 2022, enforcement will not begin until the CMPs and disincentives are finalized through rulemaking. Other compliance and effective dates for additional provisions in this rule can be found here.

The ONC has stated that each case of information blocking will be evaluated on its own unique facts. The OIG is responsible for investigating claims of information blocking, and to the extent the OIG determines an actor has been involved in information blocking, it will refer that provider to the appropriate agency for disincentives. The ONC has stated that typically the OIG will not pursue penalties for actors who make innocent mistakes or for accidental conduct.

What are the ONC Health IT certification criteria?

In 2010, the ONC launched the voluntary Health IT Certification Program to certify that health IT meets certain criteria and standards to support the requirements of the Centers for Medicare & Medicaid Services (CMS) Promoting Interoperability Program. The use of certified health IT continues to expand to other government and non-government programs. As the health care industry and health IT continues to advance, the ONC updates and expands the requirements necessary to receive certification. The new and revised criteria finalized through the Cures Act final rule is referred to as the 2015 Edition Cures Update.

How will the updates to the ONC Health IT Certification Program affect surgeons?

To meet the certification criteria of the 2015 Edition Cures Update, health IT developers must adopt APIs and EHI export functionalities within their systems. These functionalities give patients and providers more options for accessing EHI stored in an EHR. APIs allow seamless and secure exchange of EHI to apps and other health IT systems. Both the API and EHI export capabilities will make it easier for surgeons to share essential information in their EHRs with other providers outside their system.

Although these requirements are most relevant for health IT developers, it is important that physicians know that these functionalities will be available to them and required to participate in most CMS quality reporting and promoting interoperability programs.

*Food and Drug Administration. 21st Century Cures Act. 2020. Available at: www.fda.gov/regulatory-information/selected-amendments-fdc-act/21st-century-cures-act. Accessed August 2, 2021.

^†Department of Health and Human Services. Covered entities and business associates. 2017. Available at: www.hhs.gov/hipaa/for-professionals/covered-entities/index.html. Accessed August 2, 2021.

^‡HealthIT.gov. United States Core Data for Interoperability. Available at: www.healthit.gov/isa/united-states-core-data-interoperability-uscdi. Accessed August 2, 2021.