The ONC Information Blocking Rule changed how electronic health information moves between systems, providers, and patients. Since its enforcement began, healthcare organizations and health IT developers have faced real consequences for practices that interfere with the access, exchange, or use of EHI. Yet confusion around the rule persists, and searching for ONC information blocking FAQs often leads to dense legal language that raises more questions than it answers. This article breaks down the most common questions about information blocking in plain terms.

Understanding what counts as information blocking (and what doesn't) matters for anyone building or operating health IT. The rule defines specific exceptions that allow certain restrictions on data sharing, but only when those restrictions meet clearly outlined conditions. Penalties have also evolved, and compliance expectations continue to tighten as ONC refines its enforcement approach alongside existing HIPAA frameworks.

At SoFaaS, we build managed infrastructure for SMART on FHIR integration, the same interoperability standard that underpins much of the data-sharing activity these regulations target. Our platform helps healthcare application developers connect to EHRs like Epic, Cerner, and Allscripts without getting buried in the technical and compliance overhead that information blocking rules intensify. Below, we walk through the rules, exceptions, and penalties you need to know, organized as straightforward answers to the questions we hear most often.

Why the ONC information blocking FAQs matter

The 21st Century Cures Act gave the Office of the National Coordinator for Health Information Technology (ONC) a clear mandate: prevent practices that interfere with the free flow of electronic health information. When ONC published its final rule in 2020, it created binding obligations for three distinct categories of actors: healthcare providers, health IT developers certified under the ONC Health IT Certification Program, and health information networks or exchanges. That scope is wide, and the rule's reach into everyday workflows is broader than most organizations initially expect. Many teams that build or operate health IT underestimate how quickly a routine data-sharing decision can cross into regulated territory.

The rule applies to more organizations than you might think

Many organizations assume information blocking rules only apply to large hospital systems or EHR vendors. That assumption is wrong. If your company develops, offers, or maintains health IT that touches certified functionality, you are likely subject to the rule whether you are a startup or an enterprise. Similarly, a small physician practice can be classified as a healthcare provider actor under the regulation, which means your front-desk workflows, data-sharing policies, and patient request processes all fall within scope.

The ONC information blocking FAQs published at HealthIT.gov make clear that the rule's intent is to capture a broad range of practices, not just obvious vendor-level restrictions on data access.

Reviewing the official ONC information blocking FAQs helps you identify whether your current processes include any practices that could be flagged during an investigation. ONC and the HHS Office of Inspector General have both signaled that enforcement activity is actively expanding, which means the risk of operating on assumptions rather than verified compliance grows with each passing enforcement cycle.

Penalties are real and tiered by actor type

The consequences for information blocking are not uniform across organizations. Health IT developers, health information networks, and health information exchanges face civil monetary penalties of up to $1 million per violation under 42 U.S.C. 300jj-52. Healthcare providers currently face "appropriate disincentives" determined by HHS, which can include exclusion from Medicare and Medicaid programs under rules finalized in 2024. These distinctions matter significantly when you assess your own exposure and decide where to invest compliance resources.

Understanding which category your organization falls into changes how you prioritize compliance work at a practical level. A health IT developer building a SMART on FHIR application sits in a different enforcement category than a provider clinic, and the conditions for each exception apply differently depending on which actor type you are.

What counts as information blocking and who is an actor

Under the rule, information blocking means any practice by a regulated actor that is likely to interfere with the access, exchange, or use of electronic health information (EHI), unless that practice qualifies under one of the defined exceptions. The definition is intentionally broad, which means you cannot rely on intent to shield your organization. If a practice has the likely effect of restricting EHI flow, it meets the threshold regardless of the reason behind it.

The definition of information blocking

The ONC information blocking FAQs published at HealthIT.gov clarify that both direct and indirect interference count under the rule. This includes technical practices like system configurations that slow data requests, contractual terms that discourage data sharing, and business policies that create unnecessary friction for patients or providers requesting records. You do not need to have malicious intent for a practice to qualify as information blocking.

A configuration decision that delays a FHIR API response by design can constitute information blocking just as readily as a contract clause that restricts data access.

The three categories of actors

Your organization falls into one of three specific actor types: healthcare providers, certified health IT developers, and health information networks or exchanges (HINs/HIEs). If your business fits any one of these categories, your data-sharing practices, system design choices, and contractual agreements all carry regulatory weight. Healthcare providers include individual clinicians, hospitals, and group practices. Certified health IT developers include any company that develops or offers ONC-certified products. HINs and HIEs cover networks that connect multiple providers or facilitate health data exchange between organizations.

What electronic health information includes and excludes

The scope of electronic health information (EHI) under the information blocking rule is broad by design. Since October 2022, EHI covers the full United States Core Data for Interoperability (USCDI) standard and extends to essentially any electronic protected health information (ePHI) as defined under HIPAA. If your system stores, processes, or transmits patient health data electronically, that data is almost certainly within scope.

What EHI covers

EHI includes all ePHI in your designated record set, which means clinical notes, lab results, medications, diagnoses, immunization records, care plans, and patient demographics all qualify. The ONC information blocking FAQs at HealthIT.gov confirm that this scope is not limited to structured data. Unstructured content like scanned documents and free-text clinical notes counts as EHI too, so long as it exists in an electronic format and falls within your designated record set.

The rule does not require the data to be in a FHIR-formatted resource for it to qualify as EHI. Format does not determine scope.

What falls outside EHI

Not every piece of electronic data in a health IT system is EHI for information blocking purposes. Psychotherapy notes kept separately from the rest of a patient's record are excluded, as are data compiled in anticipation of civil, criminal, or administrative proceedings. Information maintained by an employer in its role as an employer rather than as a healthcare provider also falls outside the definition.

Your legal and compliance review should map specific data types to these exclusions before you rely on them. Assuming a data category is excluded without verifying it against the regulatory text creates real enforcement risk for your organization.

The main exceptions explained with examples

The rule defines eight exceptions that allow actors to restrict or limit EHI access under specific, tightly scoped conditions. Each exception requires you to meet defined criteria before it applies. A practice does not automatically qualify just because it resembles an exception on the surface. Reviewing the ONC information blocking FAQs at HealthIT.gov directly is the most reliable way to verify whether your specific situation qualifies under any of these exceptions.

Privacy and preventing harm exceptions

The Privacy Exception lets you decline an EHI request when fulfilling it would conflict with applicable privacy law, such as state regulations that impose stricter requirements than HIPAA. For example, if a patient in a state with heightened mental health data protections requests that you share their records with a third party, and that state law restricts the release, you can decline that request without committing information blocking.

The Preventing Harm Exception applies when sharing EHI would create a reasonable risk of harm to the patient or another person, but this exception requires documented clinical or professional judgment, not a general assumption of risk.

Licensing and fees exceptions

The Licensing Exception covers situations where an actor must protect legitimate intellectual property interests. If a health IT developer requires a license agreement before sharing access to proprietary software interfaces, that requirement can qualify, provided the terms are reasonable and non-discriminatory.

Your fees structure also carries regulatory weight here. The Fees Exception permits actors to charge for accessing or exchanging EHI, but only when those fees reflect reasonable costs and do not function as a barrier designed to obstruct data flow. Excessive or discriminatory pricing does not qualify under this exception.

How to stay compliant in real workflows

Turning regulation into daily practice requires specific process changes, not just a policy document. Your compliance posture depends on whether your team can identify a potential information blocking issue before it reaches a patient, provider, or regulator. The ONC information blocking FAQs at HealthIT.gov serve as a reliable starting point for reviewing your current workflows against the rule's actual requirements, but that review needs to translate into operational checkpoints your team follows consistently.

Map your data flows before you configure your systems

Your first step is documenting every point where EHI enters, moves through, or exits your system. This includes API configurations, access control settings, contractual data-sharing terms, and patient-facing request processes. If any of these touchpoints create friction that slows or restricts EHI access without a qualifying exception, you have a compliance gap to close before enforcement activity finds it.

A configuration that requires manual approval for every FHIR API request may look like a security measure, but it can constitute information blocking if that friction is not justified by a documented, qualifying exception.

Build a review process that connects your technical team to your compliance function so that system changes get evaluated before they go live, not after a complaint surfaces.

Audit your contractual terms and vendor agreements

Many organizations focus their compliance work on technology configurations and overlook contract language with vendors, partners, and customers. Clauses that restrict downstream data sharing or create exclusivity over data access can qualify as information blocking. Review each agreement against the Licensing and Fees exceptions to confirm your terms meet the non-discriminatory and reasonable-cost standards the rule requires. Document your reasoning for each contract term so you can demonstrate compliance intent if a review occurs.

Quick wrap-up

The ONC information blocking rule applies to a wide range of organizations, and the consequences for non-compliance are real. Knowing which actor category fits your organization, what EHI your systems handle, and which exceptions actually apply to your workflows gives you a foundation for compliance that holds up under scrutiny. Reviewing the ONC information blocking FAQs at HealthIT.gov regularly keeps your team aligned as enforcement guidance evolves.

Your data-sharing infrastructure plays a direct role in whether you stay compliant or fall into a gap you did not anticipate. If your application needs to connect with EHRs like Epic or Cerner, the technical and compliance overhead involved is significant. SMART on FHIR integration built on a managed, HIPAA-compliant platform reduces that risk from the start. Launch your SMART on FHIR integration with pre-built EHR connectors and built-in compliance infrastructure so you can focus on building your application instead of navigating integration complexity.