A patient portal request that quietly times out. A referral packet that arrives missing the imaging results. A health system that tells a competing app vendor its integration “isn’t supported” without further explanation. None of these situations automatically breaks the law — but each one is exactly the kind of practice the information blocking rule was written to scrutinize. For compliance officers, health IT vendors, and practice administrators, the rule has moved from an abstract policy discussion to a live operational risk, with federal regulators signaling in 2025 that enforcement is no longer theoretical.

This article lays out what the information blocking rule actually requires, who has to follow it, the nine recognized exceptions, and how enforcement works today. It is general information for orientation purposes, not legal or compliance advice — organizations should verify current requirements against the primary sources cited below and consult qualified counsel for specific situations.

What Is the Information Blocking Rule?

The information blocking rule implements Section 4004 of the 21st Century Cures Act, a 2016 federal law aimed at accelerating interoperability across the health care system. The statute directed the Department of Health and Human Services (HHS) to define and prohibit “information blocking” — and the resulting regulation, finalized by the Office of the National Coordinator for Health Information Technology (ONC), now sits at 45 CFR Part 171.

ONC’s rulemaking and enforcement functions were subsequently reorganized under the Assistant Secretary for Technology Policy (ASTP), so current guidance is published jointly as “ASTP/ONC.” The underlying regulation has not changed name or numbering as a result of that reorganization, but readers researching the topic will see both labels used interchangeably in recent materials.

By regulatory definition, information blocking is a practice by a regulated “actor” that is likely to interfere with the access, exchange, or use of electronic health information (EHI) — unless the practice is required by law or fits within one of the recognized exceptions. Critically, the rule does not require proof that harm actually occurred. A practice that is merely likely to interfere with EHI flow can qualify, which is one reason the rule has generated so much compliance anxiety among providers who are unsure whether routine operational decisions (system maintenance windows, fee schedules, data use agreements) could be construed as blocking.

The Knowledge Standard Differs by Actor Type

Not every actor is held to the same intent standard. Health care providers are evaluated under a “knowledge” standard — they must know that a practice is unreasonable and likely to interfere with EHI access, exchange, or use. Health IT developers of certified health IT, health information networks (HINs), and health information exchanges (HIEs) are held to a stricter “knew or should have known” standard, reflecting the expectation that entities building or operating interoperability infrastructure bear more responsibility for anticipating downstream effects of their design choices.

Who Is a Covered “Actor”?

The rule applies to three categories of regulated actors:

  • Health care providers — a broad category under the statute that includes hospitals, physician practices, skilled nursing facilities, laboratories, pharmacies, and many other licensed and certified providers of care.
  • Health IT developers of certified health IT — companies that develop or self-certify health IT products under the ONC Health IT Certification Program, most commonly electronic health record (EHR) vendors.
  • Health information networks and health information exchanges (HINs/HIEs) — organizations that enable data sharing among otherwise unaffiliated participants, including regional and statewide exchanges and multi-stakeholder data networks.

Notably, the rule does not directly regulate individual patients, payers acting purely in a payer capacity, or entities entirely outside these three categories — although payers and other stakeholders may still be swept in in specific circumstances (for example, if a health plan also operates as an HIN). Organizations that are unsure whether a given business unit meets the definition of an actor should review the regulatory text and applicable ASTP/ONC FAQs directly, since the category definitions carry specific legal criteria beyond the general description above.

What Counts as Electronic Health Information (EHI)?

The scope of EHI has expanded since the rule first took effect. From the rule’s initial compliance date of April 5, 2021 through October 5, 2022, the definition of EHI for information blocking purposes was intentionally narrowed to the data classes and elements defined in the United States Core Data for Interoperability (USCDI) — a bounded, more manageable dataset meant to ease the transition into compliance.

