HL7 SSU messages carry a specimen status update from laboratory automation — the report that a specimen container has moved, been processed, or changed state on an analyzer or transport system. SSU belongs to the laboratory-automation (LAB) domain, alongside the equipment and inventory messages that keep an automated lab's instruments and consumables in sync, and it is the message that tracks the sample itself as it flows through that automation. This page explains what an SSU message represents, its trigger event and matching request, every segment the message can contain and what each one holds, and how a specimen status update relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
Naming note. This page is published under the slug
hl7/messages/bar-specimento match the site blueprint, butbar-specimenis not a real HL7 v2 message code. The message that actually carries specimen-container and sample-tracking status in the laboratory-automation domain is SSU (Specimen Status Update,SSU^U03), with its request counterpart SSR (SSR^U04). This page documents SSU accurately; the slug is retained only for blueprint consistency.
What an SSU message represents
An SSU message — SSU stands for Specimen Status Update — communicates the current status of one or more specimen containers on a piece of laboratory automation. The message is emitted by an analyzer, a pre- or post-analytical processing system, or a specimen-transport track to report where a container is and what state it is in. Its two core segments are the SAC Specimen Container Detail, which identifies the physical container and its position and status, and the SPM Specimen segment, which describes the specimen the container holds.
The message also carries an EQU Equipment Detail segment naming the instrument reporting the status, because in the automation domain a status update is always tied to a specific piece of equipment. The sender is the laboratory instrument or automation system, and the receiver is the laboratory automation system (LAS) or middleware that coordinates the track and its instruments. SSU is the sample-tracking counterpart to the equipment messages in the same domain: where those report on the instruments and their consumables, SSU reports on the specimens moving through them.
When an SSU message is sent
An SSU message is sent whenever a specimen container's status changes on the automation — when it arrives at an instrument, is aspirated or aliquoted, is moved to a new position, or completes processing. It can be sent unsolicited as the status changes, or in response to a request from the coordinating system.
Trigger event and its request
The SSU message and its request form a request/response pair, both verified in HL7 v2.5.1:
SSU^U03– Specimen status update, sent by the instrument or automation system to report container status.SSR^U04– Specimen status request, sent by the coordinating system to ask for the status of one or more containers.
The two messages share the same segment backbone — MSH, EQU, a repeating specimen-container group, and an optional ROL. The SSU update carries the specimen and observation detail; the SSR request carries the same structure to identify which containers the status is wanted for.
Integration topology
The diagram shows an instrument reporting specimen-container status through the integration engine to the laboratory automation system that coordinates the track.
{{diagram: analyzer / automation track → SSU status update → integration engine → laboratory automation system / middleware → LIS}}
Typical senders: analyzer, pre- or post-analytical processing system, specimen-transport track.
Typical receivers: laboratory automation system (LAS), automation middleware, and the laboratory information system it feeds.
Direction: primarily an unsolicited status notification from the instrument to the coordinating system; the SSR^U04 request travels the other way when status is polled.
Segments in an SSU message
The SSU_U03 message is compact and equipment-scoped: after the MSH header and an EQU equipment segment, it carries one or more SPECIMEN_CONTAINER groups, each opening with a SAC container-detail segment, and an optional ROL role. 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 SSU message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (SSU^U03), carries the message control id in MSH-10, and pins the HL7 version. Receivers route on MSH-9 and deduplicate on MSH-10. |
[{SFT}] | Software Segment. Identifies the software product behind the reporting instrument — vendor, product, and version. Optional and repeating; useful when status behaviour differs across instrument firmware releases. |
EQU | Equipment Detail. Identifies the equipment reporting the status — the equipment instance identifier, the event date and time, and the equipment state. Required; every status update is tied to the instrument that produced it. |
{SAC} | Specimen Container Detail. Opens each SPECIMEN_CONTAINER group and is the core of the message. It identifies the physical container — the container identifier, the carrier and tray or position on the automation, the container status, and the specimen source — so the coordinating system knows exactly which container this update concerns. Required, and the group repeats once per container reported. |
[{OBX}] | Observation/Result. Container- or specimen-level observations captured during processing, such as a volume, a level-sensing reading, or a clot-detection flag. Optional and repeating within the container group. |
[{SPM}] | Specimen. Describes the specimen the container holds — the specimen type, collection detail, and specimen identifiers — carried in an optional and repeating SPECIMEN subgroup, each SPM followed by its own optional OBX observations. |
[ROL] | Role. Names a person associated with the status update, such as the operator who loaded or handled the container. Optional. |
[ ] = optional, { } = repeating
The SPECIMEN_CONTAINER group from SAC onward repeats once per container, so a single SSU message can report the status of a whole rack of specimens at once. Within each container, the SPM specimen subgroup itself repeats, because one container can, in some workflows, hold more than one specimen. The canonical segment pages carry the full field-by-field detail.
Sample SSU message
Note. Constructed for illustration. Container identifiers, equipment ids, dates, and specimen ids are fictional.
MSH|^~&|CHEM_ANALYZER|MERCYLAB|LAS|MERCYLAB|202006031030||SSU^U03^SSU_U03|MSG00031|P|2.5.1
EQU|ANALYZER01^^MERCYLAB|202006031030||OK^Operational^HL70544
SAC|||CTR889900^MERCYLAB||||CARRIER07^POS12||I^Identified^HL70370
SPM|1|SPEC55501^MERCYLAB||BLD^Blood^HL70487|||||||P^Patient^HL70369
OBX|1|NM|VOL^Volume^L||3.5|mL||||F
What this sample shows
The SSU^U03 in MSH-9 marks a specimen status update sent from a chemistry analyzer to the laboratory automation system. The EQU names the reporting instrument ANALYZER01 and reports it operational. The SAC identifies container CTR889900 at carrier position CARRIER07^POS12 with a container status of "Identified". The SPM describes the specimen in that container — a patient blood specimen SPEC55501 — and the OBX reports a measured volume of 3.5 mL captured during processing.
Working with SSU messages
Key on the container, tie to the equipment
The container identifier and position in SAC are what a status update is about, and the equipment instance in EQU is what produced it. Track a specimen through the automation by the container identifier, and record the reporting instrument from EQU so the same container's updates from different instruments can be sequenced.
Idempotency and deduplication
Use MSH-10, the message control id, as the deduplication key, and treat the container identifier in SAC together with the event time in EQU as the natural business key for a status update. Automation feeds are high-volume and are replayed after a track stoppage, so deduplicating on the control id prevents a replayed status from advancing a container's state twice.
Sequence by event time, not arrival
A container passes through several instruments in a short window, and status updates can arrive out of order after a buffer flushes. Sequence a container's updates by the event date and time in EQU rather than by arrival order, so a later-arriving earlier status does not appear to move the container backward.
Distinguish the update from its request
SSU^U03 reports status; SSR^U04 asks for it. They share a structure, so dispatch on the trigger event in MSH-9 — treating an inbound request as an update, or vice versa, mishandles the exchange.
Vendor variance. Instruments differ in which
SACstatus values and position encodings they emit, in whether they include theSPMspecimen detail on every update or only on identification, and in how muchOBXprocessing detail they carry. Confirm a partner instrument's field usage against its interface specification rather than assuming the base standard.
FHIR equivalent
A specimen status update corresponds to the FHIR Specimen resource — the container and its status map onto Specimen.container and Specimen.status, the specimen type and collection onto the specimen body, and the reporting instrument onto a referenced Device. For a messaging exchange a MessageHeader sits at the head of a Bundle.
The mapping is partial rather than complete. The HL7 v2-to-FHIR Implementation Guide provides no message map for SSU_U03 and no ConceptMap for the SAC container segment, but it does publish a ConceptMap for the SPM segment to the Specimen resource. A FHIR Specimen produced from an SSU message is therefore composed from the segment maps — using the published SPM-to-Specimen ConceptMap for the specimen itself and mapping the SAC container and EQU equipment detail by hand.
Common pitfalls
Pitfall. Treating SSU as a result message. SSU carries the status of a container, not analytical results; the observations in
OBXhere are processing measurements such as volume or level, and patient results travel in an OUL or ORU message instead.
Pitfall. Ignoring the container position. The carrier and position in
SACare how the automation locates the physical tube; discarding them loses the sample-tracking value the message exists to provide.
Pitfall. Assuming a fixed date-time precision. Instruments stamp the
EQUevent time at differing precision and timezone handling; do not assume a timezone — normalize on ingest, especially since sequencing depends on it.
How Vorro handles SSU messages
Vorro ingests the SSU feed over MLLP or another transport, deduplicates on MSH-10, and routes each specimen status update to the laboratory automation system and any subscribed destination in the format that system expects. Vorro keys each update on the container identifier in SAC, ties it to the reporting instrument in EQU, sequences a container's updates by event time, and answers or forwards SSR^U04 status requests. Where a FHIR destination is configured, Vorro composes a Specimen resource from the segment maps — using the published SPM-to-Specimen ConceptMap and mapping the container and equipment detail by hand, since the Implementation Guide publishes no map for this message.
Related messages
- BPS — the blood-product dispense/status message in the same transfusion and lab-support family.
- BTS — the blood-product transfusion/disposition status message.
- EAC — the equipment command message in the same laboratory-automation domain.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for SSU_U03
- HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for SAC and a published ConceptMap for SPM
- HL7 Messaging Standard Version 2.5.1 product brief
- HAPI v2.5.1 SSU_U03 message structure
- HAPI v2.5.1 SSU_U03_SPECIMEN_CONTAINER group structure
- HAPI v2.5.1 SSR_U04 message structure
