Ten Ways to Say No: Information Blocking Exceptions Are Software Requirements

The information blocking rule is usually read as a prohibition. It is more useful to read it as a short list of permissions.

Withholding electronic health information is permitted, in defined circumstances, if conditions are met. There are ten such exceptions, and almost every condition attached to them describes something a system has to be able to do or prove. A segmentation capability. A consent state that can be queried rather than a form that was scanned. A determination with a named decision-maker attached. A written response inside ten business days. A practice applied uniformly across requesters, demonstrably.

Which means the exceptions are not a legal matter that engineering supports. They are a requirements document that happens to be written in regulatory language. An organisation whose software cannot satisfy the conditions does not have the exception available to it, whatever its policies say, because the exception was never a right. It was always a conditional permission.

This piece works through the conditions that are build requirements rather than policy statements, and what fails when they are absent.

Key takeaways

• Ten exceptions exist. None is self-executing: each is available only where its conditions are met, and most conditions are capabilities rather than intentions.

• The segmentation condition is a capability test. If your system can separate the information, you cannot claim it is infeasible to do so.

• Consent has to be queryable state. A precondition you cannot evaluate programmatically is a precondition you cannot show was unsatisfied.

• Two exceptions carry hard clocks measured in business days, and they are the easiest conditions in the whole framework to fail.

• Enforcement is no longer theoretical. ASTP has said it is issuing notices of investigation to health IT developers, and nearly 1,600 complaints had been submitted by February 2026.

The ten, named

Grouped as ASTP groups them. Five concern not fulfilling a request: Preventing Harm, Privacy, Security, Infeasibility, and Health IT Performance. Three concern the procedure for fulfilling one: Manner, Fees, and Licensing. One concerns practices related to TEFCA: the TEFCA Manner exception, added by HTI-1. And one was added by the HTI-3 final rule, published in December 2024: Protecting Care Access, at 45 CFR 171.206.

Worth knowing the whole list, because the common failure is not choosing the wrong exception. It is acting first and looking for an exception afterwards, at which point the conditions are no longer satisfiable because the moment they described has passed.

Condition one: the clocks

Two exceptions are time-bound in business days, and nothing in a typical product makes those clocks visible to anyone.

The Infeasibility exception requires a written response to the requester within ten business days, stating the reasons the request is infeasible. Not a decision within ten business days, a response. The Licensing exception requires the actor to begin licence negotiations within ten business days of the request and to negotiate a licence within thirty business days.

These are the conditions most likely to be missed, because they depend on a request being recognised as the kind of request that starts a clock. A data request that arrives as an email to a named individual, a support ticket, or a note in a sales conversation starts the clock just as surely as one arriving through a formal channel, and none of those three has a timer attached to it.

The build implication is unglamorous and specific. Requests for access, exchange or use need a single intake path with a timestamp, a classification, and an owner, and the response needs to be generated from that record rather than written from memory three weeks later. This is request-tracking infrastructure, not a compliance document.

Condition two: segmentation is a capability test

The Infeasibility exception includes a condition that the actor cannot unambiguously segment the requested electronic health information. Read the logic of that carefully. The exception is available because you are unable to separate what may be released from what may not. If your system can perform that separation, the condition is not met and the exception is not available.

HTI-3 widened where this matters. The segmentation condition now reaches all of the Privacy exception's sub-exceptions and the new Protecting Care Access exception, alongside its earlier applicability including to Preventing Harm. So segmentation is now the gate in front of several exceptions rather than one.

That makes it the single highest-leverage engineering investment in this whole area, and it is a genuinely hard one. Segmenting a record means knowing, element by element, what category each piece of information falls into, which in practice means the category has to have been captured at the point the information entered the record rather than inferred later from text. A system that stores a clinical note as prose cannot segment the sensitive sentence inside it. The same problem sits at the centre of custom EMR and EHR software development work, and it is one of the strongest arguments for structured capture over free text in the places where it matters.

The uncomfortable position is the middle one: a system that can segment some categories and not others. There the honest answer differs request by request, which is exactly why the exception requires a contemporaneous record rather than a standing policy.

Condition three: consent has to be state, not paper

The Privacy exception has four sub-exceptions, and the first is that a precondition has not been satisfied, for example that a required patient consent or authorisation is missing.

To rely on that, you have to be able to establish that the precondition was unsatisfied at the moment you declined. Which requires consent to be a value your system holds, with a scope, a date, a source and a status, rather than a PDF in a document store that somebody would have to go and read.

A fourth sub-exception covers respecting an individual's request not to share information. That one is a suppression capability: a patient-expressed preference, recorded with enough granularity to act on, and enforced at every egress point rather than at the one interface where it was captured. HTI-3 also changed this sub-exception so that it no longer depends on whether another law requires the information to be accessed, exchanged or used, which widens its availability and therefore the usefulness of building the capability properly.

Both point at the same thing. Consent and preference are data model concerns, and the quality of the data model determines which exceptions you can actually invoke. Capturing them as structured, scoped, queryable values is the kind of decision that gets made in intake forms software long before anyone is thinking about information blocking, and is close to impossible to retrofit across a live record.

Condition four: the determination has to have been made by someone

The Preventing Harm exception requires that the actor held a reasonable belief the practice would substantially reduce a risk of harm, that the practice was no broader than necessary, that it satisfied at least one condition each for the type of risk, the type of harm and the implementation basis, and that it satisfied the condition on a patient's right to request review of an individualised risk-of-harm determination.

