On December 29, 2025, the US Department of Health and Human Services (HHS) Assistant Secretary for Technology Policy/Office of the National Coordinator for Health Information Technology (ASTP) published the Health Data, Technology, and Interoperability: ASTP/ONC Deregulatory Actions to Unleash Prosperity (HTI-5) proposed rule in the Federal Register to update its Health IT Certification Program requirements and amend the information blocking regulations that ASTP issued under the 21st Century Cures Act. On the same date, ASTP published a separate notice in the Federal Register withdrawing yet-to-be finalized proposals from the Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability (HTI-2) proposed rule.

In conjunction with the proposed rule and withdrawal notice, ASTP released new information blocking frequently asked questions (FAQs), including FAQs that address the information blocking regulations’ manner and fees exceptions. Together, the proposed changes and interpretive guidance in the FAQs would reduce the circumstances under which actors may deny requests for access, exchange, or use of electronic health information (EHI).

This client alert discusses:

• The proposed changes to the information blocking regulations, including changes to the manner exception, removal or limitation of the manner exhausted condition of the infeasibility exception, and new or amended definitions, as well as the FAQs.
• ASTP’s proposal to substantially scale back the criteria for certification of health information technology under the certification program.

The deadline for submitting comments to ASTP regarding the proposed rule is February 27, 2026, at 5:00 pm EST.

For more information about information blocking, visit McDermott Will & Schulte’s Information Blocking and Interoperability in Healthcare resources page.

Key proposed changes to the information blocking regulations

The proposed rule would:

• Remove the third party seeking modification use condition of the infeasibility exception, which permits actors to deny certain requests to write back EHI to certified health IT.

• Amend the manner requested prong of the manner exception to exclude from the exception arrangements that are not at market rates, are contracts of adhesion, or include unconscionable terms.

• Overhaul the manner exception exhausted condition of the infeasibility exception to limit the circumstances under which an actor could deny a request for a manner of access, exchange, or use of EHI on the basis that it offered alternative manners to the requestor, or, alternatively, remove the condition entirely.

• Remove the Trusted Exchange Framework and Common Agreement (TEFCA) manner exception.

Information blocking prohibition

Under the current regulations, information blocking means a practice by a health IT developer of certified health IT (certified health IT developer), health information network, or health information exchange (HIN/HIE), or by a health care provider (collectively, actors), that, except as required by law or covered by an exception adopted by ASTP, is likely to interfere with access, exchange, or use of EHI, and:

• If conducted by a certified health IT developer or HIN/HIE, is a practice that such certified health IT 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, is a practice that the provider knows is unreasonable and is likely to interfere with, prevent, or materially discourage access, exchange, or use of EHI.

Interference

The current information blocking regulations define “interfere with” or “interference” to mean “to prevent, materially discourage, or otherwise inhibit.” ASTP has previously identified practices that it believes may interfere with access, exchange, or use of EHI in FAQs. ASTP’s new FAQs clarify its interpretation that interference may include interference with access, exchange, or use of EHI by agentic artificial intelligence (AI), robotic process automation, and other automation technology, and not only technology using more manual means.

Amended information blocking exceptions

ASTP proposes to revise or remove certain existing information blocking exceptions.

Manner exception

The manner exception to the information blocking prohibition permits an actor’s practice that limits the manner in which the actor fulfills a request to access, exchange, or use EHI if the practice meets the exception’s manner requested condition or alternative manner condition.

The current manner requested condition requires the actor to fulfill a request for information in any manner requested, unless the actor is technically unable to fulfill the request or cannot reach agreeable terms with the requestor to fulfill the request. If the actor and requestor mutually agree on terms for the manner requested, the agreement may include fees that do not satisfy the fees exception and interoperability element license terms that do not satisfy the licensing exception.

If the actor does not fulfill the manner requested because it is technically infeasible or the parties do not mutually agree on terms for the manner requested, the actor may meet the exception under the alternative manner condition. That condition requires the actor to fulfill the request for EHI without unnecessary delay in an alternative manner. The actor must fulfill alternative manners in a priority order and only proceed to the next priority alternative manner if the actor is technically unable to fulfill the request in the higher priority manner. Any fees charged by the actor in relation to fulfilling the request are required to satisfy the fees exception, and any interoperability element license in relation to fulfilling the request must satisfy the licensing exception.

ASTP proposes to amend that manner requested condition to exclude any contracts, agreements, or licenses that are not at market rate, are contracts of adhesion, or include unconscionable terms. The proposed rule includes the following new definitions:

• “Market rate” means the value in an arm’s length transaction, consistent with the general market value of the subject transaction.
• “Contract of adhesion” means a contract provided on a standardized form, or on a “take it or leave it basis” without a realistic opportunity to bargain, where the desired product, service, access, use, or exchange cannot be provided except by acquiescing to the form contract.
• “Unconscionable terms” means contractual terms that are excessive, unreasonable, or shockingly unfair or unjust.

In ASTP’s new FAQs, the agency interprets the manner exception to generally require the actor to provide all of the EHI requested to meet the exception. The FAQs note that the actor may be able to meet another exception for any EHI that it cannot provide in accordance with the manner requested condition and/or alternative manner condition.

Infeasibility exception

The current information blocking regulations’ infeasibility exception provides that a denial of a request to access, exchange, or use EHI due to the infeasibility of the request is not information blocking when the denial meets one of the exception’s infeasibility conditions. The denial also must meet the timeframe of the exception’s responding to requests condition, which requires the actor to respond to the requestor in writing with the reasons why the request is infeasible within 10 business days of receipt of the request.

ASTP proposes to revise or remove the following infeasibility conditions:

• Third party seeking modification use condition. One of the current infeasibility exception conditions allows an actor to deny a request if the request is to enable use of EHI to modify EHI, provided that the request is not from a health care provider requesting such use from an actor that is its business associate. ASTP proposes to remove the condition because it believes that the “condition is susceptible to misuse by actors withholding EHI to unnecessarily inhibit access, exchange, and use of EHI by third parties that patients and health care providers want,” such as competitors to the actor. In the preamble to the proposed rule, ASTP notes that actors may be able to rely on the information blocking regulations’ security or preventing harm exception to address concerns about third-party modifications impacting the integrity of EHI or creating patient safety risks from corrupt or misidentified patient data.

• Manner exception exhausted condition. The current manner exception exhausted condition allows an actor to meet the infeasibility exception if it meets three factors. First, it requires that the actor could not reach agreement with a requestor or was technically unable to fulfill a request for EHI in the manner requested under the manner requested condition. The second factor requires that the actor offered at least two alternative manners in accordance with the alternative manner condition, one of which must use either technology certified to standard(s) adopted for the certification program or certain published content and transport standards. The third factor requires that 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. The condition provides that when determining whether a requestor is similarly situated, an actor cannot discriminate based on certain factors, including whether the requestor is a patient or other individual who is the subject of EHI; the health care provider type and size; whether the requestor is a competitor of the actor; and whether providing such access, exchange, or use would facilitate competition with the actor.

