Information Blocking Rules: What Health IT Developers Must Know

Information blocking is a practice that is likely to interfere with access, exchange or use of electronic health information. The 21st Century Cures Act of 2016 made it unlawful for health care providers, developers of certified health IT, and health information networks or exchanges, unless the practice is required by law or falls within a regulatory exception. HHS rules at 45 CFR Part 171 define the details, and they directly affect how health IT products are designed, priced and operated.

After years of slow enforcement, HHS announced in September 2025 that it would actively enforce the rules, ONC began issuing notices of nonconformity to certified EHR developers in February 2026, and the HHS Office of Inspector General is pursuing investigations. In October 2026, HHS finalised the HTI-5 rule cutting certification criteria but did not finalise proposed changes to information blocking exceptions. This guide explains who is covered, what EHI means, the exceptions, penalties and what health IT vendors should do.

What is information blocking?

Section 4004 of the Cures Act defines information blocking as a practice that, except as required by law or specified by the Secretary of HHS as a reasonable and necessary activity, is likely to interfere with, prevent or materially discourage access, exchange or use of electronic health information. For health IT developers and networks, the practice is information blocking if they know or should know it is likely to interfere; for health care providers, if they know the practice is unreasonable and likely to interfere.

The Office of the National Coordinator for Health Information Technology (ONC), renamed the Assistant Secretary for Technology Policy and ONC (ASTP/ONC) in 2024, issued the implementing rule in the Cures Act Final Rule of 2020, with later amendments in the HTI rules.

Who must comply? The "actors"

• Health care providers, such as hospitals, physician practices, labs and pharmacies.
• Health IT developers of certified health IT, meaning developers with at least one product certified under the ONC Health IT Certification Program.
• Health information networks and health information exchanges, entities that determine, control or have discretion to administer requirements for exchange among multiple unaffiliated parties.

A software company without certified products is not a "developer" actor, but if it operates as a network or exchange, or provides services that affect providers' compliance, it should still take the rules seriously. Providers will expect such vendors to support timely access, reasonable fees and complete exports, because the provider can be found to be blocking information through a vendor's restrictions.

Is it mandatory or voluntary?

Mandatory for actors. Certified health IT developers must also meet Conditions of Certification, including not engaging in information blocking, providing assurances, communications protections, and API requirements.

Electronic health information (EHI)

Since 6 October 2022, EHI has been defined as electronic protected health information, as defined under HIPAA, to the extent it would be included in a designated record set, regardless of whether the actor is a HIPAA covered entity. In practice, this includes medical records, billing records, claims, and other records used to make decisions about individuals, but excludes psychotherapy notes and information compiled in anticipation of litigation. Before October 2022, the scope was limited to data elements in the US Core Data for Interoperability (USCDI).

Examples of practices that may be information blocking

• Delaying release of test results to patients without a valid exception.
• Charging excessive or discriminatory fees for exporting data or connecting interfaces.
• Contract terms that restrict customers from sharing data with other developers or apps.
• Refusing to provide export functionality when a customer switches EHR vendors.
• Implementing APIs in ways that are slow, unreliable or burdensome for third-party apps.
• Requiring unnecessary agreements or approvals before an authorised app can access data.
• Configuring systems to restrict access more than required by law or a valid exception.

The exceptions

The rule defines exceptions for reasonable and necessary practices that are not information blocking if all conditions are met. The core exceptions are:

Exception	Purpose
Preventing harm	Practices reasonably necessary to prevent harm to a patient or another person.
Privacy	Practices to protect an individual's privacy, such as meeting HIPAA or honouring patient requests.
Security	Practices directly related to safeguarding the confidentiality, integrity and availability of EHI.
Infeasibility	Requests that cannot be met due to uncontrollable events, segmentation limits or other defined conditions.
Health IT performance	Reasonable maintenance and improvement that temporarily makes systems unavailable.
Manner	Fulfilling requests in an alternative manner when the requested manner is not possible, with related provisions for TEFCA.
Fees	Charging reasonable, cost-based fees under defined conditions.
Licensing	Licensing interoperability elements on reasonable and non-discriminatory terms.

