Information Blocking Enforcement Is Here: What Health IT Teams Must Do Right Now

For five years, the information blocking provisions of the 21st Century Cures Act were a rule with no teeth. Organizations received guidance, submitted complaints, and waited. That waiting period is officially over.

On February 11, 2026, HHS's Assistant Secretary for Technology Policy (ASTP/ONC) announced that it has begun issuing letters of nonconformity to certified EHR developers — the clearest signal yet that federal enforcement has shifted from theoretical to operational. With nearly 1,600 complaints filed through the Information Blocking Complaint Portal, up to $1 million in civil monetary penalties per violation, and providers facing Medicare payment disincentives, the compliance landscape has fundamentally changed.

This guide breaks down what information blocking means in practice, the eight legal exceptions you can rely on, the five most common violations health IT teams are committing right now, and exactly how to audit your organization's compliance posture before an enforcement letter arrives in your inbox.

February 2026 — Enforcement Is No Longer Theoretical

The enforcement timeline for information blocking has been a slow burn — deliberately so. The Office of the National Coordinator for Health IT (ONC) spent years building the regulatory framework, allowing organizations time to adapt. But that patience has run out.

Here is the timeline that brought us to this moment:

• December 2016: The 21st Century Cures Act signed into law with overwhelming bipartisan support, establishing the legal foundation for prohibiting information blocking.
• April 5, 2021: The information blocking prohibition officially took effect under the ONC Cures Act Final Rule. All actors — health IT developers, health information networks (HINs), health information exchanges (HIEs), and healthcare providers — became subject to the rule.
• September 1, 2023: Civil monetary penalties (CMPs) for non-provider actors (health IT developers, HINs, and HIEs) became enforceable under HHS OIG authority. Penalties of up to $1 million per violation can now be imposed.
• July 1, 2024: Medicare payment disincentives for healthcare providers became effective. Providers found to engage in information blocking face loss of "meaningful EHR user" status, zero scores on Promoting Interoperability measures, and ineligibility for Medicare Shared Savings Program participation.
• September 2025: HHS publicly announced that information blocking enforcement is now a departmental priority — a direct signal to the industry that investigations would ramp up.
• February 11, 2026: At the ASTP 2026 Annual Meeting, HHS Assistant Secretary Thomas Keane confirmed that ASTP has begun issuing notices of investigation of potential nonconformity to health IT developers. This is the first concrete enforcement action since the rule's inception.

These letters of nonconformity are not civil monetary penalties themselves — they are a formal compliance mechanism under the ONC Health IT Certification Program. But they carry serious consequences: corrective action plans, potential certification suspension or termination, and referral to the HHS Office of Inspector General (OIG) for full enforcement proceedings.

As Holland & Knight's analysis notes, the OIG prioritizes cases involving practices that cause patient harm, significantly impair care delivery, persist over time, or cause financial losses to federal programs. If your organization's data-sharing practices fall into any of those categories, you are already in the enforcement crosshairs.

One additional data point worth noting: nearly 500 million records have been exchanged through the Trusted Exchange Framework and Common Agreement (TEFCA) as of February 2026 — proof that open data exchange is technically feasible at scale. Organizations that claim interoperability is "too hard" or "too expensive" will find that argument increasingly difficult to sustain.

What Counts as Information Blocking? (Plain-Language Definition)

The legal definition of information blocking is precise and worth understanding clearly. Under 45 CFR Part 171, information blocking is:

A practice that — except as required by law or covered by an exception — is likely to interfere with the access, exchange, or use of electronic health information (EHI).

Three critical terms in that definition need unpacking:

Electronic Health Information (EHI): As of October 6, 2022, EHI includes all electronic protected health information (ePHI) in a designated record set, not just the USCDI data elements. Here we see broader than many organizations realize. It includes clinical notes, lab results, imaging reports, billing records, and any other electronic data in the patient's designated record set. The HTI-5 proposed rule (published December 29, 2025) further expands the definitions of "access" and "use" to explicitly include automated means — including autonomous AI systems and robotic process automation.

Practice: Consider: not limited to explicit refusals. A "practice" includes any act or omission — policies, procedures, contract terms, technical configurations, organizational decisions, fee structures, or even inaction — that interferes with EHI access, exchange, or use.

Likely to interfere: The standard is not "did interfere" but "likely to interfere." This means intent does not matter. If your practice creates barriers to data access — even unintentionally — it can constitute information blocking.

