HL7 NMR Messages: Application Management Query Response

HL7 NMR messages carry an application management query response — the solicited reply an HL7 application sends when asked to report its system clock, message-processing statistics, or current operational status. An NMR message is always sent in response to an NMQ query and is the counterpart to the unsolicited NMD notification. This page explains what an NMR message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an NMR response relates to FHIR. Sample content is constructed for illustration with fictional identifiers.

What an NMR message represents

An NMR message — NMR stands for Application Management Query Response — communicates the operational state of an HL7 application in reply to a direct management query. The response is built around three optional sub-groups inside the repeating CLOCK_AND_STATS_WITH_NOTE group: a CLOCK sub-group carrying the NCK system-clock segment, an APP_STATS sub-group carrying the NST message-statistics segment, and an APP_STATUS sub-group carrying the NSC application-status segment. Each sub-group may be followed by one or more NTE comment segments.

The sender is the queried application — any HL7-capable system that received an NMQ — and the receiver is the network management or monitoring application that issued the original query. NMR sits at the network-management layer of HL7, providing operational visibility into the system rather than carrying clinical data. Because the NCK, NST, and NSC segments report state as of the moment the query is answered, the response is a snapshot, not a continuous feed.

When an NMR message is sent

An NMR message is sent immediately after receiving a valid NMQ^N01 application management query. The querying system specifies which information it wants — clock, statistics, status, or any combination — and the responding application includes only the sub-groups relevant to that request. A single NMR can carry clock, statistics, and status information simultaneously by repeating the CLOCK_AND_STATS_WITH_NOTE group.

Trigger event

The NMR message type carries a single trigger event:

• NMR^N01 – Application management query response.

Because NMR has one trigger event, the receiver's handling turns on the contents of the CLOCK_AND_STATS_WITH_NOTE group — which sub-groups are present and what data each carries — rather than on the trigger code in MSH-9.

Integration topology

The diagram shows the monitoring application issuing an NMQ query and the target application replying with an NMR response through the integration engine.

{{diagram: monitoring application → NMQ^N01 query → target HL7 application → NMR^N01 response → monitoring application}}

Typical senders: any HL7-capable application — interface engine, EHR, LIS, pharmacy system — that receives an NMQ query and implements the application-management protocol.

Typical receivers: network management application, integration engine monitoring console, HL7 operations dashboard.

Direction: solicited response from the queried application back to the querying system. Contrast with NMD, which pushes the same operational data unsolicited.

Segments in an NMR message

The NMR_N01 message opens with required header and acknowledgement segments, followed by an optional repeating CLOCK_AND_STATS_WITH_NOTE group. Inside that group, the CLOCK, APP_STATS, and APP_STATUS sub-groups are each optional; each sub-group carries its primary segment and optional repeating NTE comments. 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 group from NCK through the final NTE repeats once per queried item, so a single NMR message can respond to a clock query and a status query in one exchange. The canonical segment pages carry the full field-by-field detail.

Sample NMR message

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

MSH|^~&|IFACEENGINE|MERCYGEN|NETMGR|MERCYGEN|20260604093000||NMR^N01^NMR_N01|MSG00099|P|2.5.1
MSA|AA|MSG00042
NCK|20260604093000-0500
NST|1|20260604000000-0500|20260604093000-0500|14823|14820|0|3|0|0
NSC|MS^Application Accepting|IFACEENGINE|MERCYGEN|IFACEENGINE|MERCYGEN|||192.168.1.50|4500

What this sample shows

The NMR^N01 in MSH-9 marks an application management query response. MSA carries the acknowledgement code AA (application accept) and echoes the message control id MSG00042 from the originating NMQ query, so the querying system can match this response to its request.

The CLOCK_AND_STATS_WITH_NOTE group carries all three sub-groups. NCK reports the system clock as 20260604093000-0500 — 09:30:00 Eastern on 4 June 2026. NST reports statistics for the period from midnight to 09:30 (NST-2, NST-3): 14,823 messages received (NST-4), 14,820 sent (NST-5), no processing errors (NST-6), and 3 messages received but not yet processed (NST-7). NSC reports the application status as MS (accepting messages) with the current network address 192.168.1.50 on port 4500.

Working with NMR messages

Correlate the response to its query using MSA-2

Every NMR carries an MSA that echoes the message control id of the originating NMQ query in MSA-2. Correlate on this field — not on the connection or timing — so that responses can be matched correctly even when the monitoring system has multiple queries outstanding.

Idempotency and deduplication

Use MSH-10, the message control id of the NMR itself, as the deduplication key. Management feeds can be replayed after connectivity failures, and treating a repeated control id as a duplicate prevents a replayed response from registering a spurious status change or double-counting statistics.

Interpret NST statistics as a window, not a running total

NST reports counts over the window defined by NST-2 and NST-3. Compare successive NMR responses by aligning their statistics windows rather than subtracting raw counts — a responding application may reset its counters between queries, making a simple difference misleading.

Detect status transitions in NSC

NSC carries both the current application status and the previous status. Surface both on the monitoring dashboard rather than discarding the previous value — a transition from initialising to accepting confirms a successful startup, while a transition from accepting to error signals an incident requiring attention.

Vendor variance. The CLOCK_AND_STATS_WITH_NOTE group is optional and repeating, and which sub-groups appear depends on what the originating NMQ requested. Some implementations always return all three sub-groups regardless of the query; others return only the specific sub-groups requested. Confirm a partner's response structure against their interface specification rather than assuming the base standard.

FHIR equivalent

NMR is a system-management protocol with no FHIR equivalent. The HL7 v2-to-FHIR Implementation Guide provides no message map for NMR_N01 and no ConceptMap for the NCK, NST, or NSC segments. FHIR does not model application-level clock synchronisation, message-processing statistics, or operational status transitions, so there is no target resource to map to and no manual mapping approach is applicable. Systems that require operational health data in a FHIR context typically expose it through FHIR's CapabilityStatement or custom extensions rather than through a v2-to-FHIR translation.

Common pitfalls

Pitfall. Matching an NMR response to the wrong query. If several NMQ queries are in flight simultaneously, routing on connection or message timing instead of on MSA-2 can associate a response with the wrong query and produce a false picture of application state.

Pitfall. Treating NST counts as a running total. NST-4 through NST-9 cover the window in NST-2 to NST-3. Subtracting counts from two NMR responses is only meaningful when the windows are contiguous; a gap or reset between queries makes the arithmetic incorrect.

Pitfall. Ignoring the previous status in NSC-2. Discarding NSC-2 removes the transition context — without knowing the previous state, a current status of accepting is ambiguous between steady-state operation and recovery from an error.

How Vorro handles NMR messages

Vorro ingests NMR responses over MLLP or another transport, correlates each response to its originating NMQ query using MSA-2, and deduplicates on MSH-10. For each CLOCK_AND_STATS_WITH_NOTE group in the response, Vorro extracts the system clock from NCK, the statistics window and counts from NST, and the current and previous application status and network address from NSC, and routes the resulting operational data to every subscribed monitoring destination. Because the HL7 v2-to-FHIR Implementation Guide publishes no map for this message and defines no FHIR equivalent for system-management data, Vorro treats NMR as an operational protocol and does not attempt a FHIR translation.

Related messages

• NMQ — the application management query that an NMR message responds to.
• NMD — the unsolicited application management data message that pushes the same operational information without a prior query.
• ACK — the general acknowledgement message returned when an application accepts or rejects any HL7 message, including an NMQ.

Sources

• HL7 v2-to-FHIR IG — message maps index — confirms no message map for NMR_N01
• 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