← Back to Work
Process file · Healthcare Healthcare

What’s inside: company memory · audit trail

Prior authorisation from the chart; clinician adds one sentence

The question this file answersHow long does a prior-auth request sit in our inbox before anyone even finds the note and the code?

Fits: providers where every encounter generates coding and billing work.

Typical day

What the desk looks like today

Typical pattern, not a measured desk — the healthcare playbook has no volume for prior authorisations, so none is stated. Note, code and payer form live in three places; admin rebuilds the same request each time, then waits on a clinician for a sentence. It bites as the procedure date nears.

What changes

What Monday looks like after

Mid-morning, the authorisation clerk opens a list of requests that are complete except for the clinical sentence, each with the note and codes already attached. The clinician's part shrinks to reading and signing; the chasing between three systems is what disappears.

Typical, not a measured client result. Every figure here comes from the playbook source named below.

Pre-filled

the request pre-filled from the chart — built like our coding and denials file; prior authorisation has no published figure

Before: admin rebuilds the same request, then waits on a clinician for one sentence. After: the form is pre-filled from the chart and the clinician writes the sentence and signs. The desk carries no percentage, because none has been published for it.

No published figure for this desk. The range lives on the parent file: Suggested codes on routine encounters; denials get the specialist →

How this file is built

We found no published figure for prior-authorisation assembly. The coding range in the healthcare playbook (AHIMA and McKinsey, both 2023) and Deloitte's (2023) document-processing figure describe claims and correspondence; they live on their own files and are not transferred here. Not a clinical outcome.

What we install

What we put in front of the systems you already run

Your EHR and billing tools stay — Epic, Cerner, Athenahealth, Waystar or the ones you run. We point the coding-and-denials build at the request instead of the claim:

  1. the note, the diagnosis and procedure codes and the payer's form are pulled together from the EHR and the billing system
  2. the form is pre-filled and the gaps are marked in the file
  3. the clinician sees only the missing sentence and the submit button — nothing goes to a payer without that signature.
What stays human — and what this will not do

Medical necessity. Peer-to-peer calls. Appeals. The sentence only a clinician can write.

Not a clinical outcome.

What can go wrong — and what we do about it

Payer forms change without notice; a new template defeats the pre-fill until someone re-teaches it, so an incomplete file goes to a person rather than out of the door. If the codes in the note and in the billing system disagree, the request stalls — and that mismatch is usually the real problem, not the paperwork. Medical necessity is never inferred by the model; the coding benchmarks on the parent file are about claims, not authorisations.

What it costs to get there

The path: free 60-second estimate → free 20-minute review → paid audit of this one process (€1.5–3K, typically two weeks) → pilot with your people in the loop (€10–20K, weeks, not quarters). No transformation programme. Prices are public, on the services page →

Scoped in the audit — the playbook has no estimate for this exact desk.

This is about you if…
What does this mean in euros?

That depends on your volumes and wage costs — this page will not invent the number. The free 60-second estimate runs that calculation from your answers, with every multiplier sourced.

Get your free savings estimate 60 seconds · no sales call Or write first → Map a healthcare process like this one — free, 60 seconds →

Not a named Aperanda client. Process file · Healthcare.

Short process file. Same build as its parent file; the playbook has no separate volume or benchmark for this desk.

All process files