Who Is Considered an Actor Under the ONC Information Blocking Final Rule?

If you handle Electronic Health Information in the United States, the ONC’s information blocking regulations likely touch your work. The rule defines three categories of “actors”: Health Care Providers, Health Information Networks or Exchanges, and Health IT Developers of Certified Health IT. Knowing which category you fall into is the first step toward Information Blocking Compliance.

Health Care Providers Definition

Health Care Providers are actors when they furnish, bill for, or are paid for health care services. The definition is intentionally broad to reflect how care is delivered across settings and specialties.

Who is included

• Hospitals, critical access hospitals, and health systems
• Physicians and group practices across all specialties
• Nurse practitioners, physician assistants, and other licensed clinicians
• Behavioral health, substance use disorder, and mental health providers
• Skilled nursing facilities, long‑term care, home health, and hospice
• Federally qualified health centers and rural health clinics
• Pharmacies, laboratories, imaging centers, and ambulatory surgery centers
• Dental, chiropractic, physical/occupational/speech therapy, and optometry practices

Scope notes

• You are an actor whether or not you use ONC Certification–certified technology; actor status depends on your role as a provider, not your software choices.
• If you self-develop health IT solely for internal use, you remain a Health Care Provider actor (not a Health IT Developer actor).
• Business associates (e.g., billing companies) are not Health Care Providers unless they independently meet another actor category.
• Health plans are not Health Care Providers for this rule, but they can be actors if they run a Health Information Network or Exchange.

Health Information Networks and Exchanges

Entities that organize, control, or enable the access, exchange, or use of Electronic Health Information for multiple unaffiliated parties are actors as Health Information Networks (HINs) or Health Information Exchanges (HIEs).

Practical distinctions

• Health Information Networks set or administer the policies, technical requirements, or agreements that allow many participants to share EHI (for example, nationwide frameworks or “networks of networks”).
• Health Information Exchanges provide the technical and operational services that enable EHI sharing across unaffiliated organizations (for example, state or regional exchanges, e-prescribing networks, or clinical data registries that broker exchange).
• An organization can function as both a HIN and an HIE; actor status attaches to the actual activities performed.

Examples of potential HIN/HIE actors

• Statewide or regional HIE organizations
• National exchange frameworks and trust networks
• Payer- or provider-led networks that set terms for multi-party EHI exchange
• Technology platforms that intermediate clinical data exchange for unrelated trading partners

Health IT Developers of Certified Health IT

Health IT Developers are actors when they develop or offer Certified Health IT under the ONC Certification Program. This category primarily includes EHR and module vendors whose products meet ONC Certification criteria.

Key inclusions and exclusions

• Included: Vendors that market ONC-certified EHRs or certified modules; organizations that develop certified health IT and offer it to others.
• Excluded: Companies that develop only non-certified health IT (e.g., device software, general analytics) unless they also operate as a HIN/HIE; providers that self-develop certified modules exclusively for internal use.

What actor status means for developers

• API obligations tied to ONC Certification, including supporting standardized, FHIR-based access without “special effort.”
• Contracting practices (licensing, non-disclosure, click-throughs) must not restrict lawful access, exchange, or use of EHI.
• Fees and terms must be reasonable and non-discriminatory when others seek to connect, use, or license certified capabilities.

Regulatory Scope and Updates

The rule’s core prohibition applies to any practice by an actor likely to interfere with the access, exchange, or use of EHI, unless an exception applies. EHI generally aligns with electronic protected health information in a designated record set and excludes psychotherapy notes and information compiled for reasonable anticipation of litigation.

Key milestones

• Applicability began in 2021, establishing baseline Information Blocking Compliance expectations for all actors.
• The scope of EHI expanded in 2022 to the full designated record set, increasing what must be made available for access, exchange, and use.
• Enforcement has continued to mature, including civil monetary penalties for certain actor types and programmatic disincentives for providers through federal health programs.

“Reasonable and necessary” exceptions

Eight exceptions describe when practices will not be considered information blocking if specific conditions are met and documented:

• Preventing harm
• Privacy
• Security
• Infeasibility
• Health IT performance (temporary unavailability or maintenance)
• Content and manner
• Fees
• Licensing

Your policies should map each exception to concrete workflows (for example, how you verify a privacy precondition or apply the infeasibility exception) to ensure consistent, auditable decisions.

Compliance Responsibilities

Regardless of actor type, you must enable lawful, standards-based access to EHI without unnecessary delay or burden. Effective compliance balances openness with patient safety, privacy, and security.

Program foundations

• Assign ownership: designate an information blocking lead and define escalation paths.
• Inventory data: identify all systems and locations that house Electronic Health Information, including third parties.
• Map request pathways: portal, API, HIE, Direct, query-based, bulk data, and records management requests.
• Standardize intake: create a single intake process that timestamps, tracks, and routes requests.

