ai newsMi., 4. Nov.
EilmeldungGoogle’s first Suncatcher satellite runs an AI workload in orbit

EHR Automation Without an API: FHIR, RPA or AI Agents?

When your EHR integration stops one step short, here is how to choose between the API, an RPA bot and a computer-use agent, safely. Originally published on Nirmitee.io: EHR Automation Without API Access: FHIR vs RPA vs Computer-Use Agents (2026) Most EHR integrations stop one step short. Your team

dev.toMittwoch 05:46 · 04.11.3 Min. Lesezeit
Bild: dev.to

Posted on Nov 4 • Originally published at nirmitee.io

When your EHR integration stops one step short, here is how to choose between the API, an RPA bot and a computer-use agent, safely.

Originally published on Nirmitee.io: EHR Automation Without API Access: FHIR vs RPA vs Computer-Use Agents (2026)

Most EHR integrations stop one step short. Your team can read the patient and the referral through FHIR, but the booking, the coverage update or the claim edit still needs a person to click through the EHR.

So the question becomes: should you automate that last step, how, and who answers for it when it goes wrong? Here is the short version of how we think about it at Nirmitee.io.

Most EHR APIs read far more than they write, and the gap sits exactly where admin work piles up: scheduling, coverage, charges and work queues.

Epic's public FHIR R4 capability statement (read on 24 October 2026) lists 60 resource types. Only 14 allow a create, update or operation. Appointment, Coverage, Claim, ExplanationOfBenefit, Encounter and Account are read and search only. Oracle Health is more open on writes, including Appointment and Coverage. On athenahealth, booking goes through its own proprietary API rather than FHIR.

Before choosing any method, check the vendor's published capability statement, then check what your organization has actually switched on. The original post has a step-by-step table of common workflow steps across Epic, Oracle Health and athenahealth.

Use the API when it can do the whole step, an RPA bot when the screens are stable and the rules are fixed, and a computer-use agent when the step needs reading varied screens or documents.

Choosing between the API, an RPA bot and a computer-use agent. Source: Nirmitee.io

Most real workflows end up as a mix of all three.

When Epic runs over Citrix, the automation sees a picture of the screen, not its controls, so selector-based bots lose their usual hooks. Computer-use agents read the image directly, but they still need the same patient checks and read-after-write verification. Test both on your own Citrix sessions before choosing. Every Epic bot or agent also needs its own licensed Epic account.

A safe agent never acts on its own judgment alone. The source post describes the loop:

This split matters because models can be wrong in convincing ways. Anthropic's own computer use documentation warns that the model "sometimes acts as if its actions succeeded" without checking.

Two more rules: give every agent its own EHR account, because HIPAA requires unique user identification and audit controls for anything that touches ePHI. And never switch off multi-factor authentication for the agent.

What the agent does when something goes wrong. Source: Nirmitee.io

Whether screen automation is allowed depends on your contracts. Epic does not publish a public policy on bots, so the reliable answer comes from the health system's Epic team and its contract.

To judge the return, use one number: cost per verified completed case. That is everything you spend on automation, divided by the cases the EHR confirms as done. Compare it with what the same case costs your staff today, including the exceptions the automation sends back.

Do not lean on public benchmarks either. They measure general desktop tasks and say little about how an agent will do in your own EHR build. The full post explains the cost formula and the pilot approach step by step.

Pick one step that a person does many times a day, that your API cannot finish, and that you can test outside production. Count the volume, write down the exception types, and check the capability statement. If the API covers it, use the API. If not, choose between a bot and an agent, and agree the pass rules up front: zero writes to the wrong patient, every write verified, and a safe stop on every changed screen.

Nirmitee.io builds EHR automation as an engineering partner for healthtech companies and provider groups, starting from the API and adding screen automation only where the API stops. For the security objections table, the architecture and the vendor landscape, read the full guide: EHR Automation Without API Access on Nirmitee.io.

Dinesh Thorat is Healthtech Growth Partner at Nirmitee.io.

Quelle: dev.to (dev.to). Original öffnen