Custom Software

What is Information Blocking?

A patient asks for their lab results through a third-party app. A primary care provider needs records from a specialist before tomorrow’s visit. A researcher requests a de-identified extract from a covered EHR. Five years ago, each of these requests routinely got slow-walked, refused, or buried under “policy” objections. Today, the same behavior — done by a regulated actor, without a valid exception — can trigger a federal investigation, financial penalty, or disincentive. That’s information blocking, and the rule defining it has reshaped how health information actually moves in the US.

Calculate My Project Cost Connect With Experts

Tell Us Your Requirements

Our experts are ready to understand your business goals.

Trusted Partners

Trusted by Industry Leaders Worldwide

Recognition

Awards & Recognitions

Definition of Information Blocking

Information blocking is a practice by a regulated actor — a healthcare provider, health IT developer of certified health IT, HIE, or health information network — that, except as required by law or covered by a specific regulatory exception, is likely to interfere with, prevent, or materially discourage the access, exchange, or use of electronic health information (EHI).

The legal basis sits inside the 21st Century Cures Act, with the operational rules published by the Office of the National Coordinator for Health IT (ONC) at 45 CFR Part 171. Penalties and enforcement come from two parallel tracks: HHS Office of Inspector General (OIG) for health IT developers, HIEs, and HINs (civil monetary penalties up to $1 million per violation), and CMS for healthcare providers (program-specific disincentives that can affect Medicare reimbursement and quality program participation).

A few elements of the definition matter:

Practice. Could be a single act or an ongoing pattern. A one-time refusal counts; so does a routine policy.

Regulated actor. Three categories: healthcare providers (broadly defined, including hospitals, clinics, individual clinicians, post-acute facilities), developers of certified health IT, and HIEs/HINs.

Likely to interfere. Intent isn’t always required. A practice that would reasonably be expected to interfere with access — even without proof of a specific blocked request — can qualify.

Electronic health information (EHI). Defined broadly. Initially scoped to USCDI v1, but as of October 2022 expanded to include the full designated record set as defined under HIPAA — meaning essentially all electronic PHI a covered entity holds.

Knowledge standard. Providers are evaluated on whether they “know” the practice is unreasonable and likely to interfere. Developers, HIEs, and HINs are held to a stricter standard — they’re judged on whether they “know or should know.”

In simple terms: Information blocking is any practice by a regulated actor that gets in the way of moving electronic health information — unless it’s required by law or fits one of eight specific exceptions.

How Information Blocking Works in Practice

What does information blocking actually look like? The rule lists categories of practices that may qualify, with the understanding that fact patterns matter as much as categories.

Restricting access. Refusing a patient’s app the ability to connect to a certified EHR’s FHIR API. Requiring patients to come in person to retrieve records that are technically available through a portal. Limiting record requests to fax-only when electronic exchange is feasible.

Implementing technology in non-standard ways. Customizing FHIR endpoints so they don’t conform to published profiles, breaking interoperability with apps that follow the standard. Disabling or hobbling certified capabilities that would otherwise permit exchange.

Pricing and contracting practices. Charging fees that aren’t reasonably related to costs. Demanding API access fees that effectively block third-party connections. Imposing exclusivity terms that block competitor connections.

Delays and procedural friction. Imposing policies that “study” every record request individually when automated release is technically straightforward. Routing routine requests through legal review when no legal question exists.

Vendor lock-in tactics. Refusing to export data in usable formats when a customer migrates to a competing platform. Holding patient data hostage during contract disputes.

The fact pattern test: if a regulated actor restricts EHI exchange, the question is whether the restriction is required by law, covered by an exception, or unjustified. The third bucket is information blocking.

The Eight Exceptions

Not every restriction on EHI exchange is information blocking. ONC’s rule recognizes eight exceptions, divided into two groups.

Exceptions for Not Fulfilling Requests

Preventing harm. A practice reasonably necessary to prevent harm to a patient or another person — for instance, withholding test results pending clinician review when immediate release could cause psychological harm.

Privacy. A practice required or permitted by privacy law (HIPAA, state laws, 42 CFR Part 2 for substance use disorder records, minor consent rules in many states).

Security. A practice reasonably necessary to address legitimate security risks — declining to connect to an app that fails security review, applying access controls that protect against credential abuse.

Infeasibility. A practice required by genuine technical or operational infeasibility — for example, an unavoidable system failure, a request for data the actor doesn’t actually have, or an uncontrollable third-party dependency.

Health IT performance. Reasonable steps to maintain performance — scheduled downtime, capacity protections, software updates — that may temporarily affect EHI access.

Exceptions for Procedures Around Fulfilling Requests

Content and manner. Allows actors to fulfill requests in a different manner than requested when the original manner is infeasible, but only after offering a reasonable alternative.

