HbA1c point of care testing in community diabetes clinics

Why community diabetes services test HbA1c at the point of care

HbA1c (glycated haemoglobin) is the test most diabetes services use to monitor long-term glucose control. In the UK it is reported in mmol/mol and, for most patients, the laboratory version is requested a week or so before the review appointment. When that does not happen, or the sample is missed, the clinician is left discussing a result that is months old, or none at all. That is the problem point of care HbA1c solves: a fingerprick sample, a bench-top analyser such as the Abbott Afinion 2 or the Siemens DCA Vantage, and a result in a few minutes while the patient is still in the room.

Attendance for a separate blood test is lower than for the appointment itself, and the patients who travel furthest or rely on carers are the ones most likely to miss it. Nurse-led and pharmacist-led clinics can complete a review in a single visit.

The trade for that convenience is governance. A laboratory HbA1c is produced inside an accredited system with trained scientists and scheduled quality control (QC). A point of care HbA1c is produced by a nurse or healthcare assistant, on a device in a clinic room, between two other tasks. The service has to build the same assurance around it: the right patient, an authorised operator, a device in control, and a result that reached the record the clinician and the GP practice will read.

This page is about workflow and governance. It does not describe what an HbA1c value means or how a clinician should act on it. Monitoring intervals and targets are set out in guidance from the National Institute for Health and Care Excellence (NICE), for example NICE NG28 for type 2 diabetes in adults, and interpretation belongs to the clinician.

The end-to-end journey, stage by stage

The journey assumes a typical clinic: a diabetes nurse specialist or practice nurse running it, a healthcare assistant (HCA) taking samples and operating the analyser, and a POCT coordinator, usually in the local trust's pathology laboratory, responsible for the device.

1. Appointment and clinical decision

The clinician decides an HbA1c is needed today, because it was planned as part of the review or because there is no recent laboratory result. The clinician needs to know whether the patient is suitable for a point of care test under the local procedure (which may direct some patients to the laboratory instead), and to record the request so the result has something to attach to.

2. Patient identification

The HCA confirms who the patient is before taking the sample: at least two identifiers, typically name, date of birth and NHS number, with the same identity travelling with the sample to the analyser and with the result to the record. Typing a name into an analyser keypad is where identities go wrong. Better options are scanning an appointment barcode, selecting the patient from today's clinic list on the analyser's connected worklist, or entering the NHS number and having the software show the demographics back for confirmation before the cartridge goes in.

3. Operator sign-in and readiness

The operator signs in with their own credentials, never a shared clinic login. Before testing, three things have to be true: this operator is trained and in date on this device, this device is in service and not locked out, and QC is current per the local procedure and the manufacturer's instructions. Good systems show all three on one screen in plain words ("QC due", "competency expires in 12 days", "device ready") and stop the test if any is false.

4. Test and result capture

The sample is run according to the manufacturer's instructions for use, and the result is captured electronically with the operator identity, device serial number, cartridge lot, time and QC status attached. If the clinic still writes results on a card, this is where the workflow fails silently: the card can be lost, mistyped or attached to the wrong patient. The need here is an on-screen confirmation that the software received the result, not just that the device printed it.

5. A valid result is available to the reviewing clinician

This step is the one most often assumed rather than designed. The reviewing clinician needs to know that the result is in the record they are looking at, and that it is a valid result rather than a preliminary, held, repeated or failed one. A held result should look different from a final one and say why, and a device error code should never appear in the record as if it were a number. The record means the GP clinical system, most often EMIS Web or SystmOne, or the community trust's own system, and where the laboratory retains oversight, the laboratory information management system (LIMS) as well.

6. Clinical discussion

The clinician discusses the result with the patient and records the plan. The governance need is that the discussion is based on the valid result in the record, and that if a laboratory result later joins it, both remain visible with their source labelled, since the two come from different methods.

7. Governance review

After the clinic, and on a schedule, the POCT coordinator reviews QC, operators, held results, transmission failures and incidents, from records that already exist rather than from a reconstruction.

The exception paths

A workflow that only describes the happy path is a diagram, not a procedure. Each exception needs an agreed action, a named owner and a record.

