Information Blocking Exceptions: All Ten, and How to Decide Which Applies

Information blocking is defined at 45 CFR 171.103 as “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.” The exceptions are therefore not loopholes bolted onto the rule — they are part of its definition. A practice covered by an exception is not information blocking that has been forgiven; it is not information blocking at all.

Almost every real question in this area is a judgement call about which exception applies and whether every one of its conditions is satisfied. This guide walks each exception in the regulation, with the conditions that actually have to be met.

The two thresholds before you reach an exception

Before asking which exception applies, two prior questions decide whether the rule engages at all.

Is it “required by law”?

The definition at 171.103(a) carves out practices “required by law” alongside the exceptions. A practice a statute or regulation compels is outside the definition and needs no exception. Note the word: required, not permitted. A practice that law merely allows still needs an exception.

Does the actor’s knowledge standard apply?

171.103(b) sets two different knowledge standards depending on who the actor is, and the difference is substantial:

• A health IT developer of certified health IT, a health information network or a health information exchange — the actor “knows, or should know, that such practice is likely to interfere.”
• A health care provider — the provider “knows that such practice is unreasonable and is likely to interfere.”

Providers therefore face both an actual-knowledge standard and an unreasonableness element that the other actor types do not. This is a meaningful difference and is frequently flattened in secondary summaries.

Subpart B — Exceptions that involve not fulfilling requests

Six exceptions. Under 171.200, a practice is not information blocking if the actor satisfies an exception “by meeting all applicable requirements and conditions of the exception at all relevant times.” Partial compliance is not partial protection.

1. Preventing Harm — 171.201

The most demanding exception structurally. The practice must meet the conditions in paragraphs (a) and (b), satisfy at least one condition from each of paragraphs (c), (d) and (f), and also meet paragraph (e) where applicable.

• (a) Reasonable belief — the actor must hold a reasonable belief that the practice “will substantially reduce a risk of harm” to a patient or another natural person that would otherwise arise from the access, exchange or use.
• (b) Practice breadth — the practice must be “no broader than necessary” to substantially reduce that risk.
• (c) Type of risk — the risk must either be determined on an individualised basis in the exercise of professional judgment by a licensed health care professional who has a current or prior clinician-patient relationship with the patient; or arise from data known or reasonably suspected to be misidentified or mismatched, corrupt due to technical failure, or otherwise erroneous.
• (d) Type of harm — the harm must be one that could ground a HIPAA covered entity’s denial of access under 45 CFR 164.524(a)(3), and the regulation maps four distinct sub-cases depending on who is being interfered with and whether the risk was individualised.
• (e) Right to review — where the risk was individualised under (c)(1), the practice must be implemented consistently with any right the patient has under 45 CFR 164.524(a)(4) or other federal, state or tribal law to have the determination reviewed and potentially reversed.
• (f) Policy or determination — the practice must follow a written organisational policy based on relevant clinical, technical and other appropriate expertise, implemented consistently and non-discriminatorily; or, absent an applicable policy, a documented case-specific determination based on facts known or reasonably believed at the time and on relevant expertise.

The judgement call: the (c)(1) pathway requires a licensed professional with a current or prior clinician-patient relationship. A committee, a compliance officer, or a clinician with no relationship to this patient cannot make that determination. The (c)(2) data-quality pathway has no such requirement, which is why a suspected identity mismatch is a much easier route to this exception than a clinical harm judgement.

2. Privacy — 171.202

Structured differently: the practice qualifies if it meets all requirements of at least one of four sub-exceptions. They are alternatives, so identify which one you are relying on before assessing conditions.