Four categories of actors are subject to the rule:

• Health IT developers of certified health IT — EHR vendors and companies that develop, maintain, or offer certified health IT products
• Health information networks (HINs) — Organizations that determine, oversee, or administer policies for EHI exchange among a broad set of entities
• Health information exchanges (HIEs) — Organizations that enable and oversee EHI exchange among healthcare entities
• Healthcare providers — Any individual or entity that delivers healthcare services (hospitals, clinics, physicians, pharmacies, labs)

The penalties differ by actor type. Health IT developers, HINs, and HIEs face CMPs of up to $1 million per violation from OIG. Healthcare providers face Medicare payment disincentives — which can include loss of meaningful EHR user status, reduced MIPS scores, and disqualification from the Medicare Shared Savings Program for at least one year. Both categories face public posting of violations, creating significant reputational risk.

The 8 Exceptions You Need to Understand

The information blocking rule is not an absolute mandate to share all data in all circumstances. ONC established eight exceptions — legal safe harbors — that protect organizations from liability when they have legitimate reasons to limit data access. These exceptions are voluntary: you do not have to invoke them, but if your practice meets an exception's conditions, you are protected from enforcement.

The exceptions are divided into two categories.

Category 1 — Exceptions for Not Fulfilling Requests

Preventing Harm Exception (45 CFR § 171.201)

You may refuse to provide access to EHI when doing so is reasonable and necessary to prevent harm to a patient or another person. Notice how the most commonly misunderstood exception.

Key conditions:

• The actor must hold a reasonable belief — based on individualized assessment of the specific facts and circumstances — that sharing the EHI will substantially reduce a risk of harm.
• The determination must be made by a person with a professional or clinical relationship with the patient, or by an organizational policy established by such persons.
• The practice must be no broader than necessary to substantially reduce the risk of harm.
• The type of risk must fall into defined categories: risk to life or physical safety, harassment, intimidation, or discrimination risk, or risk related to a person's behavioral health or substance use disorder treatment.

What this does NOT cover: Blanket organizational policies that block entire categories of data "just in case." Each harm determination must be individualized and documented.

Privacy Exception (45 CFR § 171.202)

You may limit access to EHI to protect an individual's privacy, provided you meet specific sub-conditions.

Key conditions:

• The practice must be consistent with applicable federal or state privacy laws (HIPAA, state laws with stricter protections, 42 CFR Part 2 for substance use disorder records).
• If no privacy law applies, you may still invoke this exception if the individual has been given a meaningful choice to opt out and has chosen to do so.
• You cannot use this exception to deny a patient's own request for their EHI — the privacy exception protects against third-party disclosures, not patient access rights.

Security Exception (45 CFR § 171.203)

You may interfere with EHI access to protect the security of electronic health information, provided your security practice meets all conditions.

Key conditions:

• The practice must be directly related to safeguarding the confidentiality, integrity, and availability of EHI.
• It must be tailored to the specific security risk being addressed — no broader than necessary.
• The practice must be consistent and non-discriminatory — you cannot apply different security standards to different requestors without justification.
• It must be implemented in a consistent manner across your organization.

Infeasibility Exception (45 CFR § 171.204)

You may decline to fulfill a request when it is infeasible to do so, due to factors outside your control.

Key conditions:

• Infeasibility factors include: uncontrollable events (natural disasters, public health emergencies), technology failures, the requesting party's inability to receive the EHI in the format needed, or the request being in a format or manner that is not technically feasible.
• You must document the specific reason for infeasibility.
• The HTI-5 proposed rule proposes to remove or revise certain conditions from this exception to prevent overuse.

Health IT Performance Exception (45 CFR § 171.205)

You may temporarily make health IT unavailable or degrade its performance when this is necessary for overall system benefit.

Key conditions:

• The unavailability or degradation must be for a legitimate purpose: maintenance, system updates, security patches, or performance improvements.
• Notably, it implemented for no longer than necessary to achieve the legitimate purpose.
• If foreseeable, you must provide advance notice to affected users.
• You cannot use this exception as a cover for persistent underinvestment in system capacity.

Category 2 — Exceptions for How You Fulfill Requests

Content and Manner Exception (45 CFR § 171.301)

You may fulfill requests for EHI using specific content standards and delivery methods, following a priority hierarchy.

Key conditions:

