What to Demand From a Vendor When API Access Is Not Part of the Deal

Computer-use agents can automate prior authorization submissions and claim denial appeals without API access by logging into payer portals, reading screens, and filling in information as a billing specialist would. Without a structured integration layer, buyers must insist on written standards for how well the agent works, safeguards for PHI, and audit trails they can access on their own. The test is not whether an agent can complete a demonstration, but whether the vendor remains accountable for live workflow outcomes.

Why the absence of an API changes what accountability means

An API integration gives a buyer defined data schemas, error codes, versioned endpoints, and system-of-record handshakes. When work goes through screens, those structured signals are lost. The agent uses the interface instead of passing data under a system-to-system contract that both sides have agreed to. A submission can therefore appear complete without the buyer having an integration-layer acknowledgment to inspect.

Agents already operate prior authorizations, claims, scheduling, and patient inquiries in production, including through screens where API access is unavailable. These agents reason about what they see. That flexibility also makes failures less predictable, so oversight must be designed around the workflow.

How do computer-use agents work inside a workflow, and where can they fail?

Computer-use agents have three layers that work together, which are perception, decision, and execution. Perception reconstructs the software’s current state from screenshots and rendered interface elements. Decision selects the next action using that interpretation and the task context. Execution turns the decision into a click, form entry, or file upload. Each layer can introduce a different kind of error.

An agent can misread a field, choose the wrong next step, or click the wrong element even when it has the right goal. These errors can propagate through a long submission. A later action may look reasonable on its own while depending on an earlier mistake. Prior authorization workflows and appeal packets amplify that risk because they require many connected steps.

Securing Computer-Use Agents describes how perception errors can lead to execution failures later in the workflow. In a live environment, an execution mistake can become an unintended submission, exposed information, or a persistent misconfiguration. Buyers should therefore check how the agent handles failures as well as whether it finishes tasks. A vendor must explain which failures trigger human review and which have an automatic recovery path.

The specific workflows where non-API delivery is most common — and where the stakes are highest

Prior authorization, claim denial appeals, payer portal status tracking, and eligibility verification are common non-API workflows because payer systems offer providers limited or no API access. These are revenue-cycle tasks with consequential exceptions. A stalled authorization or mishandled appeal is not merely an automation defect. It creates an operational problem that staff must detect and resolve.

Commercial medical prior authorizations need portal logins, phone calls, and judgment, so screen-based automation handles only the parts done through software interfaces. Voice-based delivery handles the phone work where it is needed. The January 1, 2027 FHIR API mandate does not remove the portal and phone work required during the transition. Variations in legacy infrastructure can leave that gap open for years.

Scheduling and cancellation recovery face a similar limit when exchanges with patients and payers have no structured handshake. A failed action can mean a missed appointment, a lost slot, or a patient falling through the cracks. Buyers therefore need standards tied to these distinct consequences.

Performance standards that substitute for the integration layer — what to define before signing

To make those consequences enforceable, buyers should require workflow-level standards in writing before signing. First-pass completion rate should track the percentage of workflows finished without human rework, with separate rates for prior authorization submissions, appeals, and eligibility checks. An average across workflows can hide one that works poorly. The agreement must define what counts as completed so that the vendor and practice measure the same event.

Straight-through processing rate answers a different question. It measures whether the agent completes the entire sequence without a human touchpoint, including intake, submission, and reference number capture for a prior authorization. First-pass completion and straight-through processing should be measured separately because a workflow can need no rework while still having planned steps that a human must handle. This distinction exposes how much work the practice actually retains.

Exception escalation accuracy should specify whether the agent recognizes that it cannot finish and routes the problem to a human with enough context to act. Silent stalls are not acceptable exceptions. Before deployment, the vendor should document the escalation triggers, the human checkpoints, and the information supplied at each handoff. Human-in-the-loop architecture belongs in the performance agreement.

For same-day authorization and scheduling, the contract needs to give time limits the same weight as other standards. OSWorld-Human found that computer-use agents can take substantially longer than human experts and use more steps than necessary. Accuracy alone does not establish operational fitness. Buyers should demand a contractual maximum latency for time-sensitive workflows rather than accept a completion claim without a time boundary.

Prior authorization requires first-pass approval rate and time-to-determination, while scheduling requires fill rate and cancellation recovery. Denial appeals require overturn rate and days-to-resolution. These measures should sit beside execution measures because a completed submission and a favorable determination are different outcomes. A single generic SLA cannot make those distinctions enforceable.

The evidence behind each commitment should come from the specific workflow. Buyers should request current deployment data from a practice with a comparable size and payer mix. A demonstration establishes that a task can work. Deployment evidence shows whether the proposed standard reflects routine performance under the conditions the practice will face.

Security and PHI requirements that must be written into the contract — not assumed from a badge or a certification

