Information Blocking and Its Exceptions: Sharing as the Regulatory Default

Most health privacy education focuses on when information may be disclosed, when it must be withheld, and how unauthorized disclosure can be avoided. The federal information-blocking framework adds a different question: whether a regulated actor has knowingly engaged in an unreasonable practice likely to interfere with the access, exchange, or use of electronic health information. The rule makes sharing EHI the expected regulatory norm, but it does not establish that every delay or refusal is unlawful.

A patient asks a practice for their records through an app. The practice declines — not maliciously, but because the request looks unfamiliar, the app is unknown, the staff member is uncertain about privacy, and saying no is the conservative option. Every instinct in that sequence was trained by two decades of privacy compliance, and every one of them now points the wrong way.

The 21st Century Cures Act (congress.gov), enacted in 2016, made sharing electronic health information the expected norm in health care and authorized the Secretary of Health and Human Services to identify reasonable and necessary activities that do not constitute information blocking. Those activities — the exceptions — are set out in 45 CFR Part 171 (ecfr.gov). The structural consequence is that withholding is the practice requiring justification.

This article works through the rule as it actually operates: who is bound, what the prohibited practice is, what the ten exceptions do and do not accomplish, how enforcement differs by actor type, and where the rule is currently unsettled. It is written for physicians and administrators who have to make these decisions in real time, and for journalists who need to understand why "we were protecting privacy" is not automatically an answer.

The inversion, stated precisely

Understand the rule as a shift in the burden of explanation rather than as a new list of duties.

Privacy law as physicians learned it is permissive in structure. It identifies circumstances in which disclosure is allowed, and the safe posture in an ambiguous case is to decline, because an unauthorized disclosure carries consequences and a refusal generally does not. Decades of training built an institutional reflex around that asymmetry.

The information blocking rule reverses the asymmetry for electronic health information. Under 45 C.F.R. § 171.103, information blocking is a practice by a regulated actor that is likely to interfere with the access, exchange, or use of electronic health information, unless the practice is required by law or satisfies an applicable exception. Critically, the statute also requires a knowledge element that varies by actor: a health IT developer, HIN, or HIE must know, or should know, that the practice is likely to interfere; a health care provider must know that the practice is unreasonable and likely to interfere. That provider-specific "unreasonable" standard matters in practice — a mistaken front-desk response is not automatically information blocking merely because it delayed access. As commentary, it is fair to say the refusal is now the act that needs an account; as law, that account also has to satisfy the applicable knowledge standard.

Read that definition closely, because each element is doing work. "Likely to interfere" does not require proof that anyone was actually denied anything; a practice with that tendency is within scope. "Access, exchange, or use" is a triad, not a synonym — a practice that permits access while frustrating use is still in scope. And "practice" reaches informal, undocumented conduct: how a front desk answers a request is a practice.

The further consequence is cultural rather than legal. Institutions have well-developed machinery for approving disclosures and almost none for reviewing refusals. Refusals are distributed across staff, made quickly, rarely written down, and never audited. Under a rule that puts refusals in issue, the absence of that machinery is the compliance gap — and it is invisible on any conventional privacy audit.

Who counts as an actor

The rule does not bind everyone who touches health data. It binds defined categories, and the boundaries matter because they determine which enforcement regime applies.

The Cures Act applied the law to health care providers, health IT developers of certified health IT, and health information exchanges and health information networks. Regulatory definitions for those terms, including "health information network or health information exchange" and "health IT developer of certified health IT," were established at 45 CFR 171.102.

The categories overlap, and the overlap is deliberate. Federal rulemaking preamble text makes clear that an individual or entity could meet both the definition of a health care provider and the definition of a health IT developer of certified health IT, or both the definition of a health care provider and that of a health information exchange or network. A health system that has built its own exchange infrastructure, or that distributes software to affiliated practices, may occupy more than one category at once.

