The ONC information blocking FAQ documents have become essential reading for anyone building, selling, or operating health IT that touches electronic health information. Since the 21st Century Cures Act's information blocking provisions took full effect, the Office of the National Coordinator has published and updated its FAQ guidance multiple times, clarifying who qualifies as an "actor," what counts as information blocking, and which exceptions apply in specific scenarios. If you're responsible for a healthcare application that connects to EHRs, these answers directly shape what you can and can't do with patient data.

The problem is that ONC's guidance is spread across multiple documents, updated at irregular intervals, and written in regulatory language that doesn't always translate cleanly into engineering or product decisions. For health IT developers and product leaders, the real question isn't just "what do the rules say?", it's "what do I actually need to change?" That gap between regulatory text and practical implementation is where most teams get stuck, especially when they're managing integrations across multiple EHR systems with different technical requirements.

At SoFaaS, we build managed SMART on FHIR infrastructure that helps healthcare application teams connect to EHRs like Epic, Cerner, and Allscripts without owning the compliance and integration burden themselves. Information blocking compliance is closely tied to how data flows between systems, which makes it directly relevant to the integration layer we provide. This article breaks down the key takeaways from ONC's information blocking FAQ, the definitions, the exceptions, the recent updates, and explains what they mean for your health IT strategy going forward.

What the ONC information blocking FAQs are

The ONC information blocking FAQ is an official guidance document published by the Office of the National Coordinator for Health Information Technology. ONC developed it to interpret and apply the information blocking provisions in the 21st Century Cures Act, which Congress passed in 2016. Those provisions prohibit certain actors in the health IT ecosystem from engaging in practices that interfere with the access, exchange, or use of electronic health information (EHI). Because the statutory language left significant room for interpretation, ONC began publishing FAQ responses to give developers, providers, and health IT vendors concrete answers to real-world scenarios.

Where the FAQ guidance comes from

ONC's information blocking rule, finalized in May 2020, established the core framework, but the regulatory text alone doesn't cover every situation your team will encounter. The FAQ documents fill those gaps by addressing specific questions submitted by industry stakeholders, healthcare organizations, and developers. ONC publishes the FAQs on its official HealthIT.gov resource pages, and the agency updates them as new edge cases surface and as complementary regulations take effect. These aren't informal blog posts or policy summaries. They carry the same interpretive weight as official guidance, meaning regulators and enforcement bodies reference them when evaluating whether conduct qualifies as information blocking.

ONC FAQ responses reflect the agency's official interpretation of the rule, which means they directly influence how enforcement decisions get made.

What topics the FAQs cover

The FAQ documents address a wide range of issues, but several topics come up consistently across multiple releases. You'll find detailed responses covering which entities qualify as actors under the rule, what specific conduct constitutes interference, how to evaluate whether a practice falls within a recognized exception, and how the definitions of EHI and APIs apply in different technical contexts. ONC has also published FAQs specifically addressing the role of certified health IT, the treatment of fees, and how the information blocking provisions interact with other federal requirements like HIPAA. This breadth reflects the fact that information blocking compliance cuts across legal, technical, and operational functions simultaneously, so you rarely need just one answer in isolation.

Organized by topic area, the FAQ structure makes it possible to search by actor type, exception category, or technical standard. Individual FAQ answers often reference other sections of the rule or related guidance documents, and if you work through even a single thread carefully, you'll usually find that one answer surfaces two or three additional questions about your specific architecture or business model.

Who must comply and what counts as EHI

The 21st Century Cures Act defines three categories of actors that the information blocking rule covers: health IT developers of certified health IT, health information exchanges and networks (HIEs and HINs), and healthcare providers. If your company develops, offers, or maintains certified health IT, you fall squarely into the first category. The ONC information blocking FAQ has repeatedly clarified that this applies to the software product itself, not just the organization that builds it, which means the classification follows your product's certification status through every deployment context.

The three actor categories

Understanding which actor category applies to your situation determines what obligations you carry and which exceptions you can invoke. Health IT developers bear the broadest compliance surface because the rule covers any practice that interferes with access, exchange, or use of EHI through their certified software. Health information networks face similar obligations because they coordinate data flows across multiple entities. Healthcare providers occupy the third category, and while their compliance requirements are significant, enforcement priorities have concentrated more heavily on the health IT developer category in the early phases of implementation.

If your product connects to certified EHR systems via SMART on FHIR APIs, regulators treat your integration behavior as part of the compliance picture, not just your EHR vendor's.

What qualifies as EHI

EHI stands for electronic health information, and the scope expanded significantly as the rule phased in. Starting in October 2022, the definition covers all EHI within a designated record set as defined under HIPAA, not just the data elements in the United States Core Data for Interoperability (USCDI). This broader definition means your API responses, data transformation logic, and access controls now apply to a much larger portion of patient information than many teams initially planned for.

What the latest ONC FAQs clarify

