Clovertech

Not processing ACK

› Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › Not processing ACK

  • Creator
    Topic
  • February 14, 2006 at 10:50 pm #48319
    William Grow
    Participant

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

    • Creator
      Topic
    Viewing 4 reply threads
    • Author
      Replies
      • February 15, 2006 at 2:17 pm #58317
        Jim Kosloskey
        Participant

          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.

        • February 16, 2006 at 1:07 pm #58318
          Greg Eriksen
          Participant

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

          • February 16, 2006 at 1:42 pm #58319
            Jim Kosloskey
            Participant

              Oops, good catch Greg.

              Thanks,

              Jim Kosloskey

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

            • February 16, 2006 at 2:43 pm #58320
              William Grow
              Participant

                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.

              • February 16, 2006 at 9:47 pm #58321
                Chris Williams
                Participant

                  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
              Viewing 4 reply threads
              • The forum ‘Cloverleaf’ is closed to new topics and replies.