ASTP proposes to either revise or remove the manner exception exhausted condition from the infeasibility exception. ASTP is concerned that this condition is susceptible to misuse by actors to unnecessarily inhibit access, exchange, and use of EHI with competitors or other requestors. To address its concerns, ASTP proposes several changes to the second and third factors of the condition. If finalized, the changes would allow an actor to rely on the condition to deny a request for access, exchange, or use only if it does not provide analogous access, exchange, or use to any other individual or entity.

Specifically, ASTP would change the second factor to require the actor to offer all of the alternative manners under the alternative manner condition of the manner exception rather than only two alternatives.

In the third factor, the proposed rule would replace “same” with “analogous” so that an actor could not rely on the manner exception exhausted condition if the actor provides the same or analogous access, exchange, or use of EHI to any other requestor. ASTP believes using “analogous” access, exchange, or use in comparison to what the actor provides to others is less subject to manipulation than “same,” which could be interpreted to mean identical.

ASTP also proposes to change “substantial number” to at least one individual or entity and remove consideration of whether such individual or entity is “similarly situated” to the requestor. ASTP raised concerns that the terms “substantial” and “similarly situated” can be manipulated to deny access, exchange, or use.

TEFCA manner exception

The current TEFCA manner exception permits an actor to limit the manner in which it fulfills a request for access, exchange, or use of EHI to provide such access, exchange, or use only via TEFCA if the actor and requestor are both part of TEFCA and certain other conditions are met. The proposed rule would remove the exception completely. The administration has signaled continued support of TEFCA but proposes that using information blocking exceptions to incentivize participation in the network may be unnecessary.

Changes to certification criteria

ASTP proposes to remove 34 and revise seven certification criteria from a total of 60 current criteria to achieve its policy goals of reducing administrative burden and prioritizing the Fast Healthcare Interoperability Resources (FHIR®) standards, including FHIR-based application performance interfaces. ASTP proposes to retain and make no changes to 19 certification criteria, which include new and revised certification criteria that were adopted in the HTI-4 final rule. The following table from the proposed rule identifies the criteria to be removed or revised:

ASTP proposes to make conforming changes to related certification standards and implementation specifications, as well as various terms and definitions.

Withdrawal of non-finalized HTI-2 provisions

ASTP previously finalized certain proposals contained in the HTI-2 proposed rule, but others related to certification criteria and information blocking exceptions remained in proposed form. In its notice, ASTP withdrew the remaining proposals, citing:

• Public comments on the HTI-2 proposals and requests for information.
• A focus on deregulation.
• Technology changes (e.g., newer standards).
• Emerging AI technologies.

Future rulemaking and enforcement

The proposed rule signals future rulemaking, specifically to further reduce and remove long-standing functionality-oriented and non-FHIR-based certification criteria. While this rule did not add significant new capabilities to the certification program, ASTP seeks feedback on tools other than C-CDA and ways to advance AI-enabled interoperability solutions. Furthermore, actions continue to signal that information blocking enforcement is on the horizon.

The McDermott Will & Schulte difference

If you have questions about how ASTP’s proposals would affect your organization if finalized, or if you would like assistance preparing comments to submit to ASTP, please contact any of the authors of this client alert, your regular McDermott Will & Schulte lawyer, or your regular McDermott+ consultant.

The US Department of Health and Human Services (HHS) announced its intent to begin actively enforcing the information blocking regulations adopted under the 21st Century Cures Act, in a press release on September 3, 2025, and an enforcement alert issued jointly by the HHS Office of Inspector General (OIG) and Assistant Secretary for Technology Policy/Office of the National Coordinator for Health Information Technology (ASTP) on September 4, 2025. Actors subject to the information blocking regulations should review their current information sharing practices to ensure compliance.

For more information on information blocking, visit McDermott Will & Schulte’s Information Blocking & Interoperability in Healthcare resources page. For more information about how to prepare for HHS enforcement of the information blocking regulations, view our webinar “Information Blocking: Defense of Cures Act Investigations and Enforcement.”

The Cures Act prohibits information blocking by health care providers, certified health information technology (IT) developers, and health information networks and exchanges (HIN/HIEs). Information blocking refers to practices that are likely to interfere with the access, exchange, or use of electronic health information (EHI), except as required by law or specified in an information blocking exception, and that:

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

On July 3, 2023, OIG issued its final rule to implement OIG’s authority under the Cures Act to investigate claims of information blocking and assess civil monetary penalties of up to $1 million (subject to inflation adjustments) for information blocking violations by a certified health IT developer or an HIN/HIE. The effective date of the OIG final rule was September 1, 2023. For a discussion of the OIG final rule, see our Special Report. To date, OIG has not publicly released information about any investigation or enforcement action under the OIG final rule.

On July 1, 2024, HHS issued a final rule to implement the Cures Act provision establishing penalties (called “appropriate disincentives”) for certain health care providers determined by OIG to have committed information blocking. The disincentives for certain Medicare-participating hospitals and clinicians became effective July 31, 2024, while disincentives associated with the Medicare Shared Savings Program became effective January 1, 2025. For a discussion of the appropriate disincentives final rule, see our On the Subject. To date, there have been no public reports of any OIG investigation of health care providers or impositions of appropriate disincentives by HHS under this final rule.

In addition to these penalties, ASTP can terminate a certified health IT developer’s certifications under the Health IT Certification Program for information blocking in violation of ASTP’s health IT certification requirements.

HHS described the September 3, 2025, press release as “a warning to actors still engaging in information blocking to come into compliance with the rules governing the flow of patient information” and encouraged stakeholders to report alleged information blocking.

In the enforcement alert, ASTP and OIG committed “to using all available authorities to hold information blockers accountable,” and HHS stated that it will provide additional resources to enforce the information blocking prohibition. In conjunction with these public statements, ASTP held an in-person boot camp on September 4, 2025, for actors that interact with certified health IT, highlighting current capabilities to access, exchange, and use EHI as well as the complaint system process for allegations of information blocking. ASTP is planning additional outreach and engagement activities in the future.

Next steps

All regulated actors should consider the following next steps:

• Review policies, procedures, and practices affecting access, exchange, or use of EHI to confirm that they are consistent with the information blocking regulations and related laws, such as HIPAA and, for developers, ASTP’s Health IT Certification Program requirements.
• Review, update, or create documentation describing the organization’s commitment to health information sharing consistent with the information blocking regulations.
• Train personnel responsible for negotiating and implementing collaborations, partnerships, and other arrangements with third parties (e.g., digital health companies and consumer-facing app developers) seeking access, exchange, or use of EHI, to avoid conduct that may lead to information blocking claims.
• Refine processes to create and retain records and other documents demonstrating the organization’s compliance with the information blocking regulations, including relevant exceptions.
• Interview and identify defense counsel to help navigate a potential OIG investigation so the organization is prepared in the event of an actual investigation.

Because ASTP has emphasized information sharing practices through certified application programming interface (API) technology in multiple guidance documents during the past 12 months, certified health IT developers should consider the following next steps:

