Information Blocking and HIPAA Explained: Rules, Exceptions, and How to Stay Compliant

Information Blocking Definition

The Information Blocking Rule prohibits practices by certain “actors” that are likely to interfere with the access, exchange, or use of Electronic Health Information (EHI), unless the practice is required by law or fits a defined exception. In plain terms, you must not create obstacles that keep patients, clinicians, or authorized apps from getting or using EHI.

Core concepts you should know

• Electronic Health Information (EHI): Electronic information that includes the electronic protected health information in a designated record set, such as medical records, billing records, and records used to make decisions about individuals.
• Access, exchange, or use: Getting EHI, sharing it with another party, or putting it to work for treatment, payment, operations, or patient-directed purposes.
• Practice: Any organizational policy, contract term, technology setting, or workflow that materially affects access to EHI.
• Knowledge standard: An actor knows, or should know, the practice is likely to interfere with access, exchange, or use of EHI.
• Exceptions: Specific, narrowly tailored safe harbors that, if satisfied, mean the practice is not information blocking.

Common practices that can trigger risk

• Delaying portal release of results without a valid exception.
• Refusing to enable standards-based APIs or blocking third-party apps without objective, documented security criteria.
• Using contracts to restrict data sharing or to forbid patient-directed app connections.
• Charging unreasonable or discriminatory fees for interfaces, exports, or patient access.
• Requiring manual steps when automated exchange via certified API is feasible.

Applicable Entities

The rule applies to three actor types. Your obligations depend on which role you play, but the prohibition on information blocking reaches all three.

• Health care providers: Hospitals, clinicians, laboratories, pharmacies, long‑term care facilities, and many others, regardless of size or specialty.
• Health IT developers of certified health IT: Companies that develop or offer certified EHRs, APIs, or modules under the Health IT Certification program.
• Health information networks (HINs) and health information exchanges (HIEs): Organizations that control, facilitate, or govern the exchange of EHI among multiple unaffiliated parties.

Being a HIPAA covered entity or business associate is not what determines applicability; being an “actor” under the Information Blocking Rule does. Many organizations fit more than one category and should align policies accordingly.

Exceptions to Information Blocking

Exceptions recognize that safe, private, and workable information sharing sometimes requires limits. To rely on an exception, you must meet all its specific conditions and apply them consistently and non‑discriminatorily.

Exceptions that allow not fulfilling a request

• Preventing Harm Exception: You may withhold EHI if sharing is reasonably likely to cause substantial harm to a patient or another person, following an objective, evidence‑based process and documenting the decision.
• Privacy Exception: You may decline to share when doing so would violate privacy laws or the individual’s preference, or when you lack a required authorization.
• Security Exception: You may implement measures that are directly related to safeguarding EHI, tailored to specific risks, and applied using objective, documented criteria.
• Infeasibility Exception: You may deny a request when it is not feasible to fulfill due to uncontrollable events, segmentation limitations, or lack of necessary technology—provided you explain the reasons and offer reasonable alternatives when possible.
• Health IT Performance Exception: You may take reasonable, time‑limited steps—such as scheduled maintenance or addressing system outages—that temporarily limit sharing to maintain the performance and safety of your systems.

Exceptions that govern how you fulfill a request

• Content and Manner Exception: If you cannot provide EHI exactly as requested, you may offer the content in an alternative, readily producible format or manner, using available standards and without unnecessary delay.
• Fees Exception: You may charge reasonable, cost‑based fees for certain services (for example, maintaining APIs or large‑scale data exports) so long as fees are not anti‑competitive, are applied uniformly, and do not target specific requesters.
• Licensing Exception (Interoperability Licensing): You may license interoperability elements—like APIs or vocabularies—on reasonable and non‑discriminatory terms. Licensing must not be used to block access or to favor certain parties.

How to use exceptions effectively

• Map each exception to clear criteria, approvers, documentation, and time limits.
• Respond promptly even when denying a request; explain the rationale and suggest feasible alternatives.
• Keep evidence, such as risk assessments or patient preferences, that supports your decision.

Compliance Requirements

Governance and accountability

• Appoint an information sharing lead, align legal, compliance, IT, privacy, and clinical operations, and review high‑risk practices quarterly.
• Adopt written policies for intake, triage, and fulfillment of EHI requests, with escalation paths and time targets.

Technology and Health IT Certification alignment

