Point of care testing in general practice: workflow and governance

Why GP practices adopt point-of-care testing

Point-of-care testing (POCT) in general practice means running a test in the practice, during or straight after the consultation, instead of sending the sample to the pathology laboratory. Practices adopt it for a small number of tests where the same-day result changes what happens in the room.

• CRP for respiratory infection. C-reactive protein (CRP) testing at the point of care is the test with the clearest place in national guidance. National Institute for Health and Care Excellence (NICE) clinical guideline NG237, Pneumonia in adults: diagnosis and management, says that for people presenting in primary care with symptoms of lower respiratory tract infection, a point-of-care CRP test can be considered when pneumonia has not been diagnosed after clinical assessment and it is not clear whether antibiotics should be prescribed. The practice's antimicrobial stewardship lead is usually the sponsor. Check the current version on nice.org.uk, because NICE revises guidelines and the antibiotic prescribing element is now covered by NICE NG138.
• HbA1c for diabetes reviews. Glycated haemoglobin (HbA1c) on a benchtop analyser lets a diabetes review be completed in one appointment rather than a blood test followed by a second contact.
• INR clinics. Practices that run their own anticoagulation service for patients on warfarin use a handheld international normalised ratio (INR) meter with a dosing tool.
• Urinalysis. Dipstick testing, visually read or on a reader, is the most widely used and least governed test in general practice.
• Others. Glucose, pregnancy tests, and in some practices D-dimer or lipids. Each needs the same governance as the tests above.

What this article does not do is say what any result means or what treatment follows. That is clinical guidance and the practice's own protocols. It covers the workflow, the governance and the connectivity, which are the parts that go wrong.

The workflow from consultation to filed result

The workflow for a POCT result should look like the workflow for a laboratory result, because the record it ends up in is the same. In order:

1. Decision. The clinician decides a test is needed and records the reason in the consultation, in EMIS Web or SystmOne.
2. Identity. The patient's identity is confirmed and the NHS number is the identifier that travels with the sample and the result. Where the analyser accepts a patient identifier, it should be scanned or selected, not typed.
3. Operator. The person running the test signs in to the analyser or the software with their own identifier. That person must be on the current competency list for that device.
4. Sample and test. A finger-prick or venous sample, run according to the standard operating procedure (SOP), on a device whose quality control (QC) is in date.
5. Result. The analyser produces the result with a time stamp, the device serial number and the reagent lot.
6. Filing. The result is filed in the patient's record as a coded result, using the SNOMED CT concept the practice uses for that test, so that it appears in the results view, contributes to searches and the Quality and Outcomes Framework (QOF), and is visible to anyone who later reads the record. It should carry the fact that it was a point-of-care result, the device and the operator.
7. Action. The clinician reviews and acts on the result in the consultation, and the action is recorded.
8. Housekeeping. QC, consumable use and any device messages are logged, ideally automatically.

Step 6 is where most practices fall short. There are two ways a result gets into EMIS Web or SystmOne. The first is a person typing it into a template. The second is a message from the analyser, through connectivity software, that files the result the way a laboratory report files, through the practice's results workflow. The second route is what middleware provides; the guide to connecting POCT to UK clinical systems explains the messaging options and which of them need the practice's system supplier or the integrated care board (ICB) to enable an interface.

Common failure modes

These are the problems that come up when a practice's POCT is reviewed, whether by the local laboratory, the Care Quality Commission (CQC) or an internal audit after an incident.

• Retyping. The result is read off the screen and typed into the consultation. A transposed digit in an INR or an HbA1c is a treatment error waiting to happen, and there is no way to detect it afterwards.
• Results in a notebook. The practice keeps a paper log by the analyser. The result is in the notebook and, sometimes, in the record. The two disagree and nobody knows which is right.
• Results as free text. The result is typed into the consultation text rather than filed as a coded value. Searches, QOF and the results view do not see it, and the next clinician does not either.
• QC not done. Controls are expensive and the box says the device self-checks, so QC is run when someone remembers. There is no chart, so drift is invisible until an external quality assessment (EQA) report or a patient result that does not fit.
• No competency record. The nurse who set the device up trained everyone else informally. When they leave, no one can say who is competent, and the CQC inspector asks.
• Device drift. The analyser has not been compared with the laboratory since it was installed. Results have moved and no one has noticed because nothing forces the comparison.
• Lot and storage. Reagent lots are not recorded against results, expired strips are in the drawer, and controls have been kept at room temperature.
• No downtime plan. When the analyser fails during a clinic, nobody knows whether to send samples to the laboratory, and results due that day are missed.

Every one of these is preventable, and most of them are prevented by making the record a by-product of running the test rather than a separate task.

What the MHRA guidance asks, in plain language

The Medicines and Healthcare products Regulatory Agency (MHRA) publishes Management and use of IVD point of care test devices. IVD means in vitro diagnostic, a test on a sample taken from the body. It is guidance, not regulation, and it is written for hospitals as much as for practices, but it is the document an investigator will reach for if a POCT result leads to harm. Stripped of the laboratory language, it asks a practice to do the following.