• Review deployments of certified API technology to confirm compliance with the Health IT Certification Program’s conditions and maintenance of certification requirements specific to certified APIs.
• Review certified API practices, informed by the practices ASTP highlighted in its API guidance, to confirm compliance and identify potential information blocking exceptions that may apply to related practices.
• Promptly evaluate and, if appropriate, address any complaints from certified API users alleging noncompliance with any certification requirements.

Health care providers should consider the following steps with respect to their certified API technology deployments:

• Review the provider’s certified API practices, informed by the practices ASTP highlighted in its guidance, to confirm compliance and identify potential information blocking exceptions that may apply to related practices.
• Promptly evaluate and, if appropriate, address any complaints from certified API users alleging noncompliance with any certification requirements.

For more information about ASTP’s API guidance, see our On the Subject about the ASTP fact sheet released October 29, 2024.

Please contact your regular McDermott Will & Schulte lawyer or any of the authors of this article if you have questions about compliance with the information blocking regulations or responding to OIG inquiries.

On December 17, 2024, the US Department of Health and Human Services (HHS) Assistant Secretary for Technology Policy/Office of the National Coordinator for Health Information Technology (ASTP) published the Health Data, Technology, and Interoperability: Protecting Care Access (HTI-3) final rule in the Federal Register. The final rule establishes the new protecting care access exception to the 21st Century Cures Act’s information blocking prohibition and makes minor amendments to two existing information blocking exceptions. The final rule finalizes information blocking regulatory changes that ASTP proposed in the HTI-2 Patient Engagement, Information Sharing, and Public Health Interoperability proposed rule.

ASTP adopted the protecting care access exception to address concerns that an actor subject to the information blocking prohibition may have about a patient’s, health care provider’s, or other person’s risk of potential exposure to an investigation, liability, or other legal action resulting from the access, exchange, or use of electronic health information (EHI) that indicates an abortion or other reproductive healthcare was sought, obtained, provided, or facilitated. ASTP notes that the concerns emanate from the new legal landscape in the wake of the Supreme Court of the United States’ 2022 decision in Dobbs v. Jackson Women’s Health Organization. Since that decision, some states have enforced laws or are contemplating legislation that authorizes administrative, civil, or criminal legal action against persons who engage in reproductive healthcare that is permitted by the law of the state in which the care is provided.

The HHS Office for Civil Rights (OCR) addressed the same concerns in its final rule amending the Health Insurance Portability and Accountability Act of 1996 Privacy Rule to prohibit the use and disclosure of protected health information potentially related to reproductive health care for certain legal actions. As part of the HTI-3 final rule, ASTP adopted substantially the same definition of reproductive health care.

Both the HTI-3 and OCR final rules are final agency actions; however, the incoming Trump administration has signaled that it may further act on these rules given different political views tied to reproductive health care. Specifically, the new administration has suggested further review of the new regulations that could result in delay, adjustments, or even full repeal. ASTP had, to some degree, anticipated these possible actions and divided its HTI-2 proposals into several different final rules that the new policy leads could review separately. For now, the HTI-3 final rule changes took effect on December 17, 2024.

New Protecting Care Access Exception

Under the protecting care access exception, a practice by a health care provider, health information network and health information exchange (HIN/HIE), or certified health IT developer (each, an actor) that is implemented to reduce potential exposure to legal action will not be information blocking when the practice satisfies the requirements of the exception’s threshold condition and either the exception’s patient protection or care access conditions.

Threshold Condition

To satisfy the threshold condition, an actor’s practice must meet each of the following requirements:

• Good faith belief. The practice is based on the actor’s good faith belief that persons seeking, obtaining, providing, or facilitating reproductive health care are at risk of being potentially exposed to legal action that could arise as a consequence of particular access, exchange, or use of specific EHI, and the practice could reduce that risk. According to ASTP, an actor’s belief does not need to be accurate, provided that it is held in good faith. ASTP advises that to hold a belief in good faith, an actor does not need to conduct tracking, detailed analysis, or extensive research of laws under which the actor does not furnish health care and does not provide HIN/HIE functionality or other health IT items or services to health care providers.

• Tailoring. The practice is no broader than necessary to reduce the risk of potential exposure to legal action that the actor in good faith believes could arise from the particular access, exchange, or use of the specific EHI.

• Implementation. The actor implements the practice either consistent with a written organizational policy or pursuant to a case-by-case determination, either of which must meet requirements specified in the final rule’s regulation text.

An actor who is a business associate of, or otherwise maintains EHI on behalf of, another actor may rely on the good faith belief and organizational policy or case-by-case determinations of the actor on whose behalf relevant EHI is maintained.

Patient Protection Condition

When an actor implements a practice to reduce the patient’s risk of potential exposure to legal action, the practice must:

• Affect only the access, exchange, or use of specific EHI the actor in good faith believes could expose the patient to legal action because the EHI shows, or would carry a substantial risk of supporting a reasonable inference, that the patient obtained reproductive health care; inquired about or expressed an interest in seeking reproductive health care; or has any health condition(s) or history for which reproductive health care is often sought, obtained, or medically indicated.
• Be subject to nullification by an explicit request or directive from the patient that the access, exchange, or use of the specific EHI occur despite the risks to the patient that the actor has identified.

Care Access Condition

When an actor implements a practice to reduce the risk of potential exposure to legal action for licensed health care professionals, other health care providers, or other persons involved in providing or facilitating reproductive health care that is lawful under the circumstances in which it is provided, the practice must affect only access, exchange, or use of specific EHI that the actor believes could expose care providers and facilitators to legal action because the EHI shows, or would carry a substantial risk of supporting a reasonable inference, that they provide or facilitate, or have provided or have facilitated, reproductive health care.

Presumption

For purposes of determining whether reproductive health care is lawful under the circumstances in which it is provided, care provided by someone other than the actor is presumed to have been lawful unless the actor has actual knowledge that the care was not lawful under the circumstances in which such care is it was provided.

Privacy Exception Amendment

The existing privacy exception to the information blocking prohibition includes four sub-exceptions intended to allow an actor to deny a request to access, exchange, or use EHI to protect an individual’s privacy. The fourth sub-exception allows an actor to not fulfill a request for EHI at the request of an individual. ASTP expanded the sub-exception by removing a limitation to individual-requested restrictions that was contingent on whether another law required the EHI be accessed, exchanged, or used.

Infeasibility Exception Amendment

The existing infeasibility exception includes a segmentation condition that allows an actor to deny a request for EHI if the actor cannot fulfill it because the actor cannot unambiguously segment the requested EHI from EHI that cannot be shared. The final rule expands the segmentation condition to cover all of the sub-exceptions under the privacy exception and the new protecting care access exception discussed above.

Action Items and Next Steps

Actors should consider taking the following steps in response to the final rule:

• Evaluate whether the actor wants to leverage the new protecting care access exception to protect the privacy of patients who have received or will receive reproductive health care, including in light of the laws of the states in which the actor conducts business.
• Review and revise existing information blocking and privacy policies and procedures to reflect the revisions to the information blocking exceptions included in the HTI-3 final rule.
• Educate reproductive health care providers about the special privacy and information blocking considerations related to EHI and other protected health information potentially related to reproductive health care.
• Monitor for additional updates from the new Trump administration as it reviews the implications of this final rule.

The McDermott and M+ Difference

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

On October 29, 2024, the US Department of Health and Human Services (HHS) Assistant Secretary for Technology Policy (ASTP) released a fact sheet titled “Information Blocking Reminders Related to API Technology.” The fact sheet reminds developers of application programming interfaces (APIs) certified under the ASTP’s Health Information Technology (IT) Certification Program and their health care provider customers of practices that constitute information blocking under ASTP’s information blocking regulations and information blocking condition of certification applicable to certified health IT developers.

The fact sheet is noteworthy because it follows ASTP’s recent blog post expressing concern about reports that certified API developers are potentially violating Certification Program requirements and engaging in information blocking. ASTP also recently strengthened its feedback channels by adding a section specifically for API-linked complaints and inquiries to the Health IT Feedback and Inquiry Portal. It appears increasingly likely that initial investigations and enforcement of the information blocking prohibition by the HHS Office of Inspector General will focus on practices that may interfere with access, exchange, or use of electronic health information (EHI) through certified API technology. For more information about the ASTP blog post, see our On the Subject. For more information about how to prepare for enforcement of the information blocking regulations, view our webinar titled “Information Blocking: Defense of Cures Act Investigations and Enforcement.”

The fact sheet focuses on three categories of API-related practices that could be information blocking under ASTP’s information blocking regulations and Certification Program condition of certification:

• ASTP cautions against practices that limit or restrict the interoperability of health IT. For example, the fact sheet states that health care providers who locally manage their fast healthcare interoperability resources (FHIR) servers without certified API developer assistance may engage in information blocking when they refuse to provide to certified API developers the FHIR service base URL necessary for patients to access their EHI.

• ASTP states that impeding innovations and advancements in access, exchange, or use of EHI or health-IT-enabled care delivery may be information blocking. For example, the fact sheet indicates that a certified API developer may engage in information blocking by refusing to register and enable an application for production use within five business days of completing its verification of an API user’s authenticity as required by ASTP’s API maintenance of certification requirements.

• ASTP states that burdensome or discouraging terms, delays, or influence over customers and users may be information blocking. For example, ASTP states that a certified electronic health record (EHR) developer may engage in information blocking by conditioning the disclosure of interoperability elements to third-party developers on the third-party developer entering into business associate agreements with all of the EHR developer’s covered entity customers, even if the work being done is not for the benefit of the customers and HIPAA does not require the business associate agreements.

The fact sheet does not address circumstances under which any of the above practices of certified API developers may meet an information blocking exception (established for reasonable practices that interfere with access, exchange, or use of EHI). Regulated actors should consider whether exceptions apply to individual circumstances.

For information about steps that certified API developers and health care providers should take to avoid information blocking, see our On the Subject regarding the recent ASTP blog post. If you would like to evaluate your certified API compliance, contact any of the authors of this On the Subject or your regular McDermott lawyer or McDermott+ consultant.

On October 8, 2024, Micky Tripathi, the US Department of Health and Human Services (HHS) Assistant Secretary for Technology Policy (ASTP), released a blog post titled “Getting Real About Information Blocking and APIs.” In the post, Tripathi notes that ASTP is “highly concerned” about reports that developers of application programming interfaces (APIs) certified under ASTP’s Health IT Certification Program are engaging in practices that violate the Certification Program’s conditions and maintenance of certification requirements specific to certified APIs and ASTP’s information blocking regulations adopted under the 21st Century Cures Act. The blog post, which notes that ASTP has received “hundreds” of information blocking complaints, appears to be a warning to developers of health information technology certified under the Health IT Certification Program (certified health IT developers) and health care providers that enforcement of ASTP’s information blocking regulations is coming soon.

Cures Act Enforcement and Penalties

On July 3, 2023, the HHS Office of Inspector General (OIG) issued its final rule to implement OIG’s authority under the Cures Act to investigate claims of information blocking and assess civil monetary penalties of up to $1 million (subject to inflation adjustments) for information blocking violations by a certified health IT developer or a health information network or health information exchange (HIN/HIE). The effective date of the OIG final rule was September 1, 2023. For a discussion of the OIG final rule, see our Special Report. To date, OIG has not publicly released information about any investigation or enforcement action under the OIG final rule.

On July 1, 2024, HHS issued a final rule to implement the Cures Act provision establishing penalties (called “appropriate disincentives”) for certain health care providers determined by OIG to have committed information blocking. The disincentives for certain Medicare-participating hospitals and clinicians became effective July 31, 2024, while disincentives associated with the Medicare Shared Savings Program will become effective January 1, 2025. For a discussion of the appropriate disincentives final rule, see our On the Subject. To date, there have been no public reports of any OIG investigation under the appropriate disincentives final rule.

Certified API Practices Raising Concerns at ASTP

In the blog post, ASTP discusses what it considers to be the “biggest impediments to progress” on interoperability and data sharing. In ASTP’s view, these impediments are alleged “behaviors” by certified health IT developers or health care providers, as opposed to technology issues. ASTP does not address or otherwise note any explanations or potentially available defenses by certified health IT developers, their health care provider customers that deploy the certified APIs, or other stakeholders.

Specifically, ASTP names the following alleged behaviors as impediments to interoperability and data sharing:

• API documentation is unavailable or unusable. The conditions and maintenance of certification require a certified API developer to publish complete business and technical documentation via a publicly accessible hyperlink that allows any person to directly access the information without any preconditions or additional steps. According to ASTP, certified API users have alleged that the required documentation is unavailable or not usable, and is inconsistent and incomplete about access terms and conditions, fees structure, and the process to register applications.

• Third-party application developers are effectively being closed out. API users have claimed that certified API developers have conditioned API access on onerous fees and other terms prohibited by ASTP regulations, and engaged in other practices prohibited by the Certification Program.

• API users are prevented from connecting with providers. API users have alleged that “EHR systems are hidden behind generic API endpoints, making it difficult for API users to connect directly with health care systems.” ASTP also raised concerns about third-party applications being unavailable to electronic health record (EHR) systems users and third-party developers being denied the opportunity to sell their applications to EHR users.

• Third-party developers serving patients are presented with false regulatory hurdles. Third-party developers have alleged that health care providers or certified API developers require third-party developers using patient access APIs to sign HIPAA business associate agreements in order for patients to have electronic access to their information, even though the developers are not business associates because they are serving patients.

• Developers or providers fail to respond to API access requests. Certified API users have claimed that certified API developers and/or health care providers do not provide written and timely responses to denials for access to electronic health information as required by regulatory requirements.

Notably, the blog post does not address practices with respect to noncertified, proprietary APIs. The omission is consistent with ASTP’s prior statements that it is focused on standards-based technology rather than bespoke solutions.

Potential Enforcement

