Announcement

Collapse
No announcement yet.

tcp listener issue - <FS><CR> not detected

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • tcp listener issue - <FS><CR> not detected

    Hello, I am working on an issue where we have a tcp listener set up to receive ORU messages from a vendor. These are on the longer side, since they are transcribed documents, but not overly so. I'm seeing an issue where some messages keep getting rejected by mirth with "End of message bytes (<FS><CR>) not detected."

    Well I've done a capture, and I can see that this document makes up about 7 packets worth of information, but Mirth is sending an RST packet after the 6th packet, the 7th having the 1c 0d at the end of it to close the message.

    This isn't all messages, just some of them, but enough that it has become a problem. I'm kind of on the fence regarding whether this is a vendor issue, or some type of networking problem.

    Mirth settings:
    Version: 3.2.2.7694
    Set Data Types: HL7 v2.x
    Source Queue On, Auto Generate Response
    Receive Timeout 0 - I have attempted to adjust this but it hasn't had an effect.
    Keep Connection Open = Yes
    Data Type: Text
    Encoding: Default


    I don't want to include the full capture since PHI could be gotten from it, but I might be able to include some screenshots of parts of it. Has anyone had a similar issue? Thank you,

  • #2
    Added screenshots in a doc file.
    Attached Files

    Comment


    • #3
      What does the end of packet 14 look like?

      Comment


      • #4
        Originally posted by agermano View Post
        What does the end of packet 14 look like?
        I've attached that one as well. It doesn't really seem different than the end of packet 12 to me, but I haven't read through many captures before.
        Attached Files

        Comment


        • #5
          I am not sure if this is related to differences between versions but here is what I've found:

          Sending Vendor is using Mirth 3.8.0

          Receiving Vendor is using Mirth 3.2.2

          After much trial and error, adjusting the channels in both systems to use MLLP V2 seems to work.

          Comment

          Working...
          X