Ambiguous patient match. The software finds two possible patients, or none. The result is held in a work queue visible to the clinic lead, the identity is resolved against the clinic list and the patient, and the result is filed with a record of who resolved it and how. Holding is a feature, not a fault: it is the reason a wrong-patient result did not reach the record.

Operator not authorised. The person about to test has no training record, or their competency has lapsed. The analyser should refuse the test, and the clinic needs a fallback planned in advance: another authorised operator, or a laboratory sample. The coordinator needs to see who is close to expiry before clinic day. The clinic should never respond by sharing a login.

QC failure. The device fails its QC run, or QC is overdue. Per the manufacturer's instructions and the local procedure, patient testing on that device stops until QC passes, and any patient result produced since the last acceptable QC is flagged for review. The QC software should link the failed run to those results automatically.

Transmission failure. The result was produced but did not reach the record. Two things matter: that the result is not lost (a gateway that stores locally and forwards later solves this) and that somebody is told. An unsent results queue with a visible count, checked before the clinic closes, is the practical control.

Unexpected result. A result outside the range the service has agreed to act on is escalated according to local clinical policy, which may mean a repeat, a laboratory sample or a same-day discussion with the supervising clinician. The software's role is to flag the result against the agreed threshold and record who was notified and when, not to interpret it.

Device error or no result. The operator follows the manufacturer's troubleshooting steps, records the error code, and either repeats with a new cartridge or moves to the fallback. Error codes are logged against the device so the coordinator can see a pattern.

Accessibility of the software for clinic staff

Clinic staff use POCT software on a shared PC or a tablet, often with gloves on, so accessibility is part of whether the workflow above will actually be followed. Public sector organisations in the UK are also subject to the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, which point to the Web Content Accessibility Guidelines (WCAG) 2.2 at level AA; GOV.UK explains the accessibility requirements for public sector bodies. The practical checks are:

• Keyboard use. Every step, including selecting a patient, confirming identity, acknowledging a held result and signing off, can be completed with the keyboard alone. This matters for speed at a shared PC as much as for staff who cannot use a mouse.
• Not colour alone. A held, failed or preliminary result is distinguished by a word or an icon as well as a colour. Red and green alone are invisible to a proportion of staff and to anyone reading a monochrome printout.
• Clear error messages. When something is wrong, the message says what to do next in plain English, not a code.

Ask the supplier for an accessibility statement and test the clinic's actual steps against it.

What the POCT coordinator reviews afterwards

The POCT coordinator, acting for the laboratory under ISO 15189:2022 Annex A and the guidance from the Medicines and Healthcare products Regulatory Agency (MHRA) on managing point of care test devices, reviews the clinic's testing on a schedule agreed with the POCT committee. The review covers:

1. QC. Every device ran QC at the required frequency, results were within the manufacturer's ranges, failures were actioned, and Levey-Jennings charts show no drift or shift.
2. Operators. Every result was produced by an operator with in-date competency on that device. Anyone approaching expiry is booked for reassessment. The operator competency records should give this list without manual cross-checking.
3. Held and unmatched results. Every held result was resolved, by whom and when. Any that were discarded have a reason recorded.
4. Transmission. The count of results produced matches the count filed in the record. Any gap is investigated.
5. Escalations. Unexpected results were escalated per the policy, with the notification recorded.
6. Incidents and errors. Device errors, near misses and wrong-patient events are logged in the organisation's incident system and, where a device may have contributed, reported to the MHRA through the Yellow Card scheme.
7. External quality assessment (EQA). EQA samples, for example from a UK NEQAS scheme, were run on schedule, returned and reviewed, with any unsatisfactory performance investigated.
8. Inventory. Cartridge lots in use are recorded, in date and stored per the manufacturer's instructions.

The output is a short written record for the POCT committee, plus actions with owners. If the review takes longer than the clinic did, the evidence is being collected in the wrong place.

Whose responsibility is what

Three parties stand behind a point of care HbA1c, and the workflow only works if each one's responsibility is clear.

