Reply To: Not processing ACK

[Greg Eriksen]

Not sure if that was just an unintentional transposition in the last post, but I would have expected the last 3 characters to be:  0D 1C 0D

Someone I work with here was having the same type of argument with a new vendor who wasn’t supplying the proper MLLP envelope.  I just copied the following section (C-23 of Appendix C) out of the HL7 Implementation Guide and suggested she send it to them, asking “why are they claiming to be HL7 compliant if they’re not willing to do this?”:

Quote:

MINIMAL LOWER LAYER PROTOCOL

C.4.2 Block Format

HL7 messages are enclosed by special characters to form a block. The format is as follows:

dddd

= Start Block character (1 byte)  ASCII , i.e., <0x0B>. This should not be confused with the ASCII characters SOH or STX.

dddd = Data (variable number of bytes)  This is the HL7 data content of the block. The data can contain any displayable ASCII characters and the carriage return character, .

= End Block character (1 byte) ASCII , i.e., <0x1C>. This should not be confused with the ASCII characters ETX or EOT.

= Carriage Return (1 byte)  The ASCII carriage return character, i.e., <0x0D>.