ASTP notes in the blog post that HHS can take action in two ways to address the certified API practices:

• ASTP may directly review certified API developers and certified health IT to assess compliance with applicable Certification Program requirements, suspend or terminate certifications of certified health IT modules, and ban developers from the Certification Program.

• OIG may investigate alleged information blocking practices by certified API developers and other actors subject to the information blocking regulations. As noted above, if OIG determines that information blocking occurred, OIG may impose civil monetary penalties on health IT developers and HIN/HIEs and refer information blocking violations by health care providers to CMS for application of appropriate disincentives.

Next Steps

Developers of certified API technology should consider the following next steps:

• Review their deployments of certified API technology to confirm compliance with the Certification Program’s conditions and maintenance of certification requirements specific to certified APIs.
• Review their certified API practices, as informed by the practices highlighted by ASTP in the blog post, to confirm compliance and to identify potential information blocking exceptions that may apply to related practices.
• Promptly evaluate and, if appropriate, address any complaints from certified API users alleging noncompliance with any certification requirements.

Health care providers should consider the following steps:

• Review their certified API practices, as informed by the practices highlighted by ASTP in the blog post, to confirm compliance and to identify potential information blocking exceptions that may apply to related practices.
• Promptly evaluate and, if appropriate, address any complaints from certified API users alleging noncompliance with any certification requirements.

For more information about how to prepare for HHS enforcement of the information blocking regulations, view our webinar titled “Information Blocking: Defense of Cures Act Investigations and Enforcement.” If you would like to evaluate your certified API compliance, contact any of the authors of this On the Subject or your regular McDermott lawyer.

On August 5, 2024, the US Department of Health and Human Services (HHS) Assistant Secretary for Technology Policy/Office of the National Coordinator for Health Information Technology (ASTP) published the Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability (HTI-2) Proposed Rule in the Federal Register to update its Health IT Certification Program (Certification Program) requirements and amend the information blocking regulations that ASTP issued under the 21st Century Cures Act.

This On the Subject discusses the proposed changes to the information blocking regulations, which include new exceptions intended to offer regulated actors certainty that they can restrict information sharing in certain circumstances where the restrictions would protect patients’ access to care or honor an information sharing partner’s preferences for how much electronic health information (EHI) is made available to the partner, when and under what circumstances. ASTP also proposed adoption of certain certification criteria and standards for payer-focused application programing interfaces (APIs). For a discussion of those proposals, see our separate On the Subject.

The deadline for submitting comments to ASTP regarding the proposed rule is October 4, 2024, at 5:00 pm EDT.

For more background on these issues, see our previous articles:

• A Special Report on ASTP’s final information blocking regulations adopted in 2020.
• An On the Subject about ASTP’s amendments to those regulations as part of the Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing (HTI-1) final rule.

Key Proposed Changes to the Information Blocking Regulations

• The proposed rule would codify examples of certain practices that ASTP believes constitute an interference with EHI and may need to meet an exception to the information blocking prohibition.

• The proposed new protecting care access exception would allow actors meeting certain conditions to limit EHI sharing to reduce a risk of exposing patients, providers or persons who facilitate reproductive health care to legal action based on the mere fact that they sought, obtained, provided or facilitated lawful reproductive health care.

• The proposed new requestor preferences exception would permit an actor to tailor access, exchange or use of EHI to a requestor’s preference if the practice meets certain conditions.

Information Blocking Prohibition

Under the current regulations, information blocking means a practice by a health IT developer of certified health IT (certified health IT developer), health information network or health information exchange (HIN/HIE), or health care provider (collectively, actors) that, except as required by law or covered by an exception adopted by ASTP, is likely to interfere with access, exchange or use of EHI, and:

• If conducted by a certified health IT developer or HIN/HIE, is a practice that such certified health IT developer or HIN/HIE knows, or should know, is likely tointerfere with, prevent or materially discourage access, exchange or use of EHI.

• If conducted by a health care provider, is a practice that the provider knows is unreasonable and is likely to interfere with, prevent or materially discourage access, exchange or use of EHI.

Interference

The current information blocking regulations define “interfere with” or “interference” to mean “to prevent, materially discourage, or otherwise inhibit.” The proposed rule would add a new section to codify a nonexclusive list of specific practices that ASTP believes constitute interference for purposes of the information blocking prohibition. ASTP has previously identified practices that it believes may interfere with access, exchange or use of EHI in the form of Frequently Asked Questions.

ASTP proposes to codify the following practices as interference:

• Delay on new access. Delaying patient access to new EHI, such as diagnostic test results, so the actor’s clinicians or other representatives can review the EHI.

• Portal access. Delaying patient access to EHI in a portal when the actor has the EHI and the actor’s system has the technical capability to support automated access, exchange or use of the EHI via the portal.

• API access. Delaying the access, exchange or use of EHI to or by a third-party app designated and authorized by the patient, when there is a deployed API able to support the access, exchange or use of the EHI.

• Non-standard implementation. Implementing health information technology in ways that are likely to restrict access, exchange or use of EHI with respect to exporting EHI, including exports for transitioning between health IT systems.

• Contract provisions. Negotiating or enforcing a contract provision that restricts or limits otherwise lawful access, exchange or use of EHI.

• Noncompete provisions in agreements. Negotiating or enforcing a clause in any agreement that prevents or restricts an employee (other than the actor’s employees), a contractor or a contractor’s employee who accesses, exchanges or uses the EHI in the actor’s health IT from accessing, exchanging or using EHI in other health IT in order to design, develop or upgrade such other health IT. This proposal is intended to address conditions on access to EHI in an actor’s health IT that are unrelated to security or privacy laws and are anticompetitive.

• Manner or content requested. Improperly encouraging or inducing requestors to limit the scope, manner or timing of EHI requested for access, exchange or use.

• Medical images. Requiring that access, exchange or use of any medical images (e.g., x-rays) occur by exchanging physical copies or copies on physical media (e.g., thumb drive) when the actor and the requestor possess the technical capability to access, exchange or use the images through fully electronic means.

• Omissions:
  • Not exchanging EHI under circumstances in which such exchange is lawful.
  • Not making EHI available for lawful use.
  • Not complying with another valid law enforceable against the actor that requires access, exchange or use of EHI.
  • A certified API developer (as defined in the certification program regulations) failing to publish API discovery details as required by the maintenance of certification requirements.
  • A health care provider or other API information source (as defined in the certification program regulations) failing to disclose to the certified API developer the information necessary for the certified API developer to publish the API discovery details required by the certification program regulations.

ASTP also identifies practices that it believes are unlikely to interfere with the access, exchange and use of EHI in the proposed rule preamble, but not in its proposed amendments to the information blocking regulations. For example, ASTP states that it would unlikely be an interference for qualified health information networks, participants or sub-participants to comply with required provisions of the common agreement and the incorporated terms of participation and standard operating procedures, respectively.

Amended Information Blocking Exceptions

ASTP proposes to revise certain existing information blocking exceptions.

Privacy Exception