Three things follow for the software. An individualised determination has to be recorded as an event, with who made it, when, on what basis, and over what scope. The scope has to be bounded, because "no broader than necessary" is a statement about the extent of the restriction, which means the restriction must be expressible narrowly in the first place. And there has to be a review pathway the patient can actually use, which is a product surface rather than a process document.

The Protecting Care Access exception, at 45 CFR 171.206, works on a different basis and is worth understanding on its own terms. It permits an actor to restrict sharing where it holds a good faith belief that people who seek, obtain, provide or facilitate lawful reproductive health care face a risk of legal exposure from sharing specific information, and that the restriction could reduce that risk. ASTP's own material notes the belief is subjective and need not be accurate, and that actors who do not furnish the relevant care and do not offer network or health IT services to providers need not conduct tracking, detailed analysis or extensive legal research to hold it. HTI-3 also added a definition of reproductive health care at 45 CFR 171.102, substantively the same as the HIPAA definition.

That is a lower evidentiary bar than Preventing Harm, deliberately. It is still a restriction that has to be implementable at a level of granularity your record may not support, which brings it back to segmentation.

Condition five: uniformity you can demonstrate

Two exceptions turn on consistency rather than on any single decision.

The Security exception requires a practice directly related to safeguarding the confidentiality, integrity and availability of electronic health information, tailored to specific security risks, implemented in a consistent and non-discriminatory manner, and resting on either a qualifying written security policy or a qualifying security determination. The Health IT Performance exception requires that unavailability or degradation last no longer than necessary, applied consistently and without discrimination, and that any action taken against a third-party application harming performance be time-limited, non-discriminatory and consistent with applicable service level agreements.

Consistent and non-discriminatory is a claim about a population of decisions, not about one of them. You cannot evidence it from the decision you are defending. You evidence it by showing what you did in every comparable case, which means the decisions have to be logged uniformly enough to be counted and compared. Rate limits, API throttling, app review outcomes, maintenance windows and blocked integrations all belong in one queryable place for that reason, which puts them in the same territory as the rest of the healthcare data analytics platform work rather than scattered across infrastructure logs.

The third-party application condition deserves separate attention from anyone running an app programme. Throttling or removing an app for performance reasons is permitted on those terms. Doing it on a vague basis, indefinitely, or to one app and not a comparable one, is the pattern the condition exists to exclude.

Condition six: the things you cannot charge for

The Fees exception permits fees that are objective and verifiable, uniformly applied to similarly situated parties, reasonably related to the actor's costs, and not based on whether the requester is a competitor. It also carries two explicit carve-outs: no fees for an individual's electronic access to their own information or access by their designee, and no fees for information export via the certified export capability at 45 CFR 170.315(b)(10).

For anyone building patient-facing products, that first carve-out is a design constraint rather than a billing policy. An access path that is free in principle and effectively unusable without a paid tier is the kind of arrangement that attracts attention, and the individual access route is one of the places where product and rule meet most directly, which is why we treat it as core to patient portal software development rather than as a compliance checkbox.

Where enforcement actually stands

The regulations took effect on 5 April 2021. The enforcement structure for health IT developers, entities offering certified health IT, and health information exchanges and networks was finalised on 27 June 2023, with enforcement beginning on 1 September 2023. Civil money penalties for those actors run up to one million dollars per violation, violations may stack, and developers additionally face loss of certification and exclusion from the certification programme. Disincentives for healthcare providers took effect on 1 July 2024, operating through reduced payment under the Merit-based Incentive Payment System and Promoting Interoperability, and through loss of shared savings for accountable care organisations.

Two things changed the temperature. In September 2025 the Secretary of Health and Human Services directed departmental resources toward active enforcement. At the ASTP annual meeting in 2026, Assistant Secretary Thomas Keane said ASTP is issuing notices of investigation to health IT developers, making developers the first actor category targeted. Nearly 1,600 complaints had been submitted through the complaint portal as at February 2026, and no settlements or penalties had been publicly reported at that point.

The useful read is that the gap between the rule and its enforcement has closed, and that developers are first in line.

What is proposed to change

ASTP published a proposed rule on 29 December 2025 with comments closing on 27 February 2026. It is a proposal rather than a requirement, and its contents should be treated accordingly, but three items matter for planning.

It would narrow or alternatively remove the Infeasibility exception's manner-exception-exhausted condition, and remove the third-party-modification-use condition entirely, which would leave fewer routes into that exception. It would clarify that the Manner exception's manner-requested condition is not satisfied through contracts that are not at market rate, that are contracts of adhesion, or that contain unconscionable terms. And it would revise the definitions of access and use to cover automated means, including autonomous artificial intelligence systems.

That last one is the most consequential for anyone building now. If finalised as proposed, a request from an autonomous agent would fall within the same framework as a request from a person, which means the exceptions and their conditions would apply to it. Anyone architecting agent access to clinical data on the assumption that it sits outside this rule is building against an assumption that is actively being revised. It also proposes removing Subpart D, including the TEFCA Manner exception.

None of this is legal advice. It is engineering guidance on what the conditions in the current rule ask a system to be able to do, and determinations about any specific practice belong with counsel. At Woltrio we scope this work as data model and request-handling architecture rather than as a compliance workstream, which is how our healthcare software development services approach anything where the defensibility of a decision depends on what the system recorded at the time.