• First priority: Fulfill the request using certified health IT and applicable federal standards (FHIR APIs, USCDI data elements).
• Second priority: If the first option is not available, use an alternative machine-readable format mutually agreed upon by the parties.
• Third priority: If no agreement can be reached, provide the EHI in the format in which it is maintained.
• The HTI-5 proposed rule proposes to revise the "manner requested" condition and remove the TEFCA Manner Exception.

Fees Exception (45 CFR § 171.302)

You may charge fees for providing access to EHI, including fees that result in a reasonable profit margin.

Key conditions:

• Fees must be reasonably related to the actor's costs of providing access, exchange, or use.
• Fees must be non-discriminatory — the same fee structure must apply to all similarly situated requestors.
• Fees cannot be based on the electronic access of an individual's EHI — you cannot charge patients for API-based access to their own data.
• Fee structures must be transparent and publicly disclosed.
• Fees cannot be designed to create economic barriers to data access (rent-seeking).

Licensing Exception (45 CFR § 171.303)

You may require licenses for interoperability elements needed to access, exchange, or use EHI.

Key conditions:

• Licensing terms must be reasonable and non-discriminatory (RAND).
• Licensing fees must be reasonably related to the licensor's development and maintenance costs.
• You cannot impose licensing requirements that effectively prevent or unreasonably restrict access to EHI.
• The license scope cannot extend beyond what is necessary for interoperability.

5 Common Scenarios That ARE Information Blocking

The exceptions above provide legitimate safe harbors. But many common health IT practices do not qualify for any exception — and organizations are engaging in them daily without realizing they are in violation. Here are the five most common scenarios that constitute information blocking under the rule.

Charging Excessive Data Extraction Fees

An EHR vendor charges a hospital $50,000 to extract and export patient data when the hospital decides to switch to a competing system. A health information network charges per-record fees for API access that far exceed the actual cost of providing that access.

Why it is information blocking: The Fees Exception (§ 171.302) requires that fees be reasonably related to the actor's actual costs. Fees designed to discourage switching vendors, lock in customers, or generate disproportionate profit from data access are rent-seeking practices that violate the rule. ONC has been explicitly clear that excessive fees for data export or access constitute information blocking.

What compliant looks like: Transparent, cost-based fee schedules that apply equally to all requestors, with fee justifications documented and available for review.

Requiring Custom Interfaces Instead of Standard APIs

A health IT developer tells a requesting organization that they must purchase a custom interface ($150,000+) to access data from the EHR, when the developer already has certified FHIR APIs available. Or a hospital requires third-party app developers to use a proprietary data format instead of the standard USCDI/FHIR format.

Why it is information blocking: The Content and Manner Exception (§ 171.301) establishes a clear priority: fulfill requests using certified health IT and federal standards first. Steering requestors toward expensive proprietary interfaces when standard APIs exist is a practice likely to interfere with EHI access. As Alston & Bird notes, organizations should carefully evaluate any revenue-sharing or royalty arrangements that condition EHI access.

What compliant looks like: Standard FHIR R4 APIs deployed and documented, with third-party app registration processes that are straightforward and non-discriminatory. For organizations building their own EHR or health IT systems, a standards-first architecture — like the approach Nirmitee uses when building FHIR R4 servers — ensures compliance is built into the foundation rather than bolted on afterward.

Slow-Walking API Implementations

An EHR vendor has deployed FHIR APIs in a test environment but has not made them production-ready for provider organizations. A health system has the technical capability to provide API access but delays deployment by months or years, citing "resource constraints" or "competing priorities."

Why it is information blocking: Implementing capabilities in ways that limit the timeliness of access, exchange, or use of EHI constitutes a practice likely to interfere with EHI access. The Infeasibility Exception does not cover voluntary organizational decisions to deprioritize compliance. ONC's direct messaging has been clear: "information blocking practices, your days are numbered."

What compliant looks like: Defined timelines for API deployment, documented progress against those timelines, and interim data access solutions while APIs are being built.

Restricting Patient App Access

An EHR vendor imposes onerous terms on third-party application developers who want to connect to their patient-facing APIs. Registration processes are opaque, take months to complete, or require prohibitive fees. API documentation is incomplete, inconsistent, or simply unavailable.

In practice, why information blocking: Certified API Developers are required to make publicly accessible API documentation available. Conditioning API access on excessive fees, restrictive contractual terms, or unreasonable intellectual property requirements — or giving unequal treatment to application registration requests — directly interferes with patients' ability to access their EHI through the apps of their choice. Here we see one of the core scenarios the Cures Act was designed to prevent.

