For most of 2020, hospital compliance officers, EHR vendors, and health plan IT teams have been working from the same two documents: the ONC Cures Act Final Rule and the CMS Interoperability and Patient Access Final Rule, both published on May 1, 2020. Together they represent the most significant federal push yet to force patient health data out of closed systems and into standardized, API-accessible formats. They also introduce a new legal concept — “information blocking” — that did not previously exist in federal health IT regulation, along with a compliance calendar that has already shifted once this year because of the COVID-19 public health emergency.

This article summarizes what each rule finalized, who is affected, and where the compliance dates currently stand. Because enforcement timelines have moved once already in 2020 and could move again, organizations should treat the dates below as a snapshot and verify current requirements directly against ONC’s Cures Act Final Rule materials and the CMS Interoperability and Patient Access final rule before making final compliance decisions. Nothing here is legal advice.

Two Rules, One Policy Goal

The ONC interoperability final rule and the CMS rule were developed under separate statutory authority but released together and designed to reinforce each other.

  • ONC’s rule (“21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program”) implements Section 4004 of the 21st Century Cures Act. It defines information blocking, establishes exceptions to that prohibition, and updates the ONC Health IT Certification Program — including a requirement that certified health IT support a standardized, FHIR-based API.
  • CMS’s rule (“Interoperability and Patient Access,” CMS-9115-F) uses CMS’s authority over federally regulated payers to require Medicare Advantage organizations, state Medicaid and CHIP programs, and qualified health plan (QHP) issuers on the federally facilitated exchanges to expose patient claims and clinical data through a standards-based Patient Access API, and to make provider directory information available through a public API.

Read together, the two rules are meant to close the loop: ONC obligates health IT developers and providers not to block data flow and to build standardized APIs into certified products, while CMS obligates a large slice of the payer market to actually stand up patient-facing APIs using those same standards. Both rules point to HL7 FHIR (specifically FHIR Release 4) as the technical foundation, and both rules were published in the Federal Register on May 1, 2020, with an official effective date of June 30, 2020.

The Information Blocking Definition

ONC’s rule creates a new prohibition, drawn from the statutory text of the Cures Act: it is unlawful for a regulated “actor” to engage in a practice that the actor knows (or, for some actors, “knows or should know”) is likely to interfere with the access, exchange, or use of electronic health information (EHI) — unless the practice is required by law or fits within a defined exception.

Who Counts as an Actor

Three categories of entities are directly regulated:

  • Health care providers, a broad statutory category covering hospitals, physician practices, skilled nursing facilities, laboratories, pharmacies, and other licensed providers.
  • Health IT developers of certified health IT — companies, most commonly EHR vendors, that develop or self-certify products under the ONC Health IT Certification Program.
  • Health information networks and health information exchanges (HINs/HIEs) — organizations that enable data sharing among otherwise unaffiliated participants.

Providers are held to a “knowledge” standard: they must know a practice is unreasonable and likely to interfere with EHI flow. Developers, HINs, and HIEs are held to a stricter “knew or should have known” standard, reflecting their greater visibility into how their systems and agreements affect data flow downstream.

What Data Is Covered, For Now

At the outset, the scope of EHI subject to the information blocking provisions is intentionally narrowed to the data classes and elements defined in the United States Core Data for Interoperability (USCDI) — a bounded dataset meant to give actors a manageable starting point rather than immediately subjecting the entire designated record set to the new prohibition. ONC has signaled that this narrower scope is transitional and expects the definition to expand in a later rulemaking once the industry has more experience operating under the rule.

The Eight Information Blocking Exceptions

Recognizing that not every practice that limits data flow is problematic, ONC finalized eight exceptions — reasonable and necessary activities that will not be treated as information blocking provided their specific conditions are met. They fall into two groups.

