HL7 EAN messages let laboratory automation equipment push unsolicited notifications — status changes, alerts, errors, alarms — to the system that controls or monitors it. An EAN message is the equipment's way of saying something happened: a state transition, a warning, a severe fault, or a critical condition that the controlling application needs to know about right now. This page explains what an EAN message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an EAN notification relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What an EAN message represents
An EAN message — EAN stands for Automated Equipment Notification — communicates a notification raised by a piece of laboratory automation equipment to a system that is supervising, controlling, or monitoring it. The core of the message is the pairing of EQU and NDS: the EQU segment identifies the equipment and its current state, while the NDS segment carries the specific notification — what happened, when, how severe it is, and the notification code that names it.
EQU carries the equipment instance identifier in EQU-1, the event date and time in EQU-2, the equipment state in EQU-3, the local/remote control state in EQU-4, and the overall alert level in EQU-5 — a coded severity from the alert-level code system that ranges from normal through warning, severe, to critical. NDS names the specific notification: its reference number in NDS-1, the notification date and time in NDS-2, the notification alert level in NDS-3, and the notification code in NDS-4. The EAN message is unsolicited — the equipment raises it whenever its state changes or a condition arises that warrants a notification, rather than in response to a query — and the structure is built around the NOTIFICATION group, which repeats once per notification the equipment is reporting in this message.
When an EAN message is sent
An EAN message is sent by laboratory automation equipment whenever a condition arises that the controlling or monitoring system needs to be told about — a transition into a new operating state, a warning condition, a severe fault, a critical alarm, or an error that interrupts processing. It is a push, not a reply: the equipment originates the message on its own timing, not in response to a query. A single EAN can carry multiple notifications when several conditions arose together, with one repetition of the NOTIFICATION group per notification.
Trigger event
The EAN message type carries a single trigger event:
EAN^U09– Automated equipment notification.
Because EAN has one trigger event, the receiver's handling turns on the alert level in EQU and NDS and the notification code in NDS-4 — what happened and how severe it is — rather than on the trigger code in MSH-9.
Integration topology
The diagram shows the lab automation equipment raising a notification, the integration engine routing it, and the controlling or monitoring application receiving the alert.
{{diagram: lab automation equipment → EAN notification → integration engine → equipment control/monitoring system (LIS, automation manager, alerting dashboard)}}
Typical senders: laboratory automation equipment — analyzers, track systems, pre-analytical and post-analytical instruments, automated storage and retrieval modules.
Typical receivers: the equipment control or monitoring application — laboratory information system, automation manager, instrument middleware, or alerting dashboard subscribed to equipment events.
Direction: an unsolicited push from the equipment to the controlling system — the EAN travels outbound from the instrument whenever a condition the controller needs to know about arises.
Segments in an EAN message
The EAN_U09 message opens with MSH, optionally carries software-identification in SFT, names the equipment in EQU, then carries one or more NOTIFICATION groups built around the NDS notification detail segment, and closes with an optional ROL. 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 EAN message. It names the sending equipment and receiving application and facilities, stamps the creation time, declares the trigger event in MSH-9 (EAN^U09), 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 equipment — vendor, product, and version. Useful when notification behaviour differs across releases. Optional and repeating. |
EQU | Equipment Detail. Identifies the equipment and its current state at the moment the notification was raised. EQU-1 carries the equipment instance identifier, EQU-2 the event date and time, EQU-3 the equipment state, EQU-4 the local/remote control state, and EQU-5 the overall alert level — a coded value that names the severity of the equipment's current condition on a normal/warning/severe/critical scale, drawn from the alert-level code system. Required. |
NDS | Notification Detail. The core of the NOTIFICATION group — the specific notification the equipment is raising. NDS-1 carries the notification reference number, NDS-2 the notification date and time, NDS-3 the notification alert level (a coded value), and NDS-4 the notification code that names what happened. Required, and the notification group repeats once per notification the message carries. |
[{NTE}] | Notes and Comments. Free-text notes relative to the notification — operator-readable context, an originating subsystem, or a vendor-specific detail that does not fit in a coded notification code. Optional and repeating, closing each NOTIFICATION group. |
[ROL] | Role. Names the operator, system, or service role associated with the notification. Optional, at the end of the message. |
[ ] = optional, { } = repeating
The NOTIFICATION group from NDS onward repeats, so a single EAN message can carry every notification the equipment raised in a burst — for example a state transition into a fault state followed by the specific error codes that explain it. The canonical segment pages carry the full field-by-field detail.
Sample EAN message
Note. Constructed for illustration. Equipment identifiers, notification codes, dates, and names are fictional.
MSH|^~&|ANALYZER1|MERCYLAB|AUTOMGR|MERCYLAB|202006150930||EAN^U09^EAN_U09|MSG00091|P|2.5.1
EQU|ANALYZER1^Track-A^MercyLab|202006150930
NDS|1|202006150930||RX_CLOG^Reagent line clogged^L
NTE|1|L|Reagent line 3 occluded; intervention required at module A
What this sample shows
The EAN^U09 in MSH-9 marks an automated equipment notification. EQU identifies the equipment ANALYZER1 at facility MercyLab (EQU-1) and stamps the event at 202006150930 (EQU-2); the equipment-state, control-state, and alert-level fields (EQU-3 through EQU-5) take coded values from the equipment-state and alert-level code systems and are populated by the instrument according to its own table mappings. NDS carries the notification: reference number 1, the same timestamp in NDS-2, and the notification code RX_CLOG ("Reagent line clogged") in NDS-4. The NTE adds operator-readable context — which reagent line and which module require intervention.
Working with EAN messages
Read the equipment state and alert level from EQU first
EQU frames every notification in the message. The equipment state in EQU-3 and the local/remote control state in EQU-4 describe what the instrument is doing right now, and the alert level in EQU-5 sets the severity floor for everything that follows on a normal-through-critical scale. Read EQU before the NOTIFICATION group; a critical alert level on the equipment frames the individual NDS entries differently than a normal state report.
Route on the notification code in NDS-4
The notification code in NDS-4 is what names the condition — the clogged reagent line, the lost calibration, the door open, the temperature out of range. Route and prioritize on NDS-4, not on the free-text in any accompanying NTE. Per-notification alert level in NDS-3 can differ from the overall equipment level in EQU-5, so honour the notification's own severity when deciding what to escalate.
One EAN can carry multiple notifications
The NOTIFICATION group repeats, so a single EAN message can report several conditions raised together. Iterate the NDS entries rather than reading only the first — losing later notifications loses the conditions that explain the equipment state.
EAN is unsolicited — there is no query to correlate against
Unlike a query-response message, an EAN has no originating request. Correlate notifications by the equipment instance identifier in EQU-1 and the event time in EQU-2, and deduplicate on the message control id in MSH-10 rather than expecting an acknowledgement payload to tie back to.
Vendor variance. Notification codes in
NDS-4and the coded values inEQU-3,EQU-5, andNDS-3are largely vendor- and site-defined — instrument manufacturers publish their own code sets for the equipment states, alert levels, and notification conditions their devices report. Confirm a partner's code tables against their interface specification rather than assuming the base standard defines the values.
FHIR equivalent
An equipment notification has no first-class HL7 v2 message map in FHIR. Conceptually, the equipment state in EQU corresponds to the FHIR DeviceMetric resource (with Device identifying the instrument), and the specific notification in NDS corresponds to a Communication carrying the alert payload — with a MessageHeader at the head of a Bundle for the messaging envelope.
There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for EAN_U09, and no ConceptMap is published for the EQU or NDS segments — equipment-notification content sits outside the clinical scope the IG covers. A FHIR representation of an EAN message is therefore mapped manually, taking the equipment identity and state from EQU and the notification code, time, and severity from NDS.
Common pitfalls
Pitfall. Reading only the first
NDSand dropping the rest. The NOTIFICATION group repeats; later notifications in the same message often carry the specific codes that explain the equipment state inEQU.
Pitfall. Treating the alert level in
EQU-5as the per-notification severity. The notification has its own alert level inNDS-3; escalate on the notification's severity, not only on the equipment's overall level.
Pitfall. Assuming notification codes in
NDS-4are interoperable across vendors. They are not — each instrument manufacturer publishes its own code set. Map the vendor's codes to your internal alert taxonomy on ingest rather than passing them through unchanged.
How Vorro handles EAN messages
Vorro ingests each EAN notification from the originating equipment, reads the equipment state and overall alert level from EQU, iterates every NDS in the NOTIFICATION group, and routes each notification to every subscribed destination in the format that system expects — the laboratory information system, the automation manager, the alerting dashboard, the on-call paging path. Vorro keys routing and escalation on the notification code in NDS-4 and the notification alert level in NDS-3, deduplicates on MSH-10, correlates bursts on the equipment instance identifier in EQU-1, and, where a FHIR destination is configured, maps the equipment state to a DeviceMetric and the notification to a Communication — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.
Related messages
- EAC — the automated equipment command message, the controller's instruction sent to the same equipment that raises an EAN.
- EAR — the automated equipment response message, the equipment's reply to an EAC command.
- ESU — the automated equipment status update, the periodic state update that complements the event-driven EAN notification.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for EAN_U09
- HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for the EQU or NDS segments
- HL7 Messaging Standard Version 2.5.1 product brief