In practice, what like: Publicly available API documentation, a transparent registration process with defined timelines, reasonable terms of service, and consistent treatment of all app developers. Organizations building SMART on FHIR authentication need to ensure the process is genuinely accessible, not just technically available.

Limiting Data Export Formats

A health IT developer only supports data export in a proprietary format that requires expensive proprietary tools to read. A health system provides patient data only through its portal in human-readable (PDF) format but refuses to provide machine-readable formats (C-CDA, FHIR resources) even when requested.

Notably, why information blocking: The Content and Manner Exception requires that EHI be provided in standard formats first, then machine-readable alternatives. Limiting export to formats that cannot be practically used by other systems or by patients' chosen applications creates barriers to exchange and use.

Notably, what like: Support for standard data formats (C-CDA, FHIR R4 resources, USCDI v3 data elements) and the ability to export data in machine-readable formats on request.

How to Audit Your Organization's Compliance

With enforcement now active, every health IT organization needs to conduct a systematic compliance audit. Here is a structured approach organized into three domains.

API Access Review

Your FHIR APIs are the front line of information blocking compliance. Audit these elements:

• API availability: Are your FHIR R4 APIs deployed in production (not just test/staging)? Are they accessible to authorized third-party applications?
• Documentation: Is your API documentation publicly accessible? Is it complete, accurate, and regularly updated? Does it include authentication requirements, supported resources, rate limits, and error handling?
• Registration process: How long does it take for a third-party app to register and gain access? Is the process documented with defined timelines? Are all applicants treated consistently?
• Response times: Are API response times within acceptable thresholds? Are you monitoring uptime and availability? Do you have SLAs for API performance?
• Data completeness: Do your APIs return all USCDI data elements? Are you supporting USCDI v3 (required by January 1, 2026)? Can patients access all EHI in their designated record set, not just USCDI core elements?
• Fee transparency: Are your API access fee structures publicly disclosed? Are fees cost-based and non-discriminatory?

Patient Access Testing

Test your systems from the patient's perspective:

• Patient portal access: Can patients view, download, and transmit their complete health records? Are all EHI data elements accessible — including clinical notes, lab results, imaging reports, and billing data?
• Third-party app connectivity: Can patients connect apps of their choice to access their data via FHIR APIs? Test with at least 2-3 independent SMART on FHIR applications to verify compatibility.
• Data format availability: Is patient data available in both human-readable (portal view, PDF) and machine-readable formats (C-CDA, FHIR resources)?
• Timeliness: How quickly is new data (lab results, visit notes) available through the API after it is entered into the system? Delays beyond what is technically necessary can constitute information blocking.
• Export completeness: Request a full data export for a test patient. Verify that the export includes all designated record set elements, not just a subset.

Documentation Requirements

If you ever need to invoke an exception, you must have documentation ready:

• Exception justifications: For every instance where you deny, delay, or limit access to EHI, document which exception applies, why the specific conditions of that exception are met, and the individualized assessment that led to the decision.
• Policy documentation: Maintain written policies that describe your organization's approach to information blocking, including your process for evaluating requests, applying exceptions, and escalating edge cases.
• Staff training records: Document that relevant staff (IT, compliance, clinical, privacy officers) have been trained on information blocking rules, the eight exceptions, and your organization's policies.
• Audit logs: Maintain logs of all EHI access requests, responses, denials (with reasons), and exception invocations. These logs are essential evidence if your organization is investigated.
• Vendor contract review: Review all contracts with health IT developers and data partners for terms that may constitute information blocking (exclusive data-sharing arrangements, non-standard fees, restrictions on data portability).

For organizations that work with integration engines like Mirth Connect or similar platforms, your compliance audit should also cover how your integration architecture handles data routing decisions — ensuring that integration logic does not inadvertently create information blocking patterns.

How Open Standards Prevent Information Blocking by Design

The most effective compliance strategy is not to memorize eight exceptions and hope your practices qualify. It is to build systems on open standards from the ground up, so information blocking simply cannot occur by design.

Consider: why the regulatory trajectory — from the Cures Act through HTI-1, HTI-2, HTI-3, and now the HTI-5 proposed rule — consistently pushes toward standardization:

FHIR R4 APIs as the default exchange mechanism. The Content and Manner Exception's priority hierarchy puts certified health IT and federal standards first. Organizations that deploy FHIR R4 APIs with US Core profiles and USCDI v3 data elements are, by definition, fulfilling requests in the manner the regulation prefers. There is no ambiguity about whether your practice is compliant when you are using the standard the rule specifies.

