Clovertech

IMPAC and 1460 characters

› Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › IMPAC and 1460 characters

  • Creator
    Topic
  • August 18, 2005 at 7:37 pm #47979
    Keith McLeod
    Participant

      We have been sending ADT messages to IMPAC for years.  The issue that was brought to my attention is that in the tcp log for IMPAC it reads in teh message from cloverleaf to approximately 1460 characters.  It then reads in more of the message usually to the end. Say 1600 characters.  The first portion is all that is processed up to the 1460 characters usually through the 2nd iteration of the IN1 segment.  The remaining portion of the message is invalid without an MSH segment and ignored by IMPAC.  This appears to be an issue at the tcp level.  IMPAC says that I need to fix it on the engine.  I don’t believe them.   Has anyone else faced this issue?  What did you do to fix it?

      I am on AIX 5.1 Cloverleaf 3.8.1P rev 4.

    • Creator
      Topic
    Viewing 4 reply threads
    • Author
      Replies
      • August 18, 2005 at 8:37 pm #57215
        Kevin Scantlan
        Participant

          It sounds like the engine thinks it’s 2 messages.  I would look for end-of-message characters in the message that they send.  In order to do that, I would turn on “enable all” for the process of the inbound thread.  You then can look at the inbound message (hexadecimal on the right side of the message in the log) as your protocol driver sees it.

          Just a suggestion.

        • August 18, 2005 at 9:03 pm #57216
          Tim Gobbel
          Participant

            We have been seeing a similar problem with Quaramed’s EDM product.  In our case, their interface thinks it is getting a partial message and won’t ACK until it gets the whole thing.  These are always 1458 characters which is the usual packet size for a system set up to send 1500 as the max size minus some encoding characters.  It doesn’t happen on all 1458 message and when i bounce their side, the same message that wouldn’t go thru now goes thru without a problem. We looked for EOF characters, extra ^M etc and found nothing which accounts for why they go thru once the connection on their side is bounced.  They have tried a few things but no success.  The last I heard, they were looking into a malformed .exe file.  I hope they find it soon!  if we do, I’ll try to let you know to see if it may be an avenue for you to pursue.

          • August 19, 2005 at 10:51 am #57217
            Keith McLeod
            Participant

              I am using the mlp pdl driver.  I send this to 6 other systems.  The save message database has the entire message. It is as though they are not reassembling the packets on their interface PC before they are getting processed.  The wrapper is there at the beginning of the first part of the message and at the end of the second part of the message according to there logs.

              I am going to look at another hospital to see if they are getting the same result for their impac system and just don’t know it…..

            • August 19, 2005 at 12:50 pm #57218
              Rob Abbott
              Keymaster

                I’m sure everyone is aware that the TCP/IP will break a message into packets sometimes as it crosses the network.  Some systems think they can get the whole message in one read, this is not the case, they need to keep reading data until they see the end-of-message character.

                Having said that, Cloverleaf will sometimes write a message in chunks for performance reasons, especially if the message has been translated, each field stored will be a “chunk”.  One way to reform the message object into a single chunk is to do the following in a pre-write or outbound TPS:

                msgset [msgget $mh]

                This will reform the message object into a single chunk before it goes to the protocol driver.

                Most of you mentioned packets of ~1500 bytes so I doubt that this is going on and it’s TCP that’s breaking up the message into packets, but it’s worth a try.

                You can also crank up PDL EO to see what packets are being written by the driver.

                Hope this information helps.

                PS. If you’re interested in looking at how message objects are broken up, play with the msgstats command:

                Code:

                tcl>set mh [msgcreate abc]
                tcl>msgstats $mh
                {NUMBUFS 1} {NUMCHUNKS 1} {TOTALSPACE 236} {WASTESPACE 64}
                tcl>msgappend $mh def
                tcl>msgstats $mh
                {NUMBUFS 1} {NUMCHUNKS 1} {TOTALSPACE 236} {WASTESPACE 68}
                tcl>msginsert $mh 123 3
                tcl>msgstats $mh
                {NUMBUFS 1} {NUMCHUNKS 3} {TOTALSPACE 236} {WASTESPACE 120}


                The above message would be written out in 3 packets (NUMCHUNKS = 3)

                Rob Abbott
                Cloverleaf Emeritus

              • October 3, 2005 at 4:31 pm #57219
                Tim Gobbel
                Participant

                  We just upgraded the Quadramed (Quantim) HL7 interface to their 5.2 version.  This includes a new .exe file and it seems to be holding up for now.  if it goes sour, i’ll attach to thia again.  Thanx!

              • Author
                Replies
              Viewing 4 reply threads
              • The forum ‘Cloverleaf’ is closed to new topics and replies.