Home / Resources / Sending POCT results into your LIS or EHR

Sending POCT results into your LIS or EHR

When a point-of-care analyser prints a result and someone keys it into the practice system by hand, two things happen: it takes time, and sooner or later a digit gets transposed. For a busy clinic running several devices, that manual transcription is a daily tax and a clinical-governance worry.

This guide explains how Catenix takes the results it captures from your analysers and forwards them onward, into a laboratory information system (LIS), an EHR, or a patient-held record, without anyone retyping a value. It also explains the part people ask about most: how quality-control runs are kept out of the patient record.

Quick answer

Catenix can push captured patient results to your LIS or EHR as an outbound HL7 message, and it can also expose them through a read-only FHIR interface for systems that prefer to pull. Every outbound message is tracked through queued, sent, retried and failed states, so nothing disappears silently. Quality-control runs are never sent to a clinical record: only patient results are forwarded.

AspectWhat Catenix does
Outbound interface familyHL7 v2 result messages and a read-only FHIR interface
TransportNetwork connection to your LIS, EHR or FHIR endpoint
DirectionResults out; can also receive orders and demographics in
Patient-held recordOptional push to an NHS patient-held record via Patients Know Best
Quality-control dataQC runs kept separate and never forwarded to a clinical record
Delivery trackingEach message tracked through queued, sent, retried and failed

How results leave Catenix

Once Catenix has captured a patient result from an analyser through the on-site gateway, it can forward that result to your laboratory information system or EHR as an outbound HL7 version 2 message. HL7 v2 is the long-standing messaging standard that most laboratory and clinical systems already understand for reporting results, so in many cases your existing system can receive Catenix messages without bespoke work at its end.

The push runs over a network connection to the endpoint you nominate. Rather than sending a message and hoping it arrived, Catenix places every outbound message on a delivery queue and records its state as it moves along: queued while it waits, sent once it has been delivered, retried when a delivery attempt did not succeed and the system is trying again, and failed if it could not be delivered after those attempts. That means a result never disappears silently. If an endpoint is down for a spell, the queue holds the message and keeps trying, and anything that ends up failed is visible rather than lost.

A read-only FHIR interface

Some systems prefer to pull data rather than receive a push. For those, Catenix offers a read-only FHIR interface. FHIR is a modern healthcare data standard that represents information as resources, and Catenix exposes three of them: patient, observation and diagnostic report. A connecting system can read the patient a result belongs to, the individual observations, and the report that groups them together.

Two points matter here. The interface is read-only, so a connecting system can retrieve results but cannot change anything inside Catenix through it. And the values are passed through exactly as captured: Catenix does not add any clinical interpretation, flags of its own, or commentary. What the analyser reported is what the interface returns.

Sharing results with patients through Patients Know Best

Catenix can also push a patient result into a patient-held NHS record through Patients Know Best, so a patient can see their own result in the record they already use. Because that record follows the patient across NHS services, Catenix is deliberately strict about identity: it will only send when a verified NHS number is present for that patient.

If the NHS number is missing or has not been verified, the push does not go ahead. This is a fail-closed rule: when the platform cannot be confident it is writing to the right person's record, it stops rather than guesses. That keeps a result from ever landing in the wrong patient-held record.

Quality control stays out of the clinical record

Clinics run quality-control samples through the same analysers they use for patients, to check that a device is performing as it should. Those QC runs are essential for governance, but they are not patient results and they must never appear in a patient record.

Catenix separates quality-control runs from patient results at the point of capture, and only patient results are forwarded onward. QC runs are held for review and trending inside the platform, and are never included in an outbound HL7 push, the FHIR interface, or a Patients Know Best push. So when your LIS or EHR receives data from Catenix, it receives patient results, not control material. You can read more about how the platform handles this on our platform page.

Receiving orders and getting connected

The flow does not have to be one-way. Catenix can also receive orders and patient demographics from an upstream system, so that a request placed in your ordering system, along with the patient details attached to it, can meet the result Catenix captures at the device. That cuts re-keying at the front of the process as well as the back.

To connect a site, Catenix needs to know which system is receiving, the network endpoint it listens on, and the message format it expects, along with the equivalent details for anything you want to send into Catenix. The on-site gateway handles the link to your analysers; the outbound configuration handles the link to your LIS, EHR or FHIR consumer. If you would like to scope a connection for your clinic, talk to us. For pricing see our pricing page, and for how we handle data security see security.

Questions clinics ask

Will connecting Catenix mean replacing our LIS or EHR?

No. Catenix forwards results to the system you already run. It sends an outbound HL7 v2 result message, which most laboratory and clinical systems already understand, and it can also present results through a read-only FHIR interface. The aim is to fit alongside your current setup, not replace it.

What happens if our LIS is offline when a result is ready?

The message waits on the delivery queue and Catenix keeps trying. Each message has a state you can see: queued, sent, retried or failed. Nothing is dropped silently, so if something does end up failed it is visible rather than lost.

Do quality-control results get sent to the patient record?

No. Catenix keeps quality-control runs separate from patient results and only forwards patient results. QC runs are held for review inside the platform and are never included in an outbound message, the FHIR interface, or a patient-held record push.

Can results go straight to the patient?

Optionally, through Patients Know Best, which is a patient-held NHS record. Catenix will only push when a verified NHS number is present for that patient, and it fails closed if that number is missing or unverified, so a result cannot land in the wrong person's record.

Does Catenix change or interpret the values it sends on?

No. Values are passed through as captured. The read-only FHIR interface exposes patient, observation and diagnostic-report resources with the reported values unchanged, and Catenix does not add any clinical interpretation of its own.

Can Catenix receive orders as well as send results?

Yes. As well as pushing results out, Catenix can receive orders and patient demographics from an upstream system, so a request and its patient details can meet the result captured at the device. That reduces re-keying at both ends.

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.

Reviewed July 2026. Back to integrations.