Information Blocking Explained: When Can Your Small Practice Legally Deny Access to PHI? (45 CFR § 171.200)

Small practices are under growing pressure to share electronic health information quickly with patients, payers, and other providers. The information blocking rule under the 21st Century Cures Act, implemented at 45 CFR Part 171, makes it risky to deny or delay access to electronic health information unless you can clearly point to a specific legal basis. 

Section 45 CFR 171.200 explains that you are protected only when a denial or limitation fits within one of the formal information blocking exceptions, and you meet every requirement of that exception at all relevant times.  In practice, that means a simple “no” is never enough; you need a documented link to a recognized exception, such as privacy, security, infeasibility, health IT performance, or preventing harm.

For small clinics with lean staff, this can feel like a legal maze. But with a few structured tools, you can turn 45 CFR 171.200 into a clear decision path: is this denial required by law, explicitly permitted by HIPAA or state law, or squarely inside one of the information blocking exceptions? Getting that answer right, and recording it, is what keeps your clinic on the safe side of Cures Act enforcement.

The title question is the one your front desk, nurses, and clinicians ask every week in different words: “Can we say no to these records request?” Historically, small practices leaned on HIPAA’s right-of-access framework and a few familiar denial grounds, such as psychotherapy notes or risk-of-harm determinations under 45 CFR 164.524. Today, that is no longer enough. Information blocking rules overlay a second layer of analysis whenever the request involves electronic health information. 

Under 42 USC 300jj-52 and 45 CFR 171.103, a provider engages in information blocking when it uses a practice that is likely to interfere with access, exchange, or use of electronic health information and knows that practice is unreasonable, unless it is required by law or covered by a regulatory exception.  Clinicians and administrators do not need to memorize every subparagraph, but they do need a repeatable way to connect each denial or restriction to something the rule explicitly allows.

This article distills that challenge into an operational question: how do you build a defensible pattern of “legal no” decisions that fall under 45 CFR 171.200, while minimizing true information blocking? The focus is practical, aimed at small clinics that cannot afford a full-time legal team but still need to prove they are acting within the law.

Understanding Legal Framework and Scope Under 45 CFR 171.200

The statutory engine behind information blocking is 42 USC 300jj-52. Congress defined information blocking as a practice that, except as required by law or specified by the Secretary, is likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information. For health care providers, liability requires knowledge that the practice is unreasonable and has that effect. 

ONC translated this definition into regulatory text in 45 CFR Part 171. Subpart A sets out the general provisions and incorporates the statutory definition, while Subpart B identifies exceptions that involve not fulfilling requests to access, exchange, or use electronic health information.  Section 171.200 sits at the threshold of Subpart B and states the core principle for this article:

The exceptions that matter most when you are considering “Can we legally deny?” include:

• Preventing harm (171.201)

• Privacy (171.202)

• Security (171.203)

• Infeasibility (171.204)

• Health IT performance (171.205)

• Protecting care access (171.206)

Each exception is detailed and conditional; there is no generic “provider discretion” safe harbor.  In addition, Subpart C adds procedural exceptions for how you fulfill requests (content and manner, fees, and licensing), and Section 171.300 mirrors 171.200 for those procedural exceptions: if you meet all the conditions, the practice is not treated as information blocking. 

Federal law interacts with state law in two key ways. First, if state privacy or access law requires you to deny or restrict access, your practice falls into the “required by law” carve-out and is not information blocking at all.  Second, where state law gives patients broader access than HIPAA, your failure to honor those rights can make it harder to justify a denial under 171.200, because you cannot point to an applicable exception or statutory requirement.

For small practices, understanding this framework does three things: it clarifies when you must say yes, it narrows the circumstances in which you may say no, and it gives you a map to connect each denial to either “required by law” or a specific exception. That alignment sharply reduces the risk of denials being recast later as unreasonable information blocking.

Information blocking enforcement is shared across HHS. ONC writes and updates the regulations in Part 171 and publishes technical guidance and FAQs to explain how the exceptions operate in real-world scenarios. 

The HHS Office of Inspector General is responsible for investigating information blocking allegations and imposing civil monetary penalties on health IT developers, networks, and exchanges under 42 CFR Part 1003.  For health care providers, including small clinics, HHS has established disincentives instead of direct CMPs, tying information blocking findings to reduced benefits in certain Medicare programs. 

OCR, which enforces the HIPAA Privacy Rule, also plays an indirect role. If an information blocking complaint appears to be rooted in misunderstanding HIPAA access rules, OIG can consult with or refer the matter to OCR under the statute, and OCR’s views on whether a denial was permissible under 45 CFR 164.524 can be highly persuasive in the information blocking context. 