Operational practices

• Respond promptly: release available EHI without unnecessary delay; use exceptions only when conditions are met.
• Document exceptions: capture the rationale, criteria met, and evidence (e.g., risk assessments for security or preventing harm).
• Privacy and consent: align HIPAA and other privacy rules (including 42 CFR Part 2 where applicable) with your access policies.
• API readiness: support ONC Certification requirements for standardized APIs; publish connection processes and non-discriminatory terms.
• Contracts and fees: review terms for overbroad restrictions; align fees and licensing with the rule’s reasonableness conditions.
• Downtime protocols: define and communicate maintenance windows and fallback options consistent with the Health IT performance exception.
• Training and auditing: educate staff; run spot checks on turnaround times, denials, and exception use.

Provider-specific tips

• Automate patient portal release for commonly requested results and notes where safe and permitted.
• Establish a process for third‑party app connections that verifies request scope and identity while avoiding unnecessary hurdles.
• Coordinate HIM and privacy teams so HIPAA right‑of‑access deadlines never drive information blocking delays.

Developer and HIN/HIE tips

• Offer clear, published onboarding paths; avoid prolonged or opaque certification gating.
• Apply objective, consistently enforced security criteria to all similarly situated requestors.
• Structure fees to reflect reasonable cost and value; document methodology and comparators.

Role of the HHS Secretary

The HHS Secretary Authority shapes both the guardrails and the enforcement of information blocking. Through ONC, the Secretary defines the actor categories, the scope of Electronic Health Information, the certification framework for ONC Certification, and the “reasonable and necessary” exceptions. Through OIG and other HHS components, the Secretary oversees investigations, civil monetary penalties for certain actors, and coordination of provider disincentives across federal programs.

In practice, this means the HHS Secretary can refine definitions, update certification criteria, and align enforcement tools so that Health Care Providers, Health Information Networks, and Health IT Developers have clear, consistent expectations.

Implications for Stakeholders

If you are a Health Care Provider

• Expect patient and third‑party app requests to increase; design workflows to release EHI quickly and consistently.
• Align privacy, security, and clinical risk processes so exceptions are applied narrowly and documented well.
• Review vendor contracts for clauses that could restrict lawful sharing; seek amendments where needed.

If you operate a Health Information Network or Exchange

• Ensure participation agreements, policies, and trust frameworks do not impose unnecessary access barriers.
• Offer transparent, non‑discriminatory connection criteria and dispute resolution processes.
• Continuously monitor performance, uptime, and support to avoid practices that could be viewed as interference.

If you are a Health IT Developer of Certified Health IT

• Maintain API conformance and documentation; enable standardized FHIR access “without special effort.”
• Structure licensing and fees to be reasonable; avoid tying arrangements or restrictions that block lawful use.
• Provide customers with configuration options that facilitate compliance (e.g., granular data release and audit trails).

Conclusion

Under the ONC Information Blocking Final Rule, actors are Health Care Providers, Health Information Networks or Exchanges, and Health IT Developers of Certified Health IT. Your responsibility is to enable lawful access, exchange, and use of Electronic Health Information while applying the rule’s exceptions carefully and transparently. Treat Information Blocking Compliance as an ongoing program—anchored in patient trust, privacy, and interoperability—not a one‑time checklist.

FAQs.

Who qualifies as a health care provider under the ONC rule?

Any individual or organization that delivers or is paid for health care services qualifies, including hospitals, physicians, group practices, behavioral health providers, long‑term care, home health, pharmacies, laboratories, and many allied health professionals. You are an actor based on your role as a provider, regardless of which software you use.

What is the role of health information exchanges as actors?

Health information exchanges enable cross‑organization data sharing and are actors when they broker or control the exchange of EHI among unaffiliated parties. As actors, they must avoid policies, technologies, or terms that unreasonably impede access, exchange, or use of EHI and must apply the rule’s exceptions consistently.

How does the ONC define certified health IT developers?

They are entities that develop or offer ONC‑certified health IT—such as EHRs or modules—that meet ONC Certification criteria. These developers must support standardized APIs without special effort, avoid restrictive contracting that blocks EHI sharing, and structure reasonable, non‑discriminatory fees and licensing.

What are the compliance requirements for actors under the final rule?

All actors must enable lawful access, exchange, and use of EHI without unnecessary delay or burden, use and document one of the eight exceptions when limitations are necessary, and align privacy, security, and operational policies accordingly. Providers should streamline release workflows; HINs/HIEs should ensure open, fair participation terms; developers must meet ONC Certification obligations and avoid restrictive practices.