That is not an academic point, because — as the next sections set out — the consequence of a determination differs sharply by category. An entity that is a provider for one purpose and a network for another faces different exposure depending on which hat the practice was worn under. Organizations that have never asked which categories they occupy have not completed the first step of the analysis.

The practical instruction is unglamorous: establish your category or categories in writing, and revisit the answer when you deploy an app, stand up an exchange, or begin supplying software beyond your own walls.

The ten exceptions, and what kind of thing they are

On behalf of HHS, the Assistant Secretary for Technology Policy has defined ten exceptions, which give actors — providers, developers, networks, and exchanges — certainty that where their practices with respect to accessing, exchanging, or using electronic health information meet the conditions of one or more exceptions, those practices will not be considered information blocking. The full text is in 45 CFR Part 171 (ecfr.gov), and the federal exceptions fact sheet (healthit.gov) summarizes them.

Two characteristics of the exceptions are more important than their content, and both are routinely misread.

First, they are conditional. Each exception applies where certain conditions are met. The preventing harm exception provides that it will not be information blocking for an actor to engage in practices reasonable and necessary to prevent harm to a patient or another person, provided certain conditions are met. The privacy exception provides that it is not information blocking for an actor to decline to fulfil a request in order to protect an individual’s privacy, again provided conditions are met. The conditions are the exception. Invoking the label without satisfying them accomplishes nothing.

Second, and more surprising to most practitioners: the exceptions are voluntary. Federal guidance is explicit that they offer actors certainty, and — importantly — that even where a practice does not meet any exception, it does not automatically mean information blocking has occurred. Such practices are evaluated case by case.

That second point cuts both ways, and honest advice acknowledges both edges. It means a practice outside the exceptions is not automatically a violation. It also means an actor operating outside the exceptions has surrendered the certainty the exceptions exist to provide, and has accepted a case-by-case evaluation conducted by someone else, later, on a record the actor did not build for that purpose.

The preventing-harm exception, and why it is over-invoked

The preventing harm exception, at 45 CFR 171.201, is the one clinicians reach for most, and the one most often misapplied. It is worth understanding why the mismatch is so reliable.

The exception addresses practices reasonable and necessary to prevent harm to a patient or another person, subject to conditions. The clinical instinct it appears to license is familiar and sincere: a result should not reach a patient before a clinician can contextualize it, because an uncontextualized abnormal result causes distress and distress is harm.

That reasoning does not map onto the exception as written. The exception is built around conditions concerning the nature of the risk, the basis on which it is determined, and the practice’s tailoring to it — not around a general clinical preference for sequencing disclosure after interpretation. A blanket delay applied to a category of results, adopted because the practice considers it better care, is a policy rather than an individualized harm determination, and policies of that shape are the paradigm case of what the rule was enacted to reach.

The operational failure is documentary. Even where a genuine individualized harm determination exists, practices generally do not record it in a form that could later support the exception: what risk was identified, on what basis, why the specific practice was reasonable and necessary, and why a narrower measure would not do. Commentary aimed at smaller practices makes the point that clinics misusing these exceptions, even with good intentions, risk referral and federal consequences.

The instruction follows directly. If you rely on preventing harm, you are making an individualized determination and you must write it down at the time. A category-wide delay is not this exception, however defensible it feels clinically.

One category boundary is worth resolving early because it recurs. Where a health system operates its own exchange infrastructure, the analysis of what that infrastructure may and may not do sits alongside the questions examined in payer-to-payer data exchange (Payer-to-Payer Data Exchange) and provider access APIs (Provider Access APIs) — different rules, overlapping plumbing, and a single set of engineering decisions answerable to both.

The privacy exception, and the HIPAA confusion beneath it

The second most-invoked exception is the privacy exception, and the reason it is misapplied is a widespread misunderstanding of what HIPAA requires.

The exception provides that it is not information blocking for an actor to decline to fulfil a request in order to protect an individual's privacy, provided certain conditions are met — with the conditions, as always, doing the work. The federal exceptions fact sheet (healthit.gov) sets out what each requires.