Fees. Permits cost-based fees structured to reflect reasonable costs, not to discourage exchange.

Licensing. Allows reasonable license terms for interoperability elements (APIs, terminology assets), provided terms aren’t structured to be discriminatory or anticompetitive.

Each exception has multiple specific conditions — and missing any condition collapses the defense.

Key Standards and Regulatory Hooks

21st Century Cures Act

The statutory basis. Sec. 4004 establishes the information blocking framework and authorizes HHS to define exceptions and enforcement.

45 CFR Part 171

ONC’s regulatory text defining information blocking, regulated actors, EHI scope, and the eight exceptions. The current version reflects amendments through HTI-1 and subsequent rulemaking.

Enforcement Rules

42 CFR Part 1003 — OIG civil monetary penalty rules for developers, HIEs, and HINs (up to $1M per violation).

The CMS disincentives final rule — published 2024, establishing program-specific consequences for providers found to have engaged in information blocking. Includes Promoting Interoperability program penalties, MIPS impact, and ACO program effects.

USCDI and FHIR

USCDI defines the data classes EHI initially mapped to. The FHIR-based Patient Access and Provider Access APIs created under CMS Interoperability rules are how compliant exchange typically happens in practice.

HIPAA Interaction

HIPAA permits more disclosures than people often assume. Information blocking enforcement frequently turns on whether a refusal cited “HIPAA” when HIPAA actually permitted the disclosure. The rule expects regulated actors to know the difference.

Implementation Considerations

Compliance isn’t a one-time policy review. The actors who handle this well treat it as an operational discipline.

Map your EHI inventory. What electronic health information do you hold? Where does it live? Who has it? The expanded definition of EHI means most actors hold more than they initially recognize. Without an inventory, defending a request denial is guesswork.

Document every refusal. When a request gets refused or delayed, the basis matters. An exception is only valid if the conditions are documented at the time of the decision — not reconstructed afterward. Build the audit trail into the workflow, not as an afterthought.

Watch the fees and licensing terms. Vendors and developers face the highest penalty exposure here. Pricing that “feels reasonable” internally may not survive cost-justification scrutiny. License terms drafted years ago may now be problematic.

Reconcile portal and API behavior. A common gap: the patient portal shows everything, but the FHIR API blocks certain data classes by default. That inconsistency is harder to defend now that EHI extends to the full designated record set.

Train front-line staff carefully. Many information blocking complaints originate from a release-of-information clerk, IT support tech, or medical records staffer applying a misremembered rule. Front-line training that emphasizes when to escalate beats reflexive refusals.

Build the complaint response capability. Anyone — patient, provider, app developer — can file a complaint with ONC. Knowing how to receive, investigate, and respond internally reduces the risk that a single complaint becomes an OIG investigation.

Review automated systems. Some information blocking happens because a deployed system silently filters data based on outdated rules, legacy permissions, or vendor defaults. Periodic configuration review catches what manual policy review misses.

Track the regulatory updates. EHI scope changed once already (USCDI v1 designated record set). Enforcement guidance continues to evolve. A compliance posture from 2022 isn’t enough.

How Taction Helps with Information Blocking Compliance

Compliance lives in the technology stack as much as in policy documents. The systems that move EHI — EHRs, FHIR servers, integration engines, patient portals, API gateways — determine whether a given request gets fulfilled appropriately or fails in a way that creates exposure. Taction’s work sits at that technical layer.

What we do:

EHI inventory and data flow mapping — We help organizations map where electronic health information lives across their systems, how it flows between them, and where access requests get fulfilled or refused. This baseline is what every other compliance activity depends on.

FHIR API conformance and remediation — We audit FHIR endpoints for conformance to published profiles and identify configurations that could be flagged as non-standard implementation. Where remediation is needed, we build it.

Mirth Connect channels for compliant data exchange — Our Mirth Connect consulting team builds and maintains the integration channels that support compliant EHI flow between source systems, FHIR servers, HIEs, and external partners.

Audit logging and request tracking infrastructure — We build the logging, traceability, and request-handling tooling that lets organizations demonstrate when and how each EHI request was handled — and on what basis any exception was applied.

Patient access workflow engineering — From SMART on FHIR launches to patient portal record-release flows, we build the patient-facing access mechanisms that compliance assumes are in place.

Vendor and platform configuration review — We review certified health IT configurations, vendor default settings, and integration patterns to surface practices that could be flagged.

Related Terms and Resources

Explore related glossary terms:

What is the 21st Century Cures Act? — The statutory basis for information blocking

What is FHIR? — The standard underlying compliant EHI exchange APIs

What is an EHR? — The system most EHI lives in

What is Healthcare Interoperability? — Broader category for EHI exchange

What is HIPAA Compliance? — The privacy framework that frequently intersects with information blocking exceptions