Healthcare operations guide
EHR automation, including the half that has no API
Almost every guide on this topic gives the same advice: use the FHIR API. That advice is fine right up to the moment you try to write something back. The free, publicly available FHIR APIs on Epic and Cerner are essentially read-only, so the expensive manual work (registration, order entry, keying values off a scanned fax, reconciling the EHR against a billing system) sits in screens no API will write to. This guide sorts EHR tasks into the two buckets that actually matter, then explains how to automate the one everybody skips.
Direct answer (verified 2026-06-17)
What EHR automation is, and the catch nobody states.
EHR automation is software that runs repetitive electronic-health-record tasks (registration, order entry, documentation, charge capture, reconciliation) without a human typing. The catch: where the EHR exposes a real write path you integrate there, but the freely available FHIR APIs are read-only (labs, meds, problems, vitals, demographics). So most write-heavy work has no API, and the durable way to automate it is an agent that drives the EHR's own desktop screens through the Windows accessibility tree, the same interface a screen reader uses.
Read-only scope of the free APIs verified against Epic's developer site at fhir.epic.com on 17 June 2026.
Triage: which bucket is your task in?
Before you scope any EHR automation, ask one question per task: does the EHR expose a real write path for this exact action? The answer splits cleanly. Most published playbooks describe the left column and quietly assume the right column does not exist. The right column is where the hours actually go.
Has an API path
Integrate directly, no agent needed
- Reading labs, medications, problems, vitals, and demographics for a known patient
- Pulling a problem list or med list into a clinical decision tool
- Subscribing to ADT events through an HL7 v2 feed your interface engine already runs
- Posting a clinical document via DocumentReference when your org has Vendor Services write access
No API write path
Where the desktop agent earns its keep
- Typing a new patient's demographics into the registration screen during intake
- Placing orders, because the free USCDI FHIR APIs do not let you push orders back into the chart
- Keying values off a faxed referral or a scanned insurance card into the encounter form
- Reconciling a value between the EHR and a separate billing or scheduling application
- Working a payer prior-authorization portal that has no integration at all
- Navigating a specialty module or a legacy green-screen the FHIR layer never modeled
Why "just use FHIR" runs out of road
FHIR is a genuinely good standard, and where it fits you should use it. The problem is the gap between what the standard promises and what the free tier exposes. The publicly available USCDI APIs were designed for patient access and app read scenarios: an app pulls a med list or a lab result for a patient who has authorized it. They are not a general-purpose write interface for clinical actions. Placing an order, the canonical example, is not something you can push back through the open APIs at all. Write access to richer resources is gated behind the vendor's commercial program, and several common flows (enrollment, ADT events, billing feeds) end up needing a hybrid of FHIR, HL7 v2, and the EHR's own interfaces.
Now look at where a registrar, a nurse, or a biller actually spends the day. They open the registration screen and type demographics off a portal form or a scanned card. They work an order set inside a desktop module with cascading dropdowns. They copy a value from the chart into a separate billing or prior-auth tool, confirm it, and write it back. Every one of those is a write, and almost none of them have an API. That is the half the other guides skip, and it is precisely the half this product was built for.
The four no-API workflows that show up on every project
When healthcare ops teams describe the work they want gone, it clusters into four shapes. None of them have a clean write API, which is why they have stayed manual.
Patient registration and intake
The single most common request. A registrar opens the EHR registration screen, then types demographics, insurance, and consent from a portal payload, a faxed form, or a scanned card. None of that is a FHIR write on the free APIs. Mediar reads the source and fills the named fields directly.
Order entry into quirky modules
Orders are the textbook example of work the open APIs will not let you push back into the chart. The order lives behind a desktop workflow with cascading dropdowns and order sets. Mediar drives that module by element name, the same path a clinician's hands take.
Scanned document and fax to field
A referral PDF, a lab fax, an insurance card. Mediar extracts the values and types them into the encounter or registration form end to end, instead of handing a JSON blob back to a human who still has to log in and key it.
Cross-application reconciliation
Most of the cost is between systems: copy a value from the EHR into a separate billing, scheduling, or prior-auth tool, confirm it, and write back. The reconciliation step has no shared API, so it has lived with a human until now.
The mechanism: target a field by name, not by pixel
The thing that makes this durable on a system with no API is the same thing that makes a screen reader work. Every Windows desktop application, the EHR client included, publishes an accessibility tree: a structured set of named nodes. A field is named Last Name, a button is named Accept, a window is named Registration. Mediar targets those nodes by name and role. The selector model is open source. You can read it in the Terminator SDK, and you can verify the exact shape below against the project.
The anchor fact worth checking: the selector engine is terminator-rs, a Rust crate published under the MIT license, with TypeScript bindings shipped as @mediar-ai/terminator and pinned inside the product at version 0.23.36. The source is at github.com/mediar-ai/terminator. Because the target is the element name, when the EHR ships a UI refresh and the field slides across the screen, the selector still resolves. That is the whole reason these deployments self-heal instead of breaking on the next vendor patch.
What one automated EHR run actually does
A single run against a registration or intake screen is concrete and auditable. There is no black box: every step writes a named field, validates, and logs.
Per-encounter run
- Open the target EHR screen and confirm the right patient or encounter is in focus
- Read the source: a portal payload, an email body, a scanned PDF, or a separate desktop app
- Type each field by its accessibility-tree name, not by pixel coordinate
- Apply your existing validation rules before committing the screen
- Capture a screenshot and the field values it wrote for the audit log
- Self-heal on the next run when a label or layout shifts, because the selector is the name
The number ops leaders ask about
The reason the no-API bucket matters is that it is where the labor sits. Patient intake is the clearest example: it is high volume, it is all writes, and almost none of it is reachable through the free APIs. Across Mediar's documented healthcare deployments, moving patient intake off manual keying is a recurring six-figure annual saving.
“Patient intake is high volume and almost entirely writes, the exact shape the free FHIR APIs do not cover, which is why moving it to a desktop agent is where the savings concentrate.”
Mediar healthcare deployment, patient intake automation
When the API really is the right answer
This is a triage, not a sales pitch against FHIR. If the action you want is a read that the free USCDI APIs already serve (pulling a med list, a problem list, vitals for a known patient), use the API. It is faster, cleaner, and supported. If your organization has Vendor Services write access and the workflow maps to a supported write resource, use that too. The desktop agent is the answer specifically for the actions that have no such path, which on most real EHR projects is the majority of the manual minutes.
The honest scoping conversation is per-task, not per-product. Bring the list of things your team types into the EHR every day, and the split between the two columns above usually falls out in twenty minutes.
Want the two-column triage done on your actual EHR workflows?
Book a 25 minute call. Bring the list of tasks your team keys into Epic, Cerner, or eClinicalWorks every day. We will sort each one into API-reachable versus desktop-agent and give you a runtime estimate.
Frequently asked questions
What is EHR automation, in one paragraph?
EHR automation is software that performs the repetitive electronic-health-record tasks a registrar, nurse, or biller would otherwise type by hand: registration and intake, order entry, documentation, charge capture, and reconciliation between the EHR and other systems. The honest version of the answer has two halves. Where the EHR exposes a real write path through FHIR or an HL7 interface your org already runs, you integrate there. Where it does not, which covers most write-heavy clicks, an agent drives the EHR's own desktop screens directly through the Windows accessibility tree, the same interface a screen reader uses, so it can type into named fields without an API.
Why can't I just use the Epic or Cerner FHIR API for all of this?
Because the freely available USCDI FHIR APIs are essentially read-only. They return labs, medications, problems, vitals, and demographics for a known patient. They were built so an app can pull data out, not push clinical actions back in. Write operations like placing orders generally require a commercial agreement through the vendor's program, and even then several workflows (patient enrollment, ADT events, certain billing feeds) need a hybrid of FHIR, HL7 v2, and the EHR's own interfaces. You can verify the scope of the free read APIs on Epic's developer site at fhir.epic.com. The practical consequence is that the expensive manual work, the part you are trying to automate, usually sits in screens the API never modeled.
How does accessibility-tree automation actually drive an EHR screen?
Every Windows desktop application, including the EHR client, exposes an accessibility tree: a structured set of named nodes that a screen reader consumes to announce fields and buttons. A field is named Last Name, a button is named Accept, a window is named Registration. Mediar targets those nodes by name and role rather than by pixel coordinate. In the open-source terminator-rs model that looks like a selector such as role:Edit name:Last Name inside window:Registration. Because the target is the name, not the rectangle, the automation keeps running when the EHR ships a quarterly UI refresh that moves the field. That is what self-healing means here, and it is the reason a deployment ships in days instead of the months a pixel-mapped bot needs.
Will a browser-based AI agent automate my EHR?
Only for the parts that are genuinely in a browser. Many EHR clients, registration desktops, and specialty modules run as Windows desktop applications, and the green-screen and legacy systems behind them are not browser pages at all. Browser-only agents cannot reach those. If the data you need to enter lands inside a desktop EHR screen, the automation has to live at the operating-system layer, which is exactly why the accessibility-tree approach exists.
Is this compliant for healthcare, and where does patient data go?
Mediar is SOC 2 Type II certified and HIPAA aligned, and the desktop agent can run on-prem or inside your existing Windows VDI rather than in our cloud, so PHI does not have to leave your network. Every run produces an audit log: the field values the agent wrote and a screenshot of the resulting screen, which is what compliance and audit teams ask for. Validation rules run before a screen is committed so the agent does not write a bad value silently.
How is it priced compared to traditional RPA?
Mediar bills runtime at $0.75 per minute, with no per-seat license and no separate orchestrator. There is a $10,000 turn-key program fee that converts into prepaid credits with a bonus, so it behaves like prepaid usage. The contrast with a UiPath or Automation Anywhere rollout against the same EHR screens is the maintenance line item: a pixel-mapped bot has to be re-mapped every time the EHR client gets a UI refresh, and that recurring cost is usually larger than the build.
Can my team extend it, or is it a closed product?
The selector engine underneath is open source. The Terminator SDK lives at github.com/mediar-ai/terminator under an MIT license, with a Rust core (terminator-rs) and TypeScript bindings published as @mediar-ai/terminator. Teams that want to write custom EHR workflows or wire the agent into an existing system can build directly against it. The no-code recorder at app.mediar.ai is the path for non-developers who want to capture a workflow by demonstration.
Related guides
Keep reading
Cerner automation
The accessibility-tree approach applied specifically to the Cerner desktop client.
Automate EMR documentation
The data-entry last mile scribes skip, and how an agent closes it inside the chart.
EMR billing workflow automation
Charge capture and reconciliation between the EMR and the billing system.
Comments (••)
Leave a comment to see what others are saying.Public and anonymous. No signup.