The confusion is structural. Two decades of training taught staff that HIPAA is a restriction on disclosure, and the safe answer to an unfamiliar request is no. But HIPAA is largely permissive rather than prohibitive: it identifies disclosures that are permitted, and a patient's own request for their own information sits at the centre of what it contemplates. A refusal is not the HIPAA-compliant option — it is a choice requiring its own justification.

The app scenario is where this does most damage. A patient directs that their information be sent to a third-party application. Staff, unfamiliar with the app and uncertain about its security, decline out of caution. The reasoning conflates two distinct questions: whether the disclosure is permitted, and whether the recipient is one the practice would have chosen. The second question is generally not the practice's to answer where the patient has directed the disclosure.

There is a legitimate core to the concern, and honest guidance acknowledges it. Some requests genuinely raise privacy issues — where a third party's information is entangled in the record, or where the identity or authority of the requester is uncertain. Those situations are what the exception exists for, and its conditions are satisfiable.

The operational instruction is to separate the questions explicitly. Is this disclosure permitted? Is there a specific, articulable privacy interest, and does it satisfy the exception's conditions? Have I recorded that determination? A refusal grounded in general unease about an unfamiliar app answers none of the three and is the paradigm case the rule was enacted to address.

What a defensible refusal record contains

The conditions established by the regulation constitute each exception; documentation is the evidence used to demonstrate those conditions were satisfied, not a separate legal element in itself. Because the exceptions are conditional, contemporaneous documentation may be critical evidence that their conditions were satisfied — an actor who satisfied every substantive condition but documented none of it is in a materially worse position than one who documented a weaker case, because the assessment happens later, by someone else, from paper.

A usable record has several components worth building as a matter of practice, not because every item is an express universal requirement of every exception.

The request, as received. What was asked for, by whom, on what date, through what channel, and in what form.

The decision and the decider. Who declined, and under what authority. Record who made the decision and whether the person acted under an established policy, delegated authority, training, or an ad hoc judgment — those facts may affect whether the conduct is attributable to an organizational practice and whether the applicable knowledge standard is met; a single unauthorized mistake by staff does not automatically establish that the provider knowingly engaged in unreasonable interference, though repeated or tolerated conduct can.

The potentially applicable exception, identified at the time whenever reasonably possible, so its particular conditions can be evaluated rather than reconstructed later — Part 171 does not universally require stating the regulatory name contemporaneously, but doing so is very good practice.

The conditions, addressed individually. If the preventing harm exception is invoked, the record needs the risk identified, the basis for identifying it, and why the specific practice adopted was reasonable and necessary. If privacy is invoked, the record needs the privacy interest and the basis for concluding the exception's conditions applied.

Where the particular exception requires reasonableness, necessity, tailoring, or consideration of alternatives — not every exception turns on this; Fees, Licensing, and the TEFCA Manner exception operate through different criteria — document why a less restrictive measure would not adequately address the identified problem.

Enforcement, part one: penalties for developers and networks

The enforcement architecture splits by actor type, and the split is the single most important structural fact for anyone assessing exposure.

For health IT developers of certified health IT, health information exchanges, and health information networks, the HHS Office of Inspector General (official source) administers a civil money penalty regime, with an inflation-adjusted civil money penalty of up to $1,327,209 per violation under the 2026 adjustment (the underlying regulation states an original $1 million figure; the maximum is adjusted periodically), implemented under 42 CFR Part 1003 (official source).

The per-violation framing is what makes the number consequential. A single policy applied across an installed base or a network’s participants is not naturally one violation, and an organization reasoning from the ceiling as though it were a cap on total exposure has misread the structure.

There is a second-order effect that providers should understand even though the penalty does not reach them. Developers and networks facing seven-figure per-violation exposure will design their products and participation agreements to protect themselves. That shows up in contractual terms, default configurations, and constraints on what a provider customer may switch off. Providers frequently experience these as vendor inflexibility; they are the downstream shape of the vendor’s own liability.