Common triggers for review include:

• Patient or caregiver complaints about denied portal access, withheld visit notes, or refusals to transmit data to third-party apps.

• Referrals by payers or partner organizations that see consistent patterns of non-cooperation or slow responses to electronic records requests.

• Program integrity data showing outlier denial rates, long delays for access, or health IT performance “downtime” that is suspiciously aligned with high-volume periods.

For a small practice, that means every denial is potentially discoverable. If reviewers can quickly see that your “no” was required by law or fits cleanly within an exception recognized by 45 CFR 171.200, the matter can often be resolved without escalation. If your records show ad hoc reasons that do not link to any exception, you look much more like an information blocker.

Turning 45 CFR 171.200 into daily practice requires a simple but disciplined pattern: every time you consider saying no, you identify the legal category and document it. The following controls help small practices do that without buying new systems.

First, build and use a “Denial Reason Matrix” that sits at the heart of your access policy. Before anyone denies or significantly limits access to electronic health information, they must choose one of three boxes on the matrix: required by law, HIPAA-permitted denial (for example, 45 CFR 164.524(a)(2)), or information blocking exception (with a citation such as 45 CFR 171.202 for a privacy-based denial). 

• Implementation: Create a one-page table listing common denial scenarios in one column and the corresponding authority in another, clearly labeling which line corresponds to which exception under Subpart B or which HIPAA right-of-access ground you are using. Incorporate 45 CFR 171.200 at the top as the “safe harbor” statement.

• Evidence: Attach a copy or electronic capture of the completed matrix line (or a short note referencing the line) to each denial event in the patient’s record or request file. Auditors should be able to see, at a glance, which legal path justified that decision.

• Low-cost approach: Use a shared document or policy manual accessible through your existing cloud storage, and print a laminated copy for the front desk and clinical workstations.

Second, require a “least-blocking” analysis for every potential denial and capture it in a short worksheet. 45 CFR 171.200 protects you only if you truly satisfy an exception; several exceptions, such as privacy, security, infeasibility, and health IT performance, are built around proportionality and narrow tailoring.  That means you should first ask whether you can grant partial access, use an alternative manner, or delay for a defined period instead of issuing a full denial.

• Implementation: Design a one-page “Request Resolution Worksheet” with three core questions: (1) Can we fulfill this as requested without violating any law? (2) If not, can we fulfill part of it or use an alternative manner (for example, redacting or providing a different format) consistent with the content-and-manner and infeasibility frameworks in Part 171? (3) If we still cannot, which specific exception in 171.201–171.206 applies, and how do we meet its conditions?

• Evidence: Save completed worksheets in a centralized folder or as part of the electronic record, so that each denial or significant limitation has a corresponding trail showing that alternatives were considered.

• Low-cost approach: Embed the worksheet prompts in existing EHR note templates or create a simple fillable PDF that staff can complete and upload.

Third, standardize patient-facing denial communications so they reflect the Denial Reason Matrix and 45 CFR 171.200. The exceptions do not require you to quote regulatory text to every patient, but they do expect consistency and transparency about the basis of your decision.

• Implementation: Draft a set of short denial and partial-fulfillment templates that map to each category of your matrix. Each template should indicate in plain language whether the denial is required by law, based on HIPAA’s access provisions, or grounded in an information blocking exception such as privacy or security. Where HIPAA requires future review rights or alternative options, build that language in.

• Evidence: Retain copies of these communications (letters, portal messages, secure emails) in the record, clearly tied to the underlying worksheet or matrix entry. During an investigation, this shows that your external messages match your internal legal reasoning.

• Low-cost approach: Use your existing patient portal and EHR letter tools, saving templates as canned responses or smart phrases so staff can select the correct one quickly.

Fourth, create a crosswalk between your HIPAA right-of-access policy and your information blocking policy so that staff are never choosing between two conflicting documents. HIPAA at 45 CFR 164.524 already defines when access may be denied or limited; 45 CFR 171.200 and the related exceptions define when such denials or limitations will not be treated as information blocking. 

• Implementation: Update your access policy to include a concise section titled “Coordination with Information Blocking Exceptions,” summarizing how each HIPAA denial ground aligns with one or more exceptions in 171.201–171.206 or with the “required by law” carve-out. Reference 45 CFR 171.200 explicitly, so staff understand that this is the legal link between your policy and the rule.

• Evidence: Maintain version-controlled policies with documented approval dates and training logs showing when staff were oriented to the integrated policy.

