New ONC Final Rule Expands Information Blocking Regulatory Exceptions

KEY CHANGES TO THE INFORMATION BLOCKING REGULATIONS

• Updated scope of entities that may qualify as certified health IT developers under a new definition for what activities constitute “offering health IT” (with specific discussion about health IT donation and subsidized supply arrangements).
• New information blocking exception for actors that fulfill requests for EHI through the Trusted Exchange Framework and Common Agreement (TEFCA) when the requestor is connected through TEFCA for the EHI they seek.
• Revised infeasibility exception with two new conditions that apply to certain situations when an actor is asked to allow a third party to modify the EHI and when an actor cannot fulfill EHI requests after offering at least two alternative, interoperable manners for EHI access, exchange or use.

INFORMATION BLOCKING PROHIBITION

Under the regulations adopted by ONC in 2020, information blocking means a practice that, except as required by law or covered by an exception adopted by ONC, is likely to interfere with access, exchange or use of EHI and meets one of the following criteria:

• If conducted by a certified health IT developer or HIN/HIE, such developer or HIN/HIE knows, or should know, is likely to interfere with, prevent or materially discourage access, exchange or use of EHI.
• If conducted by a health care provider, the provider knows the practice is unreasonable and is likely to interfere with, prevent or materially discourage access, exchange or use of EHI.

For an initial period (before October 6, 2022), the EHI within the definition of information blocking was limited to the data elements represented in the US Core Data for Interoperability version 1 standard. Since October 6, 2022, EHI for purposes of the information blocking definition has meant all protected health information to the extent it would be included in an electronic designated record set as such terms are defined by the Health Insurance Portability and Accountability Act (HIPAA). The HTI-1 final rule did not change the current definition but did remove the now-obsolete language that applied prior to October 6, 2022.

DEFINITIONS OF “CERTIFIED HEALTH IT DEVELOPER” AND “OFFER HEALTH IT”

The certified health IT developer category of actors includes individuals or entities that “offer” certified health IT, but do not themselves develop certified health IT or take responsibility for the certification of health IT under the Health IT Certification Program.

The HTI-1 proposed rule included a proposed definition of “offer health IT” to clarify what arrangements would cause an individual or entity to become a certified health IT developer. The HTI-1 final rule adopts substantially the same definition as proposed but with wording changes intended to improve clarity. As finalized, offer health IT means to hold out for sale, resale, license, or relicense or to sell, resell, license, relicense or otherwise provide or supply health IT that includes one or more certified health IT modules for deployment by or for other individuals or entities except for certain excluded arrangements.

The excluded arrangements that would not constitute an offer are certain:

• Electronic health record (EHR) and other health IT cost donation and other funding subsidy arrangements, provided the individual or entity offers and makes the subsidy without condition(s) limiting the interoperability or use of the technology to access, exchange or use EHI for any lawful purpose.
• Health IT implementation and use activities conducted by an individual or entity, such as issuing login credentials.
• Consulting and legal services, including legal services furnished by outside counsel and health IT consultant assistance selection, implementation and use consulting services.
• Comprehensive and predominantly non-health IT clinician practice or other health care provider administrative or operations management services.

The exclusion for health IT donation and funding subsidy arrangements is potentially valuable for health systems and other health care providers that subsidize independent physician practices’ and hospitals’ purchase or license of certified EHRs under the Stark Law’s EHR donation exception and the Anti-Kickback Statute’s EHR donation safe harbor. However, ONC states in the preamble that the exclusion from the offer health IT definition would not apply when an actor licenses or otherwise provides a health IT item or service itself to a recipient.

The scope of the definition (including its exclusions) is important for health systems and other health care delivery organizations that may operate as a health care provider category of actor in most cases, but potentially act as a certified health IT developer actor in other instances by offering health IT to third parties. The category of actor impacts the knowledge standard under the information definition and the potential liability for information blocking violations. If the subsidizing providers are deemed to be certified health IT developers as offerors, they can be held liable for civil monetary penalties for any information blocking under the Cures Act. For more information about the final rule implementing the Cures Act provisions authorizing the HHS Office of Inspector General to impose civil monetary penalties for information blocking violations, see our Special Report. If the subsidizing providers are instead health care provider actors, they can be held liable for appropriate disincentives after HHS finalizes its appropriate disincentives proposed rule. For more information about HHS’s appropriate disincentives proposed rule, see our On the Subject.