Where an entity occupies more than one category — the overlap discussed above — the question of which regime applies to a given practice is genuinely contestable, and it is contested on a record built long before anyone asks.

There is a broader point buried in the publication mechanism, and it generalizes well beyond this rule. A system’s capacity to see its own failures is infrastructure, and infrastructure has to be built before anything can be counted — which means the first effect of building it is that recorded failure rises. That dynamic, and the perverse incentive it creates for anyone whose performance is judged on the numbers, is examined in low-resource safety systems (Low-Resource Safety Systems: What the Global Action Plan Asks of Countries That Cannot Buy Their Way to Safety).

The infeasibility and manner exceptions, and why they are contested

Two exceptions govern the practical texture of most disputes, and both were put in play by deregulatory rulemaking — which makes them the ones to verify before relying on.

The infeasibility exception addresses situations where fulfilling a request is genuinely not feasible, subject to conditions. It exists because a rule requiring the impossible would be unworkable: legacy systems that cannot export, requests for data in forms that do not exist, technical states that genuinely cannot be met.

The manner exception addresses how information is provided rather than whether. An actor unable to fulfil a request in the manner requested may, subject to conditions, fulfil it in an alternative manner.

The manner exception is where most real friction lives, because it is the boundary between compliance and evasion. Providing information in a technically responsive but practically useless form — a scanned image of a document rather than structured data, a portal view with no export — satisfies access while frustrating use. The rule's definition covers access, exchange, and use as three separable things precisely so that this manoeuvre remains in scope.

What makes both exceptions difficult in practice is that they turn on technical judgments the requester cannot audit. An organization asserting infeasibility is asserting something about its own systems, and a patient or a competing vendor has no way to test it.

And both were the subject of proposed revision, along with the access and use definitions and the TEFCA-related provisions in subpart D. Anyone advising on either should confirm the current codified text in Part 171 (official source) and read the current exceptions fact sheet (official source) rather than working from commentary, including this article. The general point stands regardless of how the rulemaking resolves: an exception that depends on an unauditable technical claim will be over-invoked, and the corrective is documentation the actor creates at the time.

What a regulator will ask for

Organizations prepare for this rule by writing policies. A regulator assessing a complaint asks for something different, and knowing what is worth more than any policy document.

The request itself, as received. Date, channel, requester, and what was asked for. An organization that cannot produce this has already lost the ability to explain what happened.

What was done, by whom, and when. The decision and the decider, with authority established. A refusal made by someone without delegated authority is not a considered institutional practice.

The exception relied on, named at the time. Not reconstructed — named. As set out above, the exceptions are conditional, and the conditions must be shown to have been considered.

Evidence addressing each condition. For preventing harm, the risk identified and its basis. For privacy, the interest and the basis for concluding conditions applied. For infeasibility, the technical account. Reconstruction here is visibly reconstruction.

Why a narrower measure was insufficient, because necessity is comparative.

And the pattern. A single refusal is an incident; a category of refusals is a practice. Where a policy produced repeated refusals, the policy is the subject of the inquiry rather than any individual decision — which is why blanket delays are structurally more dangerous than individual determinations, however well-intentioned.

The asymmetry to keep in view is that enforcement consequences differ sharply by actor type. Developers and networks face civil money penalties administered by the OIG (official source) under 42 CFR Part 1003 (official source); providers face the disincentives framework. An organization occupying both categories should know which hat each practice was worn under, because that determination will be made from this record and not from its policy manual.

Enforcement, part two: disincentives for providers

Health care providers sit under a different regime, and the difference is a matter of design rather than leniency — and not every provider is presently exposed to the same disincentive.