The privacy exception under the current information blocking regulations provides that an actor’s denial of a request to access, exchange or use EHI to protect an individual’s privacy is not information blocking when the denial satisfies at least one of the privacy exception’s sub-exceptions. ASTP proposes to amend certain of the sub-exceptions:

• Unreviewable Grounds Sub-Exception. One sub-exception allows denial of an individual’s request for EHI consistent with the “unreviewable grounds” for denial of access under the HIPAA Privacy Rule’s right to access protected health information in a designated record set. The unreviewable grounds are intended to address certain public policy objectives separate from privacy, such as when a health care provider provides treatment in the course of clinical research. ASTP proposes to broaden the applicability of the sub-exception so that it is available to any actor responding to a request for EHI where the circumstances for unreviewable grounds apply, and not just to actors that are also HIPAA covered entities or business associates.

• Individual’s Request Not to Share EHI Sub-Exception. Another sub-exception permits an actor to deny a request for access, exchange or use of EHI to respect an individual’s request not to share EHI if certain requirements are met. ASTP proposes to amend the existing sub-exception so that any practice that meets the requirements of the sub-exception would not be considered information blocking even if no law requires the actor to disclose EHI against the individual’s expressed wishes.

Infeasibility Exception

The current information blocking regulations’ infeasibility exception provides that a denial of a request to access, exchange or use EHI due to the infeasibility of the request is not information blocking when the denial meets one of the exception’s infeasibility conditions. The denial also must meet the timeframe of the exception’s responding to requests condition, which requires the actor to respond to the requestor in writing with the reasons why the request is infeasible within 10 business days of receipt of the request.

ASTP proposes to revise certain infeasibility conditions and to make the responding to requests condition more flexible:

• Segmentation Condition. The segmentation condition of the infeasibility exception allows an actor to deny a request to access, exchange or use EHI because the actor cannot unambiguously segment the requested EHI from other EHI that cannot be made available because of an individual’s preference, because the EHI cannot be made available by law or because the EHI may be withheld under the preventing harm exception to the information blocking prohibition. ASTP proposes to expand the segmentation condition to allow for denial of access when EHI cannot be segmented from EHI that may be withheld under the privacy exception or the proposed protecting care access exception discussed below.

• Third Party Seeking Modification Use Condition. One of the current infeasibility exception conditions allows an actor to deny a request if the request is to enable use of EHI to modify EHI, provided that the request is not from a health care provider requesting such use from an actor that is its business associate. ASTP proposes to revise the condition so that it is unavailable to requests by any HIPAA covered entity (and not only HIPAA-covered health care providers) requesting a modification use from an actor that is its business associate. ASTP also proposes to extend the exclusion so that the third party seeking modification use condition would not apply where a health care provider that is not a HIPAA covered entity requests modification use from an actor that would be the provider’s business associate if the provider were a HIPAA covered entity.

• Responding to Requests Condition. ASTP proposes to revise the responding to requests condition to offer actors a more flexible response timeframe where the reasons for infeasibility are consistent with the infeasibility exception’s manner exception exhausted or infeasible under the circumstances conditions. Under the proposal, the actor could satisfy the responding to requests condition by:
  • Determining, without unnecessary delay and based on a reasonable assessment of the facts, that the requested access, exchange or use cannot be provided in accordance with the manner exception or is infeasible under the circumstances; and
  • Informing the requestor with a written response indicating the reason for infeasibility within 10 business days of the actor’s determination.

According to ASTP, the revised condition would allow the actor, within 10 days of receiving a request, to initiate good-faith collaborative engagement with the requestor to discuss the potential infeasibility of the request as received and potentially feasible alternative ways to achieve EHI sharing. When discussions and negotiations reach a result other than successful fulfillment of access, exchange or use of EHI for the requestor, the revised condition would require the actor to provide the requestor with a written response indicating the reason for infeasibility within 10 business days of the actor’s determination of infeasibility or the discontinuation of discussions.

Proposed New Information Blocking Exceptions

The proposed rule includes two new information blocking exceptions.

Protecting Care Access

The proposed protecting care access exception would, under specified conditions, allow actors to limit EHI sharing to reduce a risk of potentially exposing patients, providers or persons who facilitate care to legal action based on the mere fact that they sought, obtained, provided or facilitated lawful reproductive health care. The proposed exception is intended to address the changed legal landscape for patients seeking, and for health care providers providing, reproductive health care, resulting from the US Supreme Court’s decision in Dobbs v. Jackson Women’s Health Organization.

Under the proposed exception, an actor’s practice to reduce potential exposure to legal action would not be information blocking when the practice satisfies the exception’s threshold condition and also satisfies either the exception’s patient protection condition or the care access condition.

• Threshold Condition. To meet the threshold condition, a practice must meet the following requirements:
  • Good Faith Belief. The practice is undertaken based on the actor’s good faith belief that persons seeking, obtaining, providing or facilitating reproductive health care are at risk of being potentially exposed to legal action that could arise as a consequence of particular access, exchange or use of specific EHI, and that specific practices likely to interfere with such access, exchange or use of such EHI could reduce that risk.
  • Tailoring. The practice is no broader than necessary to reduce the risk of potential exposure to legal action that the actor in good faith believes could arise from the particular access, exchange or use of the specific EHI.
  • Implementation. The practice is implemented either consistent with an organizational policy or pursuant to a case-by-case determination meeting certain requirements.

• Patient Protection Condition. When an actor implements a practice to reduce the patient’s risk of potential exposure to legal action, the practice must:
  • Affect only the access, exchange or use of specific EHI the actor in good faith believes could expose the patient to legal action because the EHI shows, or would carry a substantial risk of supporting a reasonable inference, that the patient obtained reproductive health care; inquired about or expressed an interest in seeking reproductive health care; or has any health conditions or history for which reproductive health care is often sought, obtained or medically indicated.
  • Be subject to nullification by an explicit request or directive from the patient that the access, exchange or use of the specific EHI occur despite the risks to the patient that the actor has identified.

• Care Access Condition. When implemented to reduce the risk of potential exposure to legal action for one or more licensed health care professionals, other health care providers, or other persons involved in providing or facilitating reproductive health care that is lawful under the circumstances in which such health care is provided, the practice must affect only access, exchange or use of specific EHI that the actor believes could expose care providers and facilitators to legal action because the information shows, or would carry a substantial risk of supporting a reasonable inference, that they provide or facilitate, or have provided or facilitated, reproductive health care.

Requestor Preferences Exception

The proposed requestor preferences exception permits an actor to tailor access, exchange or use of EHI to a requestor’s preference if the practice meets the following conditions:

• Request. A requestor, without any improper encouragement or inducement by the actor, requests in writing that the actor:
  • Limit the scope of EHI made available for access, exchange or use by the requestor;
  • Delay provision of access, exchange or use by the requestor of particular EHI health information until a condition specified by the requestor (such as passage of a particular event or completion of an action) has been met; or
  • Delay provision of access, exchange or use by the requestor of particular EHI for a specified period of time.

