Information-blocking exceptions require case evidence—not a transport verdict

The decision object is a practice in context

The direct answer in ASTP's information-blocking page is that the analysis concerns an actor's practice that is likely to interfere with access, exchange, or use of electronic health information, subject to required-law and exception context. A failed API request, delayed interface, incomplete data element, identity mismatch, security review, policy setting, or manual process can be evidence about a practice; none independently establishes the full regulatory conclusion.

An interoperability record should connect the requester and actor, EHI and purpose, request and response, transport and content standards, authorization and identity, timing, system behavior, policy or operational practice, communications, reason, law or exception considered, decision makers, evidence, and outcome. Technical logs need clinical and governance context, while narrative decisions need traceable technical evidence.

Actor category changes the knowledge question

ASTP identifies health care providers, developers of certified health IT, and health information exchanges or networks as actor categories. It also explains different knowledge standards: developers and exchanges or networks are assessed against whether they know or should know a practice is likely to interfere, while a provider standard asks whether the provider knows the practice is unreasonable and likely to interfere.

A system should not apply one universal questionnaire or score to every participant. It should preserve the legal entity, actor role, certified-product context where relevant, responsible people, information available at the time, advice or escalation, and basis for the decision. Labels inferred from organizational type need review because one enterprise may perform different roles in different practices.

An exception needs a criterion-level record

ASTP says information-blocking exceptions are voluntary and offer certainty when a practice meets an exception. The page also warns that failing to meet an exception does not automatically mean information blocking occurred; the practice then requires case-by-case evaluation. An exception dropdown without the applicable criteria, facts, timestamps, evidence, approver, and later reassessment cannot carry that reasoning.

A buyer should test whether software versions the exception and regulation reference, captures each element and condition, links supporting evidence, records alternatives considered, preserves disagreements and unknowns, separates legal advice from operational facts, and supports review when circumstances change. Automation can prompt evidence and surface deadlines, but humans remain accountable for the legal, clinical, privacy, security, and operational judgment.

Technical interoperability and regulatory disposition stay separate

A conformant transport or successful exchange can coexist with a restrictive policy, and a technically failed exchange can result from facts other than information blocking. Likewise, certification, USCDI support, FHIR support, TEFCA participation, and a passed interface test are bounded evidence, not universal proof about access, exchange, use, EHI scope, privacy, security, actor knowledge, or an exception.

ASTP provides a claim portal and explains that ONC and OIG have different review or investigation authorities. This article does not decide whether information blocking occurred, whether an exception is met, whether data are EHI, or whether a system is conformant or secure. Organizations need the current rule, complete facts, and qualified legal, compliance, clinical, privacy, security, health-information-management, and technical review.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Health Interoperability Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.