Home / Resources / HL7 v2 for POCT: a plain-English field guide
HL7 v2 for POCT: a plain-English field guide
If your clinic runs point-of-care analysers, you have probably watched staff read a number off a device and type it into your clinical system by hand. It works, until someone mistypes a value or a busy morning means results pile up. Somewhere in the conversation about fixing this you will have heard the phrase "HL7", usually presented as if everyone already knows what it means.
This guide explains HL7 version 2, the messaging standard most point-of-care devices use to send results, in plain language. It covers what a result message carries, how it travels between systems, why connecting real devices takes more than reading the specification, and what Catenix does to make results arrive clean and consistent.
Quick answer
HL7 v2 is the common language healthcare systems use to send results to each other. A result message bundles who the patient is, what was requested and the observations found, and it usually travels as a framed stream over the local network. The standard is stable, but device makers use it in their own dialects, so connecting real analysers takes normalisation work rather than just reading the spec. Catenix normalises those dialects with an on-site gateway and a cloud workspace, keeps quality control data separate from patient results, and forwards clean results to the LIS or EHR you already run.
| Aspect | General picture |
|---|---|
| Interface family | HL7 v2 is common for results; some devices instead use POCT1-A2, ASTM, or newer FHIR interfaces |
| Transport | Usually a framed message stream over the local network; some benchtop analysers use a serial connection |
| Direction | Most point-of-care links send results in; some support bidirectional order and result exchange |
| Quality control data | QC readings are captured and reviewed separately in Catenix, not merged into a patient's record |
What HL7 v2 actually is
HL7 v2 is a messaging standard that healthcare systems use to send structured information to each other, results being one of the most common uses. Think of it as a shared grammar: when an analyser or a connectivity layer produces a result, it packages that result into a message built from a predictable set of building blocks, and the receiving system knows how to unpack it.
It has been in wide use for decades, which is why so many analysers, laboratory information systems (LIS) and electronic health records (EHRs) can speak some version of it. For a small clinic, the practical point is simple: HL7 v2 is usually the route by which a result leaves a device and reaches the system where staff actually read it, without anyone retyping numbers.
What a result message carries
At a conceptual level, a result message answers three questions. Who is this about, meaning the patient identity and enough context to file the result against the right person. What was asked for, meaning the test or panel that was requested. And what was found, meaning the observations themselves, each with its value, its units, and a flag when it falls outside the expected range.
The message is organised into ordered sections so a receiving system can find each piece reliably. You do not need to read the raw message to benefit from it: the value is that all of this travels together, in one structured package, rather than being copied by hand from a screen.
How the message travels
Most point-of-care links carry these messages over the ordinary local network as a continuous, framed stream. Framing simply means each message has an agreed marker for where it starts and where it ends, so the receiver can tell one message from the next on a shared connection.
Some older or benchtop analysers use a serial cable instead of the network. Either way, the transport is deliberately plain. The intelligence is in the message content and in how each side agrees to interpret it, which is where the real work of connecting begins.
Why real devices need more than the spec
Here is the part that surprises people. HL7 v2 is stable and well documented, yet reading the specification is not enough to connect a real device. The standard leaves room for choices, and over many years different manufacturers have made those choices differently.
One analyser may organise a piece of information differently from another, use a different code for the same test, or express a value in a slightly different way. None of this is wrong: it is simply that each maker has its own dialect. This is why connecting a device is an integration exercise rather than a copy-and-paste job, and why "it speaks HL7" does not by itself guarantee two systems will understand each other cleanly.
What Catenix does
Catenix sits between your analysers and the systems you already run. A small on-site gateway listens to each connected device, and the Catenix cloud workspace normalises the different dialects so results arrive clean and consistent no matter which maker produced them.
Two things matter for a POCT service. First, quality control data is kept separate from patient results, so a QC run is recorded and reviewed as QC and never lands in a patient's record. Second, once results are captured they can be forwarded to the LIS or EHR you already use, with the record of what arrived and when kept along the way. The outcome is that results flow without manual transcription, QC stays where it belongs, and you can see what happened and when. To discuss connecting a specific site, see our contact page. For how we handle security, see security.
Questions clinics ask
Can I connect a HL7 v2 device to my LIS?
In most cases yes. If a device offers an HL7 v2 result interface and your LIS or EHR can receive HL7 messages, the two can be linked. The work is in reconciling one system's dialect with the other so values arrive in the right place, which is what Catenix handles for you. See /contact/ to discuss a specific device.
Does 'it speaks HL7' mean two systems will just work together?
Not on its own. HL7 v2 leaves room for choices, and manufacturers make them differently, so two compliant systems can still interpret the same message in different ways. Connecting them reliably means reconciling those differences, not just confirming that both support HL7.
How is quality control data handled?
In Catenix, QC readings are captured and reviewed separately from patient results. A control run is recorded as QC and does not land in a patient's record, which keeps your patient data and your QC evidence cleanly apart.
What has to be installed on site?
A small on-site gateway connects to your analysers on the local network or by serial cable and passes results to the Catenix cloud workspace. Most sites need very little beyond a network point near the devices. See /contact/ for what a specific setup involves.
Can results be sent on to the system we already use?
Yes. Once results are captured and normalised, Catenix can forward them to the LIS or EHR you already run, with a record of what arrived and when kept along the way. This avoids manual retyping while leaving your existing systems in place.
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.