• Ensure your certified EHR and APIs are implemented as designed—enable standardized FHIR APIs, patient‑facing apps, and EHI export capabilities.
• Monitor vendors for uptime, release management, and settings that could inadvertently restrict access or exchange.

Operational playbooks

• Define when results release is immediate versus delayed under a valid exception; log all delays with reasons.
• Standardize third‑party app review to objective, security‑focused criteria; avoid custom hurdles or duplicative attestations.

Contracts, licensing, and fees

• Update agreements to remove anti‑sharing clauses; use Interoperability Licensing terms that are reasonable and non‑discriminatory.
• Publish fee schedules tied to actual costs; avoid requester‑specific or volume‑based surcharges that deter exchange.

Privacy and security coordination

• Harmonize HIPAA policies with the Privacy Exception and Security Exception; apply minimum necessary where required but never to disclosures to the individual.
• Maintain audit trails showing who requested EHI, what was shared, timing, and the exception rationale (if any).

Enforcement and Penalties

The Office of the Inspector General investigates alleged information blocking. For health IT developers of certified health IT and for HINs/HIEs, violations can trigger civil monetary penalties that are substantial and may be assessed per violation. Providers face programmatic disincentives administered through federal payment and quality programs.

Expect enforcement bodies to weigh factors such as the actor’s intent, duration and scope of impact, the number of patients or clinicians affected, financial gain, and corrective actions taken. Developers also risk consequences under Health IT Certification if certified capabilities are disabled or not made available as required.

Relationship with HIPAA

HIPAA sets the baseline for privacy and security; the Information Blocking Rule promotes timely, practical sharing within that framework.

Right of Access versus information sharing

HIPAA’s Right of Access sets outer time limits and fee rules for disclosures to individuals. Information blocking focuses on avoiding unnecessary delays and obstacles—especially through APIs and portals—so patients and clinicians can use data without friction.

Minimum necessary and patient-directed sharing

Minimum necessary does not apply to disclosures to the individual, and you should not use it to delay patient‑directed app connections. For other disclosures, apply minimum necessary in a way that fits the Privacy and Security Exceptions.

Business associates and vendor roles

Vendors may be actors even if they are not HIPAA covered entities. Align business associate agreements and service terms so they support, rather than restrict, lawful EHI sharing.

Reporting Information Blocking

You can report suspected information blocking to federal authorities. Clear, well‑documented submissions speed triage and help regulators see patterns across similar cases.

Before you report

• Confirm the requester’s authority, the EHI requested, and the specific practice that prevented access, exchange, or use.
• Check whether a valid exception applies and whether the actor offered a reasonable alternative.
• Escalate internally to seek rapid remediation and preserve evidence.

Where to report

• Submit complaints about developers, HINs, or HIEs to the Office of the Inspector General.
• Submit complaints about any actor through the federal information blocking complaint portal operated by the national interoperability program.
• Report suspected Health IT Certification noncompliance (for example, disabled APIs) to the certification program for follow‑up.

What to include

• Actor name and role (provider, developer, HIN/HIE) and points of contact.
• A timeline of events, communications, and screenshots or logs.
• The EHI requested, the manner requested, and any alternative offered.
• The exception cited (if any) and why you believe it does not fit.

Conclusion

Information blocking and HIPAA work together: protect privacy and security while ensuring EHI is shared without unnecessary friction. If you align governance, technology, contracts, and training to the exceptions and the Health IT Certification capabilities you already have, you will reduce risk, speed care, and stay compliant.

FAQs

What is information blocking under HIPAA?

Information blocking is not a HIPAA rule; it stems from the 21st Century Cures Act. It prohibits actors from engaging in practices that are likely to interfere with access, exchange, or use of Electronic Health Information unless a narrow exception or another law allows the limitation.

How do exceptions apply to information blocking?

Exceptions are detailed safe harbors. If you meet all conditions—such as using objective security criteria, documenting a preventing‑harm assessment, showing infeasibility, or offering content in an alternative manner—your practice is not considered information blocking.

Who enforces information blocking rules?

The Office of the Inspector General investigates and can impose civil monetary penalties on health IT developers and HINs/HIEs. Providers face programmatic disincentives administered through federal payment and quality programs, and certification authorities oversee compliance with Health IT Certification requirements.

How can entities report suspected information blocking?

Collect facts, determine whether an exception applies, and escalate internally. If unresolved, submit a complaint through the federal information blocking complaint portal and, when appropriate, report to the Office of the Inspector General, including timelines, communications, and evidence supporting your claim.