Providers do not face the OIG civil money penalty framework applicable to developers, HINs, and HIEs. Instead, OIG refers a provider determination to the appropriate federal agency, which may apply a disincentive established under an applicable federal program, as the Secretary sets forth through notice and comment rulemaking — the disincentives provision of PHSA section 3022(b)(2)(B). The implementing rule was published in the July 2024 Federal Register final rule (federalregister.gov), with the resulting disincentives appearing in Part 171.

Current disincentives principally reach specified Medicare Promoting Interoperability participants, MIPS-eligible clinicians, and Medicare Shared Savings Program participants — the regulation does not yet create an identical financial consequence for every entity falling within the broad statutory definition of a health care provider. As set out in the regulation, CMS may apply disincentives including: that an eligible hospital or critical access hospital as defined in 42 CFR 495.4 is not a meaningful electronic health record user; that a MIPS eligible clinician who is also a health care provider under § 171.102 is not a meaningful EHR user for MIPS; and that ACOs, ACO participants, and ACO providers or suppliers may be removed from, or denied approval to participate in, the Medicare Shared Savings Program for at least one year — potentially arising from an OIG determination involving a practice attributable to the affected provider or organization, subject to the applicable program rules and CMS's facts-and-circumstances analysis, rather than automatically whenever conduct originated anywhere in the organization.

Read those consequences functionally rather than as citations. Meaningful-user status is not a designation — it is a payment adjustment. Removal from the Shared Savings Program for at least a year is a revenue event affecting an entire organization. The actual financial effect on any given practice depends on MIPS eligibility, Medicare volume, payment-adjustment rules, possible reweighting, and ACO participation — it is fact-specific rather than reliably modest for a small practice, and should not be assumed either way without running the numbers for the specific organization.

Publication: the consequence that is not financial

A distinct consequence operates alongside the payment mechanisms, and organizations consistently under-weight it because it does not appear on a budget line.

Part 171 provides for public posting on the federal website of information about actors determined by the HHS Office of Inspector General to have committed information blocking — but the timing and trigger differ by actor type, and the posting is conditional rather than automatic. For a health care provider, information is publicly posted after OIG determines the provider committed information blocking, refers the provider to the appropriate agency, that agency imposes an applicable disincentive, and the relevant administrative appeals process is complete. For a developer, HIN, or HIE, posting follows settlement of CMP liability or a final CMP determination.

A published federal determination naming a practice and describing the conduct is durable in a way a payment adjustment is not — it is indexed and citable, and section 171.1101 does not state an express expiration period for the posting. That is not the same as a legal guarantee that the information will remain indexed and available permanently; it means only that no expiration provision currently exists in the text.

This alters the calculus for organizations that might otherwise treat a modest payment consequence as an acceptable cost of a preferred policy. The financial exposure can be modelled; the publication, once it occurs, is harder to bound.

Complaints reach the system through a federal reporting portal, and information that could identify the source of a possible information-blocking claim is exempt from mandatory disclosure under the Freedom of Information Act and is generally not disclosed by ASTP/ONC except as necessary to administer the statute. That protection is real, but it is not a guarantee of complete practical anonymity — the underlying request, communications, or factual circumstances of a specific matter may independently make the likely source apparent.

What is currently unsettled

Any account of this rule that presents it as stable is misleading, and the instability is concentrated in identifiable places.

The administering office has been renamed. Material of different vintages refers to the Office of the National Coordinator for Health Information Technology and to the Assistant Secretary for Technology Policy. Both refer to the same regulatory function. Anyone searching guidance needs to know both names, and any document that uses only one is dated by that fact.

More substantively, the exceptions themselves have been the subject of deregulatory rulemaking. A proposed rule published in the Federal Register in December 2025 (federalregister.gov) set out deregulatory actions on health IT certification and information blocking, including proposals addressing the "access" and "use" definitions, revisions to the infeasibility exception, the manner exception, and removal of subpart D from 45 CFR Part 171 — which contains the Trusted Exchange Framework and Common Agreement manner exception at § 171.403 and associated definitions. The stated rationale for the TEFCA removal was that exception’s appropriateness given TEFCA’s continued implementation and maturation, and comments received including through the CMS–ASTP/ONC health technology ecosystem request for information.

