Capability Questions to Ask Any Vendor Claiming to Automate Payer Portals That Expose No API

Computer-using AI agents can automate healthcare administrative workflows without API integrations by reading screens and operating the visible controls in payer portals and electronic health record systems. For payer portal automation, the burden of proof belongs to the vendor. Practices need evidence that an agent can complete real workflows, recover from interruptions, protect access, and produce an audit record, rather than merely retrieve structured data or replay recorded clicks.

Why payer portals without APIs are a permanent fixture, not a temporary gap

Most prior authorization work happens inside payer portals that were never built for outside automation. Each payer has its own login flow, form fields, and submission rules. That fragmentation is structural. Availity’s developer API, for example, covers eligibility, claim status, and remittance, but not Payer Space interactions, portal-only reporting, or prior authorization submissions for payers outside its Service Reviews API coverage.

CMS-0057-F does not require its FHIR-based Prior Authorization API, Provider Access API, and Payer-to-Payer API until January 1, 2027. Its scope includes Medicare Advantage, state Medicaid and CHIP fee-for-service programs, Medicaid and CHIP managed care plans, and QHP issuers on the Federally Facilitated Exchanges. The rule leaves out commercial employer-sponsored plans, state-based exchange plans, and many regional and specialty payers. The mandate does not cover the whole market.

Even for covered payers, clinical attachments, appeal submission workflows, and payer-specific fields extend beyond the API surface described here. The rule requires payers to give specific denial reasons and publicly report appeal outcomes, but they still need portals for some work. Portal automation will still be needed after 2027. For a 2026 purchase, practices should contract the API path only where a live endpoint exists, rather than treating a future obligation as present coverage.

How do computer-use agents automate a payer portal with no API?

A computer-use agent operates the interface a person would use, without requiring an API integration or cooperation from the target application. It captures a screenshot, reasons over the screen, and selects an action such as clicking, typing, or scrolling. After the action executes, a fresh screenshot returns. The loop continues until the task finishes or the agent determines that it is stuck. Interface access, however, is not proof of reliable completion.

The distinction turns partly on what the agent observes. Its action interface determines what it can do, while its observation interface determines what it can perceive between actions. An agent that receives only periodic screenshots has gaps in its observation window. In those gaps, a session warning or confirmation dialog can appear and disappear. Re-planning from live screen state helps only when the agent sees the screen changes it needs to act on.

Adaptive observation addresses that gap through inter-step keyframe capture, audio transcription, and persistent visual narration. Bojie Li and Noah Shi’s 2026 study found gains of 17 to 48 percentage points on dynamic browser tasks, distinct from payer-specific completion rates, when computer-use models shifted from screenshot-only baselines to adaptive observation interfaces. They establish why observation design deserves separate scrutiny, especially when portal workflows include loading indicators, session-timeout warnings, and auto-dismissing confirmations.

Why static RPA scripts and API aggregators fail at exactly the workflows practices most need automated

Static robotic process automation and API aggregators can both be presented as portal automation, although their limits differ. Static RPA relies on recorded UI selectors. When a payer changes a layout, adds a field, or redesigns a submission flow, that script can break. When a bot stops, the problem may be clear right away. A failed workflow may also leave work sitting in a queue without an alert, so a failure may go unseen.

API aggregators encounter a different boundary, which is the reach of structured transaction data. Clinical attachments, payer-specific fields, and appeals that require portal navigation cannot simply be submitted through a standard HIPAA transaction set. An aggregator may return a confident “pending” status that is stale, without signaling that manual follow-up is needed. Data access does not establish workflow completion. The relevant comparison is therefore not whether a product uses AI, but whether it can execute the payer-specific steps that structured transactions omit.

Having these limits still leaves room for both technologies to be useful. It does make broad coverage claims insufficient. Eligibility retrieval, for example, does not demonstrate that the same system can upload clinical documentation and complete a branching prior authorization submission. For a practice evaluating vendors, the lesson is to test the actual workflow rather than accept one supported transaction as evidence for another.

The seven capability questions every practice should put to a vendor before signing

Authentication is the first operational test, because a portal agent must complete the access steps that a human encounters. Shared credentials are not a substitute for that capability. Ask the vendor how the agent handles multi-factor authentication, including authenticator app codes or SMS verification, and where credentials are stored. Ask whether credentials are encrypted at rest, held in an isolated vault, and scoped to the specific agent session.

A moved button or renamed field requires the system to interpret the current screen. Ask the vendor what happens when a payer changes its UI mid-workflow. Ask for a real incident, including the payer, when the change occurred, what broke or continued working, and how quickly recovery happened without manual intervention.

Session continuity is a separate capability from screen navigation. Prior authorization can span multiple pages, clinical uploads, branching questions, saved drafts, and timeout recovery. Losing state can abandon a request or cause a restart that creates duplicates and payer-side flags. Ask the vendor whether the agent maintains session state across those steps, how it detects a timeout, and what it does with an unexpected mid-submission error. Ask specifically whether state is saved between steps.

