HL7 NMQ Messages: Application Management Query

HL7 NMQ messages carry a solicited query for application management data — a direct request from an operations or monitoring system asking a running HL7 application to report its current state. An NMQ message can request the system clock, message-processing statistics, or current application status, and it is sent from the querying system to the application being monitored. The target application replies with an NMR^N01 response. This page explains what an NMQ message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how NMQ relates to FHIR. Sample content is constructed for illustration with fictional identifiers.

What an NMQ message represents

An NMQ message — NMQ stands for Application Management Query — is a solicited pull for operational information about a running HL7 application. Unlike most HL7 v2 messages, NMQ carries no clinical payload. Its purpose is to let one system ask another to report on its own health and status — on demand, at the moment of the query — rather than waiting for the monitored application to push data voluntarily.

The sender is the operations or monitoring system, and the receiver is the application being queried — any HL7-capable system that implements the network and application management chapter. NMQ sits in the network and application management chapter of the HL7 standard alongside the NMD unsolicited push and the NMR query response. Where NMD sends operational data without being asked, NMQ asks for it directly — the difference between pushing and polling. The querying system controls what it wants to know by including the relevant sub-group in the repeating CLOCK_AND_STATS_WITH_NOTE group: a NCK sub-group signals a request for the system clock, an NST sub-group requests message-processing statistics, and an NSC sub-group requests the current application status. The receiving application answers only the items queried, and its reply is an NMR^N01.

When an NMQ message is sent

An NMQ message is sent whenever a monitoring or operations system needs a point-in-time snapshot of a remote application's state. Common occasions include a periodic health check against a known endpoint, a triggered investigation after an alert fires, and an on-demand status poll during a maintenance window or incident response. A single NMQ can request all three types of information simultaneously by including multiple sub-groups in the repeating CLOCK_AND_STATS_WITH_NOTE group, or it can request only one — for example, requesting only the system clock to verify synchronisation without asking for statistics or status.

Trigger event

The NMQ message type carries a single trigger event:

• NMQ^N01 – Application management query (solicited).

Because NMQ has one trigger event, the receiver's handling turns on which sub-groups are present in each CLOCK_AND_STATS_WITH_NOTE group instance — CLOCK, APP_STATS, or APP_STATUS — rather than on a further qualifier in MSH-9. Each sub-group present in the query is a separate data request, and the NMR^N01 response includes one corresponding sub-group per requested item.

Integration topology

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

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

Typical senders: network management application, integration engine monitoring console, HL7 operations dashboard, incident-response tooling.

Typical receivers: any HL7-capable application — interface engine, EHR, LIS, pharmacy system — that implements the application management protocol and can respond with an NMR^N01.

Direction: solicited request from the querying system to the target application. The flow is request-response, in contrast to NMD, which is a unidirectional unsolicited push.

Segments in an NMQ message

The NMQ_N01 message opens with a required MSH header and optional software segment, followed by one or more CLOCK_AND_STATS_WITH_NOTE groups. Each group contains at most one of three optional sub-groups: CLOCK (optional NCK with optional repeating NTE), APP_STATS (optional NST with optional repeating NTE), and APP_STATUS (optional NSC with optional repeating NTE). The presence of a sub-group in the query signals to the receiving application that the querier wants that type of information returned in the NMR. 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 repeats, so a single NMQ can request clock data, statistics, and status in one message by including multiple group instances — one per requested item. 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 request types to issue. The canonical segment pages carry the full field-by-field detail.

Sample NMQ message

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

MSH|^~&|NETMGR|MERCYGEN|LABSYS|MERCYGEN|20260604093000||NMQ^N01^NMQ_N01|MSG00042|P|2.5.1
NCK|
NST|
NSC|

What this sample shows

The NMQ^N01 in MSH-9 marks a solicited application management query from the monitoring application NETMGR at facility MERCYGEN to LABSYS. The message control id MSG00042 in MSH-10 will be echoed in MSA-2 of the NMR^N01 response, allowing the querier to correlate the reply.

