沒有 API 的 EHR 自動化：該選 FHIR、RPA 還是 AI 智能體？

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.

Check the API first

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.

Three ways to automate one step

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

• Vendor API (FHIR, proprietary or X12): the fastest and most stable option. It breaks when the customer has not enabled the API or the vendor changes versions.
• RPA bot: scripted clicks on known screen elements. Good for high-volume, identical steps. It breaks when a field moves, a label changes, or a Citrix upgrade removes the bot's extension.
• Computer-use AI agent: a model reads screenshots, proposes the next action, and software carries it out. Good for varied layouts, free-text notes and faxes. It is slower, because each step needs a screenshot and a model call.

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

Epic over Citrix is harder

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.

The model proposes. Code decides.

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

1. The work queue hands the agent one task, with the allowed actions for that task type.
2. The agent reads the patient banner and proposes one action, such as booking a specific slot.
3. A policy guard (plain code, not the model) compares at least two identifiers, such as name, date of birth or MRN, with the source record, and checks the action is allowed. A mismatch stops the task.
4. Only then does the agent make one write.
5. The record is reopened and the saved values and confirmation number are read back.

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.

Plan for the four ways it goes wrong

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

• Patient mismatch: no write happens. The task goes to an exception queue with the screenshot.
• Changed screen: if expected labels are missing, the agent stops before acting and engineers get an alert.
• Timeout after a click: check the record first. If the save happened, mark it done. If not, retry once.
• Bad save: if the read-back does not match, a person fixes it, and the case feeds the next test run.

Is it allowed, and is it worth it?

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.

Where to start

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.

Originally published at nirmitee.io.