Concurrency tests whether a system that handles one submission well can handle enough work for a high-volume practice or a group with multiple locations. Ask the vendor whether it can run submissions across multiple payers concurrently, with each session in a sandboxed environment and its own authentication state. Ask for the tested concurrency limit together with a description of what happens as that limit approaches. Throttling, queuing, or failure can each be an acceptable answer to that question, but the vendor should know which behavior applies.

A session warning that disappears in three seconds can come and go between screenshots. Ask the vendor what the agent observes between actions and how it handles loading spinners, timeout warnings, and transient confirmations. Ask how it distinguishes a loading state from a submission-complete state, and how it handles a confirmation visible for fewer than five seconds. The answer should identify an observation mechanism.

Auditability tests both traceability and the controls around access to ePHI. HIPAA’s Security Rule requires audit controls that record and examine system activity, but it does not prescribe a fixed set of log fields. Ask the vendor what its audit log captures at field level, how long records are retained, whether they are exportable, and whether a Business Associate Agreement is in place before PHI is shared. Ask how the workflow meets the requirements for minimum necessary and access-control. NIST guidance supports details such as the operation, data accessed, identity, and timestamp, but those are not an enumerated Security Rule checklist, and “human authorizer” is not a mandated field.

A general computer-use agent should not need a pre-built connector for every payer, yet each new portal still requires workflow validation. Ask the vendor how many payers it works with today and which have been tested and tuned. Ask what happens when the practice adds a payer mid-contract, including any fee, engineering queue, self-service configuration path, and realistic time to production. That distinction exposes whether coverage is an operational commitment or a broad architectural claim.

What a satisfactory answer looks like — and what should disqualify a vendor

A satisfactory answer names a payer, describes a workflow or incident, acknowledges a constraint, and explains the mechanism used to handle it. Perfection is not the standard for this evaluation. On MFA, an answer describing the same TOTP or SMS step a human completes, supported by an encrypted vault and session-scoped access, is operationally meaningful. “We handle authentication securely” is not.

UI-change evidence should be equally concrete. A vendor should be able to explain an unexpected screen state, whether the agent re-planned or flagged the case for human review, and whether recovery required an updated workflow. Human intervention is not automatically disqualifying here. What is disqualifying is “our AI figures it out” without a re-planning mechanism or a real recovery incident. A vendor that cannot name any payer portal it has operated against in production also fails the basic evidence test.

A vendor that cannot produce a BAA, or treats HIPAA compliance as a property of its model, should be disqualified. Compliance depends on how the workflow is configured, contracted for, and controlled. Shared credential pools or pre-authentication through a service account not issued to the practice are also disqualifying because they bypass the practice’s access controls and violate payer terms of service.

A log containing only login, logout, and task-complete events is a procurement disqualifier because it does not provide the field-level visibility this evaluation requires. A satisfactory vendor describes the data-access record, retention, export, and access controls in enough detail for compliance review.

A vendor that acknowledges payer-validation time or difficulty with dynamic content is more credible than one promising frictionless coverage everywhere. Those admissions show what still needs to be tested. They allow the practice to discover and assess constraints before signing while leaving the vendor accountable for an inability to complete the contracted workflow.

How the payer-automation landscape is shifting and what that means for contracts signed today

The appropriate procurement object is a workflow outcome. HFMA has described a multimodal approach in which agents route payer-bound work across EDI, API, portal, and voice through the fastest available channel, reserving manual or portal-based steps as exceptions where possible. Portal capability remains necessary within that approach. Its value is completing work when a structured path is unavailable.

CMS-0057-F’s January 1, 2027 requirements create a concrete transition question for covered payers. A vendor already completing a workflow through the portal should be able to explain how routing changes when a compliant FHIR endpoint becomes available. Ask the vendor how its system adapts when a payer currently automated through the portal stands up that API. Ask whether the change happens within the existing service or requires a new integration engagement, re-contracting, or re-training.

The operational pressure is not limited to API availability. Payers are deploying AI-assisted review faster than most provider organizations are deploying AI-assisted submission, widening the disadvantage for teams still handling prior authorization manually. The submission channel does not remove that imbalance. Practices should therefore contract for outcomes such as prior authorization submitted and tracked, appeals filed, and status retrieved, with an upgrade path as FHIR endpoints emerge. A portal-only contract without that path binds the practice to an implementation.

Before signing, the final test should be a structured reference call with a practice running the same payer mix, with the specific payers named in advance. A general customer reference from a different specialty or geography may involve materially different portal configurations. The reference must match the work being purchased. That makes vendor evaluation a skills assessment grounded in actual payer workflows, rather than a sales conversation about what an agent might eventually do.