When Do Information Blocking Exceptions Actually Protect You?

Information blocking exceptions are narrow, voluntary safe harbors codified in 45 CFR Part 171 that protect specified practices from being treated as information blocking when every condition of the exception is met. There are nine of them: Preventing Harm, Privacy, Security, Infeasibility, Health IT Performance, Manner, Fees, Licensing, and the newly finalized Protecting Care Access exception. A TEFCA-specific version of the Manner exception rounds out the list for actors participating in the Trusted Exchange Framework and Common Agreement.

Three federal bodies govern this space. The Assistant Secretary for Technology Policy, formerly ONC and now operating as ASTP/ONC, writes and interprets the rules. The HHS Office of Inspector General enforces them against health IT developers, health information exchanges, and health information networks, with civil monetary penalties reaching up to a million dollars per violation. Health care providers face a separate enforcement track through disincentives tied to Medicare and Medicaid payment programs rather than direct OIG fines.

Here's what matters for compliance planning: meeting an exception isn't the only way to avoid liability, but it's the only way to get certainty. According to ONC's own guidance, a practice that fails to satisfy an exception isn't automatically information blocking. It just loses the safe harbor and gets evaluated case by case, which is a far riskier position than having a documented, exception-compliant policy.

The nine exceptions break into two functional groups:

• Not fulfilling requests: Preventing Harm, Privacy, Security, Infeasibility, Health IT Performance, and Protecting Care Access
• Procedures for fulfilling requests: Manner, Fees, and Licensing

Key Takeaways

Information blocking exceptions protect specific, well-documented practices under 45 CFR Part 171, and losing that protection almost always traces back to missing documentation rather than a bad legal position.

Table of Contents

• What Are the Information Blocking Exceptions, in Plain Terms?
• The Fine Print Behind Each Exception
• How to Evaluate a Request and Build a Defensible File
• Who Enforces These Rules, and What Triggers a Penalty?
• What the HTI-2 Final Rule Changed
• The Records Auditors Will Actually Ask For
• An Executive Checklist for Startups and Health IT Teams
• Where to Verify the Primary Sources
• Why Compliance Teams Keep Getting This Wrong
• Sources

What Are the Information Blocking Exceptions, in Plain Terms?

Each exception targets a specific operational reality, and knowing which one applies to your situation is the first step in building a defensible policy.

• Preventing Harm shields an actor who reasonably believes that sharing electronic health information would create a real risk to a patient or another person. Clinicians invoke this most often when releasing raw lab results before a physician can provide context.
• Privacy covers an actor who doesn't share information because doing so would violate state or federal privacy law, or because the individual asked that specific information not be shared. Health IT developers not covered by HIPAA rely on this exception frequently.
• Security protects reasonable, tailored practices that safeguard the confidentiality, integrity, and availability of electronic health information. IT security teams use it to justify access controls tied to documented risk assessments.
• Infeasibility applies when an actor genuinely cannot fulfill a request, often due to a natural disaster, a segmentation requirement, or a lack of technical capability. Smaller hospitals cite this when legacy systems can't isolate a specific data element.
• Health IT Performance allows temporary unavailability during scheduled maintenance or unplanned downtime needed to protect system performance. Health IT developers use this for patch deployments and infrastructure upgrades.
• Protecting Care Access is the newest addition, finalized under HTI-2, and covers information withheld to protect access to certain types of care where disclosure could expose a patient to legal or personal risk.
• Manner permits an actor to fulfill a request in an alternative manner when the requested manner isn't technically possible. TEFCA participants have a parallel version of this exception tailored to network exchange.
• Fees allows reasonable, cost-based fees for accessing, exchanging, or using electronic health information, provided the fee structure doesn't function as a barrier.
• Licensing permits an actor to license interoperability elements on reasonable and non-discriminatory terms, with defined negotiation timelines.

The Fine Print Behind Each Exception

Passing the "does this sound reasonable" test isn't enough. Each exception carries specific conditions, and 45 CFR Part 171 spells out exactly what an actor must prove. Compliance teams that skip the sub-conditions are the ones who end up explaining themselves to OIG investigators later.

1. Preventing Harm (171.201). The actor needs a reasonable belief, formed using either a case-by-case determination or a defined organizational policy, that disclosure would create substantial risk. A common mistake is applying this exception broadly to entire categories of information rather than the specific data element that poses risk. Document who made the call, what evidence supported the harm assessment, and whether the decision was contemporaneous with the request. According to deep knowledge on preventing harm determinations, individualized clinician judgment carries far more weight than a blanket policy applied after the fact.