As of October 6, 2022, that transition period ended. EHI now means electronic protected health information (ePHI) to the extent it would be included in a HIPAA “designated record set,” regardless of whether the entity holding it is itself a HIPAA-covered entity. In practical terms, this is a much broader universe of data than USCDI alone — it can include clinical notes, imaging, lab results, billing records tied to clinical care, and other information typically maintained in a patient’s chart, not just the discrete structured data elements USCDI enumerates. For more detail on how designated record set concepts map onto EHI, ASTP/ONC maintains explainer material through HealthIT.gov.

What Are the Nine Information Blocking Exceptions?

This is the part of the rule that actually governs day-to-day decisions. ASTP/ONC has defined nine exceptions — eight from the original 2020 rule plus a later TEFCA-related addition — that describe practices that will not be treated as information blocking, provided specific conditions are met. Meeting an exception is voluntary; a practice that doesn’t fit neatly into an exception isn’t automatically information blocking either. It simply gets evaluated case by case.

The exceptions fall into three groups: those that justify not fulfilling a request at all, those that govern the manner or terms of fulfilling a request, and one relating specifically to participation in the Trusted Exchange Framework and Common Agreement (TEFCA).

Exceptions for Not Fulfilling a Request

Preventing Harm Exception. An actor may decline to share EHI when it holds a reasonable belief the practice will substantially reduce a risk of harm to a patient or another person, the practice is no broader than necessary, and specific risk/harm/implementation conditions in the regulation are satisfied — including, in some cases, a patient’s right to request review of an individualized harm determination.

Privacy Exception. An actor may withhold EHI to protect individual privacy if one of four sub-conditions applies: a legally required precondition (like consent) hasn’t been met; the actor is a non-HIPAA-covered health IT developer withholding data for a legitimate privacy purpose; the denial falls within HIPAA’s own permitted grounds for denying record access (45 CFR 164.524(a)(1)-(2)); or the individual patient has specifically asked that their information not be shared.

Security Exception. Interfering with EHI access is permitted when the practice directly safeguards the confidentiality, integrity, or availability of EHI, is narrowly tailored to a specific security risk, and is applied consistently and without discrimination — generally by following a documented organizational security policy or a specific, justified security determination.

Infeasibility Exception. An actor can decline a request it genuinely cannot fulfill — due to uncontrollable events (disasters, cyberattacks, labor disruptions, and similar), inability to unambiguously segment the requested data, a third party’s request to modify EHI outside a qualifying relationship, a documented case-by-case infeasibility determination, or after having already exhausted good-faith efforts under the Manner Exception. A written explanation must go to the requestor within 10 business days.

Health IT Performance Exception. Taking systems offline or degrading performance temporarily for maintenance, upgrades, or to stop a misbehaving third-party application is permitted, as long as the disruption lasts no longer than necessary and is applied in a consistent, non-discriminatory way.

Exceptions for How a Request Is Fulfilled

Manner Exception. Actors have flexibility in how they fulfill a request — for example, offering an alternative technical method — when they are technically unable to provide the exact manner requested or cannot reach agreeable terms with the requestor. Any alternative manner must follow a defined order of priority and still satisfy the Fees and Licensing exceptions where relevant.

Fees Exception. Charging fees for accessing, exchanging, or using EHI — including fees that generate a reasonable profit margin — is allowed if the fees are based on objective, uniformly applied, cost-related criteria and are not designed to penalize competitors or extract rents. Fees tied to a patient’s own electronic access to their record, or to EHI export via certified export capability, are specifically excluded from this protection.

Licensing Exception. Actors may license the interoperability elements needed to access, exchange, or use EHI, provided they begin negotiating within 10 business days of a request, conclude a license within 30 business days, and meet conditions covering reasonable royalties, non-discriminatory terms, and related licensing safeguards.

TEFCA Manner Exception. Added in a later rulemaking, this exception protects an actor that fulfills certain requests only through the Trusted Exchange Framework and Common Agreement, when both actor and requestor participate in TEFCA and specific conditions around fees, licensing, and certified API standards are met. Regulators have proposed changes to this exception as part of a broader 2025-2026 rulemaking cycle (discussed below), so organizations relying on it should track the exception’s status rather than assume it is static.

How Is the Rule Enforced?

Enforcement runs through two different tracks depending on the type of actor involved.

