The information blocking definition under the 21st Century Cures Act sounds straightforward: don't interfere with the access, exchange, or use of electronic health information. But in practice, the rules are layered with specific actor categories, eight named exceptions, and real financial penalties that took years to finalize.

If you're building or operating a healthcare application that connects to EHRs, this isn't abstract policy, it directly affects how you design data-sharing workflows, respond to access requests, and structure your business agreements. Getting it wrong, even unintentionally, can mean fines up to $1 million per violation for health IT developers. Getting it right means understanding exactly what the rule requires and where the boundaries are.

That's also why platforms like SoFaaS exist. We provide managed SMART on FHIR integration infrastructure that helps healthcare applications exchange EHR data using open standards, the same interoperability framework the Cures Act was designed to promote. When your integration layer already supports standardized, secure data access, you're building on a foundation that aligns with the rule rather than working against it.

This article breaks down the full information blocking rule: who it applies to, what counts as a violation, the eight exceptions that protect legitimate business practices, and the enforcement actions and penalties now in effect. Whether you're a health IT developer, a healthcare provider, or a health information network, here's what you need to know.

Why information blocking matters for patients and teams

When a patient switches providers, undergoes emergency care in a new city, or asks for a copy of their records, they're counting on that data to move with them. Information blocking disrupts that expectation in concrete ways, whether through delayed records, denied API access, or contractual terms that lock data inside one vendor's system. Understanding the information blocking definition matters not just for compliance officers, but for every person on your team who touches data architecture, vendor contracts, or patient-facing workflows.

How blocked data harms patient care

Delayed or withheld health data creates real clinical risk. When a treating physician lacks access to a patient's prior diagnoses, medication lists, or lab results, they make decisions with incomplete information. That can lead to duplicate testing, missed drug interactions, or treatment plans that contradict a patient's actual history. These aren't theoretical scenarios; they represent the everyday cost of fragmented health records.

The 21st Century Cures Act was specifically designed to address this fragmentation by making data sharing a legal obligation, not just an industry best practice.

The harm extends beyond individual appointments. Care coordination between providers depends on timely data exchange. A home health agency admitting a patient after hospital discharge needs that patient's discharge summary, medication reconciliation, and care plan available at the point of admission. When that information is held back, care gaps widen and readmission risk rises. Patients bear the direct consequences of every blocked data exchange.

What the rule means for your development team

For health IT developers, the information blocking rule reshapes several product decisions. How your application handles patient record requests, exports data, and manages API access must now be evaluated against the rule's requirements, not just user experience goals. If your application can technically return a patient's records but requires unnecessary steps, delays responses without a valid reason, or charges fees that exceed what the rule permits, you may already be in violation.

Your legal and compliance teams need to review vendor contracts and business associate agreements for language that could be read as restricting data access. That includes exclusivity clauses, data portability restrictions, and any terms that limit what users can do with their own health information. These contract provisions have surfaced in multiple enforcement investigations and represent one of the most common sources of unintentional violations.

Product managers and engineers also need to think about API availability. If your application is a certified health IT module, you're required to publish and maintain a compliant FHIR API endpoint. Downtime, rate limits, or technical barriers that go beyond what's operationally reasonable may qualify as information blocking under the interference prong of the rule.

Finally, operational teams managing data requests need clear internal policies. When a patient or provider submits a request for health information, your team needs to know the applicable response timeframes, what documentation to maintain, and when you're permitted to decline. Ambiguity in your internal process is not a valid exception under the rule, and enforcement investigations routinely expose organizations that lacked any documented procedure for handling access requests.

Who must comply and what counts as EHI

The information blocking definition under the 21st Century Cures Act doesn't apply to every organization in healthcare. Three specific actor categories carry the compliance obligation, and the scope of protected data has its own precise regulatory definition. Before you assess your organization's risk, you need to confirm whether the rule covers your business type and understand exactly which data falls under its protections.

The three actor categories

The 21st Century Cures Act targets three distinct groups that must comply with the information blocking rule. Each category carries specific obligations based on its role in the health data ecosystem, and if your organization fits more than one description, each role carries its compliance requirements independently.

