Rapid Tests, Real-World Conditions: A Commissioner's Checklist for Community Point-of-Care Diagnostics

Point-of-care testing has moved from the margins of UK diagnostics to something closer to a front door. Community pharmacies now deliver NHS-funded consultations for common conditions, urgent treatment centres triage with a meter at the elbow, and community diagnostic centres have pushed phlebotomy and imaging closer to where people live. Each of those settings has generated an appetite for a result that arrives in minutes rather than days.

That appetite is understandable. But a rapid test is not a small laboratory. It is a laboratory function distributed across a building that was never designed for it, performed by staff whose primary role is something else, and connected to a record system that may never have expected it. Scaling community testing well depends far less on the analytical performance of the device than on the arrangements wrapped around it.

What a rapid test can, and cannot, tell you

Analytical performance is the easy part. Manufacturers publish precision, limit of detection and interference data, and for most UKCA-marked devices those figures are credible within their stated scope.

Clinical performance is harder. Sensitivity and specificity are properties of a test; positive and negative predictive values are properties of a population. Move a test with 90 per cent specificity into a setting where prevalence is 2 per cent and a large share of its positives will be false. The device has not changed. The setting has. Commissioners inheriting a performance table from a business case written for a hospital clinic should ask, explicitly, whether the prevalence assumption still holds at the pharmacy counter.

There is also the question of what the result is for. A test that changes a decision within the same consultation — treat or refer, antivirals or reassurance — earns its place. A test that produces a number which then has to be interpreted elsewhere, or repeated in a laboratory anyway, adds a step rather than removing one.

Four places programmes come unstuck

The operator

Point-of-care devices are often described as simple. Simple is not the same as error-proof. Capillary sampling, device hygiene, timing, storage temperature and correct entry of patient identifiers all sit with the operator, and operator variability is usually the largest single source of uncertainty in a community setting. Training is necessary but not sufficient. What matters is competency assessment at defined intervals, a record of who is authorised to test on which device, and a route to withdraw that authorisation when competence lapses.

Quality

Internal quality control, external quality assessment, lot-to-lot verification and equipment records do not disappear because the analyser is small. In practice they are the first things to be dropped when a pharmacy is short-staffed. A scalable model assigns these tasks explicitly, names an accountable person, and builds them into the rota rather than bolting them on afterwards.

Connectivity

Results typed into a clinical system by hand are results that will one day be typed wrongly. Where a device can post directly into the shared record, the gain is real; where it cannot, the manual transcription step needs its own control. Connectivity also determines whether the laboratory can see what is happening in the community at all — and a laboratory that cannot see community results cannot assure them, trend them or investigate them.

Governance

Decisions about who owns the quality framework, who investigates a discrepant result, who reports an incident and who is accountable to the regulator need answers before go-live. Diagnostic and screening activity is a regulated activity where it is delivered; device conformity and post-market surveillance obligations sit with the provider; and accreditation against the applicable medical laboratory and point-of-care quality standards is a live question rather than a hospital-only concern. These are not obstacles to community testing. They are the terms on which it is safe.

A pre-scale checklist

Before any device is ordered, it is worth being able to answer the following without hedging:

• The clinical question. Which decision changes, for which patients, at which point in the pathway?
• The prevalence assumption. What is the expected prevalence in this setting, and what does that do to predictive values?
• The operator model. Who tests, how often, how are they trained, and how is competence re-verified?
• The quality plan. Who runs internal quality control, how are external assessment rounds handled, and where are the records kept?
• The connectivity route. Does the result reach the record automatically, and if not, what control covers transcription?
• The escalation route. Where does an unexpected or discrepant result go, and who acts on it, and by when?
• The incident route. How is a device fault or a patient-safety event reported, and to whom?
• The finance. Has the whole cost been counted — staff time, quality activity, consumables, connectivity, disposal?
• The exit. What happens if the service is withdrawn, the device is discontinued or the supplier changes?

Commissioning the service, not the box

The temptation in a constrained financial year is to buy the cheapest device that meets the specification and treat everything else as implementation detail. That framing tends to produce pilots that work beautifully for six months and then quietly stop.

The alternative is to commission a testing service and let the device be one component of it. That means writing requirements around the pathway, the quality framework and the data flow; funding quality activity honestly rather than treating it as volunteer work; and agreeing in advance how performance will be reviewed and by whom. Point-of-care testing in the community is not a shortcut around laboratory standards. It is laboratory standards delivered at a distance — and the distance is exactly where governance earns its keep.