HL7 NMD Messages: Application Management Data

HL7 NMD messages carry an unsolicited push of application management data from a sending system — the operational state of a running HL7 application reported without being asked. An NMD message can convey the system clock, message-processing statistics, or a change in application status, and it is sent from the application being monitored to any system that needs to track operational health. This page explains what an NMD message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how NMD relates to FHIR. Sample content is constructed for illustration with fictional identifiers.

What an NMD message represents

An NMD message — NMD stands for Application Management Data — communicates the operational state of a sending HL7 application. Unlike most HL7 v2 messages, NMD carries no clinical payload. Its purpose is to let one application push its own health and status to interested parties — a monitoring hub, an operations dashboard, or a peer application — as a proactive notification rather than in response to a query.

The sender is the application being monitored, and the receivers are any systems responsible for tracking operational health, raising alerts, or maintaining a record of application availability. NMD sits in the network and application management chapter of the HL7 standard alongside the NMQ query and the NMR query response. Where NMQ asks a remote application for its status, NMD sends that status without being asked — the difference between polling and pushing. Three types of payload can appear in an NMD message: a network clock reading in the NCK segment, application processing statistics in the NST segment, and an application status change in the NSC segment.

When an NMD message is sent

An NMD message is sent whenever a sending application has application management data to push without waiting for a query. Common occasions include a scheduled clock-synchronisation broadcast, a periodic statistics heartbeat, and a transition between application states — such as going from standby to active, or from active to shutdown. A single NMD message can carry one or more of these payload types together by including multiple sub-groups in the repeating CLOCK_AND_STATS_WITH_NOTE_AND_STATS group.

Trigger event

The NMD message type carries a single trigger event:

• NMD^N02 – Application management data message (unsolicited).

Because NMD has one trigger event, the receiver's handling turns on which sub-groups are present — CLOCK, APP_STATS, or APP_STATUS — rather than on a further qualifier in MSH-9.

Integration topology

The diagram shows the managed application emitting an unsolicited management data event through the integration engine to the systems that monitor and record operational state.

{{diagram: managed application → NMD message → integration engine → monitoring hub / operations dashboard / peer applications}}

Typical senders: any HL7 v2 application that implements the network and application management chapter — interface engines, laboratory systems, pharmacy systems, and ADT engines.

Typical receivers: operations monitoring platforms, integration engine consoles, and peer applications that need to track the sender's availability and processing health.

Direction: unidirectional unsolicited notification from the monitored application to the systems that observe its operational state.

Segments in an NMD message

The NMD_N02 message is organised into a mandatory MSH header followed by one or more CLOCK_AND_STATS_WITH_NOTE_AND_STATS groups. Each group contains at most one of three optional sub-groups: CLOCK (NCK with optional repeating NTE), APP_STATS (NST with optional repeating NTE), or APP_STATUS (NSC with optional repeating NTE). 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.

[ ] = optional, { } = repeating

The CLOCK_AND_STATS_WITH_NOTE_AND_STATS group repeats, so a single NMD message can push clock data, statistics, and a status change together in one transmission. Only one sub-group — CLOCK, APP_STATS, or APP_STATUS — appears per group instance, but the group itself may repeat as many times as the sender has payload types to push. The canonical segment pages carry the full field-by-field detail.

Sample NMD message

Note. Constructed for illustration. Application names, network addresses, dates, and statistics are fictional.

MSH|^~&|LABSYS|MERCYGEN|OPSMON|MERCYGEN|20260604073000||NMD^N02^NMD_N02|MSG00047|P|2.5.1
NCK|20260604073000-0500
NST|1|20260604000000|20260604073000|4821|4756|0|65|0|0|0|0|0|0
NSC|U^Active^HL70409|LABSYS|MERCYGEN|192.168.10.55|LABSYS|MERCYGEN|192.168.10.55|S^Standby^HL70409

What this sample shows

The NMD^N02 in MSH-9 marks an unsolicited application management data push from LABSYS at facility MERCYGEN to the operations monitor OPSMON. The NCK segment in the first group instance reports the sender's current system clock — 20260604073000-0500, meaning 07:30:00 on 4 June 2026, Eastern Standard Time. The NST segment in the second group instance reports a statistics window from midnight to 07:30 — 4,821 messages sent, 4,756 received, and 65 messages still pending, with no checksum errors and no rejections. The NSC segment in the third group instance records a status transition: the application has moved from S (Standby) to U (Active), is now reachable at 192.168.10.55, and the same address was used in the previous standby state.

