Point-of-care results, into the systems UK clinics actually run.

A point-of-care result is only useful once it reaches the record the clinic works from. In a UK private clinic that record is rarely a hospital laboratory information system. It is an EHR or practice system: EMIS, SystmOne, Semble, Heydoc or similar. The question this guide answers is a practical one: how does a value measured on a handheld at the bench become a filed result against the right patient in the system your clinicians already open every morning.

The short answer is standards and a small amount of software at the bench. The longer answer, which is what most tools skip for the UK, is that primary-care systems here work differently from a US hospital LIS, and a connectivity layer has to meet them where they are.

The problem: the last few feet are still manual

In most clinics the weakest link is not the analyser and not the EHR. It is the gap between them. Someone reads a value off a device screen or a printed slip, walks it to a workstation, and keys it into the patient record. That step is quick to describe and expensive to run:

• Transposition. Hand-keyed numbers get digits swapped or decimal points misplaced. Illustrative published work on manual result entry (Mays and Mathias, 2019, JAMIA) reports transcription error rates of around 3.7 per cent. Treat that as illustrative and measure your own; the point is the error rate is not zero.
• Lost results. A printout goes missing, a device is cleared before the value is filed, and the result never reaches the record at all.
• Thin traceability. Once a value is retyped, the link back to which device produced it, which operator ran it, and when, is broken. At inspection that gap is exactly what an assessor asks about.
• Wasted clinician time. Re-keying and cross-checking is work that adds no clinical value and scales linearly with test volume.

Removing that manual step is the whole job. Everything below is about how to do it with the systems UK clinics run, rather than the hospital systems most connectivity products assume.

The promise: the result is captured once, and filed once

The goal is simple to state. A result leaves the analyser once, electronically, and arrives in the patient record as a structured value with the patient, the operator and the device attached. No screen-reading, no re-typing, no second-guessing which patient it belonged to. Catenix captures at the bench and forwards onward over the standards the receiving system accepts, so the same result that was measured is the result that is filed.

Why the UK is different: EHR, not LIS

In a hospital, near-patient results usually flow into a laboratory information system, and from there into the trust's wider record. Most UK private clinics have no LIS at all. They run an EHR or practice-management system, and that is the destination a point-of-care result needs to reach. The common targets look like this:

System names above are the target records a clinic might run. Catenix is designed to connect to them over HL7 v2 and FHIR feeds where the receiving system accepts a structured result. Exactly what flows, and to which system, is scoped with each clinic.

The practical consequence: if a clinic has no LIS, the platform has to carry the result all the way through, from the analyser to the EHR, and where there is no separate EHR, through to the clinic report itself. Our guide to POCT software for private clinics covers that end-to-end shape in more depth.

The standards that carry a result onward

Two standards do most of the work of moving a finished result from the bench software into a UK clinical system. You do not need to implement them yourself, but it helps to know which is which when you talk to your EHR provider.

• HL7 v2. The long-established messaging standard for exchanging orders and results between health systems. A result travels as an ORU message, usually framed over a network connection. Most UK record systems can accept an HL7 v2 result feed, which makes it the common path for filing a value against a patient.
• FHIR. The newer web-API standard, where a result is an Observation resource linked to a Patient resource and exchanged over ordinary web requests. Where a system exposes a FHIR R4 API, a result can be posted to it directly. Catenix provides a FHIR R4 API on its side and forwards over FHIR where the receiving system prefers it.

The full segment-by-segment detail lives in our field guides to HL7, POCT1-A2 and ASTM and the outbound feed to a LIS or EHR. For this guide the point is only that the onward journey is carried by open standards, not a proprietary lock-in.

How Catenix fits: capture at the bench, forward over standards

Catenix sits between your analysers and whatever record you run. It captures results at the point of care and forwards them onward, and it is designed to connect to the UK systems above rather than assuming a hospital LIS.

• Capture. A small edge gateway on a clinic PC listens to the analysers over HL7 v2, POCT1-A2 and ASTM, plus vendor-specific formats, and takes each result electronically at the moment of measurement. The how-to guide for connecting an analyser covers this inbound side.
• Match and govern. The result is attached to the right patient and the named operator, kept separate from quality-control runs, and recorded in a tamper-evident audit trail. Interpretation is not part of this step and stays with your clinicians.
• Forward. The finished, traceable result is delivered onward over HL7 v2 or FHIR to the receiving system, or carried through to a branded clinic report where there is no separate EHR to file into.

The wording matters here, so it is worth being precise. Catenix is designed to connect to and ready to connect to the systems named on this page. That describes connectivity built to open standards, not a claim that Catenix is integrated with or deployed at any particular product or organisation. What connects in your setting is confirmed during implementation.

What flows, in both directions

A useful connection is rarely one-way. Results go out, and identity and orders can come in, so the right result lands against the right patient without a person bridging the gap.

Two things Catenix deliberately does not do. It does not choose your record system for you: it is designed to connect to the one you already run. And it does not touch the clinical meaning of a result. Catenix does not interpret clinical results and provides no clinical decision support. It does not re-calculate values, re-classify results, derive estimated quantities, or auto-flag. Interpretation, validation and authorisation stay with your clinicians, exactly where accreditation expects them.

See the connectivity layer in detail, which analysers Catenix connects, or read the companion guide to what POCT middleware is. When you are ready to see it against your own systems, book a demo and bring your device list and the record you run.

← Back to resources

Product and company names mentioned are the trademarks of their respective owners. Reference to them is for identification only and does not imply any affiliation with, endorsement by, or certification from those owners. This page describes connectivity and data handling only and is not clinical advice.