POCT middleware is the software layer that sits between point-of-care analysers and a clinic's record systems. It captures each result electronically the moment a device produces it, normalises the data into one consistent format, links it to the right patient and operator, applies the clinic's quality-control workflow, and forwards the finished record to a LIS, EHR or report.
You will also hear it called a POCT data-management system, a POC data manager, or simply POCT connectivity. The names overlap; the job is the same — make sure no result produced at the point of care is ever stranded on a device screen or a thermal printout.
From printout to platform: a short history
The category has grown in four steps, and each step still exists somewhere in the wild.
- The standalone device. Early point-of-care analysers displayed or printed a result and kept little else. Someone read it, wrote it down, and filed the slip — transcription was the interface.
- The vendor data manager. Manufacturers added docking stations and companion software so their own devices could upload results. Useful, but one silo per vendor — a clinic with three brands of analyser ran three disconnected systems.
- Vendor-neutral middleware. Around the turn of the millennium, the Connectivity Industry Consortium produced what became the POCT1-A standard, and a class of software emerged that could capture results from many vendors' devices into one place, with operator management and QC records attached. This is the layer hospitals call POCT middleware today.
- The clinic platform. The newest step extends middleware beyond device data into the whole visit — patient registration, encounter, result, report and invoice — for settings that have no hospital LIS behind them. That is the class Catenix belongs to.
What POCT middleware actually does
Strip away the vendor language and the work comes down to five verbs:
- Capture. Listen to every connected analyser and take each result electronically, at the moment of measurement, with no re-typing.
- Normalise. Different devices report the same analyte with different codes, units and flags. Middleware translates them into one consistent schema, so a glucose is a glucose regardless of which instrument produced it.
- Match. Attach the result to the right patient or encounter, and to the named operator who ran the test — identity travels with the value.
- Gate on QC. Apply the clinic's quality-control rules as a workflow step: control results are charted, evaluated statistically, and a device can be held until a failed control is resolved. This is statistical data-quality monitoring and process control — it is not interpretation of any patient result, which stays with the clinician and the analyser's instructions for use.
- Forward. Deliver the finished, traceable record to wherever it needs to live — a LIS, an EHR, or a clinic report.
The three standards you will meet
Almost every conversation about middleware lands on the same three wire standards. We cover them in depth in our guide to HL7, POCT-1A and ASTM; here is the short version.
| HL7 v2 | POCT1-A2 | ASTM E1394 | |
|---|---|---|---|
| Origin | Health Level Seven International, from the late 1980s | Connectivity Industry Consortium, published through CLSI (POCT1-A 2001, revised as POCT1-A2) | ASTM International, early 1990s; lineage continues as CLSI LIS standards |
| Transport | Usually MLLP framing over TCP/IP | XML message exchanges over TCP/IP between device and data manager | Originally serial RS-232 (with E1381 framing); also carried over TCP |
| Typical use | Orders and results between systems — analyser or middleware to LIS and EHR | Purpose-built point-of-care link: results, operator lists and QC between device and middleware | Bench-top analyser result transfer to LIS or middleware, especially on older instruments |
A practical middleware platform speaks all three — plus the vendor-specific formats that never made it into any standard. See which analysers Catenix connects and how the connectivity layer handles them.
An honest map of the market
POCT middleware is an established category with capable, mature products. In hospital networks you will most often meet TELCOR QML, Abbott RALS, Siemens POCcelerator and UniPOC, and Roche's cobas infinity POC within the navify portfolio. These systems are built for hospital scale — hundreds of devices, thousands of certified operators, and deep integration with a hospital LIS and admission feeds — and for that setting they are the natural candidates. Catenix sits in a different part of the map: it is built for private clinics, occupational health and other near-patient settings internationally, where there is usually no hospital LIS to lean on and the platform has to carry the whole workflow itself. If you are weighing the two classes, our hospital-vs-clinic comparison guide walks through the differences dimension by dimension.
A buyer's checklist
Whatever class of system you evaluate, the same eight questions separate brochures from working software:
- Real protocol coverage. Does it connect to the analysers you actually run — demonstrated, not just listed?
- Patient and operator matching. How does a result attach to the right encounter and the named operator, and what happens when it cannot?
- QC workflow. Are control charts, rule evaluation, lockout and review records built in, or exported to a spreadsheet?
- Traceability. Can every stored result be traced to who ran it, on which device, when — and is the original device message retained?
- Multi-site and tenancy. If you run several locations, how is each site's data scoped and overseen?
- Data residency. Where is the data hosted, and can the vendor offer hosting in your region?
- Pricing model. Is it priced per test, per device or per site — and what does that mean as your volumes grow? (Catenix is a subscription per clinic or site, with no per-test fees.)
- Drivers and implementation. Who builds and maintains device interfaces, and is that included? With Catenix, drivers for supported analysers are part of the platform and implementation is scoped with the quote.
Questions, answered
The questions buyers ask first.
What is POCT middleware?
POCT middleware is software that connects point-of-care analysers to a clinic's record systems. It captures results electronically, normalises them, matches them to the right patient and operator, applies the clinic's quality-control workflow, and forwards the finished record to a LIS, EHR or report.
Do small clinics need POCT middleware?
If a clinic runs more than a handful of point-of-care tests a week, manual transcription becomes the weakest link: results are re-typed, printouts go missing, and there is no audit trail. Middleware removes that step and keeps a traceable record of who ran what, on which device, and when.
What is the difference between middleware and a LIS?
A LIS is the laboratory's system of record for orders and results. Middleware is the device layer beneath it: it speaks to analysers, normalises their output and feeds clean, traceable data to the LIS or EHR. In a clinic that runs no LIS at all, a clinic-grade platform can carry the result through to the report itself.
How does POCT middleware connect to analysers?
Through the device's own interface — serial, network or docking station — using protocols such as HL7 v2, POCT1-A and ASTM E1394, plus vendor-specific formats. Typically a small gateway on the clinic network listens to the devices and forwards results securely to the platform.
See Catenix on your bench.
Bring your analyser list — we'll show results landing in the record, live.