• Low-cost approach: Have your practice manager or compliance lead adapt publicly available government guidance to your local workflows instead of outsourcing policy drafting.

Finally, perform a focused quarterly review of denial patterns using a simple tally sheet rather than a full-blown audit. 45 CFR 171.200 assumes that exceptions are used for “reasonable and necessary” activities, not as routine shortcuts. If you see denials clustering around one untested rationale, it may be a red flag.

• Implementation: Once each quarter, someone in a leadership or compliance role should pull a small sample of recent denials or restricted responses and categorize them by legal basis, exception used, and requester type. Outliers should be discussed in a brief meeting and, if necessary, used to update the Denial Reason Matrix or training.

• Evidence: Keep the tally sheets and short meeting notes as part of your compliance file, showing that you actively monitor and refine how exceptions are used.

• Low-cost approach: Use a simple spreadsheet or paper tracking form that can be updated in 30 minutes, rather than commissioning external audits.

These controls help your clinic convert ad hoc “no” decisions into structured, exception-based responses that fall within the safe harbor described by 45 CFR 171.200, while remaining manageable for small teams.

Case Study

A three-provider primary care clinic uses a popular cloud-based EHR with a patient portal. A patient requests that their visit notes and lab results be released via a third-party app connected through an API. The clinic’s front desk replies that the clinic does not support apps and that the patient must instead pay a “record handling fee” to receive PDF copies by email. Later, the same patient asks for all notes from the past year to be shared with an out-of-network specialist; the clinic delays for several weeks, citing “system upgrades,” and then sends only a partial record without explanation.

From the patient’s perspective, access was clearly denied or significantly hindered. Under 42 USC 300jj-52 and 45 CFR 171.103, the clinic’s practices are likely to be viewed as interfering with access, exchange, or use of electronic health information.  These denials do not fit neatly into any Subpart B exception: there was no identified patient safety risk (preventing harm), no specific privacy or security justification, no documented infeasibility under 171.204, and no evidence that health IT performance measures required prolonged unavailability under 171.205. 

The patient files a complaint through an HHS information blocking portal. OIG reviews the complaint and the clinic’s documentation. They see no Denial Reason Matrix, no least-blocking analysis, and no consistent policy tying these decisions to 45 CFR 171.200 or any exception. The responses appear to be driven by convenience and revenue concerns, not by narrow application of recognized exceptions.

The consequences are painful. The EHR vendor faces scrutiny for its role in handling app connections. For the clinic, the issue is treated as potential information blocking by a provider, resulting in a referral for disincentives in Medicare quality programs and a requirement to update policies and retrain staff. The clinic also spends unplanned funds on external counsel to respond to the investigation and reputationally is viewed by patients as obstructive. 

After this experience, the clinic implements the survival guide controls. It adopts a Denial Reason Matrix with specific references to 171.201–171.206, builds a Request Resolution Worksheet that must be completed before any denial, and creates patient-friendly templates that explain when and why access might be limited under privacy or security exceptions. For future app requests, staff first determine whether any law prohibits the connection; if not, they either enable access or, in rare cases where security concerns are documented under 171.203, offer an alternative electronic method consistent with the manner and infeasibility exceptions. 

When another patient later complains about a delayed record transfer, the clinic can show the completed worksheet, the mapped exception (in that case, a short maintenance window under health IT performance 171.205), and the follow-up communication that fulfilled the request as soon as feasible. Investigators see a structured approach anchored in 45 CFR 171.200 instead of ad hoc obstruction, and the matter is closed after education rather than penalties.

This checklist is designed to keep your denial decisions aligned with 45 CFR 171.200 without overwhelming your team. Use it annually or semi-annually.

By treating this table as a recurring checkpoint, your clinic can quickly detect when denials drift away from recognized exceptions and pull them back into the legal safe harbor of 45 CFR 171.200.

Common Audit Pitfalls to Avoid Under 45 CFR 171.200

Auditors and investigators notice patterns. Certain denial habits almost always raise red flags because they sit outside the structure of 45 CFR 171.200 and its related exceptions.

• Denying access to electronic health information because of unpaid balances, which is neither required by law nor covered by any Subpart B exception, and therefore risks being treated as unreasonable information blocking under 42 USC 300jj-52.

• Relying on a vague “privacy concern” without performing the detailed analysis required by the privacy exception in 45 CFR 171.202, which expects specific sub-conditions (such as unsatisfied preconditions under HIPAA or individual preference) to be met and documented.

• Invoking “security” to justify denying a request without tying the measure to a defined security risk and ensuring it is narrowly tailored, as required by 45 CFR 171.203, which can make the practice look like a general barrier rather than a targeted protection.

