Which field is used by the receiver to reconstruct the original senders segments

The sender initiates the link with a message that has no functional content. The sequence number is 0. The message type and event code are not used.

MSH|^~\&|ADT|767543|LAB|767543|199003141304-0500||ADT^A08^ADT_A01|XX3657|P|2.7|0

The responder uses a general acknowledgment. The expected sequence number is 1.

See section 2.10.1, "Sequence number protocol" for further detail.

2.17.4 Message fragmentation

This summarizes the methodology for splitting a single logical HL7 message among two or more actual HL7 messages. The actual specifications for this, the segment definitions of the ADD and DSC segments, and examples are in Section 2.10.2, "Continuation messages and segments".

Continuing of messages is a generic methodology that can be used for all HL7 message types. It can be used to split based on segment boundaries, on field boundaries, and to split a single field among several messages. It utilizes two specific segments, ADD and DSC, as well as a field in the message header, MSH-14 Continuation Pointer.

When a message is continued, a unique continuation value is used. This same value will appear in MSH-14 and DSC-1 as appropriate for a single pair of messages. This allows messages to be "chained together".

Here are two examples of ways to create continuation pointers for fragmented messages. The only absolute requirement is that when the sending application values the continuation pointer, the receiving application can appropriately reconstruct the message.

Sitecode-interfaceapplicationcode-date-sequentialcounterwithindate

This will guarantee uniqueness of this field.

e.g., BWH-LDS-19990331-27 for the 27th large message to be created on March 31, within the Discharge Summary interfaces at BWH

An alternative method of valuing the continuation pointer:

Sitecode-interfaceapplicationcode-medicalrecordnumber-datetime

e.g.. MGH-PCIS-1234567-19980331121314 for a message created on March 31, at 12:13:14pm for patient medical record number 1234567, within the PCIS interfaces at MGH

Sending Application Note: In the ADD segment, a trailing field delimiter, i.e., the vertical bar character, after the final field, has explicit meaning. The sending application should not include a trailing field delimiter for the last field in the ADD segment unless it has completely valued the entire field from the message being continued.

Receiving Application Note: The receiving application will need to be concerned with a single segment and a single field being continued.

Receiving a message with an empty ADD segment followed by a DSC segment is the notification that the segment preceding the ADD is being continued in a subsequent message. Note that the continuing message may not be the next one received! The receiver must match up the continuation pointer value from MSH-14 of subsequent messages to the DSC-1 continuation pointer value of the prior message. Also if the continuing message contains an ADD segment, the receiver should continue appending to the fields from the segment being continued with values from the ADD segment. For example, if OBX-5 is being continued, the continuation will appear in ADD-1 of the continuing message. If there were a value for OBX-13 of the original message, that would appear in ADD-9 of the continuing message, assuming that the remainder of the OBX segment fit into the single ADD segment.

Question: if continuing a message after the completion of a complete segment, should the continuing message have an empty ADD segment or not? Answer: No. This means that a continuing message need not have an ADD segment, if the continued message was split on a segment boundary.

Notation conventions: items within angle brackets are comments and not intended to represent a portion of an actual message. For example, .

Note the multiple continuation pointer values, one for each pair of physical messages.

Message 1

MSH|...|||...

PID|...

ORC|...

OBR|...

OBX|1|FT|^Discharge Summary|1|This is the first sentence of a long

message. This is the second sentence of a long message.

This is the 967th sentence of "

ADD|

DSC|BWH-LDS-19990405-6|

Message 2

MSH|...||BWH-LDS-19990405-6|

ADD|a long message. This is the 968th sentence of a long message.

This is the 1001st line of

DSC|BWH-LDS-19990405-7|

Message 3

MSH|...||BWH-LDS-19990405-7|

ADD|a long message. This is the 1002nd sentence of a long message. This is the final sentence of this long message!|||||F||199707211325|

DG1|...

The following examples discuss an unsolicited transmission of an observation message, ORU^R01.

The expected result values in OBX-5 Observation Value, for reports (e.g., autopsy, pathology) may exceed the message length restrictions of one or more interfaces.

Thus the OBX-5 Observation Value data element will be split into more than one message.

Here's an example intended to illustrate the interpretation of Chapter 2 and 7. It reflects a single logical message broken up into three distinct messages.

Example 1, a single field being split across three messages

Message #1: ---------------------------------------------------------------

Note: MSH-14, continuation pointer, is empty.

MSH|...|||...

PID|...

ORC|...

OBR|...

OBX|1|FT|^Discharge Summary|1|This is the first sentence of a long

message. This is the second sentence of a long message.

This is the 967th sentence of "

ADD|

DSC||F

Message #2: --------------------------------------------------------------

Note: MSH-14, continuation pointer, is valued with the same value as in DSC-1, continuation pointer from the message this is continuing, in this case Message #1.

