The Cures Act is Here: Your 4-Step Guide to Preventing Information Blocking Fines (45 CFR § 171.201)
Executive Summary
The 21st Century Cures Act made “information blocking” a front-line compliance risk for small clinics, not just for large systems and technology vendors. Information blocking is defined in federal law as practices that are likely to interfere with access, exchange, or use of electronic health information, unless an exception applies.
ONC’s regulations at 45 CFR Part 171 turn that statutory concept into specific rules, including the preventing harm exception at 45 CFR 171.201, which tells you when it is acceptable to slow or limit access to protect a patient or another person from harm. Small practices that misuse these exceptions, even with good intentions, risk being reported to HHS and facing federal disincentives or referrals to other enforcement agencies.
For health care providers, HHS is moving from education into active enforcement, using disincentives in Medicare and other programs when OIG finds information blocking. This article gives a practical four-step guide tailored to small clinics, showing how to use the preventing harm exception correctly, align with Part 171, and build enough documentation to survive an information blocking review without blowing your budget.
Introduction
For years, small clinics worried mainly about HIPAA and payer audits. The Cures Act’s information blocking provisions added a new layer: regulators now care not only about whether you protect health information, but also about whether you share it fast enough and without unreasonable friction. The same patient who complains to OCR about a delayed record request can now trigger a separate information blocking complaint if they believe your clinic intentionally or unreasonably stood in the way of access to their electronic health information.
Under 42 USC 300jj-52 and ONC’s information blocking rule, a health care provider engages in information blocking when it knows that a practice is unreasonable and is likely to interfere with access, exchange, or use of electronic health information, unless that practice fits within a specific regulatory exception. For small practices, the most commonly used and misused exception is the preventing harm exception in 45 CFR 171.201.
This exception acknowledges reality: sometimes releasing information can increase the risk of harm, such as when behavioral health notes could trigger violence, or when releasing data to a third party would endanger a victim of domestic abuse. However, the exception is narrow, detailed, and highly fact dependent. You cannot simply write “for patient safety” on a sticky note and deny access. If you do, you may fall outside 45 CFR 171.201 and into information blocking territory.
The goal for a small clinic is to operationalize the rule: turn the legal text into simple workflows, scripts, checklist questions, and documentation habits that any front desk associate, nurse, or manager can follow without a lawyer standing next to them.
Understanding Legal Framework and Scope Under 45 CFR 171.201
The statutory starting point is the definition of information blocking in 42 USC 300jj-52. That law says information blocking is a practice that is likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information, unless required by law or permitted by the Secretary through rulemaking. It also sets a different knowledge standard for developers and networks than for health care providers. Providers face risk when they know a practice is unreasonable and likely to interfere.
ONC’s rule at 45 CFR Part 171 implements this statute. Part 171.103 incorporates the statutory definition of information blocking and identifies the actors subject to the rule: health IT developers of certified health IT, health information networks and exchanges, and health care providers. Subparts B and C then describe when practices that might otherwise interfere with access to electronic health information will not be treated as information blocking. These are the exceptions, including the preventing harm exception at 45 CFR 171.201.
The preventing harm exception applies when a practice is likely to interfere with access, exchange, or use of electronic health information in order to prevent harm, and when certain conditions are satisfied. At a high level, the rule requires that:
-
The practice is no broader than necessary to substantially reduce a risk of physical harm.
-
The decision is made in a consistent, non-discriminatory way using reasonable clinical judgment.
-
The provider follows specified processes, such as documented individualized determinations when required.
Federal law leaves room for state variation. For example, state laws may impose stricter limits on sharing certain categories of data, such as substance use disorder records or teen reproductive health information, or may provide additional patient access rights beyond federal minimums. The information blocking rule recognizes that if a practice is required by law, it is outside the definition of information blocking altogether.
For a small practice, understanding this framework reduces denials, penalties, and friction in three ways. First, you can quickly separate “required by law” situations from true exception analysis. Second, you can design your workflows so that staff automatically ask the right questions before delaying access. Third, you can document the specific criteria under 45 CFR 171.201 in each case, so that if an information blocking complaint arises, you can show regulators exactly which rule you were applying and why.
Enforcement and Jurisdiction
Several federal players share responsibility for information blocking enforcement, and each matters to small practices differently. ONC writes and maintains the regulations at 45 CFR Part 171 and publishes guidance and FAQs that explain how the exceptions work.
HHS Office of Inspector General enforces the civil monetary penalty regime for information blocking by health IT developers, health information exchanges, and health information networks, with potential penalties of up to 1 million dollars per violation. The penalties are implemented under 42 CFR Part 1003, which authorizes OIG to impose civil money penalties for information blocking as defined in the Cures Act and ONC’s rule.
For health care providers, including small clinics, HHS has adopted a disincentive framework rather than direct civil monetary penalties at this time. A 2024 final rule establishes disincentives for Medicare-enrolled providers that OIG determines have committed information blocking, such as impacts on Medicare payment adjustments and participation in certain programs. Even if your practice is not currently at risk of a million-dollar CMP, an information blocking finding can still remove valuable program incentives and damage payer and patient trust.
Common triggers for information blocking scrutiny include patient complaints to ONC or OIG, referrals from other HHS components, and patterns identified in audits or program data. For small practices, the most realistic scenario is simple: a frustrated patient, referring physician, or payer complains that your clinic routinely delays, refuses, or conditions access to electronic health information in ways that feel unreasonable. If your documentation shows consistent, rule-based use of the preventing harm exception and other Part 171 provisions, you can demonstrate that your actions fall outside the definition of information blocking even if the patient disagrees.
Step HIPAA Audit Survival Guide for Small Practices
In a small clinic, information blocking compliance must coexist with HIPAA and other obligations. The following controls function as your operational playbook. Each one is specifically tied to 45 CFR Part 171 and, where relevant, HIPAA and the Cures Act statute.
First, standardize how you receive and classify electronic health information requests. Every request for access, exchange, or use of electronic health information should be captured in a single EHI Request Log, whether it comes from a patient portal message, payer fax, or another provider. For each entry, staff should record who is requesting, purpose, data requested, and whether any Part 171 exception is considered. This helps show regulators that you treat requests consistently, a key element of the preventing harm exception and other Part 171 exceptions.
-
Implementation: Add a simple EHI request intake form to your existing intake or front desk workflow, and train staff to enter every request into a shared log.
-
Evidence: Maintain the log for at least six years with cross-references to the record or portal message documenting the original request.
-
Low-cost option: Use your existing cloud-based spreadsheet solution and free templates, avoiding new software purchases.
Second, create a short, written decision tree for applying the preventing harm exception at 45 CFR 171.201. The decision tree should guide a clinician or designated privacy officer through each regulatory condition: Is there a reasonable belief that releasing the information will substantially reduce a risk of physical harm? Is the limitation narrowly tailored? Is the decision based on consistent, non-discriminatory criteria?
-
Implementation: Convert the regulatory text into five to seven plain-language questions, and attach the decision tree to your record request policy. Require staff to escalate potentially harmful requests to a designated clinical decision maker.
-
Evidence: For each case where access is delayed or limited based on preventing harm, attach a completed decision tree form to the patient’s record and log entry.
-
Low-cost option: Use text templates within your existing electronic health record or a shared document, and print a single laminated copy for reference at the nurses’ station.
Third, align your information blocking response timelines with HIPAA right-of-access and relevant payer expectations. While the Cures Act information blocking rule does not impose a separate fixed response time, unreasonable delays can be strong evidence of information blocking, especially when you cannot tie the delay to an exception.
-
Implementation: Set an internal target to respond to routine electronic health information requests within a set number of days, and flag any request that approaches that threshold for supervisor review.
-
Evidence: Keep timestamped entries in your EHI Request Log showing when the request was received, when it was triaged, and when it was fulfilled or denied, along with the exception analysis if applicable.
-
Low-cost option: Use automatic reminders or tasks within your existing EHR or a simple shared calendar to track approaching deadlines, rather than buying dedicated compliance software.
Fourth, build a simple exception analysis summary for each denied or significantly limited request. Even when you rely on the preventing harm exception or another Part 171 exception, regulators expect you to be able to demonstrate how your actions satisfied the rule’s conditions.
-
Implementation: For every denial or limitation, require the decision maker to complete a short note template summarizing the applicable exception, factors considered, and reasons why the practice is no broader than necessary.
-
Evidence: Keep the summary in the patient’s record and reference it in the EHI Request Log. When possible, include screenshots of configuration settings or portal rules that reflect the practice.
-
Low-cost option: Embed the template in your EHR’s standard note types or use a basic text expansion tool, so clinicians can complete it quickly.
Together, these controls create a defensible narrative: your clinic receives, logs, and triages requests in a uniform way, uses a structured, criteria-based process when invoking the preventing harm exception under 45 CFR 171.201, and documents each decision to show reasonableness rather than obstruction.
Case Study
Consider a small outpatient behavioral health clinic that serves adults and adolescents. A parent requests full electronic access to a seventeen-year-old patient’s psychotherapy notes through the portal. The patient has privately told the clinician that disclosure of those notes to the parent could lead to severe physical punishment and possible homelessness. The parent insists that denying access violates their rights, and later files a complaint with HHS claiming that the clinic is engaging in information blocking.
Under 42 USC 300jj-52 and 45 CFR Part 171, the clinic’s default obligation is not to interfere with access, exchange, or use of electronic health information unless an exception applies. At the same time, state law gives minors certain confidentiality rights, and HIPAA allows special handling of psychotherapy notes. The clinic’s compliance officer and treating clinician review the preventing harm exception at 45 CFR 171.201. They determine that giving the parent full portal access to the psychotherapy notes would create a substantial risk of physical harm to the patient, that limiting access to core treatment information without the detailed notes would significantly reduce that risk, and that similar criteria would apply to any patient in comparable circumstances.
Because the clinic has implemented the operational controls described earlier, the process looks disciplined rather than ad hoc. The front desk team logs the parent’s request in the EHI Request Log. The clinician completes a preventing harm decision tree form, documenting the specific risk, clinical rationale, and the chosen narrower response. The privacy officer drafts an exception analysis summary that cites 45 CFR 171.201 and the relevant state minor-consent law. The clinic sends a written response to the parent explaining that certain information is being limited to protect the patient from harm, consistent with federal and state law.
Months later, ONC receives the complaint and refers it to OIG. Investigators review the clinic’s documentation. They see evidence that the clinic applied a consistent process, relied on clinical judgment, and tailored the restriction narrowly to reduce a specific risk of physical harm. They also see that the clinic fulfills similar requests in other situations without invoking the exception. The complaint is closed without finding information blocking.
Financially, the clinic avoids disincentives tied to Medicare programs and avoids the cost of hiring outside counsel or consultants to rebuild its policies under pressure. Reputationally, the clinic shows both patients and payers that it can protect vulnerable individuals while still supporting electronic access for most care scenarios.
Self-Audit Checklist
The following self-audit table turns the legal framework into concrete tasks for your team. Use it quarterly or annually to confirm that your operations still align with 45 CFR Part 171 and the preventing harm exception at 45 CFR 171.201.
|
Task |
Responsible Role |
Timeline / Frequency |
CFR Reference |
|---|---|---|---|
|
Maintain a complete EHI Request Log capturing all access, exchange, and use requests and outcomes |
Front Desk Lead or Health Information Management Lead |
Ongoing, with quarterly review |
45 CFR 171.103; 42 USC 300jj-52 |
|
Review and update the preventing harm decision tree to reflect current clinical standards and state law |
Medical Director or Designated Clinician |
Annually, or after major legal changes |
45 CFR 171.201 |
|
Spot-check a sample of denied or limited requests to confirm that exception analysis summaries are complete |
Privacy or Compliance Officer |
Quarterly |
45 CFR 171.201; 45 CFR 171.300 |
|
Verify that response times for electronic health information requests meet internal targets and are not routinely delayed without a documented exception |
Operations Manager |
Quarterly metrics review |
45 CFR 171.103; 42 USC 300jj-52 |
|
Confirm that staff training on information blocking and exceptions has been delivered and documented for all relevant roles |
Compliance Officer |
At onboarding and at least annually |
45 CFR 171.100; 45 CFR 171.201 |
|
Reconcile any information blocking complaints or grievances with your logs and documentation to identify patterns |
Compliance Officer with Practice Administrator |
After each complaint and during annual risk assessment |
42 USC 300jj-52; 42 CFR Part 1003 |
|
Validate that configuration of patient portals and EHR access controls matches your written policies on exceptions |
IT Support or EHR Super-user |
Annually |
45 CFR 171.201; 45 CFR 171.205 |
By treating this table as a regular self-audit tool, your clinic can catch weak documentation, slow response times, or inconsistent use of exceptions before an external reviewer or payer sees them, directly lowering your information blocking risk under 45 CFR Part 171.
Common Audit Pitfalls to Avoid Under 45 CFR 171.201
Auditors and investigators often look for recurring, high-impact mistakes that indicate a culture of obstruction rather than compliance. The following pitfalls are especially dangerous for small practices.
-
Citing “patient safety” or “emotional harm” as a generic reason to withhold electronic health information without tying the decision to the specific conditions in 45 CFR 171.201, which weakens the claim that the preventing harm exception truly applies.
-
Applying the preventing harm exception inconsistently, such as granting access to similarly situated families in some cases but not others, which suggests discriminatory or arbitrary practices under 45 CFR 171.201.
-
Treating technical limitations in the EHR or portal as a permanent excuse to deny or delay access, instead of considering the infeasibility or health IT performance exceptions under other provisions of Part 171.
-
Ignoring requests that arrive through “inconvenient” channels, such as faxed forms from small referring practices, which can look like deliberate interference with exchange of electronic health information under 45 CFR 171.103.
-
Failing to keep any centralized record of EHI requests and exception decisions, making it nearly impossible to show a consistent pattern of reasonable, rule-based practices in the event of an information blocking investigation.
-
Delegating all decisions about access limitations to non-clinical staff without any documented clinical judgment, which can undercut the requirement in 45 CFR 171.201 that the risk of harm and tailoring be grounded in reasonable clinical judgment.
By avoiding these pitfalls and replacing them with structured logging, decision trees, and documented exception analysis, your clinic can transform information blocking from a vague fear into a manageable compliance domain under 45 CFR Part 171 and 45 CFR 171.201.
Culture and Governance
Information blocking compliance becomes sustainable only when it is woven into daily operations rather than treated as a one-time project. That starts with clear policy ownership. Assign a single responsible leader, such as the practice administrator or compliance officer, to own the information blocking policy and to coordinate updates when ONC or OIG issues new guidance.
Staff training should follow a predictable cadence. At onboarding, every employee who handles records or communicates with patients should complete a short training on what information blocking is, how to recognize an EHI request, and when to escalate potential exceptions. At least annually, refresh this training to incorporate new federal guidance, enforcement trends, and case examples from your own practice.
Your clinic should also define simple monitoring metrics. Examples include average time from EHI request to response, percentage of requests involving any exception analysis, number of denials or limitations per quarter, and the number of complaints or grievances related to access. These can be tracked in the same EHI Request Log used for operational control.
Finally, leadership must model the right tone. When a provider or staff member raises a concern that sharing information might cause harm, the response should be “Let us walk through the 45 CFR 171.201 criteria together,” not “Just deny it.” This reinforces that the rule is about carefully balancing safety and access, not hiding behind vague fears.
Conclusions and Next Actions
The Cures Act information blocking rules have moved from theory into practical enforcement, and small clinics are part of that landscape. While the million-dollar penalties highlighted in headlines apply to developers and networks today, HHS has created disincentives for health care providers, and OIG is actively investigating information blocking complaints.
For a resource-constrained practice, the safest path is not perfection but repeatability. By using 45 CFR 171.201 and the broader Part 171 framework as your guide, you can design workflows that show regulators you are trying to share electronic health information whenever possible and that you invoke exceptions only when the rule’s conditions are truly met and carefully documented.
Here are concrete next steps your clinic can take now:
-
Build or update your EHI Request Log so that every access, exchange, or use request is captured with dates, requester type, and outcome, creating a single source of truth for audits.
-
Draft a short preventing harm decision tree based on 45 CFR 171.201 and train clinicians and privacy staff to use it whenever they consider limiting access for safety reasons.
-
Create a standard exception analysis summary template and require it for all denied or significantly limited requests, tying each decision to the specific exception and legal citation.
-
Set internal response time targets for electronic health information requests, monitor performance monthly, and investigate any patterns of delay that are not clearly connected to an exception.
-
Schedule an annual mini-audit using the Self-Audit Checklist to confirm that documentation, training, and portal configurations still match your written policies and current federal guidance.
Recommended compliance tool:
ONC’s information blocking FAQs and guidance documents, downloaded and summarized into a one-page quick reference for your clinic.
Advice:
Do not wait for an information blocking complaint; choose one recent EHI request today, walk it through the preventing harm decision tree, and make sure your documentation could satisfy a skeptical auditor.