Exceptions for Not Fulfilling Requests to Access, Exchange, or Use EHI

  • Preventing Harm Exception — covers practices reasonably designed to reduce a risk of harm to a patient or another person, where the risk is substantial and the practice is no broader than necessary.
  • Privacy Exception — protects an individual’s privacy where sharing would not be permitted under state or federal privacy law, or where the actor is honoring a patient’s own request to restrict disclosure.
  • Security Exception — allows an actor to interfere with access, exchange, or use of EHI to protect the security of that information, provided the practice is directly related to safeguarding confidentiality, integrity, and availability of data.
  • Infeasibility Exception — applies when an actor cannot fulfill a request due to circumstances outside its control, such as an uncontrollable event, an inability to segment the requested data, or a documented lack of technical capability.
  • Health IT Performance Exception — permits an actor to take reasonable steps to make health IT temporarily unavailable, or to degrade its performance, for purposes like maintenance or upgrades that benefit overall system performance.

Exceptions for Procedures Governing How Requests Are Fulfilled

  • Content and Manner Exception — allows an actor to limit the content of its response or the manner in which it fulfills a request, provided it first tries to reach agreement on an alternative manner and, failing that, fulfills the request in at least one of the manners required by the rule.
  • Fees Exception — permits charging fees, including fees that yield a reasonable profit margin, for accessing, exchanging, or using EHI, so long as fees are based on objective and verifiable criteria, reasonably related to costs, and not designed to discourage data sharing.
  • Licensing Exception — allows an actor to license interoperability elements (such as APIs) on reasonable and non-discriminatory terms, provided the licensing negotiation and terms meet specific conditions in the rule, including reasonable royalties and non-exclusivity.

Each exception carries its own detailed conditions in the regulatory text at 45 CFR Part 171; meeting the general description above is not sufficient on its own. Organizations evaluating a specific practice should work through the full conditions published by ONC rather than relying on the short summaries above.

The Standardized API and Certification Requirements

Beyond information blocking, ONC’s rule updates the ONC Health IT Certification Program with new Conditions and Maintenance of Certification requirements for health IT developers. The centerpiece is a requirement that certified health IT support a standardized, FHIR-based API that allows patient data to be accessed, exchanged, and used “without special effort,” including through third-party applications a patient chooses to authorize.

Key elements of the API requirement include:

  • Use of HL7 FHIR Release 4 as the base standard, paired with implementation specifications intended to promote a consistent developer experience across different certified products.
  • A requirement that the API expose, at minimum, the data classes and elements defined in USCDI.
  • Provisions barring developers from engaging in practices that unnecessarily restrict third-party application access to the API, including certain limits on information-blocking-adjacent contractual and technical restrictions.
  • A “Condition of Certification” structure meaning that developers who fail to meet these requirements risk having their health IT products’ certifications terminated, which can have downstream Medicare and Medicaid payment implications for the providers using that software.

The rule also finalizes a new 2015 Edition Cures Update to the certification criteria, which developers of certified health IT must implement in their products by the relevant certification deadline in order to remain certified.

The CMS Patient Access and Provider Directory APIs

CMS’s companion rule reaches the payer side of the interoperability equation. It applies to Medicare Advantage (MA) organizations, state Medicaid fee-for-service (FFS) programs, Medicaid managed care plans, CHIP FFS programs, CHIP managed care entities, and issuers of qualified health plans on the federally facilitated exchanges (FFEs). Traditional Medicare fee-for-service, standalone dental plans, and a handful of other plan types are outside the rule’s direct scope.

Patient Access API

Impacted payers must implement and maintain a secure, standards-based API — built to the same FHIR foundation referenced in ONC’s rule — that gives patients access to their own claims and encounter data, including cost information, and clinical data where the payer maintains it, through the third-party application of the patient’s choice.

Provider Directory API

The same set of payers (excluding QHP issuers on the FFEs, for whom this specific requirement does not apply in the same way) must make provider directory information — names, addresses, phone numbers, and specialties — available through a public-facing, standards-based API, so that third-party developers can build tools that help patients find in-network providers.

Payer-to-Payer Data Exchange

The rule additionally directs impacted payers to exchange certain patient clinical data with other payers, at the patient’s request, when a patient moves between health plans — intended to reduce the “data left behind” problem when patients change coverage.

Admission, Discharge, and Transfer Notifications

CMS finalized a Condition of Participation for hospitals, including psychiatric hospitals and critical access hospitals, that requires sending electronic patient event notifications for admissions, discharges, and transfers to other providers designated by the patient, where the hospital has the necessary technology in place.

