HL7 vs. ASTM E1394: When Each Protocol Applies in Clinical Labs

If you've spent any time evaluating lab middleware, you've seen both "HL7" and "ASTM E1394" listed under supported protocols — and wondered whether they're alternatives or complements. The answer matters because choosing middleware that misunderstands the difference will leave your lab either over-engineered or under-connected.

The short version: ASTM E1394 is an instrument protocol. HL7 is a system protocol. They operate at different layers of the clinical data stack, and most hospital labs need both — connected by a middleware layer that speaks both languages fluently.

ASTM E1394: The Instrument-Facing Protocol

ASTM E1394 was designed to solve a specific problem: how should a lab analyzer communicate its results to an adjacent system? It defines the message format, record structure, and link-layer handshake that governs communication between analyzers and the middleware or LIS that receives their output.

ASTM messages are compact and line-based. A typical result transmission consists of a Header record (H), one or more Patient records (P), Order records (O), Result records (R), and a Terminator (L). Each CBC from a Sysmex XN-550 might produce 20+ R records — one per analyte: WBC, RBC, HGB, HCT, MCV, MCH, MCHC, PLT, and all the differentials.

The protocol was designed for serial communication (RS-232) but has since been adapted for TCP/IP. Most analyzers manufactured in the last 30 years implement some version of it, which is why it remains the dominant language at the instrument layer despite its age.

Key characteristics of ASTM E1394:

• Instrument-to-middleware direction (though bidirectional is possible for orders)
• Compact, line-oriented message format
• ENQ/ACK/EOT handshake at the link layer
• Manufacturer-specific extensions are common — parsers need instrument-specific logic
• Works over RS-232 serial and TCP/IP

HL7: The System-Facing Protocol

HL7 (Health Level Seven) is a family of standards developed for healthcare information exchange at the system level. HL7 v2.x — the version still dominant in clinical settings — defines message formats for communication between Hospital Information Systems (HIS), Electronic Health Records (EHR), Laboratory Information Systems (LIS), billing systems, and other enterprise health IT.

Where ASTM moves result data from an analyzer to the system adjacent to it, HL7 moves that same data — once structured and validated — from a lab system to the broader hospital information infrastructure. An HL7 ORU (Observation Result) message carries structured lab results to the HIS. An ORM (Order) message carries orders from the HIS down to the LIS.

HL7 is fundamentally richer and more complex than ASTM E1394. It supports full patient demographics, multi-facility routing, insurance and billing information, clinical context, and codified terminology (LOINC codes for lab tests, SNOMED for clinical findings). That richness comes with complexity: HL7 v2.x messages are pipe-delimited and segment-based, with thousands of defined fields across dozens of message types.

Key characteristics of HL7 v2.x:

• System-to-system direction (LIS to HIS, HIS to EHR, etc.)
• Segment-based, pipe-delimited message format (MSH, PID, OBR, OBX…)
• Carries full patient, order, and result context
• Used for both result delivery (ORU) and order management (ORM/OML)
• Usually transmitted over TCP/IP via MLLP (Minimal Lower Layer Protocol)

The Typical Data Path in a Hospital Lab

Understanding where each protocol lives becomes clearest when you trace a result from instrument to clinician:

1. Analyzer → Middleware (ASTM E1394): The Mindray BC-430 finishes running a CBC. It transmits the results via ASTM E1394 over TCP/IP to the middleware running on the lab workstation.
2. Middleware parses and validates: The middleware receives the ASTM message, parses each R record, validates the values against reference ranges, checks for duplicates, and structures the result into an internal representation.
3. Middleware → HIS (HL7 ORU): The middleware constructs an HL7 ORU message from the structured result and transmits it to the Hospital Information System over MLLP/TCP.
4. HIS → EHR (HL7 or proprietary): The HIS may forward the result to the EHR, pharmacy system, or clinical decision support engine via its own HL7 interfaces.

The middleware is the translation layer between these two worlds. It speaks ASTM to the instruments and HL7 to the hospital systems. A middleware solution that only supports one of these protocols is incomplete for most hospital deployments.

When Labs Only Need ASTM (Standalone Reporting Mode)

Not every lab needs full HIS integration. A standalone diagnostic clinic, a smaller hospital with a basic LIS, or a reference lab running an independent reporting workflow may only need to receive ASTM results from their instruments and generate structured reports — without pushing HL7 to a larger system.