• Health IT developers of certified health IT: Companies that develop, offer, or maintain health IT certified under the ONC Health IT Certification Program. If your application holds ONC certification or you are pursuing it, this category applies to you directly, and violations carry penalties up to $1 million per occurrence.
• Health Information Networks (HINs) and Health Information Exchanges (HIEs): Organizations that provide services enabling the exchange or use of EHI across unaffiliated entities. This includes networks that handle data routing, record locator services, or query-based exchange between providers.
• Healthcare providers: Hospitals, clinics, physician practices, and any individual or organization that meets the provider definition under HIPAA. Providers face the same prohibition on interference but are subject to civil monetary penalties determined by the HHS Office of Inspector General rather than ONC.

Your compliance obligations attach to your role in the ecosystem, not just your intent, so structure your review around what your platform actually does with health data.

What qualifies as electronic health information

Electronic health information (EHI) under the rule refers to electronic protected health information as defined in the HIPAA Privacy Rule, scoped to an identified individual's records. As of October 6, 2022, ONC expanded the applicable definition beyond the United States Core Data for Interoperability to cover all EHI a covered actor maintains. That expansion significantly widened what you must keep accessible and shareable.

Practically, clinical notes, imaging results, lab values, medication histories, care plans, and billing records all fall within scope when stored electronically and linked to an individual. You cannot limit your compliance efforts to structured FHIR data elements alone. Unstructured documents like discharge summaries and referral letters also qualify as EHI, provided they meet HIPAA's definition of ePHI, so your data access policies need to account for the full range of formats your system stores.

What counts as information blocking with examples

The information blocking definition covers three forms of prohibited conduct under the 21st Century Cures Act: interference with access to EHI, exchange of EHI, and use of EHI. Each form can occur through technology, contracts, pricing, or internal business practices. Recognizing what triggers a violation helps you evaluate your own systems before a patient complaint or ONC inquiry forces that review.

A practice doesn't have to be intentionally deceptive to qualify as information blocking; any action that is likely to interfere with EHI access, exchange, or use without a recognized exception can meet the standard.

Interference through technology and system design

Your application's technical behavior can constitute information blocking even when no human decision is involved. Common examples include building a patient data export feature that works only for certain record types, imposing undisclosed rate limits on your FHIR API that slow down third-party queries, or designing a user interface that buries the data-sharing consent flow so patients rarely complete it. Each of these creates a technical barrier that the rule treats as interference.

Specific scenarios that have surfaced in enforcement contexts include:

• Requiring users to submit data requests by fax when an electronic pathway exists
• Returning incomplete patient records through an API while the full record is available in the UI
• Delaying query responses beyond what system load actually justifies
• Disabling API access for competitors' applications while keeping it open for your own downstream products

Contractual and fee-based interference

Contract language is one of the most common sources of violations because it often restricts data portability without the parties recognizing the compliance exposure. A developer agreement that prohibits a customer from sharing patient data with another vendor, or a health system contract that bars use of patient records outside a specific clinical workflow, may directly conflict with the rule.

Fee structures also create violations. Charging prices that are not cost-based, non-discriminatory, and transparent when fulfilling EHI requests falls outside what the rule permits. If your pricing model sets different fees for different requestors without a documented, objective rationale, that disparity can be read as interference. Review your current rate schedules and any agreement language that conditions data access on purchasing additional services or maintaining exclusivity with your platform.

The eight exceptions and when they apply

The information blocking definition under the 21st Century Cures Act prohibits interference with EHI access, exchange, and use, but it also recognizes that not every restriction on data flow is harmful. ONC established eight named exceptions that protect legitimate business, clinical, and technical practices. If your organization's conduct fits squarely within one of these exceptions, you do not have a violation, but you must be able to show that your specific conduct meets each exception's documented conditions.

Claiming an exception after the fact, without records to support it, does not protect you during an investigation.

Exceptions that protect patients and system integrity