Later rules added further exceptions and conditions. Actors must document how they meet each condition when relying on an exception. Proposals made in the HTI-5 proposed rule to narrow the infeasibility exception, remove the TEFCA manner exception and revise the manner exception were not finalised in October 2026, so the existing exceptions continue to apply.

Certified APIs and Conditions of Certification

Certified health IT developers must offer standardised APIs, based on HL7 FHIR and the USCDI, that allow patients and authorised apps to access data without special effort. Conditions of Certification require developers to publish API documentation and terms, allow API users to register and access data in a timely way, not impose unreasonable fees, and not restrict communications about usability, interoperability and security. In February 2026, ONC began issuing letters of nonconformity to certain certified EHR developers over API performance, interoperability and potential information blocking, which can lead to corrective action, certification suspension or referral to OIG.

TEFCA and nationwide exchange

The Cures Act also called for a Trusted Exchange Framework and Common Agreement (TEFCA) to connect health information networks nationally. Qualified health information networks (QHINs) operate under TEFCA, allowing participants to exchange data for treatment, payment, operations, public health, individual access and other purposes through common rules. Participation is voluntary, but it has grown, and existing rules include provisions that recognise exchange through TEFCA when fulfilling requests. For vendors, connecting to TEFCA through a QHIN can make it easier to meet partners' exchange needs at scale.

Patient access apps and third-party developers

A major goal of the rules is to let patients use apps of their choice to access their records. When a patient authorises a third-party app through a certified API, the provider or developer generally cannot block the connection because it dislikes the app's business model, though it can apply reasonable security measures under the security exception and must follow HIPAA. App developers, in turn, are not usually HIPAA covered entities, so their privacy practices are governed by the FTC and state laws. Clear app registration processes, transparent security criteria, and patient education about how apps use data help balance access and protection. Third-party app developers often show security maturity through assessments such as SOC 2.

Automated access and AI

As AI tools increasingly request and process health data, questions arise about whether restricting automated access can be information blocking. The HTI-5 proposed rule would have clarified that automated processes, including AI systems, fall within access and use of EHI; that clarification was not finalised in October 2026, but commentators note that existing requirements still apply when automated technologies are involved. Vendors should apply consistent, documented criteria to automated access requests, based on security and privacy needs rather than competitive concerns.

Penalties and disincentives

• Developers and networks: the HHS Office of Inspector General can impose civil money penalties of up to $1 million per violation, adjusted for inflation, under rules effective since September 2023.
• Health care providers: HHS rules finalised in 2024 apply disincentives through Medicare programmes, such as the Promoting Interoperability Program, MIPS and the Medicare Shared Savings Program, when OIG refers a provider found to have committed information blocking.
• Certification consequences: developers can face corrective action plans, suspension or termination of certification.

In September 2025, HHS and OIG announced a stronger focus on enforcement, and commentators report that investigations are under way.

HTI-5 and other recent rule changes

HHS proposed the HTI-5 rule in December 2025 to remove many certification criteria and revise information blocking provisions. The final rule, published in October 2026, removed and revised a smaller set of certification criteria, including narrowing decision support requirements, but did not finalise the information blocking changes. HHS indicated it continues to consider comments, so further rulemaking is possible. Health IT developers should track effective dates for certification changes, which range from early 2027 to later years.

How health IT vendors should comply, step by step

1. Determine actor status for each product and service line.
2. Review contracts for terms that restrict data sharing, exports or communications.
3. Review fees for data access, exports and interfaces against the fees and licensing exceptions.
4. Provide reliable FHIR APIs with documentation, timely registration and good performance.
5. Build full EHI export for single patients and population-level data where required.
6. Document exception use, including the conditions met and dates.
7. Train sales, support and engineering teams on what practices create risk.
8. Set up a process to handle access requests and complaints promptly.

How providers comply

