Before the Robot: Why Pathology Automation Should Begin With an Ethnography, Not a Business Case

A pathology automation business case has a familiar shape. A vendor supplies throughput figures for analysers per hour and tubes per track. The laboratory supplies its annual request volume. The two are multiplied, the arithmetic shows headroom, and a case goes forward. Everyone involved behaves reasonably, and the resulting number is close to meaningless.

Not because anyone is lying. Because throughput is measured on a specimen mix, an arrival pattern, a staffing model and an exception rate that belong to the reference site, not to the one doing the buying. When a trust discovers that the machine is not delivering what the spreadsheet promised, the usual explanation is that the laboratory is not using it properly. The more honest explanation is that the laboratory was never asked to describe itself accurately in the first place.

Throughput is a property of a system, not a machine

A track and analyser combination quoted at a given number of tubes per hour assumes a continuous supply of correctly labelled, correctly separated, adequately filled specimens of the right type, in the right rack, with no add-on requests, no haemolysed samples and no clinical phone calls.

Real laboratories are not like that, and NHS laboratories in 2026 are less like that than most. Demand keeps rising, the workforce is stretched, and the estate in many trusts was not designed around the equipment now standing in it. The practical consequence is that a system capable of processing a tube every few seconds may sit partly idle through the early morning and then face a queue that no amount of engineering will clear by noon, because the constraint was never the analyser. It was the pre-analytical bench, the single centrifuge, the two staff on early shift, or the interface that loses an hour whenever a request needs clarifying.

Workarounds are not noise — they are the specification

Every laboratory has them. The rack pre-sorted by hand before it goes on the track because the software would otherwise send it the long way round. The paper list of add-on requests kept on the bench because the electronic route takes four clicks too many at the busiest hour. The biomedical scientist who knows that one ward's samples arrive cold and checks them first. The overnight team that batches a category of test deliberately, against the standard operating procedure, because batching is the only way the morning run finishes in time.

Seen from a management meeting, these look like compliance problems. Seen from the bench, they are design corrections. They persist because they work, and they encode knowledge about the process that exists nowhere in writing. If an automation programme does not capture that knowledge, it will delete it — and then rediscover it, expensively, in the months after go-live.

This is the argument for treating workarounds as evidence rather than insubordination. Each one marks a point where the formal process and the real process diverge, and the divergence is usually a cost that has been absorbed by staff goodwill rather than by the capital budget.

The handoffs nobody puts in the process map

Ask for a process map and you will usually get the idealised version: sample arrives, is booked in, is analysed, result is authorised. The interesting material is in the transitions.

The request that is ambiguous and needs a phone call. The sample that is short and requires a decision about which tests to sacrifice. The result that trips a delta check and is held. The add-on that arrives after the sample has been archived. The quality failure that sends a batch back to the beginning. The clinician who rings at ten to five.

Each of these is a small negotiation between people, and each consumes time that no vendor benchmark accounts for. Automation rarely removes such negotiations. More often it relocates them — sometimes to a place where nobody has the information to resolve them quickly, which is precisely how a system that looked faster on paper ends up slower in practice.

Two weeks on the bench is cheaper than a wrong robot

A pre-procurement ethnography does not need to be elaborate. It needs to be structured, honest and finished before the specification is written.

• Observe across the whole week. Days, evenings, nights and weekends behave differently, and the weekend model often reveals the fragility that weekday staffing conceals.
• Sample the peaks. Simple time-and-motion recording at the two or three busiest hours will tell you more about capacity than any annual total.
• Build a workaround inventory. For each one: what it is, why it exists, who owns it, and what would have to be true for it to be safely retired.
• Map the handoffs and log the interruptions. Count the phone calls, the bleeps, the re-checks and the repeat requests. This is the hidden workload.
• Read the artefacts. Whiteboards, sticky notes, local spreadsheets and laminated crib sheets are primary sources.
• Review the last twelve months of incidents and near misses. They are already-written evidence of where the process bends.
• Follow thirty tubes end to end. A specimen life history, timed from arrival to authorisation, is the most persuasive document in the whole exercise.

The cost is a small team for a fortnight and some backfill. Set against a seven-figure capital programme and the disruption of a failed go-live, it is close to a rounding error.

Turning observation into a specification

Once the real process is on paper, the procurement questions change. Instead of asking what a system can do under ideal conditions, ask how it behaves at an 8 per cent exception rate, what happens in degraded mode, how it handles an ambiguous request, and what the staff-facing interface demands of someone working a night shift alone.

Contracts can then carry key performance indicators that reference the process actually observed rather than the one imagined. Go-live can be staged, with a defined fallback and a benefits-realisation plan measured against the baseline you collected before anyone signed anything.

Automate the problem, not the process

None of this is an argument against automation. UK pathology needs it, and the workforce pressures are real. It is an argument about sequence.

If you cannot describe your process as it is actually performed, you are not buying a solution to it. You are buying a machine to automate your own ignorance. The workaround on the bench is not the enemy of the workflow. Very often, it is the only honest description of it we have.