Working with NMD messages

Route on the sub-group present, not only on MSH-9

Because all three payload types share the single trigger event NMD^N02, processing logic must inspect which sub-group segments are present in each CLOCK_AND_STATS_WITH_NOTE_AND_STATS group instance — NCK, NST, or NSC — rather than routing solely on MSH-9. A single NMD message may carry all three payload types in successive group instances, and each should be handled independently.

Idempotency and deduplication

Use MSH-10, the message control id, as the deduplication key. NMD messages are often sent on a heartbeat schedule, and an integration engine restart or network replay can re-deliver a message. Treating a repeated control id as a duplicate prevents a replayed statistics push from being recorded as new data or a replayed status change from triggering a spurious alert.

Status transitions in NSC

NSC-1 carries the current application status and NSC-8 carries the previous status. Capture both fields so that a transition log shows the full state sequence — active → standby → shutdown — rather than only the current state. Alert thresholds should fire on specific transitions (for example, any arrival at D / down) rather than on any status push, to avoid noise from expected standby transitions during maintenance windows.

Clock drift and time zones

NCK carries a single date-time field. Some senders transmit a local time without an offset; others include an offset; and others transmit UTC. Normalise the clock value on ingest — capture the offset when present, and record the raw value alongside the normalised form so that drift calculations are not contaminated by a silent timezone assumption.

Vendor variance. Not all HL7 v2 implementations support the network and application management chapter. Some systems send only one sub-group type in every NMD and never combine them in a single message, while others include all three in every heartbeat. Confirm a partner's field usage against their interface specification rather than assuming the base standard.

FHIR equivalent

NMD is a system-management protocol message with no FHIR clinical equivalent. The HL7 v2-to-FHIR Implementation Guide provides no message map for NMD_N02 and no ConceptMap for the NCK, NST, or NSC segments. FHIR addresses operational monitoring through mechanisms outside the clinical resource model — such as the FHIR capability statement or implementation-guide-specific extensions — none of which map directly to the network clock, statistics, or application-status payloads in NMD. There is no meaningful FHIR translation for this message.

Common pitfalls

Pitfall. Processing only the first group instance when a message contains multiple. The CLOCK_AND_STATS_WITH_NOTE_AND_STATS group repeats, so an NMD that carries clock data, statistics, and a status change in one transmission requires a loop over all group instances rather than reading only the first segment after the MSH.

Pitfall. Triggering alerts on every NSC push regardless of transition direction. Monitoring logic that fires on any NSC arrival will produce noise from expected standby transitions. Alert thresholds should be tied to specific NSC-1 values — particularly D (down) — and to unexpected transitions, not to the presence of the segment itself.

Pitfall. Assuming NCK carries UTC. Many implementations omit the timezone offset from NCK-1. Silently treating a bare local time as UTC produces a systematic drift error in clock-synchronisation logic; always capture and check for an offset before normalising.

How Vorro handles NMD messages

Vorro ingests NMD feeds over MLLP or another transport, deduplicates on MSH-10, and loops over every CLOCK_AND_STATS_WITH_NOTE_AND_STATS group instance in the message. Clock readings from NCK are normalised for timezone offset and forwarded to configured clock-monitoring consumers. Statistics from NST are aggregated into the operations dashboard so that throughput and error trends are visible across the interface estate without requiring a polling query. Status changes from NSC are recorded with both the current and previous state, and alerts are raised on configured transitions — such as any application reaching the down state — while expected maintenance transitions are suppressed. Because the v2-to-FHIR Implementation Guide publishes no map for this message and NMD has no FHIR clinical equivalent, no FHIR translation is performed.

Related messages

• NMQ — the application management query that asks a remote application for the same data that NMD pushes unsolicited.
• NMR — the application management query response that carries the data NMD pushes, in response to an NMQ.
• ACK — the general acknowledgement returned to an NMD sender to confirm receipt.

Sources

• HL7 v2-to-FHIR IG — message maps index — confirms no message map for NMD_N02
• HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for NCK, NST, or NSC
• HL7 Messaging Standard Version 2.5.1 product brief