Announcing CIMD support for MCP Client registration
Learn more

The Healthcare API Access Nobody Can Revoke

Nityashree Yadunath
Product Marketing Manager

In February 2023, Twitter ended free access to the API a decade of products had been built on. Four months later, Reddit repriced its API and the most popular third-party clients shut down within weeks. LinkedIn locked its API down years earlier. The lesson developers took away: when you build on a platform's API, your access exists at the platform's pleasure.

There is one market where that lesson does not apply. In US healthcare, API access to the system of record is not a platform's gift. It is federal law.

Platform APIs are revocable by design

A platform API is a business decision, and business decisions get reversed. Pricing changes, acquisition, a strategy pivot toward first-party AI: any of these can end or reprice your access, and the terms of service almost always allow it. Teams that build core product functionality on revocable APIs carry that risk permanently, and the last three years supplied enough cautionary examples that most engineering leaders now price it in.

EHR access is statutory

The 21st Century Cures Act (2016) and the ONC Interoperability Rule (2020) require every certified EHR in the US to expose patient data through a standardized FHIR API using SMART on FHIR authorization. Certification is the ticket to selling an EHR into most US healthcare settings, so the requirement covers the market that matters: Epic, which runs 43.7% of US acute care hospitals, Oracle Health (21.9%), Meditech (14.7%), AdvancedMD, Athenahealth, eClinicalWorks, NextGen, Allscripts, and Veradigm.

The enforcement is real. Since September 2023, the HHS Office of Inspector General can fine EHR vendors and health information networks up to $1 million per information-blocking violation. An EHR vendor that cuts off a legitimate application's standardized API access is not making a business decision; it is creating legal exposure.

Compare the two positions. A team building on a consumer platform's API holds access that can be repriced or revoked with a blog post. A team building on SMART on FHIR holds access backed by statute, uniform across every certified vendor, with penalties on the other side for taking it away.

How the mandate happened

The guarantee did not appear from nowhere; it took fifteen years of policy to build, and knowing the sequence explains why it will not be walked back. The HITECH Act of 2009 spent roughly $35 billion in incentives getting US healthcare off paper. It worked: by the mid-2010s nearly every hospital ran an EHR. What it did not produce was access. The records were digital and siloed, and the vendors holding them had every commercial reason to keep it that way. A hospital that cannot easily move its data is a hospital that does not switch vendors.

Congress answered with the information-blocking provisions of the 21st Century Cures Act in 2016: interfering with the access, exchange, or use of electronic health information became illegal, for EHR vendors, health information exchanges, and networks. The ONC Interoperability Rule of 2020 then turned the legal principle into a technical specification. Certified EHRs must expose a standardized FHIR R4 API with SMART on FHIR authorization, and they had until the end of 2022 to ship it. The final layer arrived in 2023, when the OIG's civil monetary penalty rule gave the mandate teeth.

Statute, then specification, then enforcement. Each layer took an act of government to build, which is exactly why the access is durable: unwinding it would take an act of government too. Compare that with a platform API, where unwinding your access takes a product meeting.

What this means for agent builders

Healthcare has a reputation as the hardest place to build software: compliance, procurement, integration pain. All true. But for AI agent products specifically, it offers something no other vertical does: the data access an agent needs in order to be useful is guaranteed, standardized, and permanent. An agent that preps charts, reconciles medications, or files diagnostic reports is building on a foundation no vendor can pull.

The durability argument compounds. Agent products live or die on their integrations, and integration risk is a real line item in any build-versus-buy analysis. In most verticals that risk includes the platform simply deciding your product should not exist. In healthcare, that specific risk is off the table.

Guaranteed access is not easy access

The law mandates that the door exists. It does not make the door easy to use. SMART on FHIR is a substantial protocol: OAuth endpoints discovered from the FHIR server's /metadata capability statement, tokens bound to a specific server through the aud parameter, a clinical scope grammar, and per-vendor registration processes and quirks on top. That implementation work is exactly what Scalekit now handles end to end: auto-discovery against any FHIR-compliant EHR through the generic SMART on FHIR connector, and a pre-built AdvancedMD connector with 30 tools agents call as the authenticated user.

What the mandate does not cover

Honesty about the boundaries makes the guarantee more useful, not less. Three things the law does not give you.

Registration is still per vendor. The mandate obligates each certified EHR to expose the standardized API, but you still register your application through each vendor's own program, on each vendor's own timeline. The access is guaranteed; the onboarding is not instant.

Only the standardized API is protected. Vendors ship proprietary APIs beyond the certified FHIR surface, and those remain ordinary platform APIs with ordinary platform risk. Build your core data path on the certified surface and treat anything proprietary as a bonus, not a foundation.

The law mandates existence, not developer experience. Endpoint discovery from /metadata, the aud parameter, SMART scope grammar, per-vendor quirks, token lifecycle across hospital tenants: all of it is still yours to implement correctly, multiplied by every EHR your customers run. The mandate opened the door; walking through it cleanly is engineering work. That layer is what Scalekit ships: discovery, authorization, scope enforcement, and tool execution against any FHIR-compliant EHR, so the guaranteed access becomes usable access.

Frequently asked questions

Is EHR API access really required by law?

Yes. The 21st Century Cures Act and the ONC Interoperability Rule require every certified EHR in the US to expose patient data through a standardized FHIR API with SMART on FHIR authorization. Since September 2023, the HHS Office of Inspector General can fine EHR vendors and health information networks up to $1 million per information-blocking violation.

Which EHR systems have to comply?

Every certified EHR: Epic, Oracle Health, Meditech, AdvancedMD, Athenahealth, eClinicalWorks, NextGen, Allscripts, Veradigm, and the rest of the certified list. Certification is what lets these systems be sold into most US healthcare settings, so the mandate covers effectively the whole market.

Does this guaranteed access apply to AI agents?

The mandate covers applications that access patient data through the standardized API, and an AI agent authorizing as a user through SMART on FHIR is such an application. The agent still needs to implement the standard correctly and pass each vendor's registration process.

If you are choosing a vertical to build in

The question worth asking about any market is what happens to your product when the platform underneath it changes its mind. In healthcare, the answer is written into federal law. If you are building an agent that acts on patient data, talk to us about your EHR.

No items found.
Agent
Auth Quickstart
On this page
Share this article
Agent
Auth Quickstart

Acquire enterprise customers with
zero upfront cost.

Every feature unlocked. No hidden fees.