POCT middleware buyer's guide: twelve capabilities that matter

How to run the selection

Most POCT middleware selections go wrong before the first demonstration, because nobody wrote down what the organisation needs and who gets to decide. A selection that takes eight to twelve weeks and involves the right people is quicker in the end than a two-week choice that has to be re-run.

Stakeholders

The POCT coordinator or quality manager leads. Around them: a laboratory manager or clinic owner who signs off on governance; a nursing or clinical lead who represents the operators; IT or the clinical system supplier for interfaces, hosting and security; information governance for data protection; procurement and finance. In a private clinic this may be three people. In an NHS trust it is a working group, and the POCT committee should approve the outcome.

Requirements

Write them before you speak to any vendor. List every analyser you have and every one you expect to buy in the next five years, with model numbers and the protocol each uses. List every system a result needs to reach. List every site, including mobile units and community clinics. Then mark each requirement as mandatory, desirable or optional. The MHRA guidance Management and use of IVD point of care test devices is a useful checklist of what a POCT service is expected to have in place, and ISO 15189:2022 Annex A sets the requirements for POCT under an accredited laboratory. A written requirements list is what turns a demonstration into an evaluation.

Demonstrate on your own analysers

Insist that the vendor connects to at least two of your own devices, in your building or over a secure link, and shows a result travelling from the device to your test system. A demonstration on the vendor's laptop with the vendor's devices proves that their software works with their devices. Ask for the QC lockout, the operator lockout and the store-and-forward behaviour to be shown, not described.

Reference checks

Speak to two customers of a similar size and setting, without the vendor on the call. Ask how long implementation took against the plan, what the vendor did when a device driver did not exist, and what the last support ticket was about. Then ask what they would specify differently if they were buying again.

The twelve capabilities that matter

These are the capabilities that separate middleware that works on the ward from middleware that works in the demonstration. Test each one on your own equipment.

1. Device coverage and protocol support. The vendor should support your current analysers by name and speak the four protocols you will meet: HL7 v2, POCT1-A2 (the CLSI connectivity standard for POCT devices, catalogued as POCT01), ASTM E1394 with E1381, and FHIR (Fast Healthcare Interoperability Resources). Ask what happens for a device with no driver: a written timeline and a price, or a shrug.
2. Bidirectional worklists. The middleware should send patient and order details down to the device, so the operator selects a patient rather than typing an identifier, and receive the result back matched to that order. One-way result capture is not connectivity; it is a download.
3. Store-and-forward resilience. When the network drops, results should queue on site and forward when the link returns, with no loss and no duplicates. Ask how long the queue can hold and how you would know it is backing up.
4. Patient identity handling. Results must attach to the right patient using a scanned identifier, a worklist or a lookup against your patient index, with a defined path for unmatched results. Nothing should reach the record on a typed name alone.
5. Operator lockout. A central operator list, pushed to every device, with expiry dates. When competency lapses the device refuses the operator. Ask how long it takes between removing an operator centrally and the device enforcing it.
6. QC with Westgard rules and lockout. QC results captured as they run, Levey-Jennings charts by device and lot, configurable Westgard multi-rules, and a device lockout on failure that a supervisor releases with a recorded reason. QC software for POCT shows what the full set looks like.
7. External quality assessment (EQA). Scheme enrolment by device, deadlines, submission records and a place to record the investigation when a return is out of consensus.
8. Competency records. Training, assessment and reassessment dates against each operator, linked to the lockout, with reminders before expiry.
9. Audit trail. Every result, QC run, configuration change and operator change recorded with who, what and when, in a form that cannot be edited afterwards and can be exported for an assessor.
10. Multi-site administration. One console for every site, with policies set once and applied everywhere, and permissions that let a site lead see their own devices without seeing everyone else's.
11. LIS and EPR delivery. Results delivered over HL7 v2 or FHIR to your laboratory information system (LIS), or directly into the clinical record where there is no LIS, with units, ranges, flags and the operator carried through. Ask which of your systems the vendor has connected to before and what they needed from the other side.
12. Reporting and dashboards. Workload by site and device, QC compliance, operator status, results not sent, turnaround, and an export to a spreadsheet for the POCT committee report.

Questions to ask each vendor, and the answer you want

Red flags

• The demonstration only uses the vendor's own devices.
• Connectivity is described as a download or a sync rather than a live interface.
• Operator lockout is a report of who is out of date, not an enforced block on the device.
• QC data lives in the device and is uploaded when someone remembers.
• Every new analyser is a paid development project, even one that speaks a standard protocol.
• Pricing is per test, and the vendor cannot say what a busy year would cost.
• The audit trail can be edited by an administrator.
• The vendor will not give references unless they are on the call.
• Data export on exit is not in the contract.
• The security answer is a logo rather than a certificate number and a date.

None of these is disqualifying on its own; two or three together are.

An evaluation scoring table

Weight the criteria before scoring, score each vendor from 0 to 5 against the evidence you saw, and multiply. Adjust the weights to your setting; the ones below suit a multi-site organisation with an LIS.

