DeskGate BAA active · Vertex AI · 28 Sep 2026
Run this with Claude, live
Off by default — the walkthrough is scripted and deterministic. Switch it on and steps 2 and 4 call the Anthropic Messages API for real, on the synthetic chart data below. The ledger records the actual call, not a description of one.

One case, end to end

The mock EHR is the system of record. DeskGate never writes to it. It reads what the coordinator already has open, stages the payer-portal step, and stops before the irreversible click. Skip to the 30-day Specimen Ledger ↓

1 · Intake (EHR)
2 · PA required
3 · Stage portal
4 · Attachments
5 · Human gate
6 · Evidence record
7 · Follow-up
Stage 1 · Coordinator's existing system MOCK EHR
43-6013.00 Compile and record medical charts, reports, and correspondence. read only — no time claimed

Case already open in the work queue

DeskGate does not create this. The clinical decision is already made and the case is already in their queue.

Data flow ledger

LIVE LEDGER
build 20261016-1454
Scripted walkthrough — nothing executes. Every step below is scripted. No API call is made, no model is contacted, no payer receives anything. Each row is tagged described to say so.
Stays in this browser session
Leaves the browser — external service
Not retained by DeskGate — provider terms and agreements to verify
0 Local — stayed in this browser session
0 External — would leave the browser in production
0 Total events — Local + External, one per row below
0 Retained by DeskGate — a subset: cryptographic hash only
AWAITINGStart the walkthrough to populate the ledger.

Who receives external calls

ROUTING

This decides whether the screen-read step may carry real PHI. The production route is DeskGate's Google Cloud project. Switch the provider below to see how the data flow ledger changes.

Honest gaps
  1. Two BAA links, one in place. Link 2 — DeskGate, Inc. with Google Cloud — was accepted on 28 Sep 2026 for the project deskgate-production, so the screen-read step may carry PHI on that route. Link 1 — DeskGate with each desk (the practice, or the billing agency acting for it) — is signed per desk before that desk sends any live PHI. Until then, measurement runs on synthetic or de-identified cases.
  2. The Google Cloud BAA covers only the products Google lists as covered. Pre-GA (preview) models and services are excluded, so the production route uses generally available models only.
  3. On the Anthropic route specifically: DeskGate has not signed Anthropic's BAA, so this route carries no PHI today. The Messages API is covered as an eligible service under Anthropic's BAA on a HIPAA-ready organization. Two caveats we do not gloss over — the Primary Owner must sign the BAA and then have PHI use enabled by Anthropic, and Covered Models carry 30-day retention and are not available with zero data retention. So "zero retention" describes what DeskGate stores, not the whole path. Anthropic's BAA coverage table →
  4. Computer Use, Web Fetch, the Files API and the Batch API are not covered under that BAA. DeskGate uses plain image-in-Messages, which is.
  5. DeskGate is a business associate whenever it touches PHI for a covered entity — client-held API keys reduce exposure but do not remove that obligation.
  6. This walkthrough runs on pages we control. Automating a third-party payer portal needs the operator runtime in that tab.
30-Day Frozen Cohort · Core Deliverable

Specimen ledger — what the 30 days produce

The walkthrough above simulates how one single case is staged without leaving the browser session. In a live pilot, 30 days of that execution across a frozen cohort compiles into this exact ledger. Every metric and definition is agreed upon in writing before day one.

SPECIMEN — read the two columns differently. The baseline column is derived — AMA survey data for volume and staff hours, our own figure for how long a residual case takes — and the full working is shown below it, so each input can be checked or argued with separately [1]. The measured column is illustrative — DeskGate has no completed measurement and nothing in it comes from a live desk. Column definitions, layer partitions and task bindings are real and are frozen in Schedule M before day one.
⚡ Interactive Scenario Modeler · Test your desk's assumptions
80 min
40 min (fast)120 min (heavy)
6.5 hrs (390m)
5.0 hrs8.0 hrs
71%
50%90%
Layer Measured Dimension Baseline
derived · see working		 Illustrative
30-day cohort		 Delta / Impact
Desk
outcome		 Completed cases / coordinator-day 4.9 6.4 +31%rate uplift · = 23% fewer coordinator-days at equal volume
Coordinator-days in period 78.0 39.5 —
Runtime
contribution		 Packets staged 0nothing was staged — no stager existed 253 —
Accepted at gate, no material edit no equivalentthe gate exists only because the runtime does 71% —
Accepted after edit no equivalentedit distance is unmeasurable without staged fields to edit 22% —
Returned before gate no equivalenta return is internal, before submission — distinct from a payer denial 7% —
Explanation
only		 Time-to-gate, median ~80 mincumulative manual touch-time for a residual case — our figure, see working 0:41 the one clock the runtime owns
Time-at-gate, median new taskreviewing staged output did not exist before — never counted as savings 1:52 —
Integrity Unauthorized submits — 0 —
Cohort in / out / exceptions — 261 / 253 / 8 —
Return reasons before gate: Attachment bind failed (11) · Quantity field mapping (5) · Portal layout drift (2)
Where the baseline comes from — check the arithmetic
39prior-authorization requests per physician per week across all casesAMA survey → [1]
13 hphysician and staff time per physician per week on blended requestsAMA survey → [1]
20 minimplied average staff time per routine request  13 × 60 ÷ 39derived
80 mincumulative touch-time for a residual case — manual portal entry, chart-note extraction, attachment assembly and phone follow-up, accumulated across days. This exceeds the published per-request range and is our figure, not the AMA's.our assumption
390 minproductive minutes per coordinator-day  6.5 h, not 8 — meetings, interruptions, other dutiesassumption, stated
4.9baseline completed cases per coordinator-day  390 ÷ 80 = 4.88derived
6.4illustrative measured rate  253 staged ÷ 39.5 coordinator-daysmodeled

