Clovertech

Unexpected message truncation

› Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › Unexpected message truncation

  • Creator
    Topic
  • May 17, 2013 at 5:09 pm #53660
    Brian Lubkeman
    Participant

      I have a tcp/ip thread set up to receive result messages (ORU^R01) from our enterprise imaging software.  When a message is received from the source system and passes through the translate routine, the message is getting truncated. The MSH segment is mapped fully, but the PID segment maps only PID-1, PID-2, and part of PID-3. Nothing else gets mapped.

      I log the inbound messages.  When I take the logged message and resend it to the inbound thread, the message translates perfectly.  When I run the logged message through the testing tool, either for xlt or route, it works perfectly.

      I have rebuilt both the inbound thread and the translation from scratch.  Both the original and the rebuilt versions have this issue.  It sounds like something is missing in the message from the source system that is corrected when CL logs the message.  Does this sound familiar?  Any thoughts on what is needed to fix it?  None of our other numerous translations experience this.

      Brian Lubkeman
      Technical Analyst III - Integrations
      McFarland Clinic, Ames, Iowa

    • Creator
      Topic
    Viewing 1 reply thread
    • Author
      Replies
      • May 17, 2013 at 7:04 pm #78487
        Jim Kosloskey
        Participant

          Brian,

          Try any of these steps:

          – turn the EO config up so you can see the inbound message in the PDL before Cloverleaf gets it. You will see the message in hex. Check the hex values around where the truncation is occurring and make sure all looks OK.

          – Stop your cloverleaf thread then using hcitcptest frtom the command line act like the Cloverleaf thread using the -f switch to save off what is received or redirect stdin to a file.

           Then use either hcihd or hcihexdump to view the file of the message just received in hex (on unix I pipe that to less or more so I can search, scroll, etc.).

          I am guessing you might find a hex 00 where the truncation is occurring or some other unwanted value. In any case you will be able to validate the data you are reciving is or is not correct.

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

        • May 20, 2013 at 6:27 pm #78488
          Brian Lubkeman
          Participant

            Jim,

            Thank you for your reply.  I believe the vendor whose interface is creating the message has inverted their segment and message delimiters.  The message contains a newline character at the end of every segment and a carriage return at the end of every message.  If I understand the HL7 standard correctly, it should be the other way around.  Assuming this gets corrected the message should start working.

            Brian Lubkeman
            Technical Analyst III - Integrations
            McFarland Clinic, Ames, Iowa

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