• The manufacturer is responsible for the analytical performance of the analyser: precision, bias, interferences, measuring range and the QC procedure, as set out in the instructions for use; the service verifies it before go-live but does not redesign it.
• The clinician is responsible for interpreting the result and deciding what to do, guided by NICE and local policy. Interpretation stays with the responsible clinician, not with the software.
• The service, through the POCT coordinator and committee, is responsible for everything in between: the right patient, an authorised operator, a device in control, a result that reached the record, and the evidence that all of this happened. Software belongs in this box, and should stay out of the other two.

Stage-by-stage table: who, what has to be true, evidence

Where software helps

Most of the failure points above are records problems, and software built for point of care workflow addresses them as they happen rather than at the review. What to look for:

• Patient selection from the clinic list or by NHS number, with demographics shown back before the test, and a held queue for ambiguous matches rather than a best guess.
• Operator lockout tied to named competency records, with expiry visible to the coordinator before clinic day.
• QC captured from the device as it runs, with Westgard rules and an automatic link between a failed run and the patient results around it.
• Delivery into EMIS Web, SystmOne or the trust's clinical system over HL7 v2 or FHIR, with a store-and-forward gateway for clinics with poor connectivity, and a visible unsent count.
• Clear result states (final, held, failed, superseded) shown in words as well as colour.
• A review screen for the coordinator that answers the eight questions above without exporting spreadsheets.

Catenix is designed and ready to do this for community and primary care services over open standards, with the connection to each clinical system confirmed during implementation: the results governance module handles patient matching, held results and escalation, and patient management covers clinic lists, identification and scheduling. It is designed and ready to connect to the clinical systems named above over open standards, and it does not interpret results or offer clinical decision support.

Questions people ask

Can HbA1c be tested at the point of care?

Yes. Bench-top analysers such as the Abbott Afinion 2 and Siemens DCA Vantage measure HbA1c from a fingerprick sample in a few minutes and are widely used in community diabetes and primary care clinics in the UK. The service running them is responsible for operator training, quality control, EQA and getting the result into the patient record, under ISO 15189:2022 Annex A and MHRA guidance on point of care devices.

Who can perform point of care HbA1c testing in a community clinic?

Any member of staff who has been trained on the specific analyser and assessed as competent under the service's POCT policy, typically healthcare assistants, practice nurses, diabetes specialist nurses and pharmacists. Competency is recorded against the named person and the named device, and reviewed on a schedule. Good practice, and most connected analysers, prevent testing by anyone without a current competency record.

Does a point of care HbA1c result go into the patient's GP record?

It should. A connected analyser sends the result, with the operator, device and lot, through middleware into the clinical system the practice or service uses, such as EMIS Web or SystmOne, and where the laboratory retains oversight into the LIMS as well. An unconnected analyser leaves the result on the device or on paper, which means it has to be typed in, with the risk of transcription error and no attached evidence.

What happens if QC fails on a point of care HbA1c analyser?

Patient testing on that device stops until the cause is found and QC passes, following the manufacturer's instructions and the local procedure. Any patient results produced since the last acceptable QC are reviewed and, where the local policy requires, repeated or referred to the laboratory. The failure, the investigation and the outcome are recorded so the POCT coordinator can see them at the next review.

Who is responsible for point of care testing in a community diabetes service?

Responsibility is shared and should be written down. The manufacturer is responsible for the analyser's performance as described in its instructions for use. The clinician is responsible for interpreting the result. The service, through a POCT coordinator and committee usually linked to the local pathology laboratory, is responsible for training, competency, quality control, EQA, device management and getting the result into the record, under ISO 15189:2022 Annex A and MHRA guidance.

Is a point of care HbA1c result the same as a laboratory HbA1c?

They are different methods measuring the same analyte, both traceable to the IFCC reference method and reported in mmol/mol in the UK. The service verifies the point of care analyser against the laboratory before use and repeats that comparison on a schedule. Because the methods differ, the record should label each result with its source so the clinician knows which method produced it. Interpretation of any difference is a clinical matter.

Sources and further reading

• ISO 15189:2022 Medical laboratories: requirements for quality and competence (Annex A, point-of-care testing)
• MHRA, Management and use of IVD point of care test devices
• NICE NG28, Type 2 diabetes in adults: management
• GOV.UK, Understanding accessibility requirements for public sector bodies
• W3C, Web Content Accessibility Guidelines (WCAG) 2.2