• (b) Precondition not satisfied — state or federal law requires one or more preconditions for the disclosure that have not been met. The practice must be tailored to the specific unmet precondition, implemented consistently and non-discriminatorily, and either conform to written organisational policies specifying the criteria for when the precondition is satisfied (and be implemented, including training) or be documented case-by-case identifying the criteria used, which were not met, and why. Where the precondition depends on a consent or authorisation and the one received is defective, the actor must use reasonable efforts within its control to supply a compliant form or otherwise assist, and must not improperly encourage or induce the individual to withhold it. Where the actor is subject to multiple laws with inconsistent preconditions, adopting uniform policies addressing the more restrictive preconditions is deemed to satisfy the requirement.
• (c) Health IT developer not covered by HIPAA — a developer of certified health IT not required to comply with the HIPAA Privacy Rule may act to promote an individual’s privacy interests, provided its organisational privacy policies were disclosed to users before they agreed to use the product, the practice follows a process described in those policies, and the policies comply with applicable law, are tailored to the specific privacy risk or interest, and are implemented consistently and non-discriminatorily.
• (d) Denial of an individual’s access request — where an individual requests their own EHI under the HIPAA right of access at 45 CFR 164.524(a)(1) from an actor required to comply with it, the practice must be consistent with 45 CFR 164.524(a)(2).
• (e) Individual’s request not to share EHI — the individual asked the actor not to share, without improper encouragement or inducement by the actor; the actor documents the request within a reasonable time; the practice is implemented consistently and non-discriminatorily. The actor may only terminate the restriction if the individual agrees or requests termination in writing, orally agrees with the agreement documented, or the actor informs the individual it is terminating — and that termination is not effective to the extent prohibited by law and applies only to EHI created or received after the individual is so informed.

The judgement call: the recurring trap is the “improper encouragement or inducement” condition in (b)(2)(ii) and (e)(1). An actor that presents the option not to share in a way designed to produce that answer has defeated its own exception. The Privacy exception protects genuine deference to a patient’s or a law’s constraint, not a workflow engineered to produce a refusal.

3. Security — 171.203

The practice must meet all of (a), (b) and (c), plus either (d) or (e):

• (a) directly related to safeguarding the confidentiality, integrity and availability of EHI;
• (b) tailored to the specific security risk being addressed;
• (c) implemented in a consistent and non-discriminatory manner;
• (d) if implementing an organisational security policy, that policy must be in writing; prepared on the basis of and directly responsive to security risks identified and assessed by or on behalf of the actor; align with one or more applicable consensus-based standards or best practice guidance; and provide objective timeframes and other parameters for identifying, responding to and addressing security incidents;
• (e) if not implementing such a policy, the actor must have determined in each case, on the particularised facts, that the practice is necessary to mitigate the security risk and that there are no reasonable and appropriate alternatives that address the risk and are less likely to interfere with access, exchange or use.

The judgement call: (d)(2) requires the policy to be responsive to risks the actor actually identified and assessed. A generic security policy not traceable to a real risk assessment does not carry the exception, and the ad-hoc route at (e) imposes a demanding no-less-restrictive-alternative test in every single instance. See also the guidance on HIPAA compliance tooling and on business associate agreements, both of which shape what an actor can defensibly claim here.

4. Infeasibility — 171.204

The actor must meet one of the five conditions in (a) and the response requirement in (b).

• (a)(1) Uncontrollable events — a natural or human-made disaster, public health emergency, public safety incident, war, terrorist attack, civil insurrection, strike or other labour unrest, telecommunication or internet service interruption, or act of military, civil or regulatory authority “that in fact negatively impacts the actor’s ability to fulfill the request.”
• (a)(2) Segmentation — the actor cannot unambiguously segment the requested EHI from EHI that is not permitted by law to be made available, or that may be withheld under 171.201, 171.202 or 171.206.
• (a)(3) Third party seeking modification use — the request is to enable use of EHI in order to modify EHI, provided the request is not from a health care provider requesting such use from an actor that is its business associate.
• (a)(4) Manner exception exhausted — all of the following are true and the actor complied with (a)(4)(iv): the actor could not reach agreement under 171.301(a) or was technically unable to fulfil the request in the manner requested; the actor offered at least two alternative manners under 171.301(b), one of which must use either technology certified to standards adopted in part 170 or published content and transport standards; and the actor does not provide the same access to a substantial number of similarly situated individuals or entities. In determining who is similarly situated, the actor shall not discriminate based on whether the requestor is an individual, on health care provider type and size, or on whether the requestor is a competitor or the access would facilitate competition.
• (a)(5) Infeasible under the circumstances — the actor demonstrates, prior to responding and through a contemporaneous written record or other documentation, its consistent and non-discriminatory consideration of six named factors: the type of EHI and the purposes for which it may be needed; the cost of complying in the manner requested; the actor’s financial and technical resources; whether the practice is non-discriminatory and the actor provides the same access to its own companies, customers, suppliers, partners and business relations; whether the actor owns or controls a predominant technology, platform, health information exchange or network through which EHI is accessed; and why the actor could not comply consistently with 171.301. In making that determination it shall not be considered whether the manner requested would have facilitated competition with the actor or prevented or reduced a fee.

