Information Blocking Fines Are Real Now

For five years, information blocking enforcement was theoretical. Complaints piled up, guidance documents multiplied, and nothing happened. That changed on February 11, 2026, when ASTP/ONC announced it had begun issuing letters of nonconformity to certified EHR developers — the first formal enforcement action under the information blocking provisions of the 21st Century Cures Act.

The enforcement machinery is now running. If you build, sell, or operate health IT that touches electronic health information, here's what you need to understand.

This content is for informational purposes only and does not constitute legal advice. Organizations should consult qualified legal counsel regarding specific regulatory obligations.

The enforcement timeline

The path to active enforcement has been gradual, but the acceleration in the past six months is unmistakable:

• April 2021: Information blocking prohibition takes effect under 45 CFR Part 171. The complaint portal opens. No enforcement mechanism exists yet.
• September 2023: Civil monetary penalties (CMPs) for non-provider actors — health IT developers, health information networks, and health information exchanges — take effect. Fines of up to $1 million per violation, with stacking.
• Mid-2024: Medicare payment disincentives for providers go live. Providers found to have committed information blocking face reduced Promoting Interoperability scores and potential Merit-based Incentive Payment System (MIPS) penalties.
• September 2025: OIG and ONC issue a joint enforcement alert, signaling "intensified enforcement activity" and "decisive action to detect and end information blocking."
• February 2026: ONC begins issuing letters of nonconformity to EHR developers. HHS enlists the Department of Justice, FTC, and OIG in a coordinated enforcement push.

As of February 2026, nearly 1,600 complaints have been submitted through the portal. OIG has publicly stated it will prioritize cases where practices cause patient harm, significantly impair care delivery, persist over long durations, or cause financial loss to federal programs.

Who is covered — and what's at stake

The Cures Act defines four classes of actors subject to the information blocking prohibition:

Actor	Penalty
Health IT developers of certified health IT	Up to $1M per violation (CMP) + loss of ONC certification
Health information networks (HINs)	Up to $1M per violation (CMP)
Health information exchanges (HIEs)	Up to $1M per violation (CMP)
Health care providers	Medicare payment disincentives (Promoting Interoperability, MIPS)

For health IT developers, the penalties go beyond fines. ONC can suspend or terminate certification for health IT involved in information blocking. Losing ONC certification means your customers can no longer use your product for CMS reporting — an existential business risk.

The February 2026 letters of nonconformity are not CMPs, but they are a formal step in the enforcement pipeline. They can trigger corrective action plans, and unresolved nonconformity can lead to certification suspension or referral to OIG for penalty assessment.

What constitutes information blocking

Under 45 CFR § 171.103, information blocking is a practice by a covered actor that is likely to interfere with, prevent, or materially discourage the access, exchange, or use of electronic health information (EHI) — unless the practice falls within one of eight regulatory exceptions.

The definition is deliberately broad. Common practices that can trigger scrutiny include:

• Charging fees for API access that exceed the cost of providing it
• Imposing unnecessary technical barriers — custom authentication flows, proprietary formats, rate limits designed to frustrate rather than protect
• Slow-walking data requests — taking weeks to respond to export or access requests
• Restricting third-party app connections — requiring business justification beyond what HIPAA mandates, or blocking patient-authorized apps
• Selective data availability — making some EHI available through one channel but not through FHIR APIs
• Onerous contract terms — licensing conditions that prevent downstream use or interoperability

Note: a practice that fails to meet an exception's conditions is not automatically information blocking. OIG evaluates each case on its facts. But the burden falls on the actor to demonstrate that their practice fits within an exception.

The eight exceptions

The regulations define eight exceptions across two categories. Understanding these is essential for any health IT developer assessing their own compliance posture.

Exceptions for not fulfilling requests

1. Preventing Harm (§ 171.201): An actor may decline a request if fulfilling it would pose a substantial risk of harm to a patient or another person. The determination must be based on an individualized assessment — blanket policies don't qualify.

2. Privacy (§ 171.202): Practices that protect EHI privacy in accordance with applicable law (HIPAA, state privacy laws, 42 CFR Part 2 for substance use records). The practice must be specifically tailored to the applicable privacy requirement.

3. Security (§ 171.203): Security measures that are directly related to safeguarding EHI confidentiality, integrity, and availability. Measures must be consistent and non-discriminatory — you cannot apply stricter security to certain requesters to discourage access.

4. Infeasibility (§ 171.204): Requests that are genuinely infeasible due to technical limitations, resource constraints, or the nature of the request. The actor must document the specific reason the request cannot be fulfilled.

5. Health IT Performance (§ 171.205): Temporary system downtime for maintenance, updates, or performance improvement is permissible — as long as it is implemented consistently and not used to selectively restrict access.

Exceptions for how requests are fulfilled

6. Content and Manner (§ 171.301): An actor may limit the content or delivery method of its response, provided it offers reasonable alternatives. Under HTI-1, actors must fulfill requests using FHIR-based standards when certified to do so.