• Claiming “system downtime” or “upgrades” for prolonged periods without meeting the conditions of the health IT performance exception in 45 CFR 171.205, including planning and limiting the duration of unavailability.

• Labeling a request as “infeasible” without analyzing uncontrollable events, segmentation limits, or other specifics listed in 45 CFR 171.204, and without timely written communication explaining why the request could not be met.

• Failing to distinguish between HIPAA-permitted denials and information blocking exceptions, leading staff to assume that a HIPAA denial automatically satisfies 45 CFR 171.200 even when the additional conditions of Subpart B are not met.

By replacing these pitfalls with structured denials that explicitly map to HIPAA, state law, or a specified exception, you reduce both the likelihood and the impact of an information blocking finding under 45 CFR 171.200 and related provisions.

The safest denial policies will fail if your culture encourages “no” as the default. To align daily behavior with 45 CFR 171.200, small practices need clear roles, simple training, and a few targeted metrics.

Start with ownership. Designate a single individual, often the practice administrator or privacy officer, as the “information blocking lead” responsible for maintaining the Denial Reason Matrix, overseeing worksheets, and reviewing denial patterns. Their role is not to approve every case, but to ensure that the tools and policies remain synchronized with ONC and OIG guidance. 

Next, build denial-specific content into regular training. New hires who handle records or patient communications should be introduced to the matrix and worksheet during onboarding. Each year, offer a brief refresher focused on real denials from your own clinic, asking staff to walk through which exception or law applied and why.

Monitoring can stay lightweight. A small set of indicators, such as the number of denials per 100 electronic requests, the distribution of denials by exception, and the count of complaints tied to access, will give leadership a quick sense of whether denials are exceptional or routine. Any drift toward frequent, pattern-based denials should trigger a closer look.

Finally, reinforce a “yes when possible, structured no when necessary” mindset. Leaders should model asking, “Which exception are we relying on, and do we meet all its conditions?” instead of “How do we avoid sharing this?” That shift aligns your culture with the expectation embedded in 45 CFR 171.200.

Information blocking rules changed the legal meaning of “no” in small practices. A denial that once felt like a harmless exercise of discretion can now be seen as an unreasonable interference with access to electronic health information unless it fits squarely within an exception recognized by 45 CFR 171.200 and its companion provisions in Part 171. 

For lean clinics, the key is not memorizing every clause but standardizing how denial decisions are made, documented, and reviewed. When each “no” is linked to “required by law,” a HIPAA access provision, or a clearly identified information blocking exception with supporting facts, your practice can defend its decisions without scrambling during an audit or investigation.

Three to five concrete steps can move your clinic toward that position:

• Draft and adopt a Denial Reason Matrix that ties each common denial scenario to a specific citation in 42 USC 300jj-52, 45 CFR 171.200–171.206, or HIPAA’s 45 CFR 164.524, and train staff to use it before they say no.

• Implement a simple Request Resolution Worksheet so that every denial or significant limitation documents why alternatives were not feasible and which exception, if any, is being used under 45 CFR 171.200.

• Update your access policy to integrate HIPAA and information blocking requirements, removing conflicting messages so staff follow a single pathway that recognizes both sets of rules.

• Establish a recurring mini-review of recent denials to spot patterns, correct misapplied exceptions, and refresh training with real clinic examples instead of abstract scenarios.

• Align your patient communication templates with these legal paths so that every denial explanation you send externally is grounded in the same reasoning you would show an auditor.

Recommended compliance tool: 

A combined HIPAA–Information Blocking access policy template that explicitly cross-references HIPAA denial grounds and each Subpart B exception.

Advice:

Pick three recent denials, run them through the Denial Reason Matrix, and if you cannot confidently link each to “required by law,” HIPAA, or a specific 45 CFR 171 exception, treat that as your starting point for policy and training updates.

• 45 CFR Part 171 – Information Blocking

• 45 CFR 171.200 – Availability and effect of exceptions 

• 45 CFR 171.201–171.206 – Subpart B Exceptions That Involve Not Fulfilling Requests to Access, Exchange, or Use Electronic Health Information 

• 45 CFR 171.300–171.303 – Subpart C Exceptions That Involve Procedures for Fulfilling Requests

• 42 USC 300jj-52 – Information blocking (U.S. Code)

• Information Blocking – Office of the National Coordinator for Health IT

• Information Blocking – HHS Office of Inspector General

• 45 CFR Parts 160 and 164 – HIPAA Privacy Rule