EXPANSION OF THE INFEASIBILITY EXCEPTION

The information blocking regulations include the infeasibility exception to allow an actor’s practice of denying a request to access, exchange or use EHI due to the infeasibility of the request, provided that both of the following apply:

• The actor meets one of the exception’s conditions for different types of infeasibility.
• The actor provides to the requestor in writing the reasons why the request is infeasible within 10 business days of receiving the request.

The final rule amends the uncontrollable events condition in the infeasibility exception and adds two new conditions: one to allow an actor to deny a third party seeking modification use of EHI; and a second to allow an offer to deny a request for access, exchange or use after exhausting alternative manners offered under the manner exception. The final rule does not change the previously finalized conditions for segmentation and infeasibility under the circumstances.

Uncontrollable Events Condition

The uncontrollable events condition permits an actor’s practice of not fulfilling a request to access, exchange or use EHI that is infeasible for the actor to fulfill as a result of an event (e.g., a disaster or public health emergency) listed in the condition. The final rule revises the text of the condition to clarify that the mere fact that an uncontrollable event occurred is not sufficient for an actor to meet the condition. Instead, there must be a causal connection between the actor’s inability to fulfill a request and the uncontrollable event.

Third Party Seeking a Modification Use Condition

ONC finalized a new infeasibility condition that allows an actor to deny a request to provide the ability for a third party (or its application or other technology) to modify (e.g., create, write or delete) EHI maintained by or for a health care provider or other entity that has deployed health IT, provided that the request is not from a health care provider requesting such use from an actor that is its business associate (as defined by HIPAA). The final condition is the same as ONC’s proposed condition except for a non-substantive editorial change to shorten the text. The new condition addresses concerns by some certified health IT developers and other actors that there are not established standards for data modification use cases and that the modification of EHI by third parties may cause data integrity and security issues.

Manner Exception Exhausted Condition

ONC finalized a new manner exception exhausted condition under the infeasibility exception that permits an actor to deny a request for access, exchange or use of EHI after offering at least two alternative manners in accordance with the Content and Manner Exception (which ONC renamed the “Manner Exception” and to which ONC made technical amendments). According to the HTI-1 final rule preamble, ONC intends for the new condition to address some actors’ concerns about requests that require an actor to divert substantial technical, human or financial resources toward “new, unique or unusual manners of supporting access, exchange or use of EHI” and away from scalable, consensus standards-based solutions.

On the other hand, ONC appears less receptive to concerns of third-party application developers and software-enabled or data-enabled service providers that some actors unfairly make available nonstandard application programming interfaces (APIs) and other interoperability elements to preferred requestors while denying substantially the same interoperability element to requestors that have developed competitive products or are otherwise disfavored.

To satisfy the new manner exception exhausted condition, the actor must be unable to fulfill a request based on the following three factors:

• The actor could not reach agreement with a requestor in accordance with the manner requested or was technically unable to fulfill a request for EHI in the manner requested.
• The actor offered at least two alternative manners in accordance with the alternative manner prong of the manner exception, one of which must use either technology certified to standard(s) adopted by ONC under the Health IT Certification Program (g., certified API technology) or content and transport standards published by the federal government or a standards development organization accredited by the American National Standards Institute.
• The actor does not provide the same access, exchange or use of the requested EHI to a substantial number of individuals or entities that are similarly situated to the requester. ONC states that this third factor is intended to prevent actors from misusing the manner exhausted condition to avoid supplying some requestors with manners of access, exchange or use that are generally available (rather than new, unique or unusual). However, ONC declines to define “substantial number” to allow for what ONC deems an “appropriate amount” of flexibility for various actors who may have very different numbers of customers or requestors. In response to comments, ONC states that calculating the percentage of customers using the same manner “may be helpful” and it believes that “‘substantial number’ is flexible enough to include as few as one customer, when appropriate, and as many as all of a given actor’s customers.” Inevitably, the meaning of substantial number will be in the eye of the beholder, such that requestors will expect their requests to be fulfilled in the manner requested if any of their competitors (or other arguably similarly situated requestors) receive the same manner, while some actors may choose to create a high threshold for what constitutes a substantial number when they do not want to provide access, exchange or use in a certain manner to a particular requestor.

The manner exception exhausted condition also provides that in determining whether a requestor is similarly situated for purposes of the condition, an actor must not discriminate based on the following criteria:

• Whether the requestor is a patient, member or other individual as defined by HIPAA.
• The health care provider type and size.
• Whether the requestor is a competitor of the actor or whether providing such access, exchange or use would facilitate competition with the actor.

The prohibition on delineating entities based on size and type contrasts with the fees and licensing exceptions frameworks, which would permit groupings of similarly situated customers based on size and type for purposes of administering costs and licensing terms.

TEFCA EXCEPTION

The HTI-1 final rule includes a new TEFCA manner exception that allows an actor to limit the manner in which it fulfills a request to access, exchange or use EHI to only via TEFCA. The final exception is a standalone exception instead of the proposed rule’s proposed manner condition to the manner exception and includes some substantive changes in response to comments to the proposed rule.

TEFCA originates from Section 4003 of the Cures Act, which required ONC to convene stakeholders to develop or support a national trusted exchange framework and common agreement for the exchange of health information between health information networks. Over the last several years, ONC has worked with stakeholders and its recognized coordinating entity, the Sequoia Project, to develop the Common Agreement for Nationwide Interoperability, the Qualified Health Information Network Technical Framework and other framework documents. Through its framework documents, TEFCA outlines a common set of principles, terms and conditions to enable nationwide exchange of EHI. On December 12, 2023, the first Qualified Health Information Networks (QHINs) were designated by The Sequoia Project on behalf of ONC, marking the start of information exchange via TEFCA.

Under the TEFCA manner exception, an actor’s practice of limiting the manner in which it fulfills a request for access, exchange or use of EHI to only via TEFCA will not be considered information blocking when the practice meets the following conditions:

• The actor and requestor are both part of TEFCA. Unlike the proposed rule, an actor is not required to check an available directory of TEFCA QHINs, participants and sub-participants. Instead, actors can determine whether requestors are enrolled in TEFCA through regular business interactions. In the final rule preamble, ONC states its policy interest in promoting interoperability through TEFCA and intends for this new exception to incentivize TEFCA participation. However, ONC acknowledges that not all entities will be ready, willing or able to join TEFCA.
• The requestor is capable of such access, exchange or use of the requested EHI from the actor via TEFCA. If an actor is capable of providing access, exchange or use of some, but not all, of the requested EHI via TEFCA, the TEFCA exception can cover the EHI that the actor is capable of providing and the requestor is capable of accessing, exchanging or using via TEFCA. The actor could then provide the remaining EHI in a different manner, such as by using any of the alternative manners in the manner exception or by addressing the request through other methods or applicable information blocking exceptions.
• The requestor does not seek to access, exchange or use EHI via the API standards (essentially Fast Healthcare Interoperability Resources (HL7 FHIR)-based standards) adopted by ONC or another version of those standards approved pursuant to the Standards Version Advancement Process under the Health IT Certification Program. When a requestor seeks to access EHI via such standards, the TEFCA manner exception is unavailable to the actor receiving such request.
• Any fees charged by the actor in relation to fulfilling the request to satisfy the fees exception and any license of interoperability elements in relation to fulfilling the request to satisfy the licensing exception.

ACTION ITEMS

The HTI-1 final rule will have a significant impact on the information sharing activities of a broad cross-section of the health care industry. Impacted organizations should consider taking the following steps in response to the final rule:

All Actors (Health Care Providers, Certified Health IT Developers, HIN/HIEs)

• Consider adopting or updating policies and procedures for responding to requests to access, exchange or use EHI from persons other than the individual who is the subject of the EHI to reflect the following:
  • The manner exception exhausted condition of the infeasibility exception
  • If applicable, the new TEFCA manner exception.
• Consider the benefits and limitations of becoming a TEFCA QHIN, participant or sub-participant in light of the TEFCA manner exception.

Certified Health IT Developers and HIN/HIEs

• Consider adopting new procedures for requests that involve the creation, deletion or other modification of EHI to reflect the new third party seeking “modification use” condition of the infeasibility exception.

Health Care Providers

• Review any EHR donation and funding subsidy agreements to determine whether any provisions could be considered by regulators as a condition limiting the interoperability or use of the technology to access, exchange or use EHI for any lawful purpose and, if so, consider removing or modifying the provisions to mitigate the risk of being deemed a certified health IT developer actor.

If you have questions about how the final rule affects your organization, contact your regular McDermott lawyer or any of the authors of this On the Subject.