Information Blocking Rule (ONC)
Information Blocking Rule (ONC)
The Information Blocking Rule is one of the most consequential provisions of the 21st Century Cures Act. It prohibits specific actors — EHR vendors, health information networks, and healthcare providers — from engaging in practices that interfere with access to or exchange of electronic health information. It is not a general data-sharing mandate; it is a prohibition on deliberate obstruction.
This article covers the statutory definition, who is subject to the rule, what constitutes a violation, the eight safe-harbor exceptions, penalty structure, and practical implications for developers and providers.
For the broader ONC regulatory context, see ONC 21st Century Cures Act Final Rule.
Statutory definition
The information blocking prohibition is codified at 21st Century Cures Act § 3022 (42 U.S.C. § 300jj-52). A practice constitutes information blocking if it:
- Is likely to interfere with, prevent, or materially discourage the access, exchange, or use of electronic health information (EHI); and
- The actor knows — or should know — that the practice is likely to have that effect; and
- If the actor is a health IT developer, HIN, or HIE: the practice is not required by law and is not covered by one of the eight exceptions; or
- If the actor is a healthcare provider: the practice is unreasonable and is not covered by an exception.
The knowledge element is significant. A practice does not need to be intentionally obstructive to constitute information blocking. If an actor should reasonably know that a practice interferes with EHI access — even if they claim ignorance — the prohibition may still apply.
Who is an actor
The rule defines a specific list of “actors” subject to the information blocking prohibition. Not all healthcare entities are actors under this rule.
| Actor type | Examples |
|---|---|
| Health IT developers of certified health IT | EHR vendors (Epic, Oracle Health, athenahealth, etc.) |
| Health information networks (HINs) | Nationwide exchange networks (CommonWell, eHealth Exchange) |
| Health information exchanges (HIEs) | Regional HIEs, state HIEs |
| Healthcare providers | Hospitals, physician practices, health systems |
Payers are not actors under the information blocking rule. Medicare Advantage plans, Medicaid managed care plans, and commercial insurers are regulated under separate CMS rules (CMS-9115-F, CMS-0057-F) for interoperability, not under the information blocking prohibition. This distinction matters: a payer refusing to share data may violate CMS interoperability rules, but not the information blocking rule.
Scope of electronic health information (EHI)
The scope of EHI covered by the prohibition expanded in two phases:
Phase 1 (through October 6, 2022): EHI was limited to the data elements in the United States Core Data for Interoperability (USCDI) — the standardized set of health data classes defined by ONC. For FHIR-based exchange, this corresponded to data representable using US Core FHIR profiles.
Phase 2 (from October 6, 2022 onward): EHI was expanded to cover all electronic protected health information (ePHI) as defined under HIPAA — the full scope of individually identifiable health information maintained or transmitted in electronic form. This is a much larger category than USCDI and encompasses data that may not have a FHIR representation.
The phase 2 expansion is significant for EHR vendors: it means the prohibition applies to any patient health data held electronically, not just data that fits neatly into standardized FHIR profiles.
The eight exceptions
A practice that meets the definition of information blocking is nonetheless not information blocking if it falls within one of eight exceptions. These exceptions are safe harbors — they define conditions under which an interference with data access is considered legitimate.
| # | Exception | Core condition |
|---|---|---|
| 1 | Preventing Harm | Actor reasonably anticipates the practice will prevent harm to patient or another person |
| 2 | Privacy | Practice required by law, or patient has not consented to sharing under applicable law |
| 3 | Security | Response to a specific, credible threat to the security of health IT or EHI |
| 4 | Infeasibility | Technical, legal, or financial circumstances make it infeasible to respond |
| 5 | Health IT Performance | Necessary for maintenance, updates, or to preserve or optimize performance |
| 6 | Content and Manner | Actor may decline a specific form or manner of access if technically not possible; must offer alternative |
| 7 | Fees | Reasonable, cost-based fees for providing access are permitted; unreasonable or discriminatory fees are not |
| 8 | Licensing | Licensing terms for health IT interfaces are reasonable and non-discriminatory (RAND) |
Exception details
Preventing Harm (Exception 1): The actor must have a reasonable, articulable basis for anticipating harm — not a speculative concern. A provider refusing to share records with a patient because they fear the patient might be upset does not meet this exception. Harm to physical safety (e.g., a domestic violence situation where disclosing address information could endanger a patient) is the intended scope.
Privacy (Exception 2): This exception applies when sharing would violate applicable privacy law — state law, HIPAA, or patient consent restrictions. A provider cannot cite a general privacy concern; there must be a specific legal restriction. HIPAA does not generally prohibit sharing records with patients or their authorized representatives, so this exception cannot be used to block patient access to their own data.
Security (Exception 3): Must be a specific, credible, documented security threat — not a general concern about cyber risk. Blocking all API access because of generalized security worries does not meet this standard.
Infeasibility (Exception 4): Genuine technical or resource limitations may apply, particularly for smaller providers. However, actors cannot claim infeasibility for interfaces or capabilities they are certified to support. For certified health IT, capability certification largely forecloses infeasibility claims.
Content and Manner (Exception 6): If an actor cannot fulfill a request in the specific format or manner requested, they may decline — but must offer a reasonable alternative manner. This exception is frequently relevant for EHR vendors who receive requests for data in non-standard formats. The alternative must be genuinely accessible, not a nominal offer.
Fees (Exception 7): Reasonable fees for providing EHI access are not information blocking. The fees must be cost-based, not punitive. Charging $50,000 for an API connection that costs $500 to maintain is not within this exception. ONC guidance provides criteria for assessing fee reasonableness.
Licensing (Exception 8): Health IT developers may require licensing for access to interfaces and APIs, but the terms must be non-discriminatory. Offering a competing EHR vendor worse licensing terms than a non-competing partner is a potential information blocking violation.
Penalties
The penalty structure differs by actor type.
Health IT developers, HINs, and HIEs
The Office of Inspector General (OIG) enforces the information blocking prohibition for health IT developers, HINs, and HIEs. The penalty is a civil monetary penalty of up to $1 million per violation.
OIG published its final enforcement rule in 2023, providing the procedural framework for investigations and penalties. OIG began initiating civil monetary penalty actions against health IT developers in 2024–2025.
A “violation” is not precisely defined per incident — OIG has discretion in determining how violations are counted. A pattern of blocking behavior could be assessed as a single violation or as multiple violations.
Healthcare providers
Providers face disincentives, not civil monetary penalties. CMS enforces provider-side information blocking, not OIG. Disincentives include:
- Reduced Medicare payment rates (similar to the Promoting Interoperability penalty structure)
- Exclusion from the Promoting Interoperability program under MIPS
CMS published its final disincentives rule in 2024. Providers who engage in information blocking can have their Promoting Interoperability score reduced to zero for the applicable performance period, resulting in a meaningful payment reduction.
The provider enforcement mechanism is softer than the health IT developer mechanism — but it is not toothless. A large health system losing Promoting Interoperability credit experiences real financial consequences.
What constitutes information blocking in practice
The following practices have been identified by ONC, OIG, and CMS guidance as likely to constitute information blocking (absent a valid exception):
For EHR vendors and health IT developers:
- Blocking or degrading data export functions when a customer is migrating to a competing EHR
- Charging excessive or discriminatory fees for API access or FHIR-based connectivity
- Implementing technical barriers to SMART App Launch authorization — non-standard OAuth flows, missing required scopes, token endpoint restrictions
- Requiring contracts that prohibit customers (health systems) from discussing or disclosing interoperability limitations publicly
- Delaying or not implementing required certification updates that affect data access
- Making data available only through proprietary interfaces when standardized FHIR APIs are certified
For healthcare providers:
- Refusing to send referral records to a provider at a competing health system without a clinical justification
- Declining to share records with a patient’s authorized representative
- Imposing conditions on data sharing (e.g., requiring the receiving party to use a specific vendor)
- Unreasonable delays in responding to patient data requests
Implications for EHR developers
Certified health IT is at the center of the information blocking rule. ONC’s certification program — the Certified Health IT Product List (CHPL) — is the primary lever. An EHR product cannot remain certified if the developer engages in information blocking. Certification withdrawal means the product can no longer be used by providers participating in Promoting Interoperability programs, which effectively removes it from the market.
Key obligations for EHR developers:
- Must implement and support standardized FHIR APIs (the g(10) criterion) without technical barriers
- Cannot impose contractual restrictions that would prevent customers from switching EHRs or discussing interoperability limitations
- Must support data export in standardized formats at reasonable cost
- API licensing terms must be non-discriminatory
Implications for healthcare providers
Providers are actors and can be found to engage in information blocking, but the enforcement mechanism is different. Providers should understand:
- Refusing to share records with a treating provider at another institution is a potential violation, not a HIPAA-justified act of caution
- Requiring patients to physically come in to retrieve records when electronic access is possible is an area of scrutiny
- Information blocking determinations for providers consider whether the practice is “unreasonable” — there is a reasonableness standard that does not apply to developers and networks
Providers should establish clear, documented policies for data sharing requests and ensure those policies do not systematically deny access without a valid exception basis.
Relationship to TEFCA and other ONC initiatives
The information blocking prohibition operates independently of TEFCA participation. Joining a QHIN under TEFCA does not satisfy the information blocking obligation — it provides a mechanism to exchange data, but does not excuse blocking practices through other channels.
TEFCA does, however, make compliance easier: having a QHIN connection provides a practical pathway to fulfill data sharing requests that might otherwise be technically infeasible.
See TEFCA for the QHIN participation framework.
See also
- ONC 21st Century Cures Act Final Rule — the regulatory framework that implements the § 3022 prohibition
- TEFCA — nationwide exchange framework that supports compliant data sharing
- Patient Access (US) — CMS-9115-F patient data access obligations for payers