1. Put someone in charge. A named person is responsible for POCT in the practice. In a hospital this is the POCT coordinator; in a practice it is usually the nurse lead or the practice manager, with a GP as clinical lead.
2. Involve the laboratory. Choose devices with advice from the local pathology laboratory, and ask them to help with verification and EQA.
3. Verify before use. Show the device performs as claimed in your hands before the first patient test, and write it down.
4. Train and assess. Everyone who runs a test is trained, assessed and reassessed, and the record says so.
5. Write the procedure. An SOP for each test covering identity, sampling, running, errors, recording and what to do with the result.
6. Run QC and EQA. Internal QC on a schedule and on every new lot, charted and reviewed; registration with an EQA scheme for quantitative tests.
7. Record every result. Against the patient, the operator, the device and the lot, in a way that can be retrieved.
8. Maintain and report. Keep the device serviced, and report faults and adverse incidents to the MHRA.
9. Review. Look at QC, EQA, incidents and usage periodically and act on what you find.

A practice that can produce evidence for those nine points is doing what the guidance asks. The operator competency page and the Westgard rules explainer cover points 4 and 6 in more depth.

Working with the pathology laboratory and the POCT committee

The pathology laboratory that serves the practice is accredited by the United Kingdom Accreditation Service (UKAS) against ISO 15189:2022, and Annex A of that standard covers point-of-care testing the laboratory supports. Whether a practice's POCT falls within the laboratory's scope is not automatic. It depends on whether the laboratory has agreed to support it and whether the arrangement is documented. Many laboratories offer a POCT support service to primary care, often through the ICB, covering device selection, verification, training, EQA registration, QC review and incident investigation. Where that exists, using it is the single most effective governance step a practice can take.

The laboratory or the ICB will usually have a POCT committee. A practice does not need its own, but it should know who sits on the one that covers it, send its QC and EQA performance to it if asked, and take new devices to it before buying. Where there is no committee covering primary care, a primary care network (PCN) can set up a light version: the PCN clinical director, a practice nurse lead, a laboratory representative and a practice manager, meeting a few times a year to approve devices and review performance across the member practices.

The laboratory will want three things from the practice in return: results it can see, so that the POCT result sits in the patient's pathology history and can be compared with laboratory results; QC data it can review without visiting; and a competency list it can trust. All three depend on the practice's POCT being connected rather than on paper.

A simple governance table

The table is deliberately short. A practice does not need a laboratory's quality manual; it needs to be able to answer, for any result, who ran it, on what, with which lot, whether QC had passed, and where the result went.

Where software helps

The software that connects a POCT analyser to the practice record is usually called middleware in a hospital. In a practice it does three things. It takes the result off the analyser so nobody types it and files it as a coded result in EMIS Web or SystmOne. It enforces the rules, so that an operator who is not on the competency list, or a device whose QC has failed, cannot run a patient test. And it keeps the records the MHRA guidance asks for, QC charts, competency, lots and an audit trail, as a by-product of the work.

Catenix is designed and ready to do this for general practice over open standards, with the connection to the practice's clinical system confirmed during implementation. Results are captured from the analyser over the device's own messaging standard and delivered to EMIS Web or SystmOne; the platform is designed and ready to connect to both over open standards, and the route used at a given practice depends on the interfaces the system supplier and the ICB make available. QC is captured as it happens and charted with Westgard rules and lockouts, competency is recorded against the person who ran the test, and inventory is tracked by lot and expiry. Catenix does not interpret results or provide clinical decision support; the clinical decision stays with the clinician.

For a practice comparing products, the questions are the ones in the workflow section: does the result file as a coded result without retyping, does the system stop a test when competency or QC is not in order, and can the laboratory see the QC data without visiting. The QC software page shows what the second of those looks like in practice.

Questions people ask

Which point-of-care tests are used in general practice?

The common ones are CRP for respiratory infection consultations, HbA1c for diabetes reviews, INR in practice-run anticoagulation clinics, urinalysis dipsticks and glucose. Some practices add lipids or D-dimer. Each test needs the same governance: a verified device, trained operators, internal quality control, EQA where the test is quantitative, and a result filed in the patient's record as a coded value.

Does NICE recommend point-of-care CRP testing in general practice?

NICE's guidance on suspected acute respiratory infection in adults (NG237) covers point-of-care CRP testing for people presenting in primary care with symptoms of lower respiratory tract infection, where pneumonia has not been diagnosed and it is not clear whether antibiotics should be prescribed. NICE's pneumonia guidance (NG250) replaced the older NG237 and NG138, so check the current version before quoting it. It is a consideration, not a requirement. Check the current version on nice.org.uk, as NICE revises its guidance.

How do I get point-of-care results into EMIS Web or SystmOne?

Either by typing the result into a template, which is the most common and most error-prone route, or by connecting the analyser through middleware that files the result as a coded value through the practice's results workflow. The connected route requires an interface that the practice's system supplier or the ICB enables, so ask the software vendor which route is available for your system before buying.

Does a GP practice need a POCT committee?

Not its own. The practice should know which POCT committee covers it, usually the pathology laboratory's or the integrated care board's, and should take new devices to it and report QC and EQA performance when asked. Where nothing covers primary care, a primary care network can run a light version with a clinical lead, a nurse lead, a laboratory representative and a practice manager.

Is the CQC interested in point-of-care testing in general practice?

Yes. The Care Quality Commission looks at whether care is safe and well led, and point-of-care testing sits inside that: whether devices are maintained and quality controlled, whether staff are trained and competent, whether results are recorded in the patient's record and acted on, and whether incidents are reviewed. A practice with a device register, competency records, QC charts and results filed in the record can show all of this.

Sources and further reading

• NICE NG237, Suspected acute respiratory infection in over 16s: assessment at first presentation and initial management
• NICE NG250, Pneumonia: diagnosis and management
• MHRA, Management and use of IVD point of care test devices
• ISO 15189:2022 Medical laboratories: requirements for quality and competence