The weights total 100, so the maximum score is 500. A vendor scoring 0 on any mandatory criterion is excluded regardless of total. A printable version of this table, with the twelve capabilities as a checklist, is in the downloads library.

Implementation and change management

Middleware is not installed, it is adopted. Plan the change with the people who will run the devices.

1. Phase by device type, not by site. Connect the glucose meters everywhere first, then blood gas, then the rest. Each device type teaches the team something the next one needs.
2. Clean the operator list before go-live. The first lockout that hits a senior nurse who was never on the training record is the moment the project gets a reputation. Reconcile the training records first.
3. Agree the QC policy in writing. Which Westgard rules, which control levels, how often, who releases a lockout and how quickly. The software applies the policy; it does not write it.
4. Test the interface end to end with real identifiers. A result from a device on a ward, read in the LIS or clinical system by a clinician, with the right units and the right flag, before any device goes live.
5. Train the trainers. Ward champions who can explain a lockout and know who releases it save more support calls than any manual.
6. Measure before and after. Results not reaching the record, QC compliance, operator currency and time spent on manual entry. The before figure is the business case; the after figure is the POCT committee report.

Timescales vary with the number of interfaces, not the number of devices. A practice with two analysers and one clinical system can be live in weeks; a trust with an LIS, an EPR and eight device types should plan in months. See Implementation for a typical sequence.

Commercial models and what they mean for your budget

Three models are common, and the right one depends on how your testing volume and site count will change.

• Per device. An annual fee for every connected analyser. Predictable, but it penalises the organisation that connects everything, which is exactly what governance requires. Watch for a separate fee per device type as well as per unit.
• Per test. A charge on every result that passes through. Cheap for a low-volume site, unpredictable for a busy one, and it gives the organisation a reason not to connect high-volume devices such as glucose meters.
• Per site subscription. A flat annual fee per location, with unlimited devices and tests, sometimes with optional modules. Predictable, and it rewards connecting everything. Catenix charges per site with no per-test fees; other vendors' models and prices change, so confirm current terms with each.

Whatever the model, ask for a three-year total that includes implementation, interfaces on both sides, training, support, hosting, new device drivers and the exit export. Then compare that number, not the headline subscription. How pricing works explains what is usually inside and outside a subscription.

Where software helps

The twelve capabilities above are the specification. Catenix covers them as one platform: device connectivity over HL7 v2, POCT1-A2, ASTM E1394, FHIR and REST with an on-site edge gateway that stores and forwards, bidirectional worklists, operator lockout tied to competency records, QC with Westgard rules and lockouts, an EQA module, a tamper-evident audit trail, multi-site administration and results delivered over open standards to an LIS, an EPR or a practice system. What is POCT middleware? explains the category in plain English, and POCT middleware alternatives sets out what each of the main products is designed for so you can build a shortlist. Details of every product change; confirm them with each vendor.

Questions people ask

What is POCT middleware and do we need it?

POCT middleware is software that connects point-of-care analysers, controls which operators can use them, captures quality control and sends results into the laboratory information system or clinical record. If you have more than a handful of devices, more than one site, or an accreditation assessor asking for an audit trail, you need it. With two meters in one room, a manual process may still be defensible.

How long does it take to implement POCT middleware?

It depends on interfaces, not device count. A practice or clinic with two analysers and one clinical system can be live in a few weeks. A hospital with an LIS, an EPR and several device types should plan in months, because each interface needs the other supplier's time and a test cycle. Ask the vendor for a plan with your systems named.

How much does POCT middleware cost?

Vendors price per device, per test or per site, with implementation, interfaces and support on top. The only useful comparison is a three-year total that includes every interface on both sides, training, hosting, new device drivers and the exit export. Ask each vendor for that number with their assumptions written down, and check the assumptions against your own volumes.

Should we buy middleware from our analyser manufacturer?

Manufacturer middleware supports that manufacturer's devices well; how well it supports other manufacturers' devices varies by product and by device, so compare the functions available for each exact device and firmware rather than assuming. If your fleet is, and will stay, one brand, it can be a good fit. If you have or expect a mixed fleet, independent middleware that speaks the standard protocols leaves you free to buy the best analyser for each test. Check the supported device list against your five-year plan.

Can POCT middleware work without a LIS?

Yes. In a GP practice, private clinic or occupational health service there is no laboratory information system, and middleware delivers results straight into the clinical system over HL7 v2 or FHIR. The middleware must then carry reference ranges, flags and a review step itself. Confirm that the vendor has done this with your specific clinical system, and ask to see it.

What should we ask a POCT middleware vendor's references?

Ask how long implementation took against the plan, what happened when a device had no driver, how the vendor handled the last outage, what the last support ticket was and how quickly it was closed, and what they would specify differently if buying again. Speak to the reference without the vendor present, and choose a site of similar size and setting to your own.

Sources and further reading

• ISO 15189:2022 Medical laboratories: requirements for quality and competence
• MHRA, Management and use of IVD point of care test devices
• CLSI POCT01, Point-of-Care Connectivity (the POCT1-A2 standard)
• National Cyber Security Centre, Cyber Essentials
• NHS Data Security and Protection Toolkit