If your healthcare product has to write into your customers’ EHRs, you usually encounter this problem: Your first customer runs their charts in an EHR with a developer program. Your second customer’s EHR offers an HL7 interface nobody on their staff can turn on. Your third charts inside a Citrix session. All three are the same kind of provider buying the same product from you, and only one of them has an EHR integration API your team can build against.
Whether that product is an AI scribe, a coding assistant, or a voice agent, it generates notes, codes, referrals, or orders, and that output has to land in whatever system of record each customer already runs.
This guide covers what the API route gets you, and how teams handle EHR write-back without an API.
What does an EHR integration API actually cover?
Less than the name implies. An EHR certified to ONC’s Base EHR definition must let you read patient data. Whether you can write is each vendor’s choice, and even a granted write API covers a subset of what the UI can do.
The regulatory baseline is real but narrow. ONC certification, under the Cures Act Final Rule as updated by HTI-1, requires Base EHR products to expose a standardized FHIR R4 API for patient and population data access.
The criterion only mandates read access to the USCDI data set. It does not require the EHR to accept a clinical note, an order, or a coding update through that same API. Write support is at each vendor’s discretion, and the ONC Certified Health IT Product List carries hundreds of certified health IT products whose API depth beyond the mandated read scope runs from excellent to nonexistent.
Authorization follows the same pattern. SMART on FHIR expresses permissions as scopes and defines write scopes alongside read scopes. Whether a given EHR honours a write scope for a note or an order is still the vendor’s decision.
The coverage map, then. A handful of large enterprise EHRs, Epic, Oracle Health, and athenahealth among them, offer real developer programs with some write capability, gated by app review, per-site approval and, at some vendors, fees. A middle tier offers HL7 v2 feeds, which still need middleware translating and routing messages, configured again at every site. Then there is the long tail: hospice EMRs, behavioral health systems, therapy documentation platforms, practice management tools. Many have no public write API at all. The way into those systems is the same one their own users take: the application itself.
Even a granted write API has edges. It exposes the operations the vendor chose to expose, and four gaps show up repeatedly:
- Documents. Uploading a scanned consent form, or pulling a generated report back out, is often UI-only.
- Workflow state. APIs move data. Marking a task complete in a work queue, acknowledging an alert, or triggering the routing that UI filing would have are frequently not exposed.
- Filing semantics. A note accepted through an API can land as an unsigned external document rather than filed to the right encounter. That is not the same outcome.
- Discovery. Listing today’s new or pending patients often has no API equivalent, because the endpoint expects an identifier you do not have yet.
This is the tier that surprises teams with full API access to a major EHR. The credential works, the endpoint responds, and the workflow still stops halfway.
What are the five options for EHR write-back?
Teams shipping clinical AI land on one of five approaches, and only the first two run on an API.
| Option | Cost shape | How it breaks | Who it fits |
|---|---|---|---|
| Native / custom API | Months per vendor; fees at some | Stops where the vendor offers no write access | One or two enterprise EHRs |
| Interop network (Redox, Health Gorilla, Metriport) | Subscription plus work on both sides | Needs the provider to stand up its half; a small practice often can’t | Hospitals and health systems |
| Selector-based RPA | Cheap to start, an engineer per portal | Silently, on every UI redesign | Stable internal tools |
| Your customer’s staff | Nothing on your invoice; all on their front desk | Unfiled notes become churn | The default until an integration exists |
| Browser agents | Per workflow, then per execution | Visibly: adapts, or stops and escalates with a typed reason | Many different systems, most without APIs |
That fourth row is the actual status quo. For most clinical AI products, the “integration” with a no-API system is the clinician or the front desk finishing the job by hand. That is the baseline the other four have to beat.
The first three share one property: their coverage is defined by someone else. The vendor decides whether an API exists. The network decides which systems it connects, and your customer decides whether they have anyone to connect them. Computer use workflows can invert that: if your customer’s staff can do the workflow in a browser or desktop, an agent can be built to that workflow, because the agent operates the same interface.
What that requires from your customer is a decision rather than a project. The provider organization provisions a dedicated, named account for the agent, scoped to the role and permissions the workflow needs, the way it would for any authorized tool it brings into the system. There is no integration build on their side.
Where vendor terms fit in
A compliance lead will ask whether automating the interface sits within the organization’s agreement with the vendor, and it is the right question. The answer depends on the agreement, and the agreement belongs to the provider organization, so that is where the decision lives.
Agents run only under credentials the provider organization provisions and authorizes, in its name and under its policies. Every action is attributable to that account and logged, so the audit trail reads the way a well-run staff account’s would. Where a vendor’s terms speak to automated access, we recommend confirming them with the vendor before go-live, the same conversation a practice would have before onboarding any third-party tool that touches the chart. That conversation is far easier to have with a named account, a defined scope, and a complete log than without them.
What browser agents look like in production today
One data platform serving post-acute and hospice care runs 33 production browser agents across 11 different EHR and portal systems, about 40,000 executions a month. For the workflows involved, no write API was available to that team. One system only runs inside a Citrix session, which rules out every DOM-based tool.
That team does not build one monolithic integration per system. Each agent is a small, single-purpose program: log in, navigate to the right screen, extract or enter the structured data, and end in an explicit success or failure state. Adding a customer on a new system means authoring one more focused agent rather than waiting for an API that may never ship.
How Asteroid handles systems with no write API
Asteroid is the execution layer for healthcare AI: one connector for every EHR, payer portal, registry, and desktop app that never shipped a usable write API, with verified execution and audit evidence on top, run under HIPAA with SOC 2 Type II certification.
In 2026 Asteroid launched Asteroid Integrate to connect to those systems out of the box. It is a catalogue of hundreds of prebuilt automations reachable through a single API call on the Scale plan, so for the systems your customers already run there is typically nothing to build and you are live in days.
When a customer arrives on a portal the catalogue doesn’t cover yet, your team builds that agent in Astro, Asteroid’s agent builder, in about 30 minutes, and it stays exclusively yours. Authoring is the half-hour. Credentialing and testing at the customer site are what make go-live a matter of days.
If your roadmap has an “integrations” line that keeps slipping, see the platform on a live workflow.
Figure: write-back without an API. The agent operates the same screens a coordinator does, across browser and remote-desktop systems, and every run ends in an explicit, auditable terminal state.
What escalates to a human?
These four situations route to a person rather than a guess:
- Credential and MFA events. Password rotations and authenticator prompts stop the run and route to a person at the provider organization. How a service account handles MFA is agreed with the customer up front, and where a vendor expects a human at that step, a human is who completes it. Agents never guess at auth.
- Portal version drift. When an EHR redirects to a redesigned or legacy interface, the agent recognizes a screen it was not built for. Depending on how the workflow is configured, it either repairs its own path and continues, or stops with a typed reason for a person to review. It does not improvise on a screen it does not recognize.
- Identity mismatches. If the patient record found doesn’t match the identifiers provided, the execution stops. Identity fields are never inferred.
- Portal maintenance and timeouts. Scheduled downtime and slow responses queue the work and retry, with a human notified if the queue stops clearing.
Every execution ends in an explicit terminal state with an audit trail. “The agent gave up cleanly and told you why” is a deliverable, and it is what makes the approach defensible to whoever reviews it at your customer.
Should you build or buy your EHR integration layer?
There are three ways to close this gap: build it, buy it, or leave it to your customer’s staff to finish by hand. Most products ship with the third without anyone having decided to.
Building one integration is reasonable. The cost is in the ones after it, because your customer list picks your systems for you, and sooner or later a customer arrives on an EHR with no write API at all. The set never closes. Each integration is a standing obligation, because the portal keeps changing after you are done. And the work competes with your product for the same engineers.
For an AI scribe or a voice agent, the integration layer is plumbing. Your customers did not buy you for it, and they cannot get your output without it. In healthcare the long tail is not an edge case; by product count, it is the market.
Further reading: healthcare workflow automation, what browser agents are, and computer use in healthcare.
Your AI already knows what should be in the chart. If getting it there is the bottleneck, book a demo and bring your hardest system.
All product and company names, including Epic, Oracle Health, athenahealth, Redox, Health Gorilla, Metriport, Citrix, and any EHR or portal systems referenced above, are trademarks or products of their respective owners. Asteroid is not affiliated with, endorsed by, or partnered with these vendors; names are used for identification and educational purposes only.