The NDS (Notification Detail) segment carries the detail of an application or network-level notification. It belongs to the network-management family of messages, where systems coordinate the operational status of applications and the links between them rather than exchange clinical or administrative data.
NDS describes a single notification event: a reference number to track it, when it occurred, how severe it is, and a code that classifies it. It is infrastructure plumbing that helps interface engines and monitoring systems reason about the health of their connections.
Purpose
The NDS segment provides the particulars of a network or application notification: a tracking reference, a timestamp, an alert severity, and a notification code. It is used so that monitoring and network-management systems can record and react to events affecting application connectivity.
NDS is operational metadata about a notification, not patient or encounter data.
Used in
NDS (Notification Detail) is used in NMD application and network-management messages. See NMD network management messages.
- Network-management (NMD) flows carry NDS to convey the detail of a notification raised about an application or link.
- NDS appears alongside NSC and NCK, which describe status changes and clock synchronization in the same network-management context.
Field-by-field reference
Source: HAPI HL7v2 v2.5.1 javadocs (NDS.html). Length is shown as —; Required and Table # come from the HL7 v2.5.1 standard where well-established.
| Seq | Name | Data Type | Length | Req | Repeat | Table # | Description |
|---|---|---|---|---|---|---|---|
| NDS-1 | Notification Reference Number | nm | — | R | — | — | Number tracking this notification event |
| NDS-2 | Notification Date/Time | ts | — | R | — | — | When the notification was generated |
| NDS-3 | Notification Alert Severity | ce | — | R | — | — | Severity level of the notification |
| NDS-4 | Notification Code | ce | — | R | — | — | Coded classification of the notification |
Most-used fields
- NDS-1 Notification Reference Number: the tracking number that lets systems correlate and de-duplicate notifications.
- NDS-2 Notification Date/Time: the timestamp that orders notifications and supports time-window analysis.
- NDS-3 Notification Alert Severity: the severity code that drives how urgently a monitoring system reacts.
- NDS-4 Notification Code: the classification code that says what kind of notification occurred.
All four fields work together as the minimal record of a single notification event.
Version differences (2.3 to 2.8.2)
- 2.3: NDS is defined in the network-management chapter with its reference number, date/time, severity, and code fields.
- 2.3.1 to 2.4: The four-field layout is stable; the CE and TS data types underlying NDS gain components.
- 2.5 and 2.5.1: NDS carries the four fields documented here, with severity and code typed as CE.
- 2.6 to 2.8.2: The segment shape persists; refinements appear in the underlying CE and TS data types rather than in the NDS field list.
NDS is rarely altered across versions because network-management messaging is a stable, infrastructure-oriented area of the standard.
Common mistakes
- Omitting NDS-1, which leaves the receiver unable to track or correlate the notification.
- Sending NDS-2 without a precise timestamp, which undermines ordering and time-window analysis.
- Treating NDS-3 severity as free text instead of a coded value, so monitoring rules cannot evaluate it.
- Confusing NDS with clinical alerting; NDS is about application and network notifications, not patient alerts.
- Using NDS outside an NMD network-management context where it does not belong.
Examples
Minimal NDS with the required reference, timestamp, severity, and code:
NDS|1001|20260610142200|W^Warning^HL7NDS|LINK_DOWN^Interface link down^VORRO_NDS
Fully populated NDS:
NDS|1001|20260610142200|C^Critical^HL7NDS|LINK_DOWN^Interface link down^VORRO_NDS
Annotated breakdown:
NDS-1 1001 Notification reference number
NDS-2 20260610142200 Notification date/time
NDS-3 C^Critical^HL7NDS Alert severity = critical
NDS-4 LINK_DOWN^Interface link down^VORRO_NDS Notification code (link down)
In-context excerpt within an NMD network-management message:
MSH|^~&|NETMON|VORRO|NETMGR|HOSP_B|20260610142200||NMD^N02^NMD_N02|NMD00031|P|2.5.1
NSC|A^Activate^HL70206|NETMON|VORRO|NETMGR|HOSP_B
NDS|1001|20260610142200|C^Critical^HL7NDS|LINK_DOWN^Interface link down^VORRO_NDS
A second in-context excerpt pairing NDS with a clock-synchronization segment:
NCK|20260610142205
NDS|1002|20260610142205|I^Informational^HL7NDS|CLOCK_SYNC^Clock synchronized^VORRO_NDS
FHIR mapping
- Source: NDS
- Target: Not mapped at the segment level.
- Notes: No segment-level ConceptMap is published in the v2-to-FHIR IG for NDS. Conceptually NDS describes network and notification infrastructure and has no direct FHIR resource target.
NDS conveys operational notification metadata that lives below the clinical layer, so a FHIR integration typically consumes it for monitoring and does not translate it into a clinical resource.
Engine considerations
- Require all four NDS fields, since the standard defines them as the core of a notification record.
- Parse NDS-2 with full timestamp precision to support ordering and de-duplication.
- Map NDS-3 and NDS-4 against the agreed severity and code tables before acting on them.
- Route NDS to monitoring and network-management subscribers, not clinical pipelines.
- Correlate notifications by NDS-1 to avoid double-handling repeated events.
How Vorro parses and produces NDS
- On inbound network-management messages, Vorro reads NDS as a notification record keyed on NDS-1 and timestamped by NDS-2.
- Severity and code values are validated against configured tables and normalized for downstream monitoring rules.
- On outbound messages, Vorro emits all four NDS fields with a precise timestamp and coded severity and notification values.
- Notifications are correlated by reference number so repeated events are not processed twice.
- NDS traffic is kept on the operational monitoring path and never mixed with clinical message handling.
