HL7 LSU messages carry log entries and service-event updates from laboratory automation equipment back to the controlling or service-management system — the maintenance just performed on an analyzer, the error the track-control system just logged, the calibration a robot just completed. An LSU message is the bookkeeping half of an equipment exchange: a piece of equipment (typically an analyzer, track, or automation cell) sends one LSU to the controller or service manager with its operational state in EQU and one or more log or service entries in EQP, and the receiver files them. This page explains what an LSU message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an LSU update relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What an LSU message represents
An LSU message — LSU stands for Automated Equipment Log/Service Update — communicates a log entry, or a batch of log and service entries, from a piece of laboratory automation equipment to a controlling or service-management system. The core of the message is the pairing of EQU, which identifies the equipment instance and reports its current operational state, with one or more EQP segments, each of which carries a log entry or a service event — the event type (log vs service), the file name and release identifier where the entry lives, any corrective action taken, the final test result, who logged it, and the device's status at the time.
LSU is an unsolicited reporting message: the equipment issues it on its own initiative — when a technician finishes a maintenance procedure, when a self-test produces a result worth recording, when an internal log accumulates entries worth pushing upstream. The EQU segment pins the update to a specific equipment instance (EQU-1) at a specific moment (EQU-2) in a known operational state (EQU-3), with an alert level in EQU-5. The sender is the equipment or its instrument-side gateway; the receiver is the laboratory automation manager, the service-management system, or a maintenance log store. Because the message reports rather than commands, the event-type code in EQP-1 and the device status in EQP-7 are the fields that drive downstream handling, while the surrounding fields carry the diagnostic and provenance detail.
When an LSU message is sent
An LSU message is sent whenever the equipment has a log entry or a service event to report — a maintenance procedure performed, an error captured in an internal log, a calibration completed, a self-test result recorded, a software or firmware file updated. It is event-driven and unsolicited: the equipment does not wait to be polled. LSU lives alongside EAC (command), EAN (notification), and ESU (status update) in the Chapter 13 laboratory automation message set.
Trigger event
The LSU message type carries a single trigger event:
LSU^U12– Automated equipment log/service update.
Because LSU has one trigger event, the receiver's handling turns on the event-type code in EQP — LOG for a log entry or SER for a service event — and the device status in EQP-7, rather than on the trigger code in MSH-9.
Integration topology
The diagram shows the connected instrument pushing an LSU log/service update through the integration engine to the laboratory automation manager and on to the service-management system.
{{diagram: instrument / equipment gateway → LSU log/service update → integration engine → laboratory automation manager → service-management / maintenance log store}}
Typical senders: the reporting instrument, an instrument-side gateway, or a track-control system on the automation line.
Typical receivers: laboratory automation manager, laboratory middleware, service-management or maintenance log system, LIS automation module.
Direction: the reporting leg of an equipment exchange — the LSU travels from the equipment to the controller or service manager and is typically acknowledged with a general HL7 ACK rather than a paired response message.
Segments in an LSU message
The LSU_U12 message opens with MSH, followed by the equipment detail in EQU, and then carries one or more LOG groups. Each log group consists of an EQP segment carrying a log entry or service event. Cardinality follows HL7 notation: [X] optional, {X} repeating, [{X}] optional and repeating; a bare code is required. Each segment code links to its canonical field-by-field reference.
| Segment | Description |
|---|---|
MSH | Message Header. Opens every LSU message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (LSU^U12), carries the message control id in MSH-10, and pins the HL7 version. Receivers route on MSH-9 and deduplicate on MSH-10. |
EQU | Equipment Detail. Identifies the equipment instance reporting the log or service update and reports its state at the moment the entry is issued. EQU-1 carries the equipment instance identifier, EQU-2 the event date/time, EQU-3 the equipment state, and EQU-5 the alert level. Required, and the heart of the message together with EQP. |
{EQP} | Equipment/Log Service. Opens each log group and carries the log entry or service event itself. EQP-1 is the event type code — LOG for a log entry, SER for a service event. EQP-2 is the file name where the entry lives, EQP-3 the file release identifier, EQP-4 the corrective action taken, EQP-5 the final test result, EQP-6 the operator or system that logged the entry, and EQP-7 the device status at the time the entry was recorded. Required and repeating — each EQP segment is one log entry or service event, and the heart of the message. |
[ ] = optional, { } = repeating
The log group from EQP onward repeats, so a single LSU message can report several log entries or service events for the same equipment in one exchange. The canonical segment pages carry the full field-by-field detail.
Sample LSU message
Note. Constructed for illustration. Equipment identifiers, file identifiers, operator identifiers, and dates are fictional.
MSH|^~&|ANALYZER01|MERCYGEN|LAB_AUTO_MGR|MERCYGEN|202006150930||LSU^U12^LSU_U12|MSG00097|P|2.5.1
EQU|ANALYZER01^MERCYGEN^EI|202006150930|IT|N
EQP|SER|MAINT_LOG_2020|R3.2|REPLACED_PROBE_ASSEMBLY|PASS|TECH456^SMITH^JANE|OK
EQP|LOG|ERROR_LOG_2020|R3.2||CAL_DRIFT_WARNING|SYSTEM|OK
What this sample shows
The LSU^U12 in MSH-9 marks an automated equipment log/service update. EQU identifies the equipment instance ANALYZER01 at 202006150930, in equipment state IT (idle) in EQU-3, with no alert in EQU-5. The first EQP carries a service event (SER) recorded in MAINT_LOG_2020 release R3.2, where the corrective action REPLACED_PROBE_ASSEMBLY was taken with a final test result of PASS, logged by TECH456 (Jane Smith), with the device status reported as OK. The second EQP carries a log entry (LOG) in ERROR_LOG_2020 release R3.2, with no corrective action, a final test result of CAL_DRIFT_WARNING, logged by the system, with the device status still OK — together telling the service manager that a probe was replaced after a calibration-drift warning, and the instrument is back in service.
Working with LSU messages
Read the event-type code in EQP-1 before filing the entry
EQP-1 distinguishes a log entry (LOG) from a service event (SER). A service event typically updates a maintenance record and may trigger downstream workflows — warranty tracking, preventive-maintenance scheduling, technician notification — while a log entry is usually filed without further action. Read EQP-1 first and route each entry into the correct store rather than treating all EQP segments alike.
Reconcile EQP-7 device status against EQU-3 equipment state
EQP-7 reports the device status at the moment the entry was recorded; EQU-3 reports the equipment's operational state at the moment the message is issued. The two are recorded separately because logs can be backfilled and the device may have moved on since. When they disagree — an EQP-7 of DOWN against an EQU-3 of IT — file the entry against its recorded status and trust EQU-3 for the current state.
Preserve EQP-2 and EQP-3 for traceability
The file name in EQP-2 and the release identifier in EQP-3 together identify where the entry lives on the equipment — which log file, which firmware or configuration release. They are the link between the upstream record and the on-device source and matter for audit and root-cause work; carry them through to the maintenance log store rather than discarding them as opaque vendor strings.
Capture EQP-6 as the entry's provenance
EQP-6 names who logged the entry — a human technician, an operator, or the system itself. It is the entry's provenance and the field a service-management system will key on when attributing service events to a technician or when separating system-generated logs from human-recorded ones.
Vendor variance. The codes used in
EQP-1for event type,EQP-7for device status, and the contents ofEQP-4for corrective action are partly site- and vendor-defined. Some instruments emit a rich vocabulary of corrective-action codes; others emit free-text. Confirm a partner's field usage against their interface specification rather than assuming a uniform vocabulary across vendors.
FHIR equivalent
An automated equipment log/service update corresponds, conceptually, to a FHIR AuditEvent — or a Communication carrying the log payload — that references the reporting equipment as a Device resource, with a MessageHeader at the head of a Bundle when carried as a messaging exchange.
There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for LSU_U12, and laboratory automation log and service data sits outside FHIR's clinical resource scope — FHIR's strengths are clinical and administrative data rather than device-level operational logging. A FHIR representation produced from an LSU message is therefore composed manually, taking the equipment instance from EQU into a Device reference and the event type, file identifiers, corrective action, final test result, logger, and device status from EQP into the AuditEvent or Communication. In most production integrations the LSU stays on the v2 channel.
Common pitfalls
Pitfall. Treating every
EQPsegment as a log entry. ASERevent inEQP-1is a service event and typically needs to update a maintenance record, schedule follow-up, or notify a technician; filing it into a flat log store loses the workflow.
Pitfall. Discarding
EQP-2andEQP-3. The file name and release identifier are the link from the upstream record back to the on-device source; without them, audit and root-cause work has no anchor in the equipment's own log files.
Pitfall. Conflating
EQP-7device status withEQU-3equipment state. The two are recorded at different moments and can legitimately disagree, especially when entries are backfilled; collapsing them into a single field loses the historical record.
How Vorro handles LSU messages
Vorro routes each LSU log/service update from the reporting equipment to the laboratory automation manager and the service-management system, reads the event-type code in EQP to separate log entries from service events, files each entry against the equipment instance in EQU, preserves the file name and release identifier from EQP-2 and EQP-3 for traceability, keys provenance on EQP-6, reconciles EQP-7 device status against EQU-3 equipment state when they disagree, and, where a FHIR destination is configured, maps the update to an AuditEvent or Communication referencing the reporting Device — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.
Related messages
- EAC — the automated equipment command that the controller issues to the equipment, the action counterpart to an LSU report.
- EAN — the automated equipment notification that the equipment raises when it needs the controller's attention.
- ESU — the automated equipment status update that reports a change in equipment state independent of a log or service entry.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for LSU_U12
- HL7 v2-to-FHIR IG — segment maps index — confirms no published ConceptMap for the EQU or EQP segments
- HL7 Messaging Standard Version 2.5.1 product brief
