Information Blocking Rules in 2026: What HealthTech Startups Must Know to Avoid OIG Penalties

For years, information blocking enforcement was described as coming soon.

In September 2025, it arrived.

HHS Secretary Robert F. Kennedy Jr. directed HHS and OIG resources toward active enforcement of the 21st Century Cures Act information blocking provisions. Nearly 1,600 complaints had been submitted to the Information Blocking Complaint Portal as of February 2026. The investigations are open.

The penalties are in effect. And the products most at risk are not the obvious bad actors. They are the well-intentioned HealthTech platforms whose workflows, pricing models, or API access decisions happen to meet the legal definition of information blocking without anyone on the team realising it.

Per violation; Not per year; Not per product. Per individual blocking practice. Its a lot to lose.

If your platform is a data silo, charges for API access, delays data responses, or restricts third-party app connectivity in ways that are not covered by a documented regulatory exception, you have exposure right now.

This guide tells you exactly what that means, which exceptions apply, and how to fix the gaps before enforcement finds them.

What Information Blocking Actually Means?

The 21st Century Cures Act defines information blocking as any practice that is likely to interfere with, prevent, or materially discourage the access, exchange, or use of Electronic Health Information (EHI), unless the practice is required by law or meets a specific regulatory exception.

Three things make this definition broad in ways that catch HealthTech teams off guard:

1. "Likely to interfere" is a low bar

You do not have to completely block data access to trigger the rule. Practices that slow, complicate, or add friction to data access in ways that are not clinically or operationally justified are included.

2. EHI now covers nearly all electronic patient data

As of October 6, 2022, the definition of EHI was expanded beyond the United States Core Data for Interoperability (USCDI), significantly increasing the practical scope of your obligations. Your product almost certainly handles data that falls within this expanded definition.

3. Intent rules are different depending on who you are

Providers must know a practice is unreasonable and likely to interfere with EHI access to be found in violation. Health IT developers face a different and lower intent standard. For your HealthTech platform, this means the standard of proof against you is lower than it is for the hospital you are selling to.

Rules Apply to Three Actor Categories

Key question for HealthTech platforms:

If your product is built on or includes ONC-certified health IT components, or if you offer a module that plugs into a certified EHR environment, you likely fall into the health IT developer category.

Health IT developers, entities offering certified health IT, and health information exchanges face substantial civil monetary penalties and potential health IT certification loss.

Loss of ONC certification is potentially more damaging than the financial penalty. Without certification, your product cannot be used by hospitals receiving Medicare and Medicaid funding, which covers the vast majority of US hospitals.

Practices Triggering Information Blocking & its Way Out

Enforcement under the Cures Act and ONC rules targets practices including: delays in record delivery beyond required timelines, excessive or discriminatory fees for API or third-party access, refusal of valid requests that meet all legal requirements, and incomplete or partial records that prevent patients and clinicians from seeing the full picture of care.

Here is how these map to common HealthTech product decisions:

The most important thing to understand: information blocking is now an operational risk, not a theoretical concern. Organizations should reassess their policies, practices, and exception documentation to demonstrate compliance.

Eight Exceptions: Your Legitimate Defences Escape

The ONC regulations define eight exceptions that can legitimately justify practices that would otherwise qualify as information blocking. The critical word is "documented." The exception must be properly documented and applied consistently. Claiming an exception after an investigation has begun is significantly harder than having documentation in place beforehand.

What makes exception documentation fail:

• Applying an exception inconsistently (using it for some requestors but not others)
• Generic exception claims not tied to specific circumstances
• No dated documentation showing the exception was assessed at the time of the practice, not retrospectively
• Claiming the Fees exception while charging rates that are discriminatory or exceed documented cost recovery

Enforcement Timeline: What Changed and When

Understanding the enforcement history tells you how seriously to treat your current exposure.

The Information Blocking Complaint Portal has been open and actively used, with nearly 1,600 complaints submitted as of February 2026. After years with no enforcement, information blocking actors can now be assured of potential penalties.

The complaint portal is open to anyone: patients, providers, competing HealthTech companies, health information exchanges. Any of your hospital clients, referral partners, or competitors can submit a complaint.

What OIG Investigations Actually Look Like

If your platform receives an OIG inquiry, here is what to expect:

Stage 1: Complaint Review

OIG receives a complaint and assesses whether it falls within scope. Initial desk review of publicly available information about your platform may happen before you are contacted.

Stage 2: Request for Information

OIG may request documentation: your API access policies, fee schedules, technical specifications, contractual terms with third parties, and records of specific data requests and how they were handled.

Stage 3: Investigation

For substantive complaints, OIG conducts a formal investigation. This involves document production, interviews, and technical analysis of your platform's behavior.

Stage 4: Determination

OIG determines whether information blocking occurred and whether any exception applies. If no exception is documented and applied correctly, penalties are assessed.

If your platform handles data requests differently for different requestors without documented justification, that inconsistency is the strongest evidence of deliberate blocking. Exception documentation that was clearly created after the fact is the second biggest red flag.

Why Interoperability Architecture Is Now a Compliance Issue

For CTOs and VPs of Engineering, information blocking is not just a legal question. It is an architecture question.

A product that is genuinely built for interoperability is significantly less likely to trigger information blocking concerns than a product built as a data silo with API access added later.

What FHIR R4 compliance means for information blocking:

• FHIR R4 is the ONC-mandated standard for certified health IT APIs. If your product uses certified EHR technology, your API must support FHIR R4.
• The ONC's 2015 Edition Certification Criteria require standardized API access using FHIR R4 for certified products. Restricting access to these APIs is information blocking by definition unless an exception applies.
• TEFCA (Trusted Exchange Framework and Common Agreement) participation is not yet mandatory, but platforms that participate are significantly better positioned in OIG exception documentation.

Practical architecture implications:

• Your API must respond to valid FHIR R4 requests from authorized third-party apps in a reasonable timeframe
• Rate limits applied to third-party apps must be technically justified and applied consistently. You cannot apply different rate limits to competing apps than to your own system
• Patient-facing apps must be able to access patient data through your FHIR API if the patient authorizes it. Routing patients back to your own portal to prevent third-party app access is exactly the practice OIG is investigating

Information Blocking Compliance Checklist

Work through this before your next hospital contract, ONC certification review, or Series B due diligence.

Conclusion

Information blocking enforcement is no longer a future compliance problem. It is a present one. With nearly 1,600 complaints already filed and OIG actively investigating, the window for voluntary remediation is narrowing fast.

The platforms most at risk are not obvious bad actors. They are well-intentioned HealthTech products whose API access controls, fee structures, or data response workflows were built without full awareness of what the law now requires.

Getting compliant does not mean becoming less competitive. It means building the kind of open, interoperable architecture that hospital procurement teams trust and enterprise buyers pay for. Fix the gaps now, before enforcement finds them for you.