From ASTM to HL7: What It Takes to Connect Lab Devices to Modern Healthcare Systems

In many medical labs, analysers produce accurate results that still have to travel the last few metres by hand. The device speaks one protocol, the lab's information system expects another, and someone ends up re-typing values — or a legacy middleware box nobody wants to touch does the translation.

We built an IoT device that closes that gap: it connects to the lab analyser, captures results in ASTM, converts them to HL7 and delivers them to the lab's system automatically. Here's what that kind of project actually involves.

Two protocols, two eras

ASTM (today maintained as CLSI LIS1/LIS2) is the protocol many lab analysers have used for decades. It was designed for point-to-point communication between an instrument and a computer, often over a serial connection, with its own framing, checksums and record structure.

HL7 v2 is the messaging standard most hospital and laboratory information systems use to exchange clinical data. It organises information into segments — patient, order, observation — and expects messages in a specific structure, with acknowledgements confirming each one was received.

Both describe the same thing — a test result — but in very different ways. Connecting them is less about "converting a file" and more about translating between two systems with different assumptions.

How it works, in 4 steps

1. The analyser outputs results in ASTM. The device connects directly to the instrument and handles the protocol's handshake, framing and checksums.
2. Data is captured right at the source. Results are read as soon as the analyser sends them — no manual export, no intermediate files.
3. The device converts ASTM records into HL7 messages. Patient, sample and result fields are mapped into the segments the receiving system expects.
4. Results reach the lab's system automatically. No one re-types values, and every message can be traced from instrument to record.

What makes this harder than it looks

Every analyser has its own dialect

ASTM defines a structure, but manufacturers interpret it differently: which fields are used, how test codes are named, how results and units are formatted. A reliable integration needs mapping rules per instrument, not one generic parser.

Mapping is clinical, not just technical

A result is only useful if it lands on the right patient, the right sample and the right test code in the receiving system. Field mapping has to be agreed with the people who own the lab's data, and validated with real samples before going live.

The connection can't be allowed to lose data

Networks drop, systems restart, receiving servers go down for maintenance. A device sitting between an analyser and a medical record has to handle that without losing or duplicating results — which is why acknowledgements, retries and logging matter as much as the conversion itself.

Hardware brings its own constraints

Unlike a cloud service, an IoT device lives next to the instrument. It has to be stable for long periods, easy to configure on site and updatable without disrupting the lab's daily work.

What labs get out of it

• Fewer manual steps between the analyser and the patient record.
• Fewer transcription errors, because values are never re-typed.
• Faster availability of results for clinicians.
• A traceable data flow that's easier to audit and troubleshoot.

Lessons for medical device and healthcare teams

Projects like this succeed when the integration is treated as part of the product from day one, not an add-on at the end. Get sample output from the actual instruments early, involve the people who own the receiving system, and design for failure before designing for speed.

Working on a medical device, lab system or healthcare integration? Talk to our team — we've built this kind of bridge before and know where the hard parts are.