2. Privacy (171.202). This exception has four sub-conditions, and mixing them up is the single most common Privacy exception error. The precondition requires that a law, and not the actor's own preference, actually restricts disclosure. The developer of health IT that is not a covered entity sub-exception lets non-HIPAA-covered developers decline sharing until they've implemented a documented privacy policy. The denial of an individual's right of access under HIPAA sub-exception mirrors existing HIPAA denial grounds. The fourth, an individual's request not to share their information, requires the actor to honor that specific request rather than withhold information broadly. Providers frequently confuse "we generally don't share this data type" with a documented, individual-specific request, and that distinction is exactly what an investigator will probe first.

3. Security (171.203). The practice must be directly related to safeguarding confidentiality, integrity, or availability, tailored to the specific risk, and consistently applied. A generic firewall policy invoked to deny one physician's records request rarely survives scrutiny. Security determinations should reference a documented risk analysis, ideally one consistent with a recognized security framework, and should specify who has authority to make security-based denials.

4. Infeasibility (171.204). Acceptable grounds include uncontrollable events like natural disasters, a lack of technological capability that segmentation can't fix, or a genuinely unreasonable resource burden given the requestor's specific situation. The critical procedural requirement: the actor must provide the requestor a written response within 10 business days explaining the reason infeasibility applies. Missing that window, or sending a vague form letter instead of a specific explanation, undermines the exception even when the underlying infeasibility claim was legitimate.

5. Health IT Performance (171.205). Downtime must be no longer than necessary, and unplanned downtime requires the actor to implement the unavailability in a consistent, non-discriminatory manner. Document maintenance windows in advance where possible and log the actual duration of unplanned outages.

6. Protecting Care Access. Finalized in the HTI-2 rule, this exception permits withholding information tied to specific categories of care where disclosure could expose a patient to civil or criminal liability, or personal harm, based on where the care was accessed or provided. Policies referencing reproductive health care or other legally sensitive care categories need updating to reflect this exception's precise scope rather than relying on the older Preventing Harm framework, which wasn't designed for this scenario.

7. Manner (171.301) and TEFCA Manner. An actor may fulfill a request in an alternative manner only after demonstrating the requested manner isn't feasible, and must offer at least one manner that's actually workable for the requestor. The TEFCA-specific version applies only when both the actor and requestor participate in TEFCA and the request wasn't already made through the standards specified in 45 CFR 170.215. Actors relying on TEFCA Manner should verify the requestor's TEFCA participation status before denying an alternative request, a step that gets skipped more often than it should.

8. Fees (171.302). Fees must be based on objective, verifiable costs and can't be structured to recoup costs already covered elsewhere or to discourage legitimate access. Fee schedules that vary unpredictably by requestor type are a frequent audit flag.

9. Licensing (171.303). An actor negotiating a license for interoperability elements must begin negotiation within 10 business days of receiving a request, and the license itself must be finalized within 30 business days of that initial response, unless the delay is due to the requestor's own actions. License terms must be reasonable, non-discriminatory, and free of exclusivity clauses that would block competing health IT products.

How to Evaluate a Request and Build a Defensible File

A repeatable workflow turns "we think we qualify for an exception" into "we can prove it." Build this into your intake process rather than reconstructing it after a complaint arrives.

1. Log the request. Record the requestor, the data requested, the date received, and the channel used.
2. Identify the applicable exception. Match the specific facts to one exception rather than a general sense that "this seems reasonable."
3. Test each condition against the facts. Walk through every sub-condition in order, not just the headline requirement.
4. Capture the decision-maker and rationale. Name the person or committee who approved the denial or delay, and record their reasoning in writing.
5. Note the alternative considered. Under Manner and Infeasibility especially, document why alternatives were rejected.
6. Timestamp every step. The 10-business-day infeasibility response and the 10/30-business-day licensing windows are hard deadlines, not guidelines.
7. Route to legal or executive review when stakes are high. Escalate any denial involving potential patient harm, a Protecting Care Access claim, or a repeat requestor.
8. Store the file with the original request. Keep evidence, correspondence, and the final written response together in one retrievable record.

Pro Tip: Build your exception decision log as a structured form, not a free-text email thread. When OIG or ASTP/ONC asks for evidence, a searchable record with consistent fields beats a folder of scattered correspondence every time.

Internal controls matter as much as the workflow itself. Periodic audits of denied or delayed requests, recurring staff training on the knowledge standard that applies to your actor type, and a named individual responsible for security-based determinations all reduce the odds that a single bad call becomes a pattern OIG investigates.

Who Enforces These Rules, and What Triggers a Penalty?

The HHS Office of Inspector General holds civil monetary penalty authority for health IT developers, health information exchanges, and health information networks, with penalties reaching up to a million dollars per violation. Health care providers face disincentives administered through CMS payment programs rather than direct OIG fines, though the underlying investigation process often starts the same way.

OIG doesn't investigate everything with equal urgency. Its stated enforcement priorities focus on:

• Practices that caused or could cause patient harm
• Practices that continued over a long duration
• Practices that led to financial loss to federal health care programs or other entities
• Actors who had actual knowledge their practice likely constituted information blocking

