The Demo site for our new HL7 Version 2+ (plus) Standard
visit the hl7 website

Draft Website - For Review Purposes Only

MSA - Message Acknowledgment Segment

The MSA segment contains information sent while acknowledging another message.

HL7 Attribute Table - MSA - message acknowledgment segment
Seq# DataElement Description Must Implement Flags Cardinality Length C.LEN Vocabulary DataType
MSA
1 00018 Acknowledgment Code SHALL [1..1] [2..2] ID
2 00010 Message Control ID SHALL = [1..1] [1..199] 199 ST
3 00020 Text Message SHALL NOT W [0..0]
4 00021 Expected Sequence Number [0..1] NM
5 00022 Delayed Acknowledgment Type SHALL NOT W [0..0]
6 00023 Error Condition SHALL NOT W [0..0]
7 01827 Message Waiting Number [0..1] NM
8 01828 Message Waiting Priority [0..1] [1..1] ID

MSA-1: Acknowledgment Code (ID) 00018

Definition: This field contains an acknowledgment code, see message processing rules. Refer to HL7 Table 0008 - Acknowledgment Code for valid values.

MSA-2: Message Control ID (ST) 00010

(Definition from MSA.2 in Ch. 2)

Definition: This field contains the message control ID of the message sent by the sending system. It allows the sending system to associate this response with the message for which it is intended.

(Definition from MSH.10 in Ch. 2)

Definition: This field contains a number or other identifier that uniquely identifies the message. The receiving system echoes this ID back to the sending system in the Message acknowledgment segment (MSA).

MSA-3: Text Message

Attention: The MSA-3 was deprecated as of v 2.4 and the detail was withdrawn and removed from the standard as of v 2.7. The reader is referred to the ERR segment. The ERR segment allows for richer descriptions of the erroneous conditions.

MSA-4: Expected Sequence Number (NM) 00021

Definition: This optional numeric field is used in the sequence number protocol.

MSA-5: Delayed Acknowledgment Type

Attention: The MSA-5 was deprecated as of v2.2 and the detail was withdrawn and removed from the standard as of v 2.5.

MSA-6: Error Condition

Attention: The MSA-3 was deprecated as of v 2.4 and the detail was withdrawn and removed from the standard as of v 2.7. The reader is referred to the ERR segment. The ERR segment allows for richer descriptions of the erroneous conditions.

MSA-7: Message Waiting Number (NM) 01827

Definition: If present, indicates the number of messages the Acknowledging Application has waiting on a queue for the Requesting Application. These messages would then need to be retrieved via a query. This facilitates receiving applications that cannot receive unsolicited message (i.e., polling).

For example, if there are 3 low priority messages, 1 medium priority message and 1 high priority message, the message waiting number would be 5, because that is the total number of messages.

Use Case: An application that is playing a "requesting" role has limited network access to a centralized application playing a receiving role. When the requesting application contacts the acknowledging application with a regular update or query message, the acknowledging application replies with the appropriate response message, along with an indication that there are urgent messages waiting. The requesting application submits a query to retrieve the queued messages.

MSA-8: Message Waiting Priority (ID) 01828

Definition: If present, indicates that the Sending Application has messages waiting on a queue for the Receiving Application. These messages would then need to be retrieved via a query. This facilitates receiving applications that cannot receive unsolicited messages (i.e., polling). The code specified identifies how important the most important waiting message is (and can govern how soon the receiving application is required to poll for the message).

For example, if there are 3 low priority messages, 1 medium priority message and 1 high priority message, the message waiting priority would be 'high', because that is the highest priority of any message waiting.

With some applications, there is no guarantee that the sending application will be running. The receiving application is therefore unable to submit unsolicited messages. To mitigate this, a polling approach is used where the receiving application requests any queued messages when it is connected. To avoid the network overhead of continuous polling, the sending application needs a way to indicate that there are queued messages awaiting retrieval. It is also useful to provide an indication of the importance of those messages to indicate how quickly they must be retrieved.

Refer to HL7 Table 0520 - Message Waiting Priority in Chapter 2C, Code Tables, for valid values.

See MSA-7 above for Use Case.