Information blocking is a practice by a covered "actor" that is likely to interfere with the access, exchange, or use of electronic health information — unless the practice is required by law or fits a regulatory exception. The concept comes from the 21st Century Cures Act, and the rules are set out in 45 CFR Part 171. They apply to health care providers, to developers of certified health IT, and to health information exchanges and networks. Since 2024 there have been real consequences attached, which is why this stopped being a policy-team topic and became an operations one.
What information blocking is
The Cures Act, passed in 2016, made sharing electronic health information the expected norm rather than a favor. The regulation defines information blocking as a practice likely to interfere with access, exchange, or use of electronic health information (EHI). The exact definition lives at 45 CFR 171.103.
The word doing the heavy lifting is practice. This is not only about dramatic refusals. It covers the ordinary friction that builds up around data: policies, fees, contract terms, technical configurations, delays. A practice that has the effect of interfering can be information blocking even if nobody set out to obstruct anyone.
Who the rules apply to
The law names three types of "actor":
- Health care providers — a broad category defined in the regulation.
- Health IT developers of certified health IT — vendors whose products are certified under ONC's Health IT Certification Program.
- Health information exchanges and health information networks (HIEs/HINs).
If your practice uses a certified EHR, both you and your vendor are actors, with separate obligations. Neither of you can point at the other as the reason data didn't move.
The two knowledge standards
This is the nuance most summaries skip, and it matters a great deal to providers. The statute applies different knowledge standards depending on who you are:
| Actor | Standard |
|---|---|
| Health IT developers of certified health IT; HIEs/HINs | They know, or should know, that the practice is likely to interfere with access, exchange, or use of EHI |
| Health care providers | They know that the practice is unreasonable and is likely to interfere with access, exchange, or use of EHI |
The provider bar is higher: it requires knowledge that the practice is unreasonable. Vendors and networks are held to a "should have known" standard. That difference is deliberate, and it reflects who is expected to understand the technology.
What counts as EHI
EHI is, broadly, electronic protected health information to the extent it would be included in a designated record set — the records used to make decisions about individuals. That is a wide scope. It is not limited to a specific data set or to what happens to be exposed through an API.
Practically: if a patient, an app they authorized, or another provider asks for information you hold electronically and that information is part of the record used to make decisions about that patient, "our system doesn't do that" is a claim you should be able to defend.
The exceptions — and what they are not
The regulation defines exceptions — reasonable and necessary activities that do not constitute information blocking. They fall into two groups:
- Exceptions that involve not fulfilling a request — including practices to prevent harm, to protect privacy, to protect security, where fulfilling the request is infeasible, and to maintain health IT performance.
- Exceptions that involve procedures for fulfilling a request — including the content and manner of a response, the fees an actor charges, and licensing of interoperability elements.
Later rulemaking has added further exceptions, so check 45 CFR Part 171 for the current list rather than relying on any article's summary, including this one.
Two points ONC makes explicitly, and both cut against common assumptions:
- The exceptions are voluntary. They exist to give actors certainty. You do not have to fit one.
- Failing to meet an exception does not automatically mean information blocking occurred. Practices that don't fit an exception are evaluated case by case.
So the exceptions are best understood as safe harbors, not as a list of the only permissible reasons to say no. Meet one and you are clearly fine. Miss one and you are in a judgment call — which is precisely where good documentation pays for itself.
How claims are handled
Anyone — a patient, a competing provider, an app developer — can submit an information blocking claim through ONC's Report Information Blocking Portal. By law, information received in connection with a claim that could identify who submitted it is exempt from mandatory disclosure under the Freedom of Information Act.
From there the authority splits. ONC can review claims against developers of certified health IT as potential non-conformities under the Certification Program. The HHS Office of Inspector General (OIG) has authority to investigate claims of information blocking across all actor types — providers, HIEs/HINs, and developers.
Penalties and provider disincentives
The consequences differ by actor, and this is worth being precise about:
- Developers of certified health IT, HIEs, and HINs face civil money penalties. Under the Cures Act, OIG may impose penalties of up to $1 million per violation.
- Health care providers are not subject to those civil money penalties. Instead, HHS finalized a rule establishing disincentives for providers found by OIG to have committed information blocking, implementing the Secretary's authority under section 4004 of the Cures Act. The disincentives operate through existing federal programs rather than as standalone fines.
Enforcement is no longer theoretical. ONC has published an enforcement alert and HHS has publicly announced action on health data blocking. Treat this as a live compliance area, not a future one.
What this means when you buy software
Information blocking should change how you evaluate vendors, because a vendor's posture on data becomes your problem:
- API access. Ask how third-party apps a patient authorizes get connected, how long registration takes, and what it costs. Slow-walking app registration has drawn explicit attention from ONC.
- Fees for interfaces and exports. Ask for the full schedule in writing during selection — not after you're a customer.
- EHI export. Confirm what the product is certified for on the Certified Health IT Product List, and ask to see an actual export.
- Contract language. Terms that restrict how you use or share your own data deserve scrutiny.
A practical checklist
For a practice trying to stay on the right side of this without hiring a compliance department:
- Release results without artificial delay. Holding results back as a blanket policy is a classic exposure. If a delay is clinically justified for an individual, that judgment is what the preventing-harm exception is about — and it should be documented as such.
- Don't obstruct patient-authorized apps. If a patient chooses an app you dislike, that is generally their choice to make.
- Review your fees. Any charge attached to access, exchange, or use of EHI should be examined against the fees exception.
- Write down your reasons. When you decline or delay a request, record who decided, why, and which exception the reasoning maps to. A contemporaneous note is worth more than a reconstructed explanation later.
- Train the front desk and records staff. Most interference is not strategic. It's a well-meaning person applying an old policy.
The through-line is simple: sharing is the default, refusing is the exception, and "the system won't let us" is an answer you should be able to back up.
Common questions
Does information blocking apply to my practice, or only to EHR vendors?
Both. The Cures Act names three types of actor: health care providers, health IT developers of certified health IT, and health information exchanges and networks. If you use a certified EHR, you and your vendor each have your own obligations.
If a practice doesn't meet an exception, is it automatically information blocking?
No. ONC states that the exceptions are voluntary and that a practice which does not meet one is evaluated case by case. Meeting an exception provides certainty; missing one puts you in a judgment call rather than an automatic violation.
What are the penalties?
Health IT developers of certified health IT, HIEs, and HINs may face civil money penalties from HHS OIG of up to $1 million per violation under the Cures Act. Health care providers are not subject to those penalties; HHS finalized a separate rule establishing disincentives applied through existing federal programs.
Can we delay releasing test results to patients?
A blanket delay policy is a common exposure. A delay based on a documented, individualized clinical judgment is what the preventing-harm exception addresses. The difference between the two is documentation and individualization.