Medicare automation is not one system. It is three.

Unattended software that does work a human registrar, biller, or AR analyst would otherwise type by hand into the systems Medicare workflows actually live on. Those systems are the seven Medicare Administrative Contractor (MAC) web portals (Noridian, Palmetto GBA, NGS, CGS, Novitas, WPS, First Coast), the Fiscal Intermediary Standard System Direct Data Entry application (FISS DDE) on the CMS mainframe, accessed through TN3270 terminal emulators by Part A providers, and the HIPAA Eligibility Transaction System (HETS 270/271), a SOAP-and-X12 endpoint for real-time eligibility. The thing that makes it hard is that those three surfaces want three different integration approaches, and most teams pick one and call the rest 'manual'.

Because two of the three surfaces are not APIs. FISS DDE is a 3270 mainframe map. The seven MAC portals are old web applications that the long tail of plan-, jurisdiction-, and claim-type-specific functions still gates behind the human UI rather than a structured endpoint. HETS, the surface that does have a structured endpoint, requires CEDI trading-partner enrollment and only covers Original Medicare beneficiary eligibility — it does not cover Medicare Advantage plan-level checks, claim status, MBI lookup, or claim entry. Any honest Medicare-automation stack has to drive the UI for the workflows the structured endpoint cannot answer.

Windows TN3270 emulators (IBM Personal Communications, Micro Focus Reflection, BlueZone, zScope, Attachmate) render their session window as a UI Automation surface. The 80x24 character grid is exposed as text. The cursor position is exposed as a focused element. The Enter, F1 through F12, and PA1/PA2/PA3 keys are exposed as actions. Mediar's get_window_tree primitive, defined alongside the rest of the read-only ASK_MODE_ALLOWED_TOOLS list in apps/desktop/src/lib/ask-mode-tools.ts, returns a tree of those nodes, and the same role-and-name selector vocabulary that addresses a portal field (role:Edit && name:Member ID) addresses a 3270 field (role:Edit && name:HIC). The grid and the form look different on screen, but the integration surface is the same accessibility tree.

HETS owns Original Medicare real-time beneficiary eligibility — coverage start and end dates, deductible status, Medicare Advantage enrollment indicator, hospice and home-health election status, MSP type, MBI verification by SSN-based lookup, and home-health agency and hospice provider names. Portal owns claim status (the long-form one with reason codes), appeal submission and tracking, MBI-by-name lookup for a beneficiary you do not have an SSN for, prior authorization for the items it applies to (DMEPOS competitive-bid items, certain hospital outpatient services, repetitive scheduled non-emergent ambulance), and PECOS revalidation tasks. FISS DDE owns Part A claim entry (especially institutional claims that fail your billing system's edits and have to be cleared by hand on map MAP1711), claim correction (MAP1741), suspended-claim resolution (RTP, T B9997 status code), and the inquiries Part A schedulers actually use (HIQA, ELGA, ELGH). The right shape is one workflow that calls all three.

Nine, defined as ASK_MODE_ALLOWED_TOOLS in apps/desktop/src/lib/ask-mode-tools.ts: get_window_tree (full UI tree), get_applications_and_windows_list, validate_element (does this selector resolve, and optionally does its text match), wait_for_element (block until visible, enabled, focused, or exists), capture_screenshot, highlight_element (visual debug), hide_inspect_overlay, delay (explicit sleep), and activate_element (focus a window without modifying state). The split between read-only and action tools is enforced as a list constant, not a runtime flag, which is the part that makes Ask-mode auditable: a workflow that runs only ASK_MODE_ALLOWED_TOOLS literally cannot have written into the chart, the portal, or the DDE map, regardless of what its prompt says.

The MBI is an 11-character alphanumeric identifier with a structural rule (positions 1, 4, 7, 10, and 11 are digits; positions 2, 3, 5, 6, 8, and 9 are letters; certain letters are excluded to avoid confusion). Validate_element accepts a literal-match check, so the workflow validates MBI format before submitting it into FISS or a MAC portal, fails closed when the format is wrong, and surfaces the bad source record back to the EHR coverage team rather than burning a portal lookup on it. When CMS reissues an MBI (the change-of-MBI flow), the workflow has to read the new identifier off the response page and update the EHR — that is two reads (HETS or portal response, EHR coverage record) and one write (the new MBI back into the EHR), each as a separate primitive step.

Three places. First, anything Medicare Advantage plan-level (utilization management, prior auth on Humana MA, UHC MA, Aetna MA, BCBS MA) that the plan exposes through its own portal. Mediar can drive those portals, but the plan logic, prior-auth criteria, and clinical decision support that decide whether the request gets approved are not Mediar's surface. Second, payer portals served entirely from inside an iframe with no accessibility tree. Rare on MAC portals, more common on a few legacy MA plan portals. Third, anywhere a 270/271 round-trip through a clearinghouse is already cleanly served — the per-check cost of driving HETS through a UI-driving runtime is real, and the right answer is to route the structured part to HETS or a clearinghouse and reserve the runtime for the long tail of work the structured endpoint does not cover.

Mediar runs SOC 2 Type II and HIPAA-covered. The runtime can deploy on-prem so PHI never leaves the provider's network. Every primitive call is logged with the selector, the resolved element, and the result; the read-only tool list is a separate constant from the action tool list, so an audit can prove an inquiry workflow never typed; get_window_tree captures whole map and whole page snapshots into the audit log, which is how a chart write that reads back wrong gets traced to the right keystroke without re-running the workflow against a live patient.

Mediar is $0.75 per minute of runtime, drawn against a $10,000 turn-key program fee that converts to credits. A single eligibility pass through a MAC portal is on the order of 40 to 90 seconds of compute depending on portal latency, so the per-check meter is a few tens of cents. A FISS DDE claim correction is closer to two to four minutes. The number to anchor against is not 'cents per check' on its own — those compete on price-per-check with HETS and clearinghouse 270/271 round-trips. The number is the registrar or AR-analyst hour the runtime replaces on the long-tail surfaces (claim correction, portal-only eligibility for a regional MA plan, MBI-by-name lookup) where the structured endpoint cannot help. Most existing Medicare-automation buyers have already paid for HETS access. The Mediar layer is what extends that automation past the structured endpoint.

The Terminator runtime — the selector vocabulary, the wait-condition primitives, 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 actually touches PHI is the runtime, and the runtime is what an audit can read end-to-end before any of the closed components see a real beneficiary identifier.