An information blocking compliance program is the written policy set, workflow and evidence log that a healthcare provider or health information exchange uses to handle requests for electronic health information (EHI) and to document its position under 45 CFR Part 171. This page is for compliance and privacy officers at healthcare providers and at health information exchanges and networks. Integral Healthcare Solutions (IHS) drafts the EHI request policies, exception documentation, escalation workflow and training for your officers to review and approve, and your counsel confirms the legal conclusions.
Last reviewed: October 2026.
What is information blocking?
ASTP/ONC states: "Information blocking is a practice by an 'actor' that is 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." (ASTP/ONC information blocking page, page opened October 4, 2026).
The definition is in 45 CFR 171.103(a): "Information blocking means a practice that except as required by law or covered by an exception set forth in subparts B, C, or D of this part, is likely to interfere with access, exchange, or use of electronic health information" (45 CFR 171.103, Legal Information Institute copy, page opened October 4, 2026).
ASTP/ONC says the Cures Act applied the law to healthcare providers, health IT developers of certified health IT, and health information exchanges and health information networks. This page is written for providers and exchanges. Developers of certified health IT are also actors, and their work is a separate subject.
Who needs a program and what triggers it?
In IHS's reading, an organization that counts as an actor benefits from a documented way to show how it handles EHI requests. We found no source in the pages we opened that requires a written program. Whether your organization is an actor is a legal question for your counsel, and IHS gives no opinion on it. The standard differs by actor type. For providers, ASTP/ONC says the law applies the standard of whether they know that the practice is unreasonable and is likely to interfere with the access, exchange, or use of EHI. For developers and exchanges the standard is whether they know, or should know, that a practice is likely to interfere (page opened October 4, 2026).
In IHS's reading, these are the common triggers for building a program:
- EHI requests are handled by individual staff members with no written policy.
- Requests are denied, delayed or limited and nobody records why.
- The organization joins an exchange or network, or changes how it shares EHI.
- Staff turnover has left the request process without an owner.
- A claim has been submitted about the organization, or leadership wants to be ready for one. ASTP/ONC says claims go through the Report Information Blocking Portal and that OIG can investigate.
How does IHS help?
IHS drafts the information blocking program documents and tests the file before anyone else reads it. The process:
- Gap assessment of how EHI requests are received, decided, answered and logged today.
- Drafting of the EHI request policy, the decision workflow with named owners, the escalation path and staff training material.
- Exception mapping: each policy is tied by title to the exceptions in 45 CFR Part 171.
- An evidence log template that records each denied, delayed or limited request, the exception relied on and the facts behind the decision.
- A mock review of the completed file, which checks that the policies, workflow and log agree with each other.
What you supply: your current policies, your request and denial records, a description of how requests arrive (portal, exchange, direct), the system administrators who know it, your compliance and privacy officers, and your counsel.
The limit: your compliance and privacy officers review and approve every document, and your organization adopts and runs the program. IHS does not configure systems, does not decide that a practice is or is not information blocking, and does not contact ASTP/ONC or OIG. Your counsel confirms legal conclusions.
If the program sits inside a larger compliance structure, see our compliance program development work and our compliance services overview. If your security controls need review as part of the same effort, see HITRUST and cybersecurity.
Which exceptions does the program cover?
The program is mapped to the exceptions in Part 171 by title. IHS read the section heading of each exception and not its conditions, so the list below names them and nothing more.
| Provision | Exception name in the section heading |
|---|---|
| 45 CFR 171.201 | Preventing harm exception |
| 45 CFR 171.202 | Privacy exception |
| 45 CFR 171.203 | Security exception |
| 45 CFR 171.204 | Infeasibility exception |
| 45 CFR 171.205 | Health IT performance exception |
| 45 CFR 171.206 | Protecting Care Access |
| 45 CFR 171.301 | Manner exception |
| 45 CFR 171.302 | Fees exception |
| 45 CFR 171.303 | Licensing exception |
| 45 CFR 171.403 | TEFCA manner exception |
ASTP/ONC says the exceptions are voluntary and offer actors certainty, and that a practice that does not meet an exception is not automatically information blocking. Such practices are evaluated case by case (page opened October 4, 2026).
What to have ready
This checklist is IHS's planning view. Items that name an exception tie to its section heading in 45 CFR Part 171, and the rest support the definition in 171.103(a).
- Your current written policy for EHI requests, or a note that none exists.
- A list of the ways requests reach you, such as a patient portal, an exchange or network, or direct requests.
- Your log of requests that were denied, delayed or limited, with the reason recorded for each.
- For any request where you relied on an exception, the documentation behind it, organized by exception title.
- Your privacy and security policies, since privacy (171.202) and security (171.203) are both exceptions by title.
- A list of your health IT systems and the person who administers each.
- If you charge for access to EHI, your fee schedule, since charging fees (171.302) is an exception by title.
- Any licensing terms for interoperability elements, since 171.303 is an exception by title.
- Exchange or network participation agreements, if you take part in one.
- Staff training records on EHI requests.
- The name of the counsel who confirms legal conclusions and the path for reaching them.
Printable version of this checklist (PDF)
Bring what you have to the free introductory call and we will tell you what is missing.
How does a written program compare with other approaches?
The approaches below are named neutrally. Which one fits depends on your counsel's advice and your own risk view, and IHS does not tell you which to choose.
| Approach | What it involves |
|---|---|
| Case by case, no written policies | Staff decide each request as it arrives. IHS's reading: the reasoning for a decision stays with the person who made it unless it is recorded. |
| Written program with documented exceptions | IHS's reading: a policy set, workflow and evidence log that record which exception, if any, supports each decision to limit, delay or decline a request. |
| Privacy and security controls only | HIPAA programs are privacy and security controls. Privacy (171.202) and security (171.203) are exceptions by title in Part 171. IHS makes no claim about how the two kinds of program interact. |
| Technical solutions | EHR and portal configuration is a technical task. IHS does not do it. |
What does an information blocking program cost?
The government pages we opened do not publish a fee schedule for an information blocking program, and costs depend on scope. Section 171.302 concerns an actor's practice of charging fees for accessing, exchanging or using EHI, which is a separate subject this page does not cover. IHS scopes each engagement after a free introductory call.
What this is not
- It is not legal advice. IHS is a consulting firm, not a law firm, and gives no opinion on whether the rule applies to your organization.
- It is not a determination that any practice is or is not information blocking, and it does not predict what OIG or any other body would find.
- It is not system configuration, and IHS does not contact, file with or speak for your organization to ASTP/ONC, OIG or any other agency. IHS drafts, and your organization adopts, runs and submits.
Frequently asked questions
What is information blocking and who is an actor?
ASTP/ONC describes information blocking as a practice by an "actor" that is likely to interfere with the access, exchange, or use of electronic health information (EHI), except as required by law or specified in an exception. It says the Cures Act applied the law to healthcare providers, developers of certified health IT, and health information exchanges and networks.
Does information blocking apply to a hospital or physician group?
ASTP/ONC says the law applies to healthcare providers. Whether your hospital or physician group is a healthcare provider as 45 CFR Part 171 uses the term is a legal question, and IHS gives no opinion on it. Your counsel answers that, and IHS builds the program around the answer.
What does a provider have to know for a practice to count?
For healthcare providers, ASTP/ONC says the law applies the standard of whether they know that the practice is unreasonable and is likely to interfere with the access, exchange, or use of EHI. Developers and exchanges are held to a know or should know standard. A written program gives your staff a documented way to recognize and escalate a request before a practice settles into habit.
What are the exceptions and does meeting one protect us?
The exceptions sit in 45 CFR Part 171, subparts B, C and D, and the table on this page lists the ten we read by section heading. The definition in 171.103(a) excludes a practice covered by an exception. ASTP/ONC says the exceptions are voluntary and offer actors certainty.
What if our practice meets no exception?
ASTP/ONC says that failing to meet an exception does not automatically mean information blocking has occurred. Such practices are evaluated case by case. IHS does not decide whether a practice is or is not information blocking. Your counsel does.
Who investigates complaints and how are claims submitted?
ASTP/ONC says the HHS Office of Inspector General has authority to investigate claims of possible information blocking across all types of actors. It says claims are submitted online through ONC's Report Information Blocking Portal. IHS does not file, answer or follow any claim for your organization.
What are the consequences for providers?
ASTP/ONC states that HHS released a final rule establishing disincentives for healthcare providers found by OIG to have committed information blocking. IHS did not read the rule itself, so this page does not describe the disincentives or when they apply. Ask your counsel for the current text.
What policies and records should a provider keep?
This is IHS's planning view, not a requirement we found in the sources we opened. A provider typically wants a written EHI request policy, a workflow with named owners and an escalation path, a log of requests that were denied, delayed or limited, and the documentation behind any exception relied on. IHS drafts these for your compliance and privacy officers to approve.
How does EHI request handling work in an HIE or HIN?
The sources IHS opened do not define health information exchange or health information network, so this page states no rule for them. IHS's work is a request handling workflow for an exchange's own staff: who receives a request, who decides, where the decision is logged, and when counsel is called. The exchange adopts it and runs it.
How does a compliance program tie to the exceptions?
In IHS's reading, the program is where each decision to limit, delay or decline a request is tied to a specific exception by title and recorded with the facts behind it. IHS maps each drafted policy to the Part 171 exceptions by title. Your counsel confirms whether an exception applies to a given practice.