Compliance Timeline, Including the COVID-19 Extension

The original May 1, 2020 rules set a series of compliance dates for both agencies. Because both rules became effective on June 30, 2020, but the country was simultaneously managing the early phase of the COVID-19 pandemic, ONC subsequently proposed and then finalized a delay to several of its own compliance dates.

  • Original information blocking compliance date: Information blocking provisions were originally set to become enforceable in November 2020.
  • COVID-19 extension: In an interim final rule with comment period published in the Federal Register on November 4, 2020, ONC extended the applicability date for the information blocking provisions from November 2, 2020 to April 5, 2021 — a roughly five-month extension. ONC cited the burden on providers, developers, and HINs/HIEs of assessing and adjusting their arrangements while simultaneously responding to the pandemic. The same interim final rule extended other certification-related compliance dates and timeframes by similar increments.
  • CMS Patient Access and Provider Directory APIs: CMS’s rule set a compliance date of January 1, 2021 for the Patient Access API and Provider Directory API requirements for the payer types described above.
  • CMS admission, discharge, and transfer notification requirement: Set to take effect approximately six months following the rule’s publication.

Because ONC’s information blocking extension was itself issued as an interim final rule with a comment period still open at the time of this writing, further adjustment is possible before April 2021 arrives. Readers should check HealthIT.gov and the Federal Register directly for the current status of these dates rather than relying on any single point-in-time summary, including this one.

What This Means Going Forward

Neither rule is self-executing overnight. ONC’s information blocking prohibition depends on a forthcoming enforcement framework — including the disincentives and penalties structure directed by the Cures Act — that has not yet been fully finalized. CMS’s API requirements, once in effect, will depend heavily on payers actually standing up functioning, standards-conformant APIs rather than technically compliant but practically unusable ones. Both agencies have signaled that they view 2020’s rules as a floor, not a ceiling, for interoperability policy, with USCDI scope, EHI definitions, and enforcement mechanisms all likely to evolve in subsequent rulemaking.

For now, the practical task facing covered actors is threefold: understand whether their organization is a regulated actor or impacted payer, map current practices against the eight information blocking exceptions where relevant, and confirm — directly with legal counsel and against the primary regulatory text — where their organization stands relative to the compliance dates above.

Frequently Asked Questions

What is the difference between the ONC rule and the CMS rule?

The ONC rule regulates health IT developers, providers, and health information networks/exchanges, defining information blocking and updating health IT certification requirements including a standardized API. The CMS rule separately requires specific federally regulated payers — Medicare Advantage, Medicaid, CHIP, and FFE qualified health plans — to build patient-facing data APIs.

Does the information blocking rule apply to insurance companies?

Not directly in most cases. The information blocking provisions apply to health care providers, health IT developers of certified health IT, and health information networks or exchanges. Payers are addressed instead through the separate CMS Interoperability and Patient Access rule, though a payer could become a regulated actor if it also functions as an HIN or HIE.

What happens if a health care provider is found to have blocked information?

As of this writing, the specific disincentives applicable to health care providers have not been finalized; that framework is expected in future rulemaking. Health IT developers and HINs/HIEs face potential civil monetary penalties for information blocking violations, subject to enforcement processes still being stood up by HHS.

Why was the information blocking compliance date pushed back?

ONC extended the original November 2, 2020 applicability date to April 5, 2021 through a COVID-19 interim final rule published November 4, 2020. ONC stated that providers, developers, and HINs/HIEs needed more time to assess and adjust their data-sharing arrangements while also responding to the pandemic.

What FHIR version do the rules require?

Both the ONC certification API requirement and the CMS Patient Access API point to HL7 FHIR Release 4 as the base interoperability standard, paired with specific implementation guides intended to promote consistency across certified products and payer APIs.

Are all health plans required to build a Patient Access API?

No. The requirement applies specifically to Medicare Advantage organizations, Medicaid and CHIP fee-for-service programs, Medicaid and CHIP managed care plans, and issuers of qualified health plans on the federally facilitated exchanges. Traditional Medicare fee-for-service and several other plan categories fall outside this particular rule.