Before the Barcode: Why UK Pathology Ordering Screens Deserve a Safety Case

Most laboratory quality effort is directed at the bench: analyser validation, internal quality control, external quality assessment, standard operating procedures and staff training. That emphasis is necessary. But it can obscure an uncomfortable fact: the specimen is often shaped before phlebotomy. The request form, whether paper or electronic, tells the patient what to expect, the collector what to take, and the laboratory what question is being asked. When those instructions are ambiguous, the laboratory inherits a problem it did not design.

The preanalytical error that starts on screen

Consider four common patterns in UK pathology ordering.

• Free-text clinical details. A field labelled clinical details may invite a sentence, a diagnosis code, a drug name or nothing at all. The laboratory may receive useful context, or it may receive an abbreviation that means different things to different teams. The result is not simply missing information; it is inconsistent information that cannot be triaged reliably.
• Default test panels. Defaults are efficient when they match the clinical question. They become a hazard when they reflect historical habit rather than current guidance. A panel that adds tests by default can increase cost and false-positive risk, while a panel that omits a relevant test can generate a repeat request and a second specimen.
• Missing clinical context at the point of order. Some requesting systems ask for the test but not the reason. The laboratory then has to interpret a result without knowing whether it is being used for screening, diagnosis, monitoring or exclusion. That uncertainty affects delta checks, add-on decisions and the advice given by clinical scientists.
• Add-on workflows. Add-on requests are a useful safety valve, but they can also become an invisible second ordering system. If the add-on process is poorly defined, samples may be retrieved unnecessarily, stability limits may be missed, and the original clinical question may be lost between the first request and the second.

None of these patterns is exotic. Each is a design choice. Together they show why the ordering interface deserves the same scrutiny as the analyser: it determines which specimen is collected, how it is labelled, what clinical information travels with it and whether the laboratory can answer the question first time.

A safety case for the ordering interface

Medical device regulation is not the only test of whether something matters. In the UK, software that informs diagnosis or treatment may fall within medical device rules, but many ordering screens are treated as administrative tools. That distinction is hard to defend at the point where a default panel selects the wrong test or a free-text field fails to carry a red flag.

The practical response is not to argue that every request form is a regulated device. It is to apply device-like discipline. That means defining the intended use of the ordering interface, analysing where it can fail, validating it with real users, controlling changes and monitoring it after deployment. A laboratory would not accept an analyser without a validation pack and change control. An ordering screen that shapes thousands of specimens should not be exempt from similar questions simply because it sits in a web browser.

An audit and redesign checklist

For laboratories, primary care and IT teams, the following checklist offers a starting point.

1. Map the order-to-bench pathway. Document every step from the clinician opening the request to the specimen arriving in the laboratory. Include paper forms, electronic requesting, phlebotomy lists, transport and add-on requests. The aim is to identify where information is created, transformed or lost.
2. Sample the free text. Review a structured sample of requests across high-volume and high-risk tests. Categorise the clinical details as sufficient, ambiguous, absent or contradictory. Feed the findings back to users and system owners rather than treating them as individual poor practice.
3. Test the defaults. For each default panel, ask what clinical question it is designed to answer, whether it reflects current UK guidance and whether it can be edited easily. Defaults should be owned, reviewed and dated, not inherited indefinitely.
4. Make clinical details purposeful. Replace open-ended prompts with structured fields where possible: indication, relevant medication, pregnancy status, previous results or infection risk. Allow free text only where it adds value, and explain why the information is needed.
5. Trace add-on requests. Define who can request an add-on, on which specimens, within what time limit and with what clinical justification. Audit a sample to see whether the process is being used as intended or as a workaround for poor initial ordering.
6. Check duplicate and look-alike orders. Look for tests with similar names, panels that overlap, and order sets that encourage repeat requesting. These are usability problems before they are utilisation problems.
7. Run usability sessions with real users. Ask clinicians, phlebotomists and laboratory staff to complete realistic ordering tasks. Observe where they hesitate, guess or seek workarounds. A screen that works in a demonstration may fail in a busy clinic.
8. Define metrics and ownership. Track duplicate requests, rejected specimens, add-on rates, missing clinical details and time to result. Assign a named owner for the ordering interface and a route for users to report problems.

Governance: the screen is shared territory

Ordering interfaces sit between primary care, secondary care, laboratory medicine and IT. That is precisely why they can be neglected. Everyone depends on them, but no single group may feel responsible for their design. A named owner is therefore essential, together with a change-control process that treats interface updates as safety-relevant changes rather than routine configuration.

Training also matters, but it should not be used to compensate for poor design. If staff need to remember a local workaround to order a test correctly, the interface is doing too little. The better approach is to make the safe order the easy order: clear prompts, sensible defaults, visible guidance and a simple route for add-on requests.

Conclusion

Laboratories cannot validate their way out of a poorly designed request. The request form and the electronic ordering screen are part of the diagnostic pathway, and they shape the specimen long before it reaches the bench. In 2026, with UK pathology services under continued pressure to do more with finite capacity, the ordering interface is not a clerical afterthought. It is a safety control. It deserves a safety case.