Cutting pre-authorisation turnaround from 9 days to 36 hours

The situation#

Every pre-authorisation request needed the clinical notes, the diagnostic reports, the proposed procedure with codes, the cost estimate and the policy details, assembled into whatever format the specific insurer wanted. Six insurers, six formats.

The information existed. It sat in the hospital information system, the lab system, a PACS archive and a shared drive of scanned consent forms, and a billing executive gathered it by hand for each request.

Median turnaround was nine days. The group had assumed this was insurer latency. It was not, and finding that out changed the whole scope.

What we did#

Week 1 — measured where the nine days actually went. We instrumented the existing process before proposing anything. Six days were internal document gathering and rework after insurer queries. Three were insurer response time. Only the first number was ours to fix, and it was the larger one.

Weeks 2–3 — built the assembly pipeline. Extraction from the source systems into a structured request, validated against each insurer's requirements before submission. The validation step mattered more than the extraction — most rework was caused by submitting incomplete packs, not incorrect ones.

Weeks 4–5 — coding assistance. ICD and procedure code suggestions from the clinical record, with the supporting text cited inline, for a coder to accept or reject. We measured agreement against 900 historic records coded by their own coders, reported per code family rather than as one headline number.

Weeks 6–7 — governance and handover. A DPIA under the DPDP Act, decision-level audit logging, the oversight design with named authority, and the evaluation suite handed to their team with the runbook.

The boundary we kept#

No clinical determination is automated. The system assembles evidence and suggests codes; a clinician decides what treatment is appropriate and a coder signs the coding. Medical necessity is never inferred by software.

That boundary made the internal approval straightforward, and it is the right design regardless of what the approval process had required.

What we would do differently#

We under-scoped the review interface. The extraction worked early, and we treated the coder-facing review screen as a thin layer over it — which meant that for the first fortnight in production, checking a suggestion took a coder almost as long as coding from scratch, because the supporting text was not positioned next to the field it justified.

We rebuilt it in week six and throughput moved immediately. It should have been designed alongside the extraction rather than after it, and on later engagements we now scope the review interface as a first-class deliverable with its own timeline. The lesson generalises: in document processing, the exception queue is not an afterthought to the automation, it is half the product.

Where it went next#

The group extended coverage to two further insurers using their own team and the evaluation suite, which was the intended outcome. Discharge summary drafting is in a pilot on one specialty.

The coding assistance is monitored on reviewer agreement rate rather than raw throughput — a rising acceptance rate paired with a falling review time is treated as a warning that coders are rubber-stamping, not as an efficiency gain.