The information blocking rule prohibits practices that unreasonably interfere with the access, exchange or use of electronic health information, and the first question for any software company is whether it applies to you at all. The rule binds specific categories of actor — health care providers, health information networks and exchanges, and developers of certified health IT — so a company building software that touches health data is not automatically covered simply by being in the data path. If you are an actor, the practical obligation is that withholding data requires fitting a defined exception rather than a business justification, and several common commercial behaviors sit uncomfortably close to the line: charging fees that exceed what the fee exception permits, imposing contractual terms that restrict a customer’s use of their own data, or building export paths so cumbersome they function as a barrier. Product and contract decisions, not just engineering ones, are where exposure usually originates.
What Is Information Blocking?
Information blocking, defined under the 21st Century Cures Act and implemented in regulation at 45 CFR Part 171, is a practice by a regulated actor that is likely to interfere with access, exchange, or use of electronic health information (EHI), when that actor knows the practice is likely to have that effect and it isn’t covered by a defined exception. The rule doesn’t require proof of intent to block data as its purpose — knowingly engaging in a practice with that likely effect is enough. It applies to electronic health information broadly, not just to a specific record type, and it covers withholding data as well as making it available in a form that’s effectively unusable.
Are You Actually an “Actor”?
This is the scoping question that determines whether any of the rest of this post applies to you, and it’s more specific than “does your software touch health data.” The rule binds three categories of actor: health care providers; health information networks and health information exchanges (HINs/HIEs); and developers of certified health IT — specifically, health IT certified under the ONC Health IT Certification Program, not health software in general. A company that builds a clinical application, a patient engagement tool, or an integration layer that is not itself certified health IT, and is not a HIN/HIE, and is not a health care provider, is generally not a regulated actor under this rule — even though its product sits squarely in the data path. That distinction matters enormously for scoping risk correctly: many software vendors in this space are not directly regulated, though their customers (providers, or their certified-EHI partners) often are, and contract terms flow downstream from that.
The Exceptions, Practically
Verify the current exception list and conditions directly against healthit.gov before relying on this section — the regulation and its interpretive guidance continue to be refined. ONC recognizes eight exceptions at 45 CFR Part 171, grouped into two practical categories. The first group covers reasonable grounds for not fulfilling a request at all: Preventing Harm, Privacy, Security, Infeasibility, and Health IT Performance. The second group covers reasonable procedures for how a request is fulfilled: Content and Manner, Fees, and Licensing. An actor that satisfies a specific exception’s conditions is not in violation for that instance — but the exceptions are narrow and condition-specific, not general good-faith defenses. Documenting how a specific practice satisfies a specific exception’s conditions, at the time the practice occurs, is what actually protects an actor if a complaint is later investigated.
Where Commercial Practice Meets the Rule
This is the section most engineering-focused coverage skips, and it’s the one that actually determines exposure for most companies: information blocking risk originates in product and contract decisions as often as in technical ones. Fees that exceed what the Fees exception permits — charging a customer more than a reasonable, cost-based amount to export or access their own EHI — are a direct exposure point. Contract terms that restrict a customer’s ability to access, use, or share their own data, or that create friction specifically designed to discourage switching vendors, sit close to the line even when framed as standard commercial terms. And an export or interoperability feature that technically exists but is so cumbersome, slow, or poorly documented that it functions as a practical barrier can be treated the same as an outright refusal. None of these require engineering intent to block anything — they’re product and legal decisions, which is exactly why counsel needs to be in this conversation alongside engineering.
Data Export and Portability
Concretely, “cumbersome” tends to look like: export formats that require significant custom parsing rather than standard structured formats; multi-week manual request processes for data a system could return programmatically; requiring a support ticket and a business justification for a routine export a customer is entitled to; or rate-limiting an export API so aggressively that a genuinely complete export becomes impractical. None of these need to be intentional obstruction to raise exposure — the standard is the practical effect, not the stated purpose. Building a straightforward, reasonably fast, standards-based export path is both the compliant answer and, generally, the better product decision.
How It Relates to TEFCA
Information blocking and TEFCA are related but distinct: information blocking is a prohibition on specific actors interfering with EHI access, while TEFCA — covered in our companion post on TEFCA and QHINs — is a voluntary(ish) exchange framework that makes broader data reachability possible for participants. An actor can be fully TEFCA-compliant or entirely outside TEFCA and still have independent information blocking exposure through its fee structure, contract terms, or export friction. Don’t treat TEFCA participation as a substitute for information blocking compliance — they’re answering different questions.
What Enforcement Looks Like
Verify current enforcement posture and penalty amounts directly against OIG and ASTP sources — this has evolved materially and continues to. HHS-OIG finalized civil monetary penalty authority for information blocking by health IT developers of certified health IT, HINs, and HIEs at up to $1 million per violation, with enforcement authority effective since September 1, 2023 and no retroactive application before that date. Health care providers face a different enforcement mechanism — disincentives tied to certain federal payment and reporting programs rather than direct OIG civil penalties. As of 2026, enforcement has moved from a mostly dormant posture to active investigation: ASTP has confirmed it has begun issuing notices of investigation of potential nonconformity to health IT developers, and HHS has reported thousands of complaints under federal review, with some organizations already placed on corrective action plans. This is not a rule that stayed theoretical — treat current exposure as real and actively enforced, not a distant compliance item.
This post describes the regulation and current enforcement posture; it is not legal advice. If a specific fee structure, contract term, or export design might raise information blocking exposure, have counsel review it directly against the current exceptions and their conditions.
Next Steps
Start by determining whether you’re actually a regulated actor — most software companies in the data path are not directly covered, but their contract terms and export design still matter to the providers and certified-IT partners who are. See TEFCA and QHINs for the related exchange framework, and healthcare data integration beyond HL7 and FHIR for the broader integration picture. If you’re evaluating whether a fee model, contract term, or export design creates information blocking exposure, our team can help you scope the technical side — reach out, and loop in counsel for the contract review.