POCT middleware vs LIS: what each does and which you need

What a LIS or LIMS does

A laboratory information system (LIS) is the system of record for a clinical laboratory. In the UK it is often called a LIMS (laboratory information management system). The two terms have different histories, LIMS having started in research and industrial laboratories that track samples rather than patients, but in healthcare they now describe the same product and this guide uses LIS for both.

An LIS is built around a specimen that travels to the laboratory. Everything it does follows from that.

• Orders. Requests arrive from the electronic patient record (EPR, called an electronic health record or EHR in the United States), from GP order communications or on paper, and the LIS turns them into a worklist with a unique request number.
• Specimens. Each sample is barcoded and tracked from collection through receipt, aliquoting, storage and disposal. Turnaround time is measured from these timestamps.
• Central laboratory analysers. The LIS, usually through its own instrument interface or a laboratory middleware layer supplied with the analysers, sends worklists to the chemistry, haematology and coagulation platforms and receives their results.
• Results. Results are checked against reference ranges, delta checks and critical limits, autovalidated where rules allow, authorised by a scientist and released.
• Reporting. The LIS sends the authorised report to the EPR, the GP system or the requester, keeps the cumulative record and produces turnaround, workload and performance figures for the laboratory's own management.

The LIS also holds the laboratory's test catalogue: thousands of tests, each with units, ranges by age and sex, reflex rules and billing codes. It is a large, stable system, typically replaced every ten to fifteen years, and every interface into it is a controlled change with a cost attached.

What POCT middleware does

POCT middleware exists because point-of-care analysers do not fit the specimen model. There is no barcoded tube in transit and often no order. A nurse takes a fingerprick, inserts the strip and reads a number within a minute. The organisation still needs that result in the record with the patient, the operator, the device, the reagent lot and the quality control (QC) status attached. Middleware is the layer that makes that happen.

• Device connectivity. Point-of-care analysers use a mix of protocols: POCT1-A2, the connectivity standard written for POCT devices and catalogued by CLSI as POCT01; ASTM E1394 with E1381, older serial protocols still common on benchtop analysers; HL7 v2; and, on newer devices, a manufacturer's own cloud interface. Middleware speaks all of them and turns the traffic into one stream. The differences are set out in HL7 vs POCT1-A2 vs ASTM.
• Operator control. Each device holds a list of certified operators. Middleware pushes that list to every device and removes a person when their competency lapses, so the device locks them out until they are reassessed.
• Quality control. QC results arrive from the device as they are run. Middleware plots them on Levey-Jennings charts, applies Westgard rules and can lock a device that has failed QC until a supervisor clears it.
• Results routing. Middleware matches the result to a patient, from the identifier scanned on the device, a worklist it sent down, or a lookup against the patient index, attaches the operator and device, and forwards it to the LIS or straight into the clinical record.
• Fleet management. Where every device is, its firmware, the lots in use, its last QC and its last successful download.

What middleware does not do is just as important. It does not manage specimens, does not hold a catalogue of thousands of assays, does not autovalidate laboratory results and does not produce the requester's cumulative report. Those remain LIS jobs. For a fuller plain-English account see What is POCT middleware?.

Where they overlap, and where they do not

The two systems overlap in three places, and each overlap needs a decision about which system is the source of truth for POCT.

Result delivery. Both systems can send an HL7 v2 result message (an ORU^R01) to the EPR. Pick one route for POCT results and switch the other off, or the record ends up with duplicates.

Result review. When middleware feeds an LIS, the LIS usually applies its own ranges and flags and the middleware only needs to pass the value, the units and the context. When middleware feeds a clinical record directly, the middleware must carry the ranges, the flags and the review step itself.

Reporting. Both can count POCT tests. The LIS counts what it received; the middleware counts what the devices ran, including QC, failed runs and results that were never sent. For governance, the middleware figure is the one to trust.

One source of confusion is the word middleware itself. Analyser manufacturers and LIS vendors also sell laboratory middleware: a layer between the LIS and high-throughput analysers that handles autovalidation, rerun rules and instrument management in one room. That is a different product from POCT middleware, which manages hundreds of small devices across many rooms, many sites and many operators. Both can exist in the same hospital.

The three common architectures

1. LIS only, with manual POCT entry

Devices are not connected. The result is read from the screen and typed into the LIS, the EPR or the paper notes; QC is written in a logbook; operator training is a spreadsheet. This is cheapest on day one and most expensive over time: every result carries a transcription risk, there is no lockout, and an assessor has to reconstruct the audit trail from paper. It survives in organisations with a handful of glucose meters and rarely anywhere else.

2. LIS plus middleware

Middleware connects the devices and sends each result to the LIS, which treats POCT as one more source, applies its own rules and reports it alongside laboratory results in the cumulative record. The LIS stays the system of record; the middleware is the system of control for devices, operators and QC. This is the standard acute hospital model and the one an assessor expects to see in a POCT service accredited to ISO 15189:2022, whose Annex A sets the additional requirements for point-of-care testing under the laboratory's responsibility. The MHRA guidance Management and use of IVD point of care test devices makes the same case for laboratory oversight, training records and quality control whatever the device. The interfaces are simple: one result feed from middleware to LIS, and either a demographics feed or a query from middleware to the patient index so the device can confirm who the patient is.

3. Middleware feeding the clinical record directly, no LIS

A GP practice, private clinic, occupational health provider or standalone diagnostic centre has no LIS to feed. The middleware becomes the POCT system of record and delivers results into EMIS Web, SystmOne, a private clinic system or an EPR over HL7 v2 or FHIR (Fast Healthcare Interoperability Resources, the newer HL7 standard built on web interfaces). Because there is no LIS behind it, the middleware must carry the governance the LIS would have supplied: reference ranges and units, abnormal and critical flags, a review step before release, and the report. POCT results into your LIS or EHR covers the message formats for each route.