Four exceptions address situations where limiting data access is justified for safety or operational reasons. The Preventing Harm Exception permits you to block access when sharing EHI creates a serious, documented risk of harm to a patient or third party. The Privacy Exception lets you decline requests that conflict with a patient's own privacy preferences, applicable law, or HIPAA requirements. The Security Exception allows temporary restrictions when a specific, documented security threat exists on your systems or a connected network. The Health IT Performance Exception covers planned maintenance windows and unscheduled outages, as long as downtime stays limited to what the situation actually requires.

Each of these four exceptions requires written documentation. The protections they provide are organized around intent:

• Preventing Harm: objective clinical or safety criteria, applied consistently
• Privacy: conflict with patient consent, applicable law, or HIPAA
• Security: active, specific threat with a response plan on file
• Health IT Performance: published maintenance policy and bounded downtime

Exceptions that govern fees, content, and licensing

The remaining four exceptions focus on how you package, price, and license access to EHI. The Infeasibility Exception applies when fulfilling a request is not technically or operationally achievable, but you must document the specific barrier and respond to the requestor in writing. The Content and Manner Exception gives you limited flexibility to negotiate the format or delivery method when the requested format is not supported, as long as you still fulfill the request through an available alternative.

The Fees Exception permits you to charge for EHI access, but your fees must be cost-based, non-discriminatory, and fully transparent. You cannot use pricing to favor your own downstream products or penalize a competitor's application. The Licensing Exception allows you to set reasonable terms for licensing interfaces or technologies needed to enable access, provided those terms do not function as a practical barrier to interoperability.

How to avoid information blocking in practice

Understanding the information blocking definition is the first step, but applying it to your day-to-day operations is where most teams struggle. The rule doesn't require perfect systems; it requires documented, consistent practices that you can defend if a complaint arrives. Build compliance into your development workflow, your vendor agreements, and your internal request-handling procedures before a problem surfaces, not after someone files a complaint with ONC.

Build your API and data access layer to open standards

Your API is the most visible compliance surface your team controls. If you maintain a certified health IT module, you need a publicly documented FHIR endpoint that supports the data categories ONC requires and that stays available outside of disclosed maintenance windows. Rate limits, authentication requirements, and response times all need to reflect what your infrastructure actually requires, not what would slow down a competitor's application querying the same data your own tools access freely.

Documenting your technical decisions matters as much as making them. Keep records explaining why specific limits or configurations exist, what your maintenance policy covers, and how your team responds when a third-party developer reports an access issue. Those records are what separate a defensible operational choice from an unexplained barrier during an enforcement review.

When your integration layer uses open standards like SMART on FHIR, you eliminate a large class of technical blocking risk because the data exchange framework is transparent and independently verifiable.

Review your contracts and fee structures

Contract language that restricts what customers or partners can do with EHI is one of the most common sources of unintentional violations. Pull your vendor agreements, business associate agreements, and customer contracts and look specifically for clauses that limit data portability, restrict third-party integrations, or condition data access on purchasing additional products from your platform. Flag any of those terms for legal review before the next renewal cycle.

Your fee schedule for EHI access requests must be cost-based, transparent, and applied consistently across all requestors. If you charge different rates for equivalent services without a documented, objective rationale, that gap can be read as interference. Build a fee rationale document before you receive your first formal request, so your pricing decisions are already recorded and explainable when someone asks. Consistency is what the rule rewards, and inconsistency is what enforcement investigations typically find first.

Final takeaways

The information blocking definition under the 21st Century Cures Act covers a wide range of conduct across technology, contracts, and pricing structures. Three actor categories carry direct compliance obligations, eight named exceptions provide structured safe harbors, and penalties up to $1 million per violation are now actively enforced. If you build or operate health IT that touches EHI, this rule applies to your product decisions right now, not at some future compliance milestone.

Your best defense is documentation. Clear records of your API policies, fee rationale, and exception criteria protect you during enforcement reviews far better than good intentions alone. Build compliance into your workflows before a complaint arrives, not in response to one.

If your application needs to exchange EHR data using open, standardized infrastructure that aligns with the interoperability framework the Cures Act was designed to promote, launch your SMART on FHIR app on a managed platform that handles the technical complexity so your team stays focused on building.