ASTP/ONC and OIG coordinate on investigations, with ASTP/ONC referring credible complaints and OIG typically requesting the exception decision log, the underlying request correspondence, and any policy documentation the actor relied on to justify the practice. The practical takeaway is straightforward: triage your own audits the same way OIG triages complaints, starting with anything touching patient safety or repeated denials to the same requestor.

What the HTI-2 Final Rule Changed

The HTI-2 final rule finalized the Protecting Care Access exception, revised elements of the Privacy and Infeasibility exceptions, and formalized the agency's rebrand from ONC to ASTP/ONC. For compliance teams, three practical updates follow:

• Update Preventing Harm and Privacy policy templates to reference Protecting Care Access where care-access risk, rather than direct clinical harm, is the actual concern.
• Revisit any policy language built around an individual's request not to share information to confirm it distinguishes that specific mechanic from a general privacy denial.
• Rename ONC references in internal policy documents to ASTP/ONC to keep citations accurate for future audits.

Watch ASTP/ONC's information blocking resource page for sub-regulatory guidance, since the agency has historically issued FAQs that clarify edge cases the rule text leaves ambiguous.

The Records Auditors Will Actually Ask For

Every exception file needs, at minimum, the requestor's identity, the date received, the exception invoked, the decision-maker's name, and the written rationale. Time-bound items need explicit timestamps: the 10-business-day infeasibility response, the 10-business-day licensing negotiation start, and the 30-business-day licensing completion window all need date-stamped proof, not an approximate recollection.

• Retain files for as long as your organization's general compliance retention policy requires, and treat exception logs as discoverable records from day one.
• Automate deadline tracking with calendar alerts tied to each request's intake date rather than relying on manual follow-up.
• Store correspondence, internal approvals, and the final written response together so an e-discovery request doesn't require reconstruction.

Pro Tip: Set your infeasibility and licensing deadlines as calendar triggers the moment a request is logged, not when someone remembers to check. A missed 10-business-day window turns a legitimate exception into a liability.

An Executive Checklist for Startups and Health IT Teams

Getting this right requires action at two levels: the board and the operations team.

1. Adopt a written information blocking policy that names each exception your organization is likely to invoke and assigns delegated decision authority for each one.
2. Set a reporting cadence so the board or executive team reviews exception invocations, denials, and any OIG inquiries at least quarterly.
3. Confirm security determinations trace back to a documented risk analysis, not an ad hoc IT judgment call.
4. Verify your platform supports segmentation and EHI export, since infeasibility claims collapse quickly if the real issue was a product gap rather than a genuine technical barrier.
5. Define sign-off roles explicitly, typically a compliance officer for routine denials and general counsel or the chief medical officer for anything touching Preventing Harm or Protecting Care Access.
6. Bring in outside advisory support before a gap becomes a pattern. Startups and health IT teams building this compliance infrastructure for the first time often lack an internal physician voice to validate Preventing Harm and Protecting Care Access judgment calls, which is precisely the gap a fractional Chief Medical Officer is built to close.

Pro Tip: A minimal exception template needs six fields: requestor, request date, exception invoked, decision-maker, rationale, and response date. Anything less leaves gaps an investigator will find.

Where to Verify the Primary Sources

For direct verification, consult 45 CFR Part 171 for the regulatory text, ASTP/ONC's exceptions fact sheet for plain-language summaries, OIG's enforcement page for penalty authority, and the HTI-2 final rule for the newest changes. Each is a primary federal source, not a secondary summary.

Why Compliance Teams Keep Getting This Wrong

The conventional advice on information blocking exceptions treats them like a checklist you complete once and file away. That's backward. The exceptions are a living decision framework, and the organizations that get burned by OIG enforcement are almost never the ones with a bad legal argument. They're the ones who had a reasonable Preventing Harm or Infeasibility claim and simply failed to document it in real time.

What gets underestimated most is the knowledge standard gap between actor types. Providers get more benefit of the doubt than health IT developers, but that benefit disappears the moment a pattern of undocumented denials emerges. If you're a healthcare SaaS company building export or segmentation features, the Infeasibility exception is not a shield for a product gap you haven't fixed yet.

Prioritize the decision log before the policy binder. A thin policy backed by consistent, timestamped records will outperform an elegant policy with no evidence behind it every single time OIG comes asking.

— Paul Bergeron MD, MBA

If your team is building or refining the clinical and compliance judgment behind these exception decisions, The StartupMD's advisory services provide the kind of fractional executive medical leadership that turns a reasonable legal position into a defensible operational one.

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

Sources

• PART 171—INFORMATION BLOCKING (govinfo)
• Information Blocking - Office of Inspector General (OIG)

Recommended

• What Is a Narrow Network: How It Works and Who It Fits
• Preventive Care Economics Explained for Founders
• Population Health Platform Features Checklist for Founders