Not processing ACK

[William Grow]

Hi,

 A problem with a new system going in has developed.  At first, it didn’t appear that the vendor was sending an acknowledgement.  The vendor sent me an email with the logged acknowledgement as an attachment.  I turned up engine output with the enable_all config and reprocessed the message.  Here is what I see for the ACK.  It doesn’t appear the the ACK is including the standard HL7 end of message character x0d.  Because I have never run into this before I wanted to see if anyone had run across this problem out in the field and how they got around it if the vendor will not change the system.

pdl :PDL :DBUG/0:   d_obix_hin] input buffer accepted 81 bytes, now 81

[pdl :PDL :DBUG/0:   d_obix_hin]  0b 4d 53 48  7c 5e 7e 5c  |.MSH|^~|

[pdl :PDL :DBUG/0:   d_obix_hin]  26 7c 4f 42  49 58 4d 57  |&|OBIXMW|

[pdl :PDL :DBUG/0:   d_obix_hin]  52 7c 30 30  32 7c 7c 30  |R|002||0|

[pdl :PDL :DBUG/0:   d_obix_hin]  30 32 7c 32  30 30 36 30  |02|20060|

[pdl :PDL :DBUG/0:   d_obix_hin]  32 31 34 31  36 30 38 34  |21416084|

[pdl :PDL :DBUG/0:   d_obix_hin]  36 7c 7c 41  43 4b 5e 41  |6||ACK^A|

[pdl :PDL :DBUG/0:   d_obix_hin]  30 31 5e 41  43 4b 7c 31  |01^ACK|1|

[pdl :PDL :DBUG/0:   d_obix_hin]  34 38 35 35  7c 50 7c 32  |4855|P|2|

[pdl :PDL :DBUG/0:   d_obix_hin]  2e 32 0d 4d  53 41 7c 41  |.2.MSA|A|

[pdl :PDL :DBUG/0:   d_obix_hin]  41 7c 31 34  38 35 35 0d  |A|14855.|

[pdl :PDL :DBUG/0:   d_obix_hin]  1c                        |.|

Topic

[Jim Kosloskey]

Bill,

I think you are correct, I think the last three characters should be 0D 0D 1C.

In any case, they should match what the ending characters are the PDL is sending out.

I am assuming the vendor documents support of and requirement of the HL/7 MLP encapsulation technique. If that is the case then there is no question that if the vendor is not complying the vendor must change – in my opinion.

Whenever I encounter the situation where the vendor is in non-compliance with their own specification and the individual with I am dealing from the vendor is unwilling to accept a change is necessary, I either escalate the issue within the vendor’s chain of command or within my organization’s chain of command until the vendor corrects the situation. As far as I am concerned no other option is acceptable but compliance.

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[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>.

[Jim Kosloskey]

Oops, good catch Greg.

Thanks,

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[William Grow]

Thanks to both of you.  I sent the vendor an email and they are going to load a code patch. Having never had to write the code for an outbound or inbound interface, I don’t know how this can be missed by the engineers.

[Chris Williams]

Hi guys,

I may be off base here, but in my world the Carriage Return <0x0d> is the SEGMENT terminator. The MESSAGE is terminated with a Linefeed <0x0a>. Then you have the <0x1c><0x0d> to wrap up the envelope. I would have expected your data sample to end with <0x0d><0x0a><0x1c><0x0d>. Am I missing something?

Cheers.

[Author]

Replies