HL7 ISD Segment: Interaction Status Detail

The ISD (Interaction Status Detail) segment describes the status of a single interaction between a piece of laboratory automation equipment and a partner system — for example, a sample-handling exchange between an analyzer and a track, or a communication link between an instrument and the automation manager. ISD complements EQU (device state) and EQP (service events) by reporting whether the interaction itself is active, held, or otherwise impaired.

In HL7 v2.5.1, ISD has three fields. It is repeatable inside ESU and ESR messages so that one EQU can be followed by several ISDs describing distinct interactions on the same device.

Purpose

Equipment in a lab automation environment rarely operates in isolation. A single analyzer may be simultaneously interacting with a sample track, an LIS, an automation manager, and a maintenance console. ISD lets each of those interactions be reported individually, so observers can see — at a glance — which interactions are healthy and which are degraded.

Each ISD entry carries:

A reference number that ties the status to a specific interaction instance.
An optional interaction type identifier (analyzer, transport, controller, etc.).
The current active state of the interaction, drawn from HL70511.

Used in

ISD is used inside the laboratory automation equipment status messages defined in HL7 chapter 13:

ESU — Equipment Status Update — ISDs describe the live interactions reported by the device.
ESR — Equipment Status Request — responses include ISDs for each interaction touched by the request window.

ISD typically follows the EQU and one or more EQP segments.

Field-by-field reference

Metadata below is derived from the HAPI HL7 v2.5.1 segment javadoc. Length values are not surfaced by the javadoc and are shown as "—"; refer to the base HL7 v2.5.1 standard for normative lengths. Required (R) reflects segment-level optionality recognised by the HL7 standard.

Seq	Name	Data Type	Length	Req	Repeat	Table #	Description
ISD-1	Reference Interaction Number	nm	—	R	—	—	Unique number identifying the interaction
ISD-2	Interaction Type Identifier	ce	—	O	—	—	Coded kind of interaction being reported
ISD-3	Interaction Active State	ce	—	O	—	HL70511	Current active state of the interaction

Most-used fields

ISD-1 Reference Interaction Number — the only required field; it is the primary key tying the status report back to a specific interaction instance maintained by the device or automation manager.
ISD-3 Interaction Active State — the field that drives operator dashboards and alerting; values come from HL70511 (Interaction Status).
ISD-2 Interaction Type Identifier — useful for grouping and filtering, especially when one analyzer reports several interaction kinds in the same message.

Version differences (2.3 to 2.8.2)

v2.3: ISD did not exist; interaction status, where reported at all, was conveyed through proprietary segments.
v2.4: ISD introduced together with EQU and EQP as part of the laboratory automation chapter. Initial structure already used Reference Interaction Number, Interaction Type Identifier and Interaction Active State.
v2.5 / v2.5.1: No structural change. v2.5.1 links ISD-3 to user-defined table HL70511.
v2.6: ISD unchanged; some implementations begin sending many ISDs per EQU to model fine-grained subsystem interactions.
v2.7 / v2.7.1: Normative truth tables published. ISD-1 remains required at the segment level.
v2.8 / v2.8.2: ISD unchanged. Vocabulary for ISD-3 continues to grow via local extensions to HL70511.

Common mistakes

Reusing the same Reference Interaction Number across unrelated interactions. ISD-1 must be unique within the device's interaction tracking scope.
Sending ISD without a corresponding EQU. ISD is meaningless on its own — automation managers expect it to follow a device descriptor.
Treating ISD-1 as a string. The data type is NM (numeric); leading zeros or alphanumeric values violate the standard and break engines that normalise to numbers.
Inventing new Interaction Active State codes without coordinating with downstream consumers. ISD-3 should draw from HL70511.
Reporting only the failing interactions. Sending the full set — both active and held — gives operators much better situational awareness.

Examples

Minimal ISD (only the required field populated):

ISD|10101

Fully-populated ISD:

ISD|10101|HEMATOLOGY^Hematology Analyzer^HL70499|ACTIVE^Active^HL70511

Annotated breakdown:

ISD                                       Segment ID
|10101                                    ISD-1 Reference Interaction Number (NM)
|HEMATOLOGY^Hematology Analyzer^HL70499   ISD-2 Interaction Type Identifier (CE)
|ACTIVE^Active^HL70511                    ISD-3 Interaction Active State (CE, table HL70511)

In-context excerpt from an ESU equipment status update:

MSH|^~&|AUTO-MGR|VORRO-LAB|LIS|VORRO-LAB|20260610081530-0500||ESU^U01^ESU_U01|MSG00061|P|2.5.1
EQU|ANALYZER-07^^VORRO-LAB^EI|20260610081530-0500|OPERATING^Operating^HL70365|REMOTE^Remote Control^HL70365|NORMAL^Normal^HL70365
EQP|HEARTBEAT^Heartbeat^HL70450|||20260610081530-0500|Heartbeat from ANALYZER-07
ISD|10101|HEMATOLOGY^Hematology Analyzer^HL70499|ACTIVE^Active^HL70511
ISD|10102|TRACK^Sample Track^HL70499|ACTIVE^Active^HL70511

In-context excerpt from an ESR equipment status response:

MSH|^~&|AUTO-MGR|VORRO-LAB|LIS|VORRO-LAB|20260610090000-0500||ESR^U02^ESR_U02|MSG00062|P|2.5.1
EQU|CHEMISTRY-03^^VORRO-LAB^EI|20260610090000-0500|PM_REQUIRED^PM Required^HL70365|LOCAL^Local Control^HL70365|WARNING^Warning^HL70365
EQP|ERROR^Error^HL70450||20260610085500-0500|20260610085930-0500|Reagent pack low: channel 3
ISD|10103|CHEMISTRY^Chemistry Analyzer^HL70499|HELD^Held^HL70511
ISD|10104|TRACK^Sample Track^HL70499|ACTIVE^Active^HL70511

FHIR mapping

There is no segment-level ConceptMap for ISD in the v2-to-FHIR Implementation Guide. Practical mapping choices:

ISD-1 Reference Interaction Number maps to the identifier of a Communication or Observation resource representing the interaction.
ISD-2 Interaction Type Identifier maps to category or code on that Communication/Observation.
ISD-3 Interaction Active State maps to status (active/completed/on-hold) on Communication, or to value on an Observation describing the interaction state.

When ISD is part of a richer model, integrators sometimes project it onto Device.contact or onto a custom DeviceMetric Observation whose code denotes the interaction type and whose value denotes the state.

Engine considerations

ISD is repeating inside ESU_U01/ESR_U02. Iterate, do not read only the first ISD.
Strictly typed engines reject non-numeric ISD-1 values. If your producer is emitting alphanumeric interaction IDs, fix the producer rather than relaxing the parser.
HL70511 is user-defined. Engines should expose a local code system mapping so dashboards can render unknown codes without losing the original value.
Pair ISD-1 with the parent EQU-1 when storing to a database, since interaction numbers are only unique within a device's namespace.

How Vorro parses and produces ISD

The Vorro integration platform parses ISD using the HAPI HL7 v2.5.1 model and projects each instance as an interaction-status row tied to its parent EQU. On the inbound path:

ISD-1 is parsed as an integer and stored alongside the EQU-1 composite key to form a globally unique interaction identifier across devices.
ISD-2 is resolved against the configured interaction-type vocabulary; unknown codes are preserved verbatim and flagged for operator review.
ISD-3 is mapped to a normalized interaction-state enum (active, held, ended, error) that powers the platform's interaction dashboards.

On the outbound path, Vorro emits one ISD per tracked interaction for the reporting device, including interactions in the steady "active" state so consumers see a complete picture rather than only the exceptions. Pre-serialisation validation ensures ISD-1 is numeric and unique within the message.

Sources

← Back to HL7 v2 Guide