All three sub-groups are present — NCK, NST, and NSC — which signals that NETMGR is requesting the system clock, message-processing statistics, and current application status simultaneously. The segments carry no data fields in the query; their presence alone is the request signal. LABSYS will reply with an NMR^N01 that populates each corresponding sub-group with the requested values. A query requesting only status would omit the NCK and NST sub-groups entirely.

Working with NMQ messages

Presence of a sub-group is the request signal

In an NMQ, the segments NCK, NST, and NSC carry no meaningful data — their presence in the CLOCK_AND_STATS_WITH_NOTE group is the signal. The receiving application should inspect which sub-groups appear in each group instance and respond in the NMR with the corresponding populated sub-groups. Processing logic that reads field values from these segments in the query, rather than checking for their presence, will misread the protocol.

Idempotency and deduplication

Use MSH-10, the message control id, as the deduplication key. A monitoring system may retry an NMQ after a timeout, and an integration engine restart may replay a message. Treating a repeated control id as a duplicate prevents a re-sent query from triggering a second response that the querier processes as new data. The receiving application should check MSH-10 before generating and sending an NMR^N01.

Correlate the NMR response using MSH-10

When multiple NMQ queries are outstanding — for example, a monitoring system polling several applications simultaneously — the NMR response must be matched to the correct query. The MSA-2 field in the NMR echoes the MSH-10 value from the NMQ. Route responses on MSA-2, not on connection or timing, to avoid associating a response with the wrong query and producing a false picture of application state.

Scope queries to what you need

Including all three sub-groups in every NMQ is valid but creates overhead on both ends — the receiving application must gather clock, statistics, and status data to populate a full NMR response regardless of whether the querier will use all of it. Scope each query to the sub-groups actually needed: request only NSC for a status check, only NCK for a clock-drift check, and only NST for a throughput inspection. This reduces processing load and makes the monitoring intent explicit in the message structure.

Vendor variance. Not all HL7 v2 implementations support the network and application management chapter. Some systems respond only to specific sub-group types and ignore others rather than returning an error. Others return all three sub-groups in every NMR regardless of which sub-groups were requested. Confirm a partner's query handling against their interface specification rather than assuming the base standard.

FHIR equivalent

NMQ is a system-management protocol message with no FHIR clinical equivalent. The HL7 v2-to-FHIR Implementation Guide provides no message map for NMQ_N01 and no ConceptMap for the NCK, NST, or NSC segments. FHIR does not model solicited queries for 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. There is no meaningful FHIR translation for this message.

Common pitfalls

Pitfall. Reading field values from NCK, NST, or NSC in the query. In an NMQ these segments carry no data — their presence is the request signal. Attempting to extract a clock value or a statistics count from an NMQ segment will yield empty or null fields; the data lives in the NMR^N01 response.

Pitfall. Sending a query without retaining the MSH-10 value for correlation. If the querying system does not store MSH-10 before sending the NMQ, it cannot match the NMR response to the correct outstanding query — particularly when multiple queries are in flight simultaneously.

Pitfall. Assuming the responding application will answer only the sub-groups requested. Some implementations return all three sub-groups in every NMR regardless of the query. Processing logic should handle additional sub-groups gracefully rather than treating unexpected segment types as an error.

How Vorro handles NMQ messages

Vorro issues NMQ queries over MLLP or another transport on behalf of configured monitoring schedules, storing MSH-10 for each query so that the NMR^N01 response can be correlated by MSA-2. Vorro includes only the sub-groups relevant to the configured health check — clock, statistics, status, or any combination — rather than querying all three on every poll, to minimise processing overhead on the target application. Inbound NMQ messages directed at Vorro-managed interfaces are handled by generating a populated NMR^N01 response that includes the requested sub-groups, with the system clock from NCK, current processing statistics from NST, and the current operational state from NSC. Because the HL7 v2-to-FHIR Implementation Guide publishes no map for this message and NMQ has no FHIR clinical equivalent, no FHIR translation is performed.

Related messages

• NMR — the application management query response that a target application sends in reply to an NMQ.
• NMD — the unsolicited application management data message that pushes the same operational information without a prior query — the push counterpart to NMQ's pull.
• ACK — the general acknowledgement message returned when an application accepts or rejects any HL7 message.

Sources

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