(b) Responding to requests — in every one of those cases, the actor must, within ten business days of receipt of the request, provide the requestor in writing with the reason or reasons the request is infeasible.

The judgement call: the ten-business-day written response is the most commonly missed element in the entire Part. An actor with a genuinely infeasible request that simply does not respond loses the exception on a procedural failure. Note also that (a)(5) requires the documentation to exist before the response — reconstructing the analysis afterwards does not satisfy it.

5. Health IT Performance — 171.205

The practice must meet whichever of (a) to (d) applies:

• (a) Maintenance and improvements — health IT made temporarily unavailable or degraded to perform maintenance or improvements. Must be for no longer than necessary, implemented consistently and non-discriminatorily, and where initiated by a developer, HIE or HIN, must be consistent with existing service level agreements (planned), or consistent with an SLA or agreed with the customer (unplanned).
• (b) Assured level of performance — the actor may act against a third-party application negatively impacting the health IT’s performance, for no longer than necessary to resolve the negative impacts, consistently and non-discriminatorily, and consistent with existing SLAs where applicable.
• (c) Practices that prevent harm — where unavailability is initiated in response to a risk of harm, the actor need not satisfy this section but must comply with all requirements of 171.201 at all relevant times.
• (d) Security-related practices — where unavailability is initiated in response to a security risk, the actor need not satisfy this section but must comply with all requirements of 171.203 at all relevant times.

The judgement call: (c) and (d) are routing rules, not softer alternatives. Taking a system down for a harm or security reason moves you to the full Preventing Harm or Security exception, both of which are harder to satisfy than the maintenance conditions in (a).

6. Protecting Care Access — 171.206

Added December 2024. It covers practices implemented to reduce potential exposure to legal action arising from reproductive health care. The practice must satisfy the threshold condition in (a) and at least one of (b) or (c).

• (a) Threshold condition — three requirements plus a reliance rule:
  • Belief — a good faith belief that persons seeking, obtaining, providing or facilitating reproductive health care are at risk of potential exposure to legal action arising from particular access, exchange or use of specific EHI, and that specific interfering practices could reduce that risk.
  • Tailoring — no broader than necessary to reduce that risk.
  • Implementation — consistent with a written organisational policy based on relevant clinical, technical and other appropriate expertise that identifies the connection between the interference and the risk reduction and is implemented consistently and non-discriminatorily; or a case-by-case determination made in the absence of an applicable policy, based on facts known or believed in good faith, and documented either before or contemporaneous with engaging in the practice.
  • Reliance — an actor that is a business associate of, or otherwise maintains EHI on behalf of, another actor may rely on that other actor’s good faith belief and policy or determinations.
• (b) Patient protection condition — where the purpose is reducing the patient’s own risk, the practice must affect only EHI the actor in good faith believes could expose the patient to legal action because it shows, or carries a substantial risk of supporting a reasonable inference, that the patient obtained reproductive health care, inquired about or expressed interest in seeking it, or has any health condition or history for which reproductive health care is often sought, obtained or medically indicated. The practice must be subject to nullification by an explicit request or directive from the patient that the information be shared despite the identified risk.
• (c) Care access condition — where the purpose is reducing the risk to licensed health care professionals, other providers or other persons involved in providing or facilitating reproductive health care lawful under the circumstances in which it is provided, the practice must affect only EHI the actor believes could expose them to legal action because it shows, or carries a substantial risk of supporting a reasonable inference, that they provide or facilitate, or have provided or facilitated, reproductive health care.
• (d) Presumption — for (b)(1)(i) and (c), care provided by someone other than the actor is presumed lawful unless the actor has actual knowledge that it was not lawful under the circumstances in which it was provided.
• (e) Definition — “legal action” means a criminal, civil or administrative investigation into any person for the mere act of seeking, obtaining, providing or facilitating reproductive health care; a civil or criminal court action to impose liability for that mere act; or an administrative action or proceeding against any person for that mere act.