In this scenario, middleware that handles ASTM E1394 parsing, result validation, and local report generation covers the full workflow. HL7 integration is unnecessary overhead.

LISBridge supports this as a standalone operating mode. You connect your instruments, parse the ASTM output, and generate local reports or export to your own system — no HL7 configuration required. This is also how labs start before a larger HIS integration project is scoped and funded.

When Labs Need Both (Full HIS Integration)

Most hospital labs eventually need both protocols. The trigger is usually one of the following:

• The hospital is implementing a new HIS or EHR and needs lab results to appear automatically
• The lab is accrediting to a standard that requires electronic result delivery
• Clinical staff need real-time result visibility in the patient record — not just in the lab system
• The lab is consolidating multiple sites and needs centralized result routing

In these cases, the data flow requires ASTM parsing at the instrument layer and HL7 transmission at the system layer — with middleware in the middle doing both. LISBridge handles both ASTM E1394 and HL7 natively, acting as the bridge between your analyzers and your HIS without requiring a custom integration project.

Common Misunderstandings

HL7 is not an instrument protocol

This is the most common confusion in lab IT. Analyzers do not speak HL7 natively. When a vendor says their analyzer is "HL7 compatible," they typically mean the analyzer can communicate with middleware that then translates to HL7 — or that they provide a separate interface engine that handles the translation. The analyzer itself almost certainly still uses ASTM E1394 or a proprietary protocol at its physical output.

ASTM E1394 is not obsolete

Despite being decades old, ASTM E1394 is the current instrument protocol in the vast majority of clinical labs worldwide. The installed base is enormous. Labs replacing analyzers with newer models will find those new models still implement ASTM E1394. It will remain relevant for at least another decade.

You don't need a different middleware for each protocol

Some labs end up with a patchwork of tools — one system for ASTM parsing, another for HL7 transmission. This creates fragile integration points and doubles the failure surface. A single middleware that handles both is more reliable and easier to maintain. LISBridge provides unified ASTM and HL7 support in a single desktop application.

How LISBridge Handles Both

LISBridge is built around the architectural reality that most labs sit between the instrument layer (ASTM) and the hospital system layer (HL7). The application connects to instruments via RS-232 serial or TCP/IP, applies instrument-specific ASTM E1394 parsers, validates and structures the results, and then routes them — either to a local report, to a flat file export, or to an HL7 endpoint in the hospital's HIS.

The ASTM parsers are deployed as WebAssembly modules and update silently in the background. When a manufacturer changes their ASTM implementation in a firmware update, the parser adapts without disrupting lab operations. The HL7 output can be configured for HL7 v2.3 through v2.6, with field mappings adjustable to match your HIS's specific expectations.

The result is a middleware layer that genuinely bridges both protocols — not one that partially handles one and delegates the other to a separate tool.

FAQ

What does HL7 stand for and why "level seven"?

HL7 stands for Health Level Seven. The "seven" refers to the seventh layer of the OSI networking model — the application layer. HL7 operates at the application layer, meaning it defines message content and meaning, not the underlying transport mechanism. The transport (TCP/IP, MLLP) is handled separately.

Can I send HL7 directly from an analyzer to a HIS without middleware?

Technically possible in some modern analyzer configurations, but uncommon and usually impractical. Most analyzers implement ASTM at their output layer. Even when an analyzer claims direct HL7 output, the result usually requires an interface engine or middleware to handle acknowledgments, error correction, and mapping to the HIS's specific HL7 profile. Middleware remains the standard approach.

What's the difference between HL7 v2 and FHIR?

HL7 FHIR (Fast Healthcare Interoperability Resources) is a newer standard based on REST APIs and JSON/XML, designed for web and mobile integration. HL7 v2 is the older, pipe-delimited standard still dominant in hospital infrastructure. Most clinical labs currently use HL7 v2. FHIR adoption is growing but focused on patient-facing and interoperability use cases rather than lab instrument integration.

If my HIS only accepts HL7, do I still need ASTM support?

Yes. Unless your analyzers natively output HL7 (very rare), you need ASTM parsing to receive the instrument data, then HL7 translation to deliver it to your HIS. The two requirements are complementary, not interchangeable.

The Bottom Line

ASTM E1394 and HL7 are not competing standards. They're sequential layers in the clinical lab data path. ASTM carries results from instrument to middleware. HL7 carries structured results from middleware to hospital systems. Labs that need both need middleware that handles both — cleanly, reliably, without custom code for each new instrument or system integration.

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