Change either assumption above and the baseline moves: at 60 minutes per residual case it is 6.5, at 90 minutes it is 4.3. That sensitivity is the point — a real measurement replaces this entire block with the desk's own prior-period count, which is why the baseline must be written down and agreed before staging begins. We publish the working so a desk can tell us it is wrong before we start, not after.

The illustrative column applies a 71% gate-accept rate to the staging share of that work (253 staged cases ÷ 39.5 coordinator-days = 6.4). It is arithmetic on an assumption, not a finding. No desk has produced this number.

Sources, so they can be checked: AMA — practices complete 39 prior-authorization requests per physician per week, consuming 13 staff hours [1] · AMA 2026 survey update — 40 requests weekly, 13 hours, 40% of practices employ staff working exclusively on prior authorization [2] · AMA Physician AI Sentiment Report — Prior authorization ranks as the #1 administrative burden physicians want automated (54%), with over 85% requiring human-in-the-loop confirmation [3].

Figures on requests per week and staff hours per week are the AMA's and are linked above [1, 2]. The per-residual-case time, the productive-day length and the resulting throughput are ours and are labelled as assumptions in the table. AMA figures vary between survey years — 39 to 45 requests, 12 to 13 hours — so we use the lower published values rather than the ones that would flatter the case [1, 2].

Definitions, agreed in writing before day one
Coordinator-day
One named person, one desk, one working day. Half-time counts as 0.5. Split lanes apportioned.
Completed
Human-approved submit and a payer reference captured in the same session. Not the gate click alone.
Material edit
Any change to a staged field value or the attachment set. Reformatting is not a material edit.
Baseline
The desk's own prior period, longer than the measured window, agreed before staging begins.
Published sources used on this page. Prior-authorization volume and staff-time figures are from the American Medical Association's physician surveys, linked at the point of use above [1]. Physician AI sentiment data is from the AMA's study on healthcare automation [3]. Task statements are from O*NET, U.S. Department of Labor; O*NET® is a trademark of USDOL/ETA. Neither the AMA nor the Department of Labor has reviewed, endorsed or is associated with DeskGate. Our assumptions, our classification of tasks, and the illustrative column are ours alone and are labelled as such wherever they appear.

Two further AMA findings we have not put in the table, because they describe payer behavior rather than desk throughput and would inflate the case if mixed in: roughly a third of physicians report requests are often or always denied, and 40% of practices employ staff working exclusively on prior authorization → [2]. The second supports the coordinator-day as a real operating unit. The first is a payer denial, which is not the same thing as a packet returned before the gate, and we do not present them as comparable.

What this is worth, without us guessing your wage: at these specimen figures a desk avoids 48 coordinator-days per 1,000 completed cases — 1,000 ÷ 4.9 = 204 days, 1,000 ÷ 6.4 = 156 days. Multiply by your own loaded daily cost. We publish no dollar figure because we do not know what you pay, and a vendor quoting your payroll back at you is not evidence. Note also that +31% is the rate uplift; the labor reduction is 23% — anyone quoting 31% as a cost saving has overstated it by roughly a third.

Why this matters: Only the middle block (Runtime contribution) requires DeskGate to exist. Throughput can be pulled from any portal report; accept-rate and edit distance cannot. That second block is the row that verifies whether the software actually did the work, or if the coordinator simply retyped it faster.

Methodology · What the ledger actually measures

Each stage is bound to a task statement from the US Department of Labor's O*NET taxonomy. That is deliberate. A vendor ledger claiming "handling time fell 30%" is measuring itself against its own internal definition. A ledger reporting a change on 43-6013.00 · Complete insurance and other claim forms is measured against a public definition that predates us, applies to every desk in the country, and can be checked by anyone.

The headline number is cases completed per coordinator per day, not minutes saved per case. Minutes are the mechanism; throughput is what a desk actually budgets and hires for. A desk does not hire because a case takes four minutes longer — it hires because the queue does not clear. Measuring throughput is also the only way the result remains honest where labor costs vary: 30% of an inexpensive hour is negligible, but a queue that clears with fewer seats is valuable at any wage.

The full role, task by task, with the boundary of what we do and do not touch: see the complete task map →

Task statements are from O*NET, by the U.S. Department of Labor, Employment and Training Administration. O*NET® is a trademark of USDOL/ETA. Which stage maps to which task is our mapping, not part of the O*NET data — the Department of Labor publishes the tasks, not this product's interpretation of them.