• Implementation. The actor’s practice must be tailored to the specific request and implemented in a consistent and nondiscriminatory manner.

• Transparency. The actor must explain to the requestor in plain language, verbally or in writing, what tailoring the actor will implement. The actor also must notify, verbally or in writing, any requestors of changes in the actor’s ability to maintain tailoring. To satisfy this condition, the actor must, at a minimum:
  • Explain to the requestor what tailoring the actor will implement and how that will impact what EHI will be available to the requestor and when, or under what conditions EHI will be available to the requestor;
  • Upon experiencing any change in operational status, technical capabilities or other circumstances affecting the actor’s ability or willingness to maintain particular tailoring of EHI, make reasonable efforts to promptly notify each requestor for which the actor had implemented the affected tailoring; and
  • Contemporaneously document in writing any verbal explanation or notice to the requestor.

• Reduction or Removal. An actor must act on any subsequent request from the requestor who previously requested scope, condition or timing tailoring of the requestor’s EHI access, exchange or use to reduce or remove restrictions as promptly as feasible.

The McDermott Difference

If you have questions about how the ASTP’s proposals would affect your organization if finalized, or if you would like assistance preparing comments to submit to ASTP, please contact any of the authors of this On the Subject, your regular McDermott lawyer or your McDermott+ consultant.

On July 1, 2024, the US Department of Health and Human Services (HHS) Office of the National Coordinator for Health Information Technology (ONC) and the Centers for Medicare & Medicaid Services (CMS) published a final rule in the Federal Register to implement a 21st Century Cures Act provision establishing penalties (called “appropriate disincentives”) for certain health care providers determined by the HHS Office of Inspector General (OIG) to have committed information blocking. Health care providers have been subject to the information blocking regulations since April 5, 2021, but there has been no enforcement mechanism under the Cures Act to date. The disincentives for certain Medicare-participating hospitals and clinicians become effective July 31, 2024, while disincentives associated with the Medicare Shared Savings Program (MSSP) become effective January 1, 2025.

Key Takeaways

• While the final rule moves the industry towards full enforcement of the information blocking regulations against health care providers, it applies penalties only to health care providers that participate in certain Medicare programs and not to all health care providers that are covered actors under the information blocking regulations.
• HHS has not proposed any disincentives for health care providers that do not participate in the Medicare Promoting Interoperability Program or MSSP, or that serve a limited number of Medicare beneficiaries.
• In a press release accompanying the final rule publication, HHS emphasized that the final rule complements OIG’s July 2023 final rule establishing penalties for information blocking actors other than health care providers. OIG’s information blocking civil monetary penalty (CMP) authority does not extend to health care providers except to the extent that they meet the definitions of a health IT developer of certified health IT (certified health IT developer) or health information network and health information exchange (HIN/HIE).

For more information about ONC’s recent final rule expanding information blocking regulatory exceptions, see our On the Subject. For a discussion of OIG’s final information blocking enforcement rule concerning the penalties for information blocking by certified health IT developers and HIN/HIEs, plus OIG’s investigation and enforcement procedures, see our Special Report.

Summary of Appropriate Disincentives

The final rule establishes the following disincentives for health care providers that participate in certain Medicare programs that OIG determines committed information blocking and refers to CMS. As discussed below, the ultimate financial impact of disincentives (if any) will vary in some instances based on Medicare reimbursement otherwise owed to the provider rather than on the severity of a health care provider’s alleged information blocking conduct or other factors related to interference with access, exchange or use of electronic health information. The final rule does not include disincentives for health care providers that are not enrolled in Medicare at all or that do not participate in certain Medicare programs.

Hospitals and Critical Access Hospitals

HHS uses the existing Medicare Promoting Interoperability Program for the meaningful use of certified electronic health record (EHR) technology to impose disincentives on certain acute care hospitals (eligible hospitals) reimbursed under the Medicare Inpatient Prospective Payment System (IPPS) and on critical access hospitals (CAHs), which are reimbursed based on their reasonable costs. Under the final rule, an eligible hospital or CAH will not be a meaningful EHR user in an EHR reporting period if OIG refers, during the calendar year of the reporting period, its determination that the eligible hospital or CAH committed information blocking. As a result, an eligible hospital would be unable to earn the three-quarters of the annual market basket increase under the IPPS, and a CAH would have its Medicare reimbursement reduced to 100% of reasonable costs, down from 101%. The disincentives under the Medicare Promoting Interoperability Program will be effective July 31, 2024.

In the proposed rule, HHS estimated that this change could result in a median disincentive amount of $394,353 and a 95% range of $30,406 to $2,430,766. Of note, the Promoting Interoperability Program does not apply to many long-term care hospitals, rehabilitation hospitals, psychiatric hospitals, laboratories and other facilities.

Physicians and Other Clinicians Reimbursed Under the Medicare Physician Fee Schedule

With some exceptions, clinicians reimbursed under the Physician Fee Schedule (PFS) must either participate in a Medicare Advanced Alternative Payment Model or achieve a threshold Merit-based Incentive Payment System (MIPS) performance score to avoid a downward adjustment to their PFS reimbursement. CMS currently calculates the MIPS performance score based on four performance categories: Quality (30%), Improvement Activities (15%), Promoting Interoperability (25%) and Cost (30%). Measures within the four performance categories are scored and combined to make up a clinician’s MIPS score. Those who score higher than a performance threshold set by CMS for a reporting year (75 points for 2024) can earn a positive adjustment of up to 9% of reimbursement under the PFS in the payment year. Likewise, those below the performance threshold face penalties of up to -9% of reimbursement under the PFS. CMS applies a payment adjustment to the payment year two years after the calendar year of the clinician’s MIPS reporting period. Not all MIPS participants are required to report the Promoting Interoperability category. For example, there are exceptions for facility-based and hospital-based clinicians (e.g., emergency room physicians and providers in ambulatory surgical centers) as well as some small practices.

Under the final rule, a clinician who participates in MIPS and is required to report on the Promoting Interoperability performance category will receive a zero score for the category if OIG refers, during the calendar year of the clinician’s reporting period, a determination that the clinician committed information blocking. Because the Promoting Interoperability performance category is currently 25% of the total MIPS score, 75 would be the highest score that the clinician could earn and would likely result in a penalty based on the current MIPS performance threshold for 2024. Those who do not report the MIPS Promoting Interoperability category would not be subject to any disincentives under the final rule. The disincentives for MIPS participants will be effective July 31, 2024.

In the proposed rule, HHS estimated that the median individual disincentive amount could be a loss of $686 for a clinician, while an estimated median group of six clinicians could see a loss of $4,116, with a range of $1,372 to $165,326 for group sizes ranging from two to 241 clinicians.

Medicare Shared Savings Program

Clinicians can avoid having to participate in MIPS by participating in the MSSP. Under the final rule, if OIG determines that a health care provider that is an accountable care organization (ACO) or part of an ACO has committed information blocking, CMS can apply a range of appropriate disincentives under the MSSP based on the relevant facts and circumstances. The disincentives may include:

• Denying the addition of an ACO participant such as a physician group to an ACO participant list (or denying addition of an ACO provider or supplier such as a physician to the ACO provider/supplier list);
• Informing an ACO that remedial action should be taken against the ACO participant, provider or supplier;
• Denying an ACO’s application to participate in the MSSP if the remedial action is not taken; or
• Terminating an ACO’s participation agreement with CMS.

CMS stated that the relevant facts and circumstances to determine the appropriate disincentives to be applied under the MSSP include:

• The nature of the provider’s information blocking practice;
• The provider’s diligence in identifying and correcting the problem;
• The time elapsed since the information blocking occurred, including whether the issue had long since been remediated; and
• Whether the provider was previously subject to a disincentive in another program.

The disincentives under the MSSP will be effective January 1, 2025.

Scope of Health Care Providers Impacted by Final Rule Disincentives

The information blocking regulations apply to a broad range of health care providers, including facilities such as nursing facilities, long-term care facilities, dialysis facilities, blood centers, ambulatory surgical centers, laboratories and pharmacies, and individual providers such as therapists and pharmacists. However, because only a subset of health care providers is subject to the requirements that are the basis for disincentives under the final rule (e.g., the Promoting Interoperability Program requirements), many health care providers will be excluded from the disincentives framework, even though they are covered actors under the Cures Act and the information blocking regulations.

OIG Investigative Authorities, “Referrals” and Intersection With OIG CMP Information Blocking Enforcement Rule

The application of disincentives to health care providers covered by the final rule turns on a determination by OIG that the health care provider committed information blocking, so to understand the potential impact of HHS’s final rule, it is important to understand OIG’s role in the information blocking ecosystem.

The Cures Act granted OIG the authority to investigate information blocking claims against each type of covered actor: health care providers, certified health IT developers and HIN/HIEs. The Cures Act also granted OIG the authority to impose CMPs against certified health IT developers and HIN/HIEs that violate the information blocking prohibition. OIG published its final rule implementing its CMP authority in the Federal Register in July 2023. That penalty authority, however, does not extend to the health care provider category of covered actors. Instead, the Cures Act requires OIG to refer health care providers that OIG determines have violated the information blocking prohibition to “the appropriate agency to be subject to appropriate disincentives.”

From a procedural perspective, the final rule notes that OIG will coordinate with the “appropriate agency” to which OIG plans to make a “referral” during the pendency of OIG’s investigation and before actually making the referral, in an effort to ensure that the agency is aware that OIG might make the referral. When OIG actually makes the referral, OIG will provide information about its determination of information blocking, including how the health care provider’s practice met the “intent element” of the prohibition, among other data related to the alleged misconduct.

In the final rule, HHS acknowledged that OIG’s anticipated information blocking enforcement priorities for health care providers are identical to those OIG identified for certified health IT developers and HIN/HIEs, except that OIG omitted actual knowledge from its enforcement priorities list for health care providers. This omission reflects the different knowledge standard in the statutory definition of information blocking for health care providers, which must know that their alleged information blocking practice is likely to interfere with access, exchange or use of electronic health information to implicate the prohibition. In contrast, health IT developers and HIN/HIEs must know or should know that their alleged information blocking practice is likely to interfere to implicate the prohibition.

Health care providers should note that in some situations, they may be considered certified health IT developers or HIN/HIEs, subject to the lower knowledge threshold. However, the HTI-1 final rule released on December 13, 2023, clarifies the definition of certified health IT developer as it may apply to health care providers who “offer” health IT, and, as a result, limits the scope of scenarios in which health care providers would be considered certified health IT developers.

OIG has provided guidance describing its planned investigative process for entities subject to information blocking CMPs. Although the final rule discusses OIG’s enforcement priorities for health care providers, it largely omits discussion of the underlying investigative process, including whether OIG’s process will similarly include an opportunity for health care providers to discuss an OIG investigation and explain why their conduct did not implicate the information blocking prohibition, met an exception or was otherwise lawful. This is notable given the absence in the final rule of any appeal mechanism by which health care providers could challenge OIG’s information blocking determination. Although there may be some limited opportunities to appeal a disincentive, HHS specifically makes clear that ACO appeals under the MSSP regulations, at least, do not extend to OIG’s underlying information blocking determination.

One would expect that OIG would need to engage with the health care provider to perform a reasonable investigation. But the final rule’s omission of meaningful discussion about such interactions leaves open the question of what, if any, reasonable opportunities health care providers will have to make their case before being subjected to disincentives.

In addition, unlike appeals for CMPs, HHS has not implemented new administrative appeals for appropriate disincentives. In the limited circumstances in which the underlying program that forms the basis for the disincentive has an appeal right, such as the right for an ACO to appeal certain actions under the MSSP, then an actor could appeal the disincentive itself through that process.

“Wall of Shame” for Information Blocking

The final rule creates a framework for public posts on ONC’s website about actors that OIG determines have committed information blocking. For health care providers subject to disincentives, the website will feature:

• The health care provider’s name;
• The provider’s business address (to ensure accurate provider identification);
• The practice found to have been information blocking;
• The disincentive(s) applied; and
• Where to find additional information, if publicly available, about the determination of information blocking.

HHS will post similar information on ONC’s website about HIN/HIEs and certified health IT developers that OIG determines have committed information blocking (regardless of whether they resolved their CMP liability with OIG or were subject to a CMP). This portion of the final rule is intended to provide transparency as to how information blocking impacts the nationwide health information technology infrastructure.

The transparency is also an extension of the ONC’s existing website, Information Blocking Claims: By the Numbers, where it publishes statistics on the information blocking claims received through its Report Information Blocking Portal since April 5, 2021 (the information blocking compliance date). As of the end of May 2024, ONC and OIG had received almost 1,000 claims of possible information blocking (including 813 claims against health care providers).

Next Steps

Health care providers should evaluate their current information blocking policies and procedures to ensure compliance with the information blocking prohibition and mitigate the risk of disincentives. If you would like to evaluate your compliance capabilities, contact any of the authors of this On the Subject or your regular McDermott lawyer.

On December 13, 2023, the US Department of Health and Human Services (HHS) Office of the National Coordinator for Health Information Technology (ONC) issued the Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing (HTI-1) final rule to update ONC Health IT Certification Program requirements and amend the information blocking regulations that ONC issued under the 21st Century Cures Act (Cures Act). The HTI-1 final rule substantially finalizes policies that ONC proposed in the HTI-1 proposed rule. This On the Subject discusses the final rule’s information blocking provisions, which are intended to support the sharing of electronic health information (EHI), but also include new and expanded exceptions to the information blocking prohibition applicable to health IT developers of certified health IT (certified health IT developers), health information network or health information exchanges (HIN/HIEs) and health care providers (collectively, actors). The HTI-1 final rule becomes effective 30 days after publication of the final rule in the Federal Register.

We will release separate publications discussing ONC’s changes to the certification criteria and standards. For more information about ONC’s final information blocking regulations adopted in 2020, see our Special Report.

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.