How well a workflow runs does not show whether protected health information is handled safely. Screen-operating deployments can expose PHI through live portal access, screenshots, call recordings, and inference pipelines. Each route needs explicit contractual treatment before deployment. The foundational demand is a Business Associate Agreement that names the specific AI product and the data flows it touches, rather than a generic template written before the agent deployment.

The contract should answer what happens after processing. It must specify the retention period, deletion schedule, and who controls deletion. It must also ban the use of PHI for model training, fine-tuning, or other model improvement. Whether vendor or subcontractor reviewers can access PHI for quality assurance or model improvement requires an explicit written answer, with the agreed exclusions reflected in the contract.

Downstream access must be visible to the buyer. The vendor should provide a written list of subcontractors and model providers, together with a specific breach notification window negotiated to be shorter than the regulatory limit. SOC 2 Type II certification and encryption badges offer some evidence of HIPAA compliance but do not prove it. Neither substitutes for a BAA covering the processing environment and enforceable restrictions on PHI use and review.

Runtime oversight and auditability — what visibility the buyer must retain when an agent acts on their behalf

Even an agent that is run securely can cause harm by taking the wrong action. The buyer therefore needs a timestamped log of every click, entry, and submission tied to the relevant patient or claim record. A vendor-produced performance report is not that record. The practice must be able to inspect what happened, when it happened, and what outcome followed without depending on a support request.

Key decision points also require screenshot or screen-state capture, with retention specified in the contract and access available directly to the buyer. An escalation log should record every unfinished task, its trigger, and its resolution. These records make exception handling independently inspectable. Because they can contain patient data, their retention and access terms must align with the PHI agreement.

Oversight must account for both the path to an action and the final screen. A History-Aware Visually Grounded Critic for Computer Use Agents describes how short-sighted decision loops and weak visual grounding make it harder to judge an agent’s actions. Buyers should require the vendor to explain where review occurs and how earlier actions inform that review. They should also demand change notifications describing portal adaptations, their timing, and any workflow gap, because models, interfaces, and tools can drift after release.

Change resilience — how to verify the vendor can handle portal changes, payer policy shifts, and workflow evolution without breaking

Payer portals alter their interfaces, authorization criteria change, and practices expand workflow scope. Screen-operating agents can be more resilient than rigid click-path scripts because they interpret the current interface. That advantage depends on the quality of perception and planning, which varies across vendors.

Buyers should demand a written SLA for finding and fixing workflows that break because of payer portals, including when the practice will be told. The vendor should explain how it tests after an update, whether through a staging environment, a shadow deployment, or only in production. New payers, new CPT scope, and revised authorization criteria also need a documented incorporation process and turnaround time. A process description alone is insufficient evidence. A reference check should establish which customer experienced a portal change, how the vendor responded, and how long the workflow was affected.

Regulatory change adds a separate durability test. CMS-0057-F sets January 1, 2027 as the implementation deadline for the FHIR API requirements, including the Prior Authorization API. Buyers should ask how the vendor’s approach accounts for that transition as structured connections become available. Otherwise, what fills today’s access gap can make it harder to move to structured connections later.

Staff impact and change management — what the vendor owes the practice operationally, not just technically

The practice administrator still needs to know who is responsible for escalations, who handles the exception queue, and who checks the audit log. Without that operating model, automation shifts burden. The vendor owns the operational transition as well as the technical deployment, including documentation of how agent handoffs fit the practice’s standard operating procedures.

The written go-live plan should state milestones, vendor responsibilities, and the work required from practice staff. Because non-API agents use the systems already in place, a credible deployment should take weeks. A longer proposal warrants a specific explanation of the delay and any changes the practice must make. Demands for system replacement or workflow redesign deserve scrutiny. Staff should not have to rebuild their work around an agent intended to use their existing systems.

Training should focus on how staff use outputs and handle escalations. The exception protocol must specify what is escalated, to whom, in what form, and within what timeframe. Those details give the administrator a concrete account of what changes at go-live and what remains the team’s responsibility.

How to structure the vendor evaluation conversation — the questions that separate credible vendors from capable-sounding ones

Buyers should ask for first-pass completion data for the specific workflow at a practice with a comparable size and payer mix, then examine the proposed BAA for screen-agent data flows. Blended projections and generic templates do not answer those requests. The conversation should establish whether the vendor already has the infrastructure needed to make its commitments real.

The same test applies to oversight and maintenance. Buyers should ask what their team can inspect in the audit log without vendor assistance, then request a named example of a payer portal change during an active deployment. The vendor should describe which workflow was affected, how long the disruption lasted, and what it told the customer. A named customer contact makes the account verifiable. An anonymous outcome claim or a description of intended process does not.

Deployment questions should establish exactly what staff must do and what existing systems or workflows must change. Any proposed redesign should prompt a follow-up about why the agent requires it. Specific payer names, workflow evidence, and reachable references distinguish an accountable offer from a capable-sounding presentation. These are reasonable conditions of purchase. The buyer’s leverage comes from requiring proof before accepting responsibility for the result.