SMART on FHIR for application access. The patient access problem — restricting third-party apps, imposing onerous registration requirements, providing incomplete documentation — disappears when you implement standard SMART on FHIR authentication. SMART provides a standardized framework for app registration, authentication, and authorization that is transparent, documented, and interoperable by design.

USCDI as the content standard. Organizations that structure their data according to USCDI standards — and make it available through standard APIs — eliminate the "limited export formats" violation entirely. Data is available in machine-readable, interoperable formats because that is how it is stored and served.

TEFCA for network-level exchange. With nearly 500 million records exchanged through TEFCA as of February 2026, participation in TEFCA demonstrates an organization's commitment to open exchange at scale. While In practice, the rule may remove the TEFCA Manner Exception specifically, TEFCA participation remains strong evidence of good-faith compliance.

At Nirmitee, our standards-first approach to health IT development — building on FHIR R4, SMART on FHIR, and open API architectures — reflects this philosophy. When your health IT infrastructure is built on open standards from the start, compliance with information blocking rules is a natural outcome rather than a burdensome afterthought. Notice how the engineering principle behind how we build EHR systems and integration solutions.

Frequently Asked Questions

What is the penalty for information blocking?

Health IT developers, health information networks, and health information exchanges face civil monetary penalties of up to $1 million per violation from the HHS Office of Inspector General. Healthcare providers face Medicare payment disincentives including loss of meaningful EHR user status, zero Promoting Interoperability scores under MIPS, and ineligibility for the Medicare Shared Savings Program for at least one year. All violators face public posting of findings.

Who can file an information blocking complaint?

Anyone can file a complaint through the ONC Information Blocking Complaint Portal. Nearly 1,600 complaints have been filed as of February 2026. Complaints can be filed by patients, healthcare providers, app developers, researchers, health IT vendors, or any other individual or entity that believes information blocking has occurred.

Does information blocking apply to patient requests for their own data?

Yes. Failing to provide patients with access to their own EHI — whether through a patient portal, API, or data export — can constitute information blocking. The Privacy Exception cannot be used to deny a patient's own request for their data. Under HIPAA, patients have a right of access to their designated record set, and information blocking rules reinforce and expand this right to include API-based access.

Can we charge patients for data access through APIs?

No. The Fees Exception explicitly provides that fees cannot be based on the electronic access of an individual's EHI. You cannot charge patients for accessing their data through patient-facing APIs. You may charge reasonable, cost-based fees for other types of data exchange (such as bulk data exports to other organizations), but these must be non-discriminatory and transparent.

What if our EHR vendor does not support FHIR APIs?

If you are using certified health IT, your vendor is required to support FHIR APIs under the ONC Health IT Certification Program. If your vendor has not deployed production-ready FHIR APIs, they may be in violation of their certification conditions — which is exactly the type of nonconformity that ASTP/ONC began investigating in February 2026. Document this gap and contact your vendor for a deployment timeline.

Does the information blocking rule override HIPAA?

No. HIPAA and state privacy laws remain in effect. The Privacy Exception and Security Exception explicitly allow organizations to comply with applicable privacy and security laws. Information blocking rules do not require you to share data in ways that violate HIPAA — but they do require you to share data in all ways that HIPAA permits. The two frameworks are complementary, not contradictory.

What is changing with Notably, the rule?

The HTI-5 proposed rule (published December 29, 2025) proposes several changes: updating the definitions of "access" and "use" to include automated means (AI systems, robotic process automation), revising conditions in the Infeasibility Exception to prevent overuse, removing the TEFCA Manner Exception, revising the "manner requested" condition in the Content and Manner Exception, and reducing certification criteria from 60 to 26 (eliminating approximately 34 requirements). The comment period closed February 27, 2026, and a final rule is expected later in 2026.

How do I know if my organization is an information blocking "actor"?

You are subject to information blocking rules if you are: (1) a healthcare provider (any individual or entity that delivers healthcare services), (2) a health IT developer of certified health IT, (3) a health information network (HIN), or (4) a health information exchange (HIE). If you develop, maintain, or offer technology that handles electronic health information — or if you deliver healthcare services of any kind — the rule applies to you. The Holland & Knight analysis recommends that organizations reassess their actor status, as many organizations may qualify as HINs or HIEs without realizing it.