• Release test results and notes to patients promptly unless an exception such as preventing harm applies and is documented.
• Respond to requests from patients, other providers and apps without unnecessary delay.
• Configure EHR settings to avoid unnecessary restrictions.
• Document privacy and security-based restrictions under the relevant exceptions.

Documentation you will need

• Actor status determination.
• Policies on access, exchange and use of EHI.
• Exception documentation for each restriction.
• Fee schedules and cost basis.
• API documentation, terms and performance metrics.
• Records of requests and responses.
• Training records.

Timeline and cost considerations

Most information blocking work is about policies, contracts and product behaviour rather than new infrastructure. Reviewing contracts and fees can take weeks; improving API reliability and building complete EHI export can take months, depending on the product's architecture. The cost of not acting is higher now that enforcement is active, with penalties that can reach over a million dollars per violation for developers and networks.

Common mistakes

• Assuming HIPAA compliance means no information blocking risk.
• Delaying patient access to results without a documented exception.
• Charging high, unexplained fees for data exports and interfaces.
• Gag clauses in contracts restricting communications about the product.
• Unreliable or throttled APIs for third-party apps.
• Not documenting how exception conditions were met.

Best practices, tools and technologies

• Implement HL7 FHIR R4 APIs with SMART on FHIR authorisation.
• Monitor API uptime and response times and publish them.
• Offer standards-based bulk export for population data.
• Use consent and privacy controls that are precise rather than blanket restrictions.
• Join or connect to TEFCA through a qualified health information network where relevant.

We build FHIR APIs, patient access apps, data export features and EHR integrations through our API integration work and experience in healthcare technology.

How it relates to other laws

Law	Relationship
HIPAA	Privacy and security rules; the privacy and security exceptions align with HIPAA, and EHI is defined by reference to HIPAA terms.
HITECH Act	Earlier law promoting EHR adoption and strengthening HIPAA enforcement.
CMS Interoperability rules	Require payers to offer patient access and provider directory APIs.
ABDM	India's consent-based health data exchange, a useful comparison for interoperability design.

Real-world example

An EHR vendor with certified products, supported by an Indian engineering team, reviews its practices after the 2025 enforcement announcement. It removes contract clauses that limited customers from sharing data with competing apps, replaces case-by-case interface fees with a published, cost-based schedule, improves its FHIR API performance and publishes uptime data, and adds a self-service EHI export for customers leaving the platform. Support staff are trained to route data access requests promptly, and each restriction applied for privacy or security is documented against the relevant exception.

Next steps

1. Confirm actor status.
2. Review contracts and fees.
3. Strengthen APIs and exports.
4. Document exceptions.
5. Track rule changes and enforcement.

Frequently asked questions

What is information blocking?

A practice likely to interfere with access, exchange or use of electronic health information, unless required by law or covered by an exception.

Who is subject to information blocking rules?

Health care providers, developers of certified health IT, and health information networks and exchanges, which the rules call actors and treat with different knowledge standards.

What is EHI?

Electronic protected health information that would be included in a designated record set, regardless of whether the actor is a HIPAA covered entity, including clinical and billing records.

What are the penalties?

Up to $1 million per violation, adjusted for inflation, for developers and networks, and Medicare disincentives for providers.

Is information blocking being enforced?

Yes. HHS announced active enforcement in 2025, ONC began issuing nonconformity letters in 2026, and OIG is investigating cases.

Did HTI-5 change the exceptions?

No. The October 2026 final rule did not finalise the proposed information blocking changes; existing exceptions still apply.

Can developers charge fees for data access?

Only fees that meet the conditions of the fees exception, such as being reasonable and based on objective criteria.

Can providers delay releasing results to patients?

Only if an exception applies, such as preventing harm, and its conditions are met and documented.

Does information blocking apply to non-certified software vendors?

Not as developers, but they may be covered if they act as a network or exchange, and their products affect providers' compliance.

What APIs are required?

Certified developers must provide standardised HL7 FHIR APIs based on USCDI for patient and population services.

What is TEFCA?

The Trusted Exchange Framework and Common Agreement, a voluntary national framework for exchange among qualified health information networks.