7. Fees (§ 171.302): Actors may charge fees for data access, but fees must be based on costs reasonably incurred and cannot include technology surcharges, penalties for choosing a competitor, or charges designed to discourage access. ONC has signaled that the Fees exception will face narrower interpretation going forward.

8. Licensing (§ 171.303): Licensing interoperability elements (APIs, documentation, interfaces) must be on reasonable and non-discriminatory (RAND) terms. Licensing conditions that effectively prevent interoperability will not qualify.

What developers should audit now

If you build health IT that handles EHI — whether a certified EHR, a third-party integration, a patient-facing app, or a data exchange platform — these are the areas to review:

API access and responsiveness

• Do you expose a FHIR API for EHI access? If you hold ONC certification, the Content and Manner exception increasingly expects FHIR-based delivery.
• What are your API response times and rate limits? Limits must be based on legitimate infrastructure concerns, not designed to discourage use.
• Do you impose different rate limits or access restrictions on different requesters without a documented security or operational justification?

Fee structures

• Are your data access fees tied to actual costs? The Fees exception requires a reasonable relationship between the fee and the cost of providing access.
• Do you charge differently for API access versus portal access to the same data?
• Are there "interoperability fees" or "integration surcharges" in your contracts?

Third-party application policies

• Can patients authorize third-party apps to access their EHI through your system?
• Do you require business justification, legal review, or manual approval steps beyond what HIPAA requires?
• Do your terms of service restrict how downstream recipients can use or share EHI they've lawfully obtained?

Data scope and completeness

• Does your API return the same EHI scope available through your web portal or direct access?
• Are any data categories excluded from API access without a documented exception justification?
• Are you withholding data that falls within the EHI definition (essentially all electronic PHI in a designated record set)?

Audit logging

• Do you maintain logs of access requests, fulfillment, and denials?
• Can you produce a documented justification for each denied or restricted request?
• OIG's investigation process involves document requests and interviews — having an audit trail matters.

The HIPAA tension

The most common question developers ask: "Doesn't HIPAA require me to restrict access?" The relationship between HIPAA and information blocking is more nuanced than it appears.

HIPAA's Privacy Rule governs how covered entities and business associates handle PHI. It requires minimum necessary access for treatment, payment, and operations. The information blocking regulations do not override HIPAA — the Privacy exception (§ 171.202) specifically allows practices grounded in applicable privacy law.

But invoking HIPAA as a blanket justification for restricting API access does not satisfy the exception. The practice must be tailored to a specific privacy requirement — not a general policy of restricting data flow. If a patient has authorized a third-party app to receive their records, HIPAA's Right of Access supports that request. Blocking it while claiming HIPAA protection would likely fail both the Privacy exception test and the underlying prohibition.

The distinction: HIPAA controls who can access PHI and under what conditions. Information blocking rules say that once those conditions are met, you cannot add additional barriers that interfere with access, exchange, or use.

What's coming next

Several regulatory changes will tighten the compliance landscape further:

• HTI-5 (proposed December 2025): Would remove over 50% of existing certification criteria and recenter the ONC program on FHIR-based APIs. If finalized, the Content and Manner exception will effectively require FHIR delivery for certified health IT.
• CMS-0062-P (proposed April 2026): Extends prior authorization FHIR mandates to drug prior authorizations, broadening the scope of data that must flow through standardized APIs.
• OIG investigation ramp-up: OIG has publicly stated it is dedicating additional resources to information blocking investigations and will prioritize cases involving patient harm or financial impact to federal programs.
• Multi-agency coordination: HHS has brought DOJ, FTC, and OIG into a coordinated enforcement framework. This is no longer a single-agency effort.

Key takeaways

• Enforcement is live. ONC is issuing letters of nonconformity to EHR developers. OIG has civil monetary penalty authority of up to $1M per violation, with stacking. Nearly 1,600 complaints are in the pipeline.
• The definition is broad. Any practice that interferes with, prevents, or materially discourages access, exchange, or use of EHI can qualify — unless it fits within one of eight exceptions.
• Exceptions require specificity. Blanket policies ("we restrict API access for security") don't satisfy exception requirements. Each practice must be individually justified, documented, and consistently applied.
• HIPAA is not a shield. HIPAA compliance and information blocking compliance are separate obligations. Meeting one does not exempt you from the other.
• FHIR-first architectures reduce risk. Systems built around standardized FHIR APIs, transparent fee structures, and documented access policies are inherently better positioned for compliance than those relying on proprietary formats and manual access controls.
• Audit now. Review your API access policies, fee structures, third-party app restrictions, and data scope. Document your justifications. The enforcement timeline has moved from "someday" to "already happening."

Further reading

• ONC Information Blocking Overview
• OIG Information Blocking Enforcement
• ONC/OIG Joint Enforcement Alert
• Holland & Knight: Information Blocking Enforcement Is Here
• Alston & Bird: What Digital Health Stakeholders Should Expect in 2026
• 45 CFR Part 171 — Information Blocking Exceptions