A common hybrid: a private clinic sends venous samples to a reference laboratory and runs POCT on site. The reference laboratory's LIS reports its own results into the clinic system, the middleware reports the POCT results, and the clinic system holds both. The two feeds should agree on patient identifiers and units before go-live.

Which fits your setting: a decision table

The right architecture follows from three facts: whether a laboratory already owns the POCT service, whether an LIS already feeds the record, and how many sites and operators are involved.

Two settings deserve a note. An NHS trust that runs POCT in community clinics, virtual wards or a CDC should keep those devices on the same middleware as the hospital, so one operator list and one QC policy cover them all; see POCT for hospital and public health teams. And a GP practice whose POCT is provided by the local trust is often best served by the trust's middleware feeding the practice system directly, which spares the trust LIS from learning primary care coding.

Cost and ownership questions to settle before you sign

1. Who owns each interface? LIS vendors usually charge per interface and treat each new connection as a project. Middleware vendors charge per site, per device or per test. Before choosing architecture 2, get both quotes: the middleware subscription and the LIS vendor's price for the inbound POCT interface.
2. Who pays when a new analyser arrives? In an LIS-only world every new device type is an interface project. With middleware it should be a configuration change if the device driver already exists. Check the vendor's supported device list against your five-year plan, not just today's fleet.
3. Where does the audit trail live? If you must show an assessor who ran a test, on which device, with which lot and what the QC status was, the middleware is the primary record. Confirm you can export it in a readable format if you change vendor.
4. Who administers operators? The POCT coordinator, not the LIS team or IT. The middleware console should be usable by someone without a database background.
5. What happens when the network drops? Devices carry on testing. Ask whether the middleware has an on-site component that stores results and forwards them when the link returns, or whether results wait in the device until someone docks it.
6. Who is the data controller and processor? An on-premises LIS and a cloud middleware have different hosting, residency and contract terms. Under UK GDPR (the UK's version of the General Data Protection Regulation) the organisation is usually the controller for both and each vendor a processor; make sure the processing agreement names the hosting region.
7. What does exit look like? Results, QC data, operator records and audit logs should be exportable in an open format. Ask for the export before you sign, not at renewal.

For a trust, the honest total is LIS interface fees plus middleware subscription plus the coordinator's time. For a clinic or practice, it is the middleware subscription plus the clinical system supplier's charge, if any, for accepting an inbound feed.

Where software helps

Whichever architecture you land on, the middleware carries the same three jobs: talk to every device, control who uses it and how, and put the result where clinicians will read it. Catenix is POCT middleware built for architectures 2 and 3. It connects analysers over HL7 v2, POCT1-A2, ASTM E1394, FHIR and REST through an on-site edge gateway that stores and forwards if the network drops, feeds an LIS where one exists, and is designed and ready to connect over open standards to EMIS Web, SystmOne, Semble and any EPR that accepts HL7 v2 or FHIR where there is none. QC, operator competency, EQA and the audit trail sit in the same platform, administered across sites from one console, on a subscription per site with no per-test fees. The protocols and gateway options are described on Device connectivity, and the current analyser list is on Supported devices.

Questions people ask

Is POCT middleware the same as a LIS?

No. A laboratory information system manages orders, specimens, central laboratory analysers, result authorisation and reporting. POCT middleware manages point-of-care analysers outside the laboratory: connecting them, controlling which operators can use them, capturing quality control and routing results into the LIS or the clinical record. Many hospitals run both; a clinic or GP practice usually runs middleware alone.

Can a LIS connect directly to point-of-care analysers?

Some can, usually through a vendor-supplied interface for each device type. That works for one or two analyser models in a single building. It does not scale to a fleet of glucose meters and blood gas analysers across many wards, because the LIS has no operator lockout, no QC rules for POCT devices and no fleet view. That is the gap middleware fills.

Do we need a LIS if we only do point-of-care testing?

Usually not. A GP practice, private clinic or occupational health provider with no laboratory on site can run POCT middleware that delivers results straight into the clinical system over HL7 v2 or FHIR. The middleware then has to carry reference ranges, flags, a review step and the report, because there is no LIS behind it to do so.

What is the difference between a LIS and a LIMS?

In healthcare, nothing that matters to a buyer. LIMS started as a term for systems in research and industrial laboratories that track samples rather than patients; LIS described hospital systems. Today vendors use both names for the same clinical product. Check what the system does with orders, specimens, results and reporting rather than what it is called.

Can POCT middleware send results to EMIS Web or SystmOne without a LIS?

Yes, provided the middleware supports the message formats the practice system accepts and the results are coded so they appear in the patient's record and searches. Confirm with the middleware vendor and the practice system supplier which route is used, how patient matching works and who is responsible for the interface. Details change, so ask for a demonstration on your own analysers.

Who should own POCT middleware in an NHS trust?

The laboratory, through its POCT coordinator and POCT committee, with IT as a partner. ISO 15189:2022 places point-of-care testing under the laboratory's responsibility, and the middleware is where operators, QC and the audit trail are controlled. IT owns the network, the hosting and the interfaces to the LIS and EPR; the laboratory owns the configuration and the data.

Sources and further reading

• ISO 15189:2022 Medical laboratories: requirements for quality and competence (including Annex A, point-of-care testing)
• MHRA, Management and use of IVD point of care test devices
• CLSI POCT01, Point-of-Care Connectivity (the POCT1-A2 standard)
• HL7 Version 2 Messaging Standard (ORU, ORM and ADT message types)
• CLIA regulations, 42 CFR Part 493 (United States)