The operational instruction is to check status before relying on any of it. A proposed rule is not law; a proposal may be finalized in altered form or not at all; and the current text governs until it does not. Anyone advising on the manner exception, the infeasibility exception, or TEFCA-related provisions should confirm the current codified position in the eCFR (official source) rather than working from commentary, including this article.

The general lesson is worth stating for its own sake. This is an area where secondary summaries age badly and confidently, because the underlying regulation has been amended repeatedly by administrations with materially different views about how prescriptive it should be.

One further consequence of the vendor dynamic deserves naming, because it connects to the other federal interoperability mandate operating on the same organizations. Where a practice’s systems must simultaneously support information blocking obligations and the FHIR APIs required under CMS-0057-F (Electronic Prior Authorization: What CMS-0057-F Actually Obliges, and What It Leaves Alone), the same vendor holds the organization’s ability to comply with both — and prices access to each. An organization negotiating one without the other is negotiating half its position.

Where practices actually fail

Enforcement risk in real organizations does not usually originate in a considered decision to withhold data. It originates in five much duller places.

The first is the front line. Requests are received and refused by staff who have been trained for two decades that caution means declining, who have no script for an unfamiliar app-based request, and whose refusals are never recorded or reviewed. This is, as a matter of this article's own analysis rather than a cited empirical finding, a likely major source of exposure in many practices, and one of the least visible.

The second is the category-wide delay policy: results held for a fixed interval so a clinician can contextualize them, adopted for sincere clinical reasons and rationalized under preventing harm. As set out above, that is a policy rather than an individualized determination.

The third is default configuration. Vendor systems ship with settings governing what is released, to whom, and how quickly. Organizations that have never audited those settings are operating under practices they did not choose and cannot describe.

The fourth is contractual. Terms with vendors and networks can constrain what an organization is able to share, and — as noted above — those terms were often written to manage the vendor’s own million-dollar exposure rather than the provider’s. An organization bound by a term that impedes sharing is not thereby excused.

The fifth is documentary. Where exceptions genuinely apply, the conditions are usually satisfiable but unrecorded. The determination existed in someone’s clinical judgment and nowhere else. Because the exceptions are conditional, an unrecorded determination is very close to no determination at all when the record is assembled by an investigator rather than by you.

The structural critique worth making

It is possible to think the rule’s objective is right and its design imperfect, and the imperfections are worth naming precisely.

The first is that voluntary conditional safe harbours create genuine uncertainty at the point of decision. The guidance is candid that exceptions are voluntary and that falling outside them does not automatically establish a violation, with practices assessed case by case. That is legally accurate and operationally hard: a front-desk staff member with a request in hand cannot conduct a case-by-case evaluation, and "we will assess it later" is not a decision rule.

The second is the mismatch between where decisions are made and where sophistication lives. The analysis is intricate — overlapping actor definitions, ten conditional exceptions, two enforcement regimes, active amendment. The decisions are made in seconds by staff with no access to any of that. Rules that require sophistication at the point of contact and supply it only at the point of counsel produce predictable failures.

The third is the enforcement split. Developers face per-violation penalties; providers face program disincentives; and an entity can be both. Whether a given practice is evaluated as a provider practice or a network practice may matter enormously and is not always determinable in advance.

The fourth is instability. A rule whose exceptions are under active deregulatory revision cannot be internalized as culture, and culture is the only mechanism that actually governs front-line refusals. Organizations are being asked to build durable habits on a shifting definitional base.

None of this argues for treating the rule as optional. It argues for building the one thing that survives amendment: a default of sharing, with refusals documented and reviewed as the exceptions they are supposed to be.

How this reaches patients, and why that matters to enforcement

