The information blocking rule: who it covers, what counts, and the exceptions

The short answer

The information blocking rule, 45 CFR part 171, says that health care providers, certain health IT developers, health information networks and health information exchanges (“actors”) must not engage in practices likely to interfere with access, exchange or use of electronic health information (EHI), unless the law requires it or one of the rule’s exceptions applies.¹ There are ten exceptions, covering things like preventing harm, privacy, security, infeasibility, fees and licensing.¹ Each has conditions that must all be met. Security limits, for example, must be directly related to safeguarding EHI, tailored to the specific risk and applied consistently.¹ This is a plain-language summary, not legal advice.

Who the rule covers

The rule defines four kinds of actor:¹

EHI means electronic protected health information in a designated record set, but not psychotherapy notes or information compiled for legal proceedings.¹

What counts as information blocking

Information blocking is a practice that, unless required by law or covered by an exception, is likely to interfere with access, exchange or use of EHI.¹ The knowledge test differs by actor:

• Developers, networks and exchanges: they know, or should know, the practice is likely to interfere.¹
• Providers: they know the practice is unreasonable and likely to interfere.¹

“Practice” is broad. It can be a policy, a contract term, a technical design, a fee or a delay. Typical examples people discuss: refusing to turn on an API, charging unreasonable fees for export, slow-walking a patient’s request, or locking data in a format only one vendor can read.

The ten exceptions

A practice isn’t information blocking if the actor meets all the applicable conditions of an exception at all relevant times.¹

Sources:¹. Six sit in subpart B (not fulfilling requests), three in subpart C (how requests are fulfilled), and the TEFCA exception in subpart D.

Two exceptions matter most for security and AI teams:

Security. The practice must be directly related to safeguarding the confidentiality, integrity and availability of EHI, tailored to the specific risk, and implemented consistently. If it implements an organisational security policy, that policy must be written, based on assessed risks, aligned with consensus standards, and give objective timeframes for handling incidents. Otherwise, the actor needs a documented determination for the specific case.¹

Preventing harm. The actor must reasonably believe the practice will substantially reduce a risk of harm, and the practice must be no broader than necessary.¹

The pattern in both: write down the reason, make the limit narrow, apply it the same way to everyone.

Consequences

For health care providers that the HHS Office of Inspector General finds have committed information blocking, CMS can apply disincentives: an eligible hospital or critical access hospital isn’t a meaningful EHR user, a MIPS clinician isn’t a meaningful EHR user for MIPS, and accountable care organisations and their participants can be removed from, or refused entry to, the Medicare Shared Savings Program for at least a year.¹ Developers, networks and exchanges face separate enforcement under other provisions.

Where AI tools and agents fit

The rule doesn’t mention AI. But AI changes how data gets accessed, and both directions raise questions.

Blocking AI access. A provider that refuses all API access because “AI might misuse the data” has a practice that interferes with access. If the concern is real, the security or preventing-harm exception is the route, and both require narrow, documented, consistent limits.¹ A blanket refusal is hard to fit.

Limiting what agents can do. Narrow scopes, rate limits and approval steps for automated clients are normal security practices. They fit the security exception better when they’re written in policy, tied to an assessed risk and applied to all similar clients alike.¹

AI as the source of delay. If an AI tool sits in the path of patient requests and slows or blocks them, the practice is still the actor’s. Records of what the tool did and why help show whether a delay had a recognised reason.

Payer APIs are a parallel track: CMS-0057-F requires impacted payers to offer FHIR APIs including a prior authorization API, generally from 1 January 2027.²

A checklist

• Map which of your products, services and policies affect access, exchange or use of EHI.¹
• For every limit on access, name the exception you rely on and keep evidence that its conditions are met.¹
• Write security limits as policy, tied to assessed risk, applied consistently.¹
• Treat AI and automated clients under the same written policy as other clients.
• Keep records of requests, decisions and timings, so a delay can be explained.
• Review fees and licence terms against the fee and licensing exceptions.¹

Questions people ask

Does the information blocking rule apply to my AI startup?

Only if you’re one of the four actor types.¹ Many AI vendors aren’t actors themselves but work for providers who are, so the provider’s practices, including yours on its behalf, may matter.

Can we refuse API access for security reasons?

Possibly, under the security exception, if the limit is directly related to safeguarding EHI, tailored to the risk and applied consistently, under a written policy or a documented determination.¹

What happens to a provider found to have blocked information?

CMS can apply disincentives tied to Medicare programs.¹

Teams building on health APIs can see how agent access is recorded and limited on our healthcare page, with record formats in the provenance spec. To try approvals and read-backs on a real database in your browser, open the playground; to grade what an agent can reach on your own machine, run npx deedglass scan (the grade, explained).

Written with AI assistance and checked against our claims register.