On 23 September I gave the LabVine Activation Session for their series on the bottleneck fallacy: you fix one part of a system and the constraint simply moves somewhere else. I used point-of-care testing as the worked example, because it's the one I've lived, from the ward floor upwards. This is the talk written down, for anyone who missed it or would rather read than watch. The recording is below.
A word on where this comes from, so you know how much weight to put on it. I worked in point-of-care teams across eight London hospital sites, through a large rollout. That's the team that walks the wards, chases the QC, retrains the night staff and explains why a result went missing. I also grew up around a family clinical diagnostics business, so I've seen the same devices from the supplier's side. POCTIFY now builds software in this field, which is my commercial interest. Nothing in the session was for sale and no product was named, and the same goes for this article.
The argument in two sentences
Moving a device closer to the patient is a local fix. The result is a system outcome. That gap is where decentralised testing succeeds or fails.
Choosing a device that performs matters, and it's the part everyone concentrates on. What decides whether decentralised testing works is what happens to the result in the ninety seconds after it appears on the screen, and in the ninety days after that.
What point-of-care testing promises, and who it belongs to
I believe in point-of-care testing, so it deserves a fair hearing first. It promises faster results, better access and earlier decisions. All three are real. None of them belong to the device. A faster result only matters if someone acts on it. Access only matters if the result reaches the person who needs it. An earlier decision only happens if the result can be trusted. Those belong to the service around the device.
The classic story goes like this. A service is frustrated with laboratory turnaround, so it buys a device and puts it where the patient is: a glucose meter on the ward, a blood gas analyser in the emergency department, a CRP test in the clinic. The result now arrives in ninety seconds instead of ninety minutes. A few months later somebody measures the pathway end to end, and it hasn't moved nearly as far as the device promised. The result sat on a screen until someone wrote it down. The laboratory repeated the test anyway. Nobody was sure who was meant to act on it. The bottleneck moved from the laboratory bench to everything around the device, and the device had already been paid for.
What arrives with the device
In a laboratory you rarely notice the quality system, because it's already around you. Someone trained runs the test, QC passed that morning and a senior is a few steps away. Put the same analyser in a community clinic or a pharmacy and very little of that travels with it unless someone designs it in. In practice I've seen five things arrive instead:
- Results that never reach the record: transcribed by hand, photographed on a phone, written on a glove.
- Competency that varies by site, by shift and by who did the induction.
- Quality control that turns into a paper ritual, filed in a folder and read only when an inspector asks.
- Tests repeated in the laboratory, because nobody trusts what they can't see.
- A result with no owner. A critical value at a community clinic at six in the evening: who acts on it?
None of these is a device fault. The device did exactly what it was bought to do. The system around it was never designed.
A real case, anonymised
A large UK hospital trust wanted to take blood gas and chemistry testing into patients' homes for its hospital-at-home service. The devices were ready and so were the clinicians. The pilot was abandoned, because nothing could carry the result from the patient's living room back into the hospital record. In the same organisation, two hundred glucose meter users were on cascade training with no central register, and every device's QC was checked by hand.
This matters beyond one trust. In March 2025 England had twenty virtual ward beds per hundred thousand people, against the forty to fifty NHS England had set as its ambition. Hospital at home is policy, and every one of those beds needs a result that gets back into the record.
Five things that have to be true around the device
I use five headings. They're my own way of organising the responsibilities set out in ISO 15189:2022, which now covers point-of-care testing, and in the MHRA guidance on point-of-care test devices. Each one is a place where a local fix becomes a system outcome, and each comes with a practical action.
1. Ownership: who owns the result?
Picture a critical potassium at a community clinic at six in the evening. The nurse who ran it has gone home, the GP hasn't seen it and the laboratory doesn't know the test happened. In most services the honest answer to "who owns that result?" is "it depends", and "it depends" isn't governance.
England had 169 community diagnostic centres in April 2025, delivering more than 96,000 point-of-care tests in the year to March 2025. When we wrote a governance playbook for them, the host trust, the operator, the integrated care board and the pathology laboratory each thought one of the others owned it. A committee doesn't answer the phone at six o'clock. Governance means a named person for every result, at every site, at every hour, with an escalation when that person isn't there.
Action: for each pathway, write down who acts on the result, within what time, and who is told when they don't. If you can't write it down, the system doesn't have an owner.
2. People: competency is a property of the network
Two hundred operators, three shifts, six sites is a typical community glucose service. Cascade training and an e-learning certificate tell you someone was trained once. They don't tell you who is safe to test today. In one small published study, thirty glucose meter operators, all automatically recertified, were observed doing the test, and six of the thirty met the study's eighty per cent checklist threshold.
Action: keep one competency register across every site, tied to the device. If the operator isn't in date, the device says no, with an agreed and audited emergency route for the genuine exceptions. Competency that can't be enforced is just a training log.
3. Quality you can see from the laboratory, and a loop that closes
Internal QC, EQA and maintenance all assume the person who runs them sits near the person who reviews them. Spread them across a city and they become paperwork that describes the past. One team I met has every community site photograph its QC log and send it on WhatsApp each morning. It's the wrong tool, with no audit trail and no trend, but the instinct is right: they want to see every site, every day.
Seeing it is half of quality. The other half is what happens after a failure. In a laboratory a QC fail or a poor EQA return becomes a non-conformance with a root cause, a corrective action and a later check that it worked. Across twenty community sites that loop breaks. The action lives in an email, nobody closes it, and the same failure comes back next month.
Action: every QC event, EQA return and lockout visible in one place by site, device and operator, and one register for every failure and incident, each with an owner, a root cause and a checked action.
4. Connectivity: a result that isn't in the record is a rumour
This is measurable. An outpatient study compared glucose results that staff typed into the record with the same results arriving through the meter's interface: 3.7 per cent disagreed, and one in seven of those was out by more than twenty per cent. A 2026 hospital study found glucose values missing from the chart or documented inaccurately. A result the laboratory can't see, or can't trust, is a result it will repeat. It has to land in the record, on the right patient, with its provenance traceable: which device, which operator, whether QC was in date.
Action: decide the route into the record before the device is chosen, not after. The trust in the case above had the devices in a cupboard and no route.
5. Oversight has to be remote by design
The POCT team can't be at every site. In a hospital they could walk the wards. Now the sites are spread across a region and the team is the same size it always was. So the service has to tell them which device missed QC this morning, which critical result hasn't been acknowledged and which site's error rate moved this week. That's the difference between finding out the same day and finding out in the audit.
Action: audit trail, alerts and performance monitoring across every site, from one screen.
Connectivity is how governance becomes behaviour
This was the point I most wanted the audience to push back on. A community result is only worth generating if the clinician acting on it and the laboratory standing behind it trust it enough not to repeat it. That trust is governance. Every one of the dependencies above can be written into a policy, and every one stays a document until something connects the device, the record and the person who has to act. Operator lock at the device is competency turned into behaviour. QC lockout is quality turned into behaviour. An alert to a named person is ownership, and an audit trail is oversight.
If a device can't connect, you lose the automation, not the governance. A manual result can still have an owner, a route and a QC record.
Once the data from every device, operator and QC event sits in one place, three things become possible: audit without a site visit, rules that apply the same way at every site, and improvement. In the talk I showed QC failures plotted by hour of day. They piled up either side of shift handover, which points at the rota before it points at the chemistry. Most point-of-care services are data rich and answer poor. The numbers exist, scattered across analysers, QC logs and competency records that were never meant to be read together.
Design the system before you choose the device
The way out of the fallacy is to change the order. Most services start with the device and work backwards. I'd start with the decision and work forwards:
- Name the decision the result changes, and who makes it. If you can't name a decision, you don't need the test.
- Name the owner of the result at every site and every hour.
- Decide the route into the patient record.
- Set the competency and QC rules the system will actually enforce.
- Then choose the device, on analytical performance and on whether it can meet steps one to four.
Make it a rule at procurement: no interface plan, no link to the competency register, no audit trail, no go-live.
Measure the service, not only the device
Time to result is the device's metric. Keep it, and put four service measures beside it, each with a threshold and a named owner:
- Reliable: QC and competency compliance, reported by site, because the average hides the site that's struggling.
- Visible: the share of results in the record within the time the pathway needs. If this is low, your device is fast and your service is slow.
- Acted upon: critical results acknowledged, with a documented clinical response, within the agreed time.
- Improved the pathway: unplanned repeat testing, and time from result to decision, looked at as the 95th percentile rather than the mean.
If you only add one, add the second. Results in the record on time is the best starting measure.
Three questions for an ordinary day
I closed with three questions a service should be able to answer on any ordinary day, not once a year with the assessor due:
- Where does a result generated outside your laboratory go after it appears on the screen? Follow it, physically, in your own service.
- Who would know today if a device at your furthest site drifted? Name the person.
- Which of your recent local fixes moved the bottleneck rather than removing it? Everyone has one. Mine was a glucose meter.
The first four of the five steps cost a pen and an honest hour with your POCT team. The connectivity will need investment, and you'll spend it far better once the rest is written down.
My thanks to Hanine and the LabVine team for the invitation, and to everyone who stayed for the discussion.
References
- Tang Friesner C, Meyer J, Nippak P. Glucose point-of-care meter operators competency: an assessment checklist. Practical Laboratory Medicine. 2020;20:e00157.
- Dyhdalo KS, Howanitz PJ, Wilkinson DS, Souers RJ, Jones BA. Documentation of quality control and operator training at point-of-care testing: a College of American Pathologists Q-Probes study of 106 institutions. Archives of Pathology and Laboratory Medicine. 2014;138(11):1444-1448.
- Mays J, Mathias P. Measuring the rate of manual transcription error in outpatient point-of-care testing. Journal of the American Medical Informatics Association. 2019;26(3):269-272.
- Hazara A, Barmanray RD, Wang R, Kyi M, Fourlanos S. Lost in transcription: frequency of inaccurate manually documented point-of-care blood glucose and ketone measures in hospital. Endocrinology, Diabetes and Metabolism. 2026;9(3):e70212.
- Parliamentary Office of Science and Technology. Virtual wards and hospital at home. POSTnote 744. UK Parliament; 2025. NHS England. Operational performance update (ambition of 40 to 50 virtual ward beds per 100,000). July 2023.
- NHS England. Community diagnostic centres. 2025. Royal College of Pathologists. An update from England's Community Diagnostic Centre Programme. RCPath Bulletin. 2025.
- ISO 15189:2022. Medical laboratories: requirements for quality and competence. International Organization for Standardization; 2022.
- Medicines and Healthcare products Regulatory Agency. In vitro diagnostic point-of-care test devices: guidance. MHRA; 2021, updated July 2026.