Why report turnaround time is not a scanner problem

When a department sets out to reduce report turnaround time, the conversation usually starts with throughput: more slots, faster sequences, another scanner. Acquisition is the visible part of the process, so it attracts the attention.

It is also rarely the bottleneck.

Measure the whole interval, not the scan

Turnaround time is the interval between the study being acquired and the report being signed. Break that interval into its real segments:

1. Acquisition to archive — how long before the study is complete and available in the archive
2. Archive to worklist — how long before it appears on the right radiologist's list
3. Worklist to open — how long it waits for a reader
4. Open to draft — the actual read, including loading priors
5. Draft to sign — review, correction and signature
6. Sign to delivery — how long before the referring clinician can see it

Most departments can quote segment 4 from memory and have no instrumentation at all for segments 2, 3 and 6. That is where the hours usually go.

The three delays we find most often

Priors that load slowly, or not at all. A radiologist who waits forty seconds for a comparison study loses more time across a session than any sequence optimisation will recover. If priors live on a different tier of storage, or require a separate query, that cost is paid on every relevant read.

Worklists that do not route. A general pool means subspecialty studies wait for the right reader by chance. Routing rules that account for subspecialty, urgency and availability change the waiting profile immediately, without adding a single reader.

Re-keying between systems. When findings are dictated in one system and re-entered in another, you pay twice and introduce a transcription risk. Structured reporting that writes straight into the record removes the second pass entirely.

Instrument before you invest

Before approving capital expenditure, put timestamps on all six segments and watch them for a month. The result reorders the priority list more often than not — and the fixes that emerge are usually configuration and integration work rather than hardware.

The scanner is rarely the constraint. The handoffs around it usually are.