Health IT developers, HINs, and HIEs face civil monetary penalties administered by the HHS Office of Inspector General (OIG), of up to $1 million per violation. OIG has indicated it prioritizes cases involving patient harm, significant operational disruption, financial harm to federal health programs, or long-running violations, rather than pursuing every technical infraction.

Health care providers are not subject to OIG civil monetary penalties. Instead, a separate CMS final rule established “disincentives” — administrative and payment-related consequences rather than direct fines. A provider found by OIG to have committed information blocking can face:

  • Loss of meaningful-user status under the Medicare Promoting Interoperability Program for eligible hospitals and critical access hospitals.
  • A zero score on the relevant performance category under the Merit-based Incentive Payment System (MIPS) for eligible clinicians and group practices.
  • Ineligibility to participate as an Accountable Care Organization (ACO) participant in the Medicare Shared Savings Program for at least one year.

Most provider disincentives took effect July 31, 2024, with the ACO-related disincentive following on January 1, 2025. OIG, not CMS, investigates and refers substantiated provider cases; CMS then applies the applicable disincentive.

Enforcement activity has ramped up. HHS leadership publicly directed increased enforcement resources in September 2025, explicitly departing from what officials characterized as a slower initial enforcement posture. Public reporting has indicated well over a thousand complaints under review by OIG and ASTP/ONC combined, though the pace at which those complaints convert into substantiated findings and penalties is still developing. Organizations should treat this as an active and intensifying enforcement environment rather than a settled or low-risk one.

Is the Rule Changing?

Yes, in ways worth tracking rather than treating as final. In late December 2025, ASTP/ONC issued a proposed rule (often referred to as “HTI-5”) that would, among other things, clarify that “access,” “exchange,” and “use” of EHI explicitly cover automated, system-to-system, and AI-driven processes — a direct response to the growing role of AI agents and automated data pipelines in clinical settings. The same proposal would also revise or narrow several existing exceptions, including changes to the Infeasibility Exception’s conditions, the proposed removal of the TEFCA Manner Exception, and adjustments to the “manner requested” condition within the Manner Exception itself.

Because this rulemaking was still in the proposed stage as of this writing, none of these changes are finalized or in effect. Compliance teams should continue operating under the current 45 CFR Part 171 framework while monitoring the Federal Register and ASTP/ONC’s published guidance for the final rule’s contents and effective dates.

Frequently Asked Questions

Does the information blocking rule apply to patient requests for their own records?

Yes. A patient’s request to access their own electronic health information is squarely within scope, and several of the exceptions — particularly around fees and privacy — include specific carve-outs that prevent actors from using the exception to justify charging patients or otherwise obstructing their own record access.

Is refusing to share data with a competing app or vendor automatically information blocking?

Not automatically. The practice is evaluated against the actor’s reason for refusing and whether it fits an exception, such as Security or Infeasibility. But a blanket refusal based on competitive concerns, without a documented, non-discriminatory basis, is exactly the pattern regulators have flagged as high risk.

What is the difference between ONC and ASTP?

ASTP (Assistant Secretary for Technology Policy) is the reorganized federal office that now houses the functions previously run by ONC (Office of the National Coordinator for Health Information Technology). Guidance is now published as “ASTP/ONC,” but the underlying information blocking regulation at 45 CFR Part 171 is unchanged by the name change itself.

Can a small physician practice really be penalized under this rule?

Yes, in principle. Any actor meeting the health care provider definition is covered regardless of size, though OIG has said it prioritizes cases involving real patient harm or significant disruption. A small practice’s realistic exposure often comes through participation-linked disincentives, like MIPS scoring, rather than direct civil penalties, which apply to developers and networks rather than providers.

Where can organizations find the authoritative text of the exceptions?

The full regulatory text lives in 45 CFR Part 171, with plain-language summaries and fact sheets published by ASTP/ONC at HealthIT.gov’s information blocking topic page. Organizations making compliance decisions should confirm current requirements against that primary source rather than relying solely on secondary summaries, including this one.