MSH|...|||

ADD|a long message. This is the 968th sentence of a long message.

This is the 1001st line of

DSC||F

Message #3: ---------------------------------------------------------------

Note: MSH-14, continuation pointer, is valued with the same value as in DSC-1, continuation pointer from the message this is continuing, in this case Message #1.

MSH|...|||

ADD|a long message. This is the 1002nd sentence of a long message. This is the final sentence of this long message!|||||F||199707211325|

PR1|...

DG1|...

Example 2, a single message being split across two messages, but on segment boundaries

Message #1: ---------------------------------------------------------------

Note: MSH-14, continuation pointer, is empty.

MSH|...|||...

PID|...

ORC|...

OBR|...

OBX|1|FT|^Discharge Summary|1|This is the first sentence of a long

message. This is the final sentence of this long discharge summary!|||||F||199707211325|

DSC||F

Message #2: --------------------------------------------------------------

Note: MSH-14 Continuation Pointer, is valued with the same value as in DSC-1, continuation pointer from the message this is continuing, in this case Message #1.

Note that no ADD segment is necessary, since a segment is not being split across two messages.

MSH|...|||

PR1|...

DG1|...

2.17.5 Acknowledgement message using original mode processing

This example shows the lab system using the Master Files specification to send two update test dictionary entries to an ICU system.

Initiating Message:

MSH|^~\&|LABxxx|ClinLAB|ICU||19910918060544||MFN^M03^MFN_M03|MSGID002|P|2.7

MFI|LABxxx^Lab Test Dictionary^L|UPD|||AL

MFE|MUP|199109051000|199110010000|12345^WBC^L

OM1|...

MFE|MUP|199109051015|199110010000|6789^RBC^L

OM1|...

Response Message: Original mode acknowledgment of the HL7 message according to MFI Response Level Code of AL.

MSH|^~\&|ICU||LABxxx|ClinLAB|19910918060545||MFK^M03^MFK_M01|MSGID99002|P|2.7

MSA|AA|MSGID002

MFI|LABxxx^Lab Test Dictionary^L|UPD|||MFAA

MFA|MUP|199110010000|199110010040|S|12345^WBC^L

MFA|MUP|199110010000|199110010041|S|6789^RBC^L

2.17.6 Acknowledgement message using enhanced mode processing

Initial message with accept acknowledgment

MSH|^~\&|LABxxx|ClinLAB|ICU||19910918060544||MFN^M03^MFN_M03|MSGID002|P|2.7|||AL|AL

MFI|LABxxx^Lab Test Dictionary^L||UPD|||AL

MFE|MUP|199109051000|199110010000|12345^WBC^L

OM1|...

MFE|MUP|199109051015|199110010000|6789^RBC^L

OM1|...

MSH|^~\&|ICU||LABxxx|ClinLAB|19910918060545||MSA|MSGID99002|P|2.7

MSA|CA|MSGID002

Application acknowledgment message

MSH|^~\&|ICU||LABxxx|ClinLAB|19911001080504|| MFK^M03^MFK_M01|MSGID5002|P|2.7|||AL|

MSA|AA|MSGID002

MFI|LABxxx^Lab Test Dictionary^L||UPD|||MFAA

MFA|MUP|199109051000|199110010040|S|12345^WBC^L

MFA|MUP|199109051015|199110010041|S|6789^RBC^L

MSH|^~\&|LABxxx|ClinLAB|ICU||19911001080507||ACK|MSGID444|P|2.7

MSA|CA|MSGID5002

2.18 OUTSTANDING ISSUES

The following items are being discussed in the Control/Query technical committee for addition to future versions of HL7:

  1. Rationalization and clarification of event structures.

  2. Reviewing network application management messages for possible upgrade requirements.

  3. Conformance Based Queries use of the Message Profiles. Current status of this can be found on the Conformance WG web site (http://www.hl7.org).

What is the use of IP ID field of IP header?

The IP Identification field (IPID) is used to re-associate fragmented packets (they will have the same IPID). The flags are used to determine if fragmentation is allowed, and whether more fragments are coming.

Which IP header field is responsible for re sending corrupted data?

UDP header and checksum It contains the source and destination ports, segment length and a checksum. The checksum is a simple error-detecting code that allows the UDP layer to check for segment corruption. If the received segment contains an error, it is dropped and not delivered to the socket.
A TCP segment header also contains the following fields: The32-bit sequence number field, and the 32-bit acknowledgment number field are used by the TCP sender and receiver in implementing a reliable data transfer service, as discussed below. The 16-bit window size field is used for the purposes of flow control.

Is a 16

Checksum: The checksum is a 16-bit field used in error detection. Urgent pointer: If URG flag is set to 1, then this 16-bit field is an offset from the sequence number indicating that it is a last urgent data byte.