The rule is usually discussed as a compliance obligation running between institutions and a regulator. Its practical energy comes from somewhere else: patients who now expect their data to move and who have a route to complain when it does not.

A patient encountering a refusal experiences it as a clinical relationship problem, not a regulatory one. This series' companion piece, what information blocking means for patients (What Information Blocking Means for You: Your Electronic Health Information Is Generally Expected to Move), covers that side of the interaction directly. The request was reasonable, the refusal was unexplained or explained in terms that sounded procedural, and the inference available to them is that the practice is withholding something. That inference is usually wrong and almost always damaging.

This is why the front-desk default discussed above is not merely a compliance control. Every refusal is simultaneously a regulatory event and a trust event, and the trust consequence arrives immediately while the regulatory one may never arrive at all. Organizations that reason only about enforcement probability systematically under-price the refusals they make.

Complaints reach the regulator through a federal reporting portal, and the practical asymmetry noted earlier applies: information received in connection with a claim of possible information blocking that could identify who submitted it is exempt from mandatory disclosure under the Freedom of Information Act. An organization cannot manage this risk by identifying and addressing individual complainants, because it will not learn who they are. The only available control is the general one — fulfil by default, and make refusals rare, deliberate, documented, and explained.

There is a corollary for how practices communicate. A refusal that is explained — in plain terms, naming what is being withheld and why, and identifying what the patient can do next — is both better care and a better record. The explanation given to the patient and the documentation created for the file can be the same act. Practices that treat these as separate workstreams do neither well.

Who to put in charge of this

A rule enforced against practices whose refusals happen at the front desk needs an owner, and in most organizations it has none.

The structural problem is that information blocking sits between existing functions. Privacy compliance owns disclosure approval. IT owns system configuration. Clinical leadership owns result-release policy. Contracting owns vendor terms. Every one of those functions makes decisions with information blocking consequences, and none of them owns the question.

The practical minimum is a named individual with four responsibilities.

Maintaining the actor-category determination — whether the organization is a provider, a developer of certified health IT, an exchange or network, or more than one. As discussed above, the categories overlap and the enforcement consequences differ sharply between them: civil money penalties administered by the OIG (oig.hhs.gov) under 42 CFR Part 1003 (ecfr.gov) for developers and networks, and the disincentives framework established in the July 2024 final rule (federalregister.gov) for providers.

Owning the refusal log. Someone has to read it, not merely collect it. A log nobody reviews establishes that refusals were happening and that nobody was assessing them, which is worse than no log.

Reviewing configuration and contract terms on a schedule. Vendor defaults and participation agreements change, and both determine practices the organization is answerable for.

And tracking the rulemaking. The December 2025 proposed deregulatory rule (official source) put the access and use definitions, the infeasibility exception, the manner exception, and TEFCA-related provisions in play. Someone must know the current codified position in Part 171 (official source) rather than working from a summary of a superseded version.

This is not a full-time role in a small practice — a few hours a month. But it is a named role, and the alternative is an organization where the rule is everyone's concern and no one's job, which is the condition in which the front-desk failure mode persists indefinitely.

How this ends up in front of a regulator

Most organizations never hear from anyone about this rule. Understanding how the ones that do got there is the cheapest form of risk management available.

The pathway almost never begins with a regulator noticing something. It begins with a complaint, submitted through the federal reporting process described on the official information blocking page (official source), and complaints come from three sources.

Patients, usually after a refusal they experienced as unexplained. These are the most common and the most avoidable, because the refusal was typically made at a front desk by someone with no authority to make it.

Other providers, when records do not arrive or arrive unusably. A receiving clinician who cannot get what they need for a patient in front of them is a motivated complainant, and their account can carry real weight with a reviewer, though this article does not have data establishing how such complaints compare empirically to others.

And competitors — developers, networks, or health systems — where the practice at issue looks like it is protecting a market position rather than a patient. As a matter of this article's own analysis, such complaints may tend to be well documented because the complainant understands the rule, though this is not established by a cited empirical source.