ONC's more recent FAQ releases have moved beyond foundational definitions and focused on specific technical and commercial scenarios that health IT teams encounter in production. The onc information blocking faq updates address situations where earlier guidance left room for conflicting interpretations, particularly around API access, fee structures, and the scope of actor responsibilities across multi-vendor architectures.

API access and certified technology requirements

ONC has clarified that certified health IT must make standardized API access available to any application requesting it, provided the request meets the technical requirements defined in the certification criteria. This means you cannot restrict access to your API based on business relationship preferences alone. If a third-party application requests access using a conformant SMART on FHIR implementation, your obligation to respond is triggered.

Denying or degrading API access to a technically conformant application, without a recognized exception, meets the definition of information blocking under the rule.

ONC has also addressed fee-related practices more directly in recent FAQ answers, specifying that fees charged for API access must be cost-based, transparent, and non-discriminatory. Charging different rates to different requestors without a documented, legitimate cost-based rationale raises a compliance flag that enforcement bodies have specifically flagged.

Clarifications on multi-actor scenarios

Many health IT products involve more than one regulated actor, such as a developer licensing certified software to a provider who also contracts with an HIE. Recent FAQ responses make clear that each actor in that chain carries independent compliance obligations. You cannot point to another actor's responsibility to excuse your own conduct. ONC has specifically emphasized that contractual arrangements do not transfer or eliminate information blocking obligations between parties.

How to apply the FAQs to your product and contracts

Reading the onc information blocking faq is one thing; translating it into product decisions and contract language is another. Your starting point should be a documented actor assessment that confirms which category applies to your organization and your specific products. Once you know your actor category, you can map each FAQ answer to your technical stack and identify where your current implementation diverges from what the guidance requires.

Review your API access policies

Your API access policies are the most direct place where information blocking rules show up in your product. If you restrict API access based on business preference rather than technical criteria, you're exposed. Work through the specific FAQ answers covering certified API access and confirm that your approval workflows, rate limits, and access tiers carry a cost-based or technical justification you can document and defend. Key areas to audit include:

• Application approval workflows and denial criteria
• Rate limiting policies and how they apply across requestors
• Documentation supporting any access restrictions you currently enforce

Audit your vendor contracts

Contracts with EHR vendors, data intermediaries, and downstream application partners need to reflect independent compliance obligations clearly. The FAQs make it explicit that you cannot use a contract to shift your information blocking responsibilities to another party. Review any language that attempts to restrict data sharing or API availability in ways that a recognized exception doesn't cover, and flag those clauses for revision with your legal team.

Your contracts cannot override your information blocking obligations, regardless of what the other party agrees to.

Addressing both your technical architecture and your contract language together gives you a more complete compliance posture than either approach alone. Prioritize areas where FAQ guidance has been most recently updated, since those typically reflect the scenarios where enforcement attention is sharpest.

Common information blocking risks for API teams

API teams carry a disproportionate share of information blocking exposure because the integration layer is where restrictions on data access show up most concretely. Working through the onc information blocking faq helps, but most risks don't announce themselves clearly. They tend to appear as reasonable-sounding engineering decisions that, under the rule, look like interference.

Inconsistent access controls across requestors

The most common risk involves applying different access policies to different applications without a documented cost-based or technical justification. This includes rate limiting one vendor more aggressively than another, delaying approval for applications from competitors, or adding undisclosed steps to the onboarding process that don't apply universally. Each of these patterns can meet the definition of information blocking even if no one on your team intended it that way.

If your API access policies produce different outcomes for similarly situated requestors, you carry the burden of explaining why that difference is justified.

Common areas where this risk surfaces include:

• Application registration and approval workflows
• Rate limit tiers tied to contract status rather than technical need
• Token expiration policies applied selectively

Scope gaps in EHI coverage

Many API teams built their data access layer when USCDI was the operative scope, which means their implementations don't cover the full designated record set now required under the expanded EHI definition. If your API responses exclude data elements that fall within the broader scope, you may be limiting access in ways the rule prohibits. Audit your data mappings against the current EHI definition and confirm your FHIR resource coverage reflects what ONC now requires, not what it required at your original launch date.

Key takeaways and next steps

The onc information blocking faq documents give you the most direct window into how regulators interpret the rule when real-world edge cases arise. Your three immediate priorities are confirming your actor category, auditing your API access policies against the expanded EHI definition, and reviewing any contracts that attempt to shift compliance obligations you independently own. Treating those three areas as a starting checklist keeps your compliance work focused and defensible.

Acting on those priorities takes more than reading guidance documents alone. You need an integration layer that supports compliant data access without adding significant operational overhead to your team. SMART on FHIR infrastructure that handles OAuth flows, EHR connectivity, and audit logging by default reduces your exposure at the exact layer where most information blocking risks surface. If you're building healthcare applications that need to connect to EHRs quickly and compliantly, launch your SMART on FHIR app with SoFaaS.