EMR automation is three layers. Most articles only cover one.

Unattended software that types, clicks, reads, and validates inside an electronic medical record application instead of asking a human to do it. The work splits across three layers. Protocol layer handles structured data exchange between systems and is served by HL7 v2 and FHIR over an integration engine like Mirth Connect, Rhapsody, or Cloverleaf. UI layer handles the work the protocol does not cover, which is most clinical and registration workflows, and is served by RPA and AI desktop agents that drive Hyperspace, PowerChart, eClinicalWorks, athenaClinicals, NextGen, Sunrise, Meditech, or Greenway through the operating system's accessibility tree. Vendor stack handles workflow logic that lives inside the EMR vendor's own runtime: Epic Cosmos, Cerner MPages, athena rules. Most published material on this topic stops at the protocol layer; the published case studies all sit in the UI layer.

Because the protocol describes the data, not the workflow. An ORU^R01 lab message can land discretely in the chart, and the order it ties back to can still need a human to open Hyperspace, click into the In Basket, route the abnormal flag, pick a SmartList option for the follow-up, and co-sign with F4. None of those four steps is an HL7 message. None of them has a FHIR Bundle. The EMR vendor expresses them as UI affordances because the workflow is about clinician judgment routing through the chart, not about moving a row between two databases. FHIR R4 covers a much wider workflow surface than v2 ever did and the gap is still wide enough that Epic's published list of workflow extensions still grows every Specialty Steering Board cycle.

Hyperspace is a WPF application built on top of the Microsoft UI Automation framework, the same surface JAWS and NVDA use. Mediar reads that tree directly. A field that a clinician sees as 'HPI' on screen is exposed as a node with role:Edit and name:HPI, and Mediar's selector vocabulary addresses it as role:Edit|name:HPI. No pixel matching, no template image, no screen scraping. When Epic ships an upgrade that moves the field two columns to the right, the rendered position changes; the role and name do not. The selector still resolves. This is the same reason NVDA keeps working across Hyperspace point releases: the surface is contractually exposed, not visually inferred.

Hyperdrive is Epic's Chromium-based replacement for the WPF Hyperspace client. When Hyperdrive runs locally on the endpoint, the accessibility tree is even cleaner because it is rendered through Chromium's accessibility layer, which exposes ARIA roles and names. When either Hyperspace or Hyperdrive runs inside a Citrix session, the ICA protocol crosses pixels and synthetic input but not the UIA tree. There are two honest answers: install a runtime on the Citrix VDA so the tree is read inside the session and proxied back (UiPath, Blue Prism), or run vision plus keyboard-first navigation on the client side and treat Citrix-rendered Epic the way a screen-reader user with no VDA permissions has to (Mediar's client-side mode for the Community Connect case). For most direct Hyperspace and locally installed Hyperdrive deployments neither is necessary.

Build the workflow against a tool list that does not contain a write primitive, and show the list to the auditor. Mediar publishes that list in apps/desktop/src/lib/ask-mode-tools.ts as the constant ASK_MODE_ALLOWED_TOOLS. It contains twelve names. Nine are read-only desktop primitives (get_window_tree, get_applications_and_windows_list, validate_element, wait_for_element, capture_screenshot, highlight_element, hide_inspect_overlay, delay, activate_element). Two are read-only file tools (read_file plus glob_files and grep_files). One is a server-side knowledge lookup (search_similar_workflow_steps). The state-changing primitives (click_element, type_into_element, press_key, set_value, run_command, write_file and the rest) live in a separate constant called ASK_MODE_BLOCKED_TOOLS. The split is enforced at compile time as two list constants, not as a runtime flag, which is the part that matters for an audit: a workflow that imports only ASK_MODE_ALLOWED_TOOLS literally cannot have written into the chart, regardless of what its prompt said.

Repetitive, structured-input, low-judgment work that lives across multiple panes. Patient registration: pull demographics from the scheduling source, type into the registration shell, run eligibility, file the response. Refill queues: read the in-basket message, pull the active medication record, draft the refill, route to the prescriber. Prior auth: read the order, fill the payer portal, file the auth number back to the order. Chart abstraction for quality measures: read structured fields, copy to a registry submission. Order entry from outside referrals: parse the inbound document, file the discrete order. The wrong candidates are anything that requires a clinician to decide whether to act, anything where a wrong action could harm the patient if the verification step fails, and anything the EMR vendor already has a first-class workflow primitive for (those should run inside the vendor stack).

Mediar runs SOC 2 Type II and HIPAA-covered. The runtime can deploy on-premises so PHI never leaves the provider network. Every primitive call is logged with the selector, the resolved element, the result, and a screenshot at the moment of the call. The split between read and write tool lists means a chart-read workflow has a paper trail an audit can verify against the read-only constant. A self-hosted vision option exists for workflows that need to look at unstructured chart documents without sending pixels off the endpoint.

An HL7 interface build for a new system pair (say, a referral source to your EMR) is typically a six-figure project that takes one to two quarters from scoping to go-live, owned by the integration team and the vendor's interface group. A UI workflow that does the equivalent of typing the referral into the chart by hand is days to author and tens of cents per run on Mediar's $0.75-per-minute meter. The protocol build wins for high-volume, structured, every-day flows where the latency and throughput justify the up-front cost. The UI workflow wins for the long tail (the regional plan with no clearinghouse, the once-a-week feed from a small specialty group, the manual prior auth that does not have a payer-side API) and for the cases where the protocol team's backlog is already two quarters out.

The Terminator runtime, which is the selector vocabulary, the wait-condition primitives, and the accessibility-tree readers, is published as an SDK at github.com/mediar-ai/terminator with TypeScript bindings on a Rust core. The closed-source layer is the no-code workflow recorder, the cloud executor, and the workflow-synthesis pipeline that turns a recording into a typed workflow file. The split matters specifically for healthcare buyers: the layer that touches PHI is the runtime, and the runtime is the layer an audit can read end-to-end.

Three places. First, anywhere the EMR vendor publishes a clean first-class workflow primitive the customer is not using yet. Configure the vendor surface; do not screen-drive what the vendor already exposes. Second, decisions that require a clinician's clinical judgment. The runtime can prep the screen, surface the candidate options, and stop. It should not pick. Third, very high-volume structured exchange where a real HL7 v2 or FHIR pipe is going to be cheaper per message and more observable end-to-end. The UI layer extends the integration team's reach into the long tail; it does not replace the integration team.