Two features of the process shape how an organization should prepare. Information submitted in connection with a possible information blocking claim that could identify the submitter is exempt from mandatory disclosure under FOIA, so an organization will not learn who complained and cannot manage the risk by managing individuals. And a determination against a provider is published — Part 171 (ecfr.gov) provides for posting information about actors found to have committed information blocking, including the practice found and when it occurred.

Which leads to the only durable control. You cannot identify complainants, you cannot rely on going unnoticed, and a determination is permanent and public. What you can do is make refusals rare, deliberate, documented, and explained to the person refused — because an explained refusal rarely becomes a complaint.

What to actually do

Determine and record which actor category or categories you occupy — provider, developer of certified health IT, exchange or network, or more than one.

Invert the front-desk default: the reflex should be to fulfil, with refusals escalated rather than made locally.

Log every refusal. An unlogged refusal is an undefendable one, because the exceptions are conditional and conditions must be shown.

Replace category-wide result delays with individualized, documented harm determinations, or retire them.

Audit vendor default configurations governing release scope and timing; you own practices you never chose.

Read vendor and network agreements for terms that impede sharing, and understand they were drafted around the vendor’s exposure, not yours.

Confirm the current codified text of Part 171 in the eCFR before relying on any exception — the manner, infeasibility, and TEFCA-related provisions have been the subject of proposed revision.

Do not assume you will learn who complained; claim-identifying information is statutorily exempt from mandatory FOIA disclosure.

The habit that survives the rulemaking

The exceptions will keep moving. The definitions of access and use, the infeasibility and manner exceptions, and the TEFCA provisions have all been put in play by deregulatory rulemaking, and the office administering the rule has already been renamed once.

What does not move is the inversion. Sharing is the expected norm; withholding is the act that requires an account. An organization that has internalized that — fulfil by default, escalate refusals, document determinations contemporaneously — remains compliant across amendments, because every version of this rule asks the same question about a refusal. An organization that has instead memorized ten exception names is compliant only until the next final rule.

General educational information—not legal or medical advice

This article describes federal regulatory structure for physicians, administrators, and journalists. It is not legal advice and creates no professional relationship. The information blocking regulations have been amended repeatedly and were the subject of proposed deregulatory revision as of late 2025; provisions described here may have changed. Nothing in this article should be relied on without confirming the current codified text at 45 CFR Part 171 and obtaining advice from qualified counsel on your specific circumstances.

Questions worth asking

Which actor category or categories does this organization occupy, and has that been recorded?

How many requests were refused last month, by whom, on what stated basis — and can we answer that at all?

Do we operate any category-wide delay on releasing results, and under which exception do we believe it sits?

Where are our individualized harm determinations documented, and would the record satisfy the exception’s conditions?

Which vendor default settings govern release scope and timing, and who last reviewed them?

Has the exception we rely on been affected by the pending deregulatory rulemaking?

Takeaway

The information blocking rule does not add a compliance list so much as reverse a reflex. Sharing is the expected norm, and a refusal is the act that must be justified — by conditional exceptions, voluntarily invoked, on a record the actor has to build at the time. Practices fail here not through considered defiance but through inherited caution at the front desk, category-wide policies mistaken for individualized determinations, and unaudited vendor defaults. All three are fixable, and none of them are fixed by learning the names of the exceptions.

Sources and Authorities

The sources below are provided so readers can confirm the governing text and current agency guidance. Laws, regulations, agency pages, and implementation dates can change; time-sensitive requirements should be checked against the current official source.

CMS — Interoperability and Prior Authorization Final Rule CMS-0057-F — cms.gov

CMS — Interoperability Policies and Regulations — cms.gov

ASTP/ONC — Information Blocking — healthit.gov

45 C.F.R. Part 171 — ecfr.gov

HHS OCR — Right of Access — hhs.gov

www.healthit.gov — healthit.gov

oig.hhs.gov — oig.hhs.gov