The judgement call: the patient-nullification requirement in (b)(2) is what distinguishes this exception from a paternalistic withholding. The protection exists for the patient’s benefit and the patient can switch it off. Note also that the presumption of lawfulness in (d) puts the burden the right way round: the actor does not have to establish that care elsewhere was lawful, only to act on actual knowledge that it was not.

Subpart C — Exceptions that involve procedures for fulfilling requests

These three apply where the actor is fulfilling the request but on limited terms. Same all-conditions-at-all-relevant-times rule, at 171.300.

7. Manner — 171.301

The baseline at (a)(1) is strong: “An actor must fulfill a request for electronic health information in any manner requested, unless the actor is technically unable to fulfill the request or cannot reach agreeable terms with the requestor.”

If the actor does fulfil in the manner requested, (a)(2) grants a significant benefit: any fees charged are not required to satisfy the Fees exception, and any licence of interoperability elements granted is not required to satisfy the Licensing exception.

If it cannot — technically unable, or no agreeable terms — the actor must fulfil in an alternative manner, without unnecessary delay, in a strict order of priority, only proceeding to the next step if technically unable to fulfil at the previous one:

1. using technology certified to standards adopted in part 170 that is specified by the requestor;
2. using content and transport standards specified by the requestor and published by the federal government or by an ANSI-accredited standards developing organisation;
3. using an alternative machine-readable format, including the means to interpret the EHI, agreed with the requestor.

On the alternative-manner path, fees must satisfy 171.302 and licences must satisfy 171.303.

The judgement call: “cannot reach agreeable terms” is not the same as “did not like the terms offered”. An actor that declines the requested manner has stepped onto a path with a mandatory ordering and mandatory fee and licensing discipline — and if it cannot complete that path either, it must have offered at least two alternative manners before it can reach the Infeasibility exception at 171.204(a)(4).

8. Fees — 171.302

Fees, “including fees that result in a reasonable profit margin”, are permitted where the practice meets the basis-for-fees condition in (a), does not include any excluded fee in (b), and where applicable meets (c).

(a) Fees must be: based on objective and verifiable criteria uniformly applied for all similarly situated classes of persons, entities and requests; reasonably related to the actor’s costs of providing that type of access, exchange or use to the person charged; reasonably allocated among all similarly situated persons or entities supplied or supported; and based on costs not otherwise recovered for the same instance of service to a provider and third party.

Fees must not be based on: whether the requestor is a competitor or potential competitor or will use the EHI in a way facilitating competition; sales, profit, revenue or other value the requestor derives; costs incurred because the health IT was designed or implemented in a non-standard way, unless the requestor agreed to that fee; costs associated with intangible assets other than actual development or acquisition costs; opportunity costs unrelated to the access, exchange or use; or any costs that led to the creation of intellectual property where the actor charged a royalty for that IP under 171.303 that included those development costs.

(b) Excluded fees — the exception does not apply at all to:

1. a fee prohibited by 45 CFR 164.524(c)(4);
2. a fee based in any part on the electronic access of an individual’s EHI by the individual, their personal representative, or another person or entity designated by the individual;
3. a fee to perform an export of EHI via the capability of health IT certified to 45 CFR 170.315(b)(10) for the purposes of switching health IT or providing patients their EHI;
4. a fee to export or convert data from an EHR technology that was not agreed to in writing at the time the technology was acquired.

“Electronic access” is defined in this section as “an internet-based method that makes electronic health information available at the time the electronic health information is requested and where no manual effort is required to fulfill the request.”

(c) A health IT developer subject to the Conditions of Certification in 45 CFR 170.402(a)(4) or 170.404 must comply with all requirements of those conditions for all practices at all relevant times, notwithstanding anything else in the exception.

The judgement call: the (b)(4) exclusion is a trap for the whole industry. A fee to export or convert data from an EHR that was not agreed in writing at the time the technology was acquired is excluded from the exception entirely — not merely subject to the cost-basis test. Exit and conversion pricing therefore has to be settled in the original contract, not at the point of departure.

