When Your Analyzer Speaks Neither HL7 Nor ASTM

Every analyzer datasheet says the same thing: "supports HL7" or "supports ASTM". Then the engineer arrives, connects the cable, and finds output that matches neither standard cleanly. The standards story that vendors tell and the lab floor that labs actually have are two different things.

This post sorts what arrives from analyzers into three groups, shows a real example of each, and ends with the questions that actually tell you whether a middleware product will handle your instrument.

The Three Things That Actually Arrive

When you capture the output of a real analyzer, it falls into one of three categories:

1. Standard messages. Clean HL7 or ASTM E1394. These parse the way the specification says.
2. Standard messages with vendor quirks. Recognisably HL7 or ASTM, but with an omitted field, an extra control byte, or a framing layer the standard does not describe.
3. Records that are not messages at all. No delimiters, no segments, sometimes no network transport. Just data in a format the vendor invented.

The first category is what "we support HL7 and ASTM" actually covers. The second and third are where integration projects stall.

Case 1: Fixed-Width and Delimiter-Less

The Tosoh HLC-723GX, an HbA1c analyzer, is a clean example. Its host-connection output is a fixed-width ASCII record. There are no pipes, no carets, no record-type letters. Fields are defined by byte position and nothing else, so a parser that works by splitting on separators has nothing to split.

The record also travels inside a vendor handshake: start-of-text, the record, end-of-text, and a block check character. That check character is computed as an XOR, and an XOR of printable bytes can itself land on a printable or control value. A "cleaning" step that strips non-printable characters from the stream, a common habit, can quietly delete the checksum byte and make every record fail validation, or worse, make bad records pass.

Handling this takes a parser written for the exact record layout, not a generic one. We cover the instrument in detail in the Tosoh HLC-723GX instrument page and the integration walkthrough.

Case 2: Vendor Framing on Top of a Standard

The HTSH-2000 biochemistry analyzer does speak HL7 v2.3.1, so on paper it belongs in the first category. In practice it has two habits that make it belong in the second.

• Extra framing. A transmission can carry an extra end-of-transmission byte after the HL7 block, and the analyzer opens with an ENQ and expects a genuine ACK byte before it sends anything at all.
• An omitted OBX Set ID. The first field after the OBX segment name is missing, so every later field shifts one position to the left. Nothing errors. The values are simply in the wrong places.

A parser built strictly from the HL7 specification reads these messages without complaint and returns wrong data. That is the dangerous failure mode: not a crash, but a plausible-looking result in the wrong field. Our HTSH-2000 integration post shows how this one is handled.

Case 3: No Transport at All

The bioMérieux VIDAS KUBE does not send a stream over a cable or a socket. Results and orders are exchanged as XML documents deposited on a file server, through the BCI Connect software, over FTP, FTPS or SFTP.

There is no connection to hold open and no handshake to answer. A middleware product built around serial ports and TCP listeners has nothing to listen to. LISBridge treats file transport as a third connection tier next to RS-232 and TCP/IP, pulling aiMessage XML for results and writing lisMessage XML for orders.

Why "We Support HL7 and ASTM" Is Not an Answer

All three of these analyzers are used in ordinary clinical labs. None of them can be integrated by a product whose entire capability is "HL7 and ASTM". A vendor can truthfully say that sentence and still be unable to read your instrument.

The sentence also hides a second problem. Support for a standard says nothing about direction. Some of these analyzers accept orders, and some only send results. We list which of the supported instruments are bidirectional, and 17 of 37 are. That is information a generic standards claim never gives you.

What to Ask a Middleware Vendor About Your Specific Analyzer

• Do you have a parser for my exact model? Not "my protocol". My model, by name.
• What happens if my analyzer omits a field or adds a framing byte? Ask for a concrete answer, not a reassurance.
• Which transports do you handle? Serial, TCP, and file server are three different problems.
• Can I see the raw data next to the parsed result? If the vendor cannot show you what the analyzer actually sent, you cannot audit what they did with it.
• Can I try it on my instrument before I pay? A trial on your own analyzer settles most of the above in an afternoon.

If your analyzer is on our list of 37, the answer to most of these is yes by name. You can check the instrument directory and the data parsing overview. How the pieces fit together is on the how it works page.

What This Means for Planning an Integration

The practical lesson is to treat the analyzer, not the protocol name, as the unit of planning. When a project plan says "integrate the chemistry analyzer over HL7", it hides a set of unknowns: which version, what framing, whether a field is missing, which direction data flows, and what happens on a retry. Each of these is cheap to find out before a project starts and expensive to find out after go-live.

A reasonable approach is to capture a few real messages from the analyzer early, even before the middleware is chosen. Seeing the actual bytes settles more arguments than reading the datasheet. If you can, capture one patient result, one control, and one result with an abnormal flag. Compare what you see with what the vendor documented. Differences are normal; surprises are what you want to find early.

Why This Is a Parser Problem, Not a Configuration Problem

It is tempting to believe these gaps can be closed with settings: a delimiter here, a field offset there. For the standard-with-quirks category that is sometimes true. For the fixed-width and file-based categories it is not, because there is nothing generic to configure. The parser has to be written for the instrument. That is why LISBridge ships parsers per model and updates them silently in the background through WebAssembly, with no restart and no IT call, so a fix for one analyzer reaches every installation without downtime.

Frequently Asked Questions

Is an analyzer that does not use HL7 or ASTM unusual?

No. Fixed-width records, vendor-specific framing, and file-based exchange are all in use on current analyzers.

Can a generic HL7 interface read a vendor-quirk analyzer?

Sometimes, but it may read the fields in the wrong positions without raising an error, which is worse than failing outright.

Does LISBridge store the raw analyzer data?

Yes. Raw protocol data is stored with each parsed result, so you can compare the two.

Which connection types does LISBridge support?

RS-232 serial, TCP/IP, and FTP/FTPS/SFTP file transport.

How do I know whether my analyzer is supported?

Check the instrument list for the exact model. LISBridge supports 37 analyzers out of the box.

Start your free trial — no credit card required. lisbridge.com/pricing