9. Licensing — 171.303

Where an actor licenses interoperability elements so EHI can be accessed, exchanged or used, the practice must meet all conditions of the section, beginning with two hard clocks in (a): the actor must begin licence negotiations within 10 business days of receiving the request, and must negotiate a licence within 30 business days of receiving it, subject to the licensing conditions in (b). The licensing conditions constrain the terms themselves — including, at (b)(iv), that an actor may not charge a royalty for intellectual property if it recovered any of the development costs that led to that IP under the Fees exception.

The judgement call: the two deadlines run from receipt of the request, not from when the actor decides the request is serious. Routing licence requests through a sales-qualification process that consumes the first ten business days forfeits the exception before negotiations begin.

Subpart D — TEFCA

10. TEFCA Manner — 171.403

An actor’s practice of limiting the manner in which it fulfils a request to only via TEFCA is not information blocking where all four conditions hold:

• (a) Mutually part of TEFCA — the actor and the requestor are both part of TEFCA;
• (b) Requestor capability — the requestor is capable of that access, exchange or use from the actor via TEFCA;
• (c) Limitation — the request is not via the standards adopted in 45 CFR 170.215, including versions approved under 45 CFR 170.405(b)(8);
• (d) Fees and licensing — any fees must satisfy 171.302 and any licence of interoperability elements must satisfy 171.303.

The judgement call: condition (c) is the limit that matters. Where the requestor asks via the adopted API standards at 170.215, an actor cannot insist on TEFCA instead. This exception permits TEFCA-only fulfilment for other exchange modalities; it does not permit an actor to route standards-based API requests into TEFCA. For how TEFCA participation itself works, see the guide to TEFCA and QHIN participation. Subpart D also imports its definitions of Common Agreement, Framework Agreement, Participant, QHIN and Subparticipant from 45 CFR 172.102.

Consequences: disincentives for health care providers

Subpart J sets out disincentives an appropriate agency may impose on a health care provider that OIG determines has committed information blocking. Under 171.1001(a), CMS may apply:

1. an eligible hospital or critical access hospital (as defined at 42 CFR 495.4) is not a meaningful electronic health record user as defined in that section;
2. a MIPS eligible clinician (as defined at 42 CFR 414.1305) who is also a health care provider under 171.102 is not a meaningful EHR user for MIPS;
3. accountable care organisations that are health care providers, ACO participants and ACO providers/suppliers will be removed from, or denied approval to participate in, the Medicare Shared Savings Program for at least 1 year.

Under 171.1002, following an OIG referral the agency imposing a disincentive must send the provider a notice describing the practice that formed the basis of the determination, the basis for applying the disincentive, the effect of each disincentive, and any other information necessary to understand how it will be implemented. Subpart K separately provides for public posting of information about actors found to have committed information blocking.

A working decision sequence

1. Is the practice required by law? If a statute or regulation compels it, the definition does not reach it. “Permitted” is not “required”.
2. Are you an actor, and which knowledge standard applies? Providers are judged on actual knowledge that the practice is unreasonable and likely to interfere; developers, HINs and HIEs on knows-or-should-know.
3. Are you refusing to fulfil, or fulfilling on limited terms? Refusals go to Subpart B; limits on manner, fees or licensing go to Subpart C; TEFCA-only fulfilment goes to Subpart D. Choosing the wrong subpart is the most common analytical error.
4. Identify the specific exception and the specific paragraph. Several exceptions are alternatives-based (Privacy, Infeasibility), so name which sub-condition you rely on.
5. Check every condition, including the procedural ones. The ten-business-day infeasibility response, the ten- and thirty-business-day licensing clocks, the pre-response documentation requirement at 171.204(a)(5), the contemporaneous documentation requirement at 171.206(a)(3)(ii)(D).
6. Check the consistency and non-discrimination conditions. They appear in almost every exception and are assessed against your practice across requestors, not against this one request.
7. Document at the time. Several exceptions require documentation made before or contemporaneously with the practice. Documentation created after a complaint does not retrofit an exception.

Frequently asked questions

How many information blocking exceptions are there?

Ten in the current 45 CFR Part 171: Preventing Harm, Privacy, Security, Infeasibility, Health IT Performance and Protecting Care Access in Subpart B; Manner, Fees and Licensing in Subpart C; and TEFCA Manner in Subpart D. The frequently cited figure of eight reflects the original 2020 rule and predates the TEFCA Manner exception (January 2024) and the Protecting Care Access exception (December 2024).

What is the definition of information blocking?

Under 45 CFR 171.103, a practice that — except as required by law or covered by an exception in subparts B, C or D — is likely to interfere with access, exchange or use of electronic health information, where a developer of certified health IT, health information network or health information exchange knows or should know it is likely to interfere, or a health care provider knows the practice is unreasonable and is likely to interfere.

Do I have to meet all the conditions of an exception?

Yes, and at all relevant times — 171.200, 171.300 and 171.400 each say so. Some exceptions are internally structured as alternatives (the Privacy exception’s four sub-exceptions, the Infeasibility exception’s five conditions), in which case you must satisfy every requirement of the one you are relying on.

How long do I have to respond to an infeasible request?

Ten business days from receipt, in writing, giving the reasons the request is infeasible — 45 CFR 171.204(b). This applies to every one of the five infeasibility conditions, and missing it forfeits the exception even where the request genuinely was infeasible.

Can I charge a patient for electronic access to their own record?

No. The Fees exception does not apply to a fee based in any part on the electronic access of an individual’s EHI by the individual, their personal representative, or another person or entity designated by the individual — 45 CFR 171.302(b)(2). Nor does it apply to a fee prohibited by 45 CFR 164.524(c)(4).

Can I charge to export data when a customer switches vendors?

Not under the Fees exception if it was not agreed in writing at acquisition. 171.302(b)(3) excludes a fee to perform an export via health IT certified to 170.315(b)(10) for purposes of switching health IT or providing patients their EHI, and 171.302(b)(4) excludes a fee to export or convert data from EHR technology that was not agreed to in writing at the time the technology was acquired.

Who can make a preventing-harm determination?

Where the exception is relied on via an individualised risk determination, it must be made in the exercise of professional judgment by a licensed health care professional who has a current or prior clinician-patient relationship with the patient — 171.201(c)(1). The alternative pathway at (c)(2), for data known or reasonably suspected to be misidentified, mismatched, corrupt or otherwise erroneous, carries no such requirement.

Does the Protecting Care Access exception let me withhold information the patient wants shared?

No. Where the exception is used for the patient’s own protection, 171.206(b)(2) requires the practice to be subject to nullification by an explicit request or directive from the patient that the access, exchange or use occur despite the identified risk.

Can I insist that requestors use TEFCA?

Only within limits. Under 171.403 both parties must be part of TEFCA, the requestor must be capable of the exchange via TEFCA, and the request must not be via the standards adopted at 45 CFR 170.215 — so a standards-based API request cannot be redirected into TEFCA. Fees and licensing must still satisfy 171.302 and 171.303.

What happens to a provider found to have committed information blocking?

Under Subpart J, CMS may determine that an eligible hospital or CAH is not a meaningful EHR user, that a MIPS eligible clinician is not a meaningful EHR user for MIPS, or that ACOs, ACO participants and ACO providers/suppliers are removed from or denied approval to participate in the Medicare Shared Savings Program for at least one year. The provider receives a notice describing the practice, the basis, and the effect of each disincentive.

Is a security practice automatically excepted?

No. The Security exception requires the practice to be directly related to safeguarding confidentiality, integrity and availability; tailored to the specific risk; implemented consistently and non-discriminatorily; and either implementing a written policy that is responsive to risks the actor actually identified and assessed and aligns with consensus-based standards or best practice guidance, or supported by a case-specific determination that no reasonable and appropriate less-interfering alternative exists.

Related reading

• TEFCA and QHIN Participation: Designation, Exchange Purposes, and How to Join
• HIPAA compliance software for clinical research units and academic medical centres
• Business associate agreements for research vendors
• Using AI With PHI in Research: HIPAA Rules and the BAA Question
• De-Identified vs. Coded vs. Anonymized vs. Pseudonymized Data
• Research Data Management