Announcement

Collapse
No announcement yet.

Initial message sent not received

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

  • Initial message sent not received

    ----------------------------------
    Environment: Windows 2000 Server w/SP4, Mirth v1.1, Java Version 1.5.0 (build 1.5.0_08-b03)
    ----------------------------------

    Initial message sent is not being received by Mirth. Subsequent messages are received.

    Steps Followed:

    Setup channel to receive messages from LLP Listener
    Send an HL7 message from the host system
    Mirth Administrator does not show any received messages
    Send the same HL7 message again from the host system
    Mirth Administrator shows received 1 and Sent 1

    -NS

  • #2
    Re: Initial message sent not received

    Which host system is sending the messages? Are there any errors in the host system's log?

    Are you sure that Mirth has had sufficient time to fully deploy and start the listener before the first message was sent?
    Chris Lang

    Comment


    • #3
      Re: Initial message sent not received

      Host System Application: GE Centricity Practice Manager 2004
      Host HL7 Module: Millbrook Itegration Kit (MIK)

      Host HL7 Log: No errors. Status message shows message was sent successfully.

      Log details
      ==================

      1. This is the log of the first message which was not received by Mirth.

      09/14/2006 10:32:51 +Send #=0, id=748, data=562, type=HL7 2.3^ADT^A04
      09/14/2006 10:32:52 ++Send done No Ack Requested, status=MIK_OKNOACK, msg=71C6D91B-9DBD-441b-8A21-44B3208CC492, dest=MirthHL7Test

      ==================
      2. The same message was sent second time which was received by Mirth.

      09/14/2006 10:33:48 +Send #=0, id=749, data=562, type=HL7 2.3^ADT^A04
      09/14/2006 10:33:48 ++Send done No Ack Requested, status=MIK_OKNOACK, msg=F9DDE139-6B1A-4483-9047-DC7E5DF32DE4, dest=MirthHL7Test
      ==================

      As regards giving sufficient time for Mirth to start before sending message,

      The DOS command windows shows:
      INFO com.webreach.mirth.server.Mirth: starting mirth server...
      Mirth 1.1.0 (August 28, 2006) server successfully started: Thu Sep 14 09:56:08 E
      DT 2006
      Running Java 1.5.0_08 on Windows 2000 (5.0, x86)

      Mitrh Administrator shows: Status -> Started, Received -> 0, Sent -> 0

      Comment


      • #4
        Re: Initial message sent not received

        Is there a way to turn on ACKs on the Millbrook system?
        Chris Lang

        Comment


        • #5
          Re: Initial message sent not received

          Chris,

          Thank you very much for the feedback.

          When I turn the ACK ON both sides I did get the initial message (Checked "Request Acknowledgement" on the Centricity Millbrook HL7 host and Set "Send Ack" to YES on Mirth HL7).

          Looks like the problem was that the host system was set to NO ACK but Mirth HL7 was set to SEND ACK. This was not intended but when I created a new channel I missed to change "Send ACK" drop-down to NO. This kind of setup was causing Mirth to miss the initial message.

          Thanks again for the quick reply.
          -NS

          Comment


          • #6
            Re: Initial message sent not received

            Excellent, glad it is working now and glad to know what the issue was! I'll add this to our FAQ asap.

            -Chris
            Chris Lang

            Comment


            • #7
              Re: Initial message sent not received

              I was having some trouble with an LLP reciever and saw this thread.

              We use Millbrook at my office as well and my supervisor made me aware of an issue with the MIK (Millbrook Integration Kit). When you set it to recieve ACKs it doesn't listen for ACKs on the same port that it sends the messages to. It listens for ACKs on its general recieving port. I'm told that everyone makes a funny face when they're told that the MIK does this and it isnt standard anywhere else.

              For example our testing MIK is set up to send messages to Mirth on 6661 and another system on 4584. The MIK is set to listen for messages on 4001. The way Mirth (and most other HL7 parsers work) is that if it recieves a message on 6661 it will try to send the ACK back to 6661.

              A good way to keep tabs on this and see where messages are getting lost is to use WireShark (formerly Ethereal) and just watch for traffic to and from the MIK and Mirth paying particular attention to port numbers.
              Jon Bartels

              Zen is hiring!!!!
              http://consultzen.com/careers/
              Talented healthcare IT professionals wanted. Engineers to sales to management.
              Good benefits, great working environment, genuinely interesting work.

              Comment


              • #8
                Re: Initial message sent not received

                Very interesting - thank you for the heads up!

                Do you think it would make sense to give Mirth the ability to send ACKs back to a different server?

                -Chris
                Chris Lang

                Comment


                • #9
                  Re: Initial message sent not received

                  Actually, now that I think about it, you can do this with Mirth:

                  1) Setup LLP listener Router
                  2) Set Send Acks to "NO"
                  3) The first destination should be the "actual" destination of the channel
                  4) The second destination should be an LLP sender with the address set to the originating system
                  5) On the transformer for the second destination, use the ACKGenerator to build an ack from the Message's Raw Data

                  -Chris
                  Chris Lang

                  Comment


                  • #10
                    Re: Initial message sent not received

                    I'm still new to the medical software industry, so I cannot say for sure if this is important enough to warrant a new feature. From what I've been told by my boss the MIK is a very rare case in the way it handles ACKs and there were some things said that makes me think even when it does get them that it does some wierd things with them.

                    I'll make some time today and add some of this to the Wiki with the right keywords so someone working with Millbrook (AKA GE Centricity) will be able to find it.

                    A little further down the line I'll create a channel to send ACKs to the MIK and post that with the code snippets.

                    nshaik - Any comments on this? Did I miss anything?

                    Jon Bartels

                    Zen is hiring!!!!
                    http://consultzen.com/careers/
                    Talented healthcare IT professionals wanted. Engineers to sales to management.
                    Good benefits, great working environment, genuinely interesting work.

                    Comment


                    • #11
                      Re: Initial message sent not received

                      jbartels,

                      Refer to the request for "Custom ACK codes" in Issue Tracker.

                      http://www.mirthproject.org/communit...owse/MIRTH-222

                      I believe this has been implemented in 1.3.2 but I didn't get a chance yet to test this version.

                      ===========================

                      1. In the link above I have explained why we need custom ACK code. The ACK format expected by Millbrook (GE Centricity) is different from what the Mirth is sending back.

                      So, if we manage to send ACK back to Millbrook, we need to make sure it is in the format MIK expects.

                      ===========================

                      2. I was planning on sending in an enhancement request to the Mirth team to facilitate accepting:

                      * IP Address and Port Number of the machine where the ACK should be sent back

                      With this functionality and custom ACK codes, we should be able get Millbrook recognize the ACK from Mirth HL7.

                      ===========================

                      3. MIK may be the only HL7 system which expects ACK back on different port, but there are quite a few Millbrook EMR (GE Centricity) installations out there. They may be interested in using / switching to Mirth HL7 and processing ACK the way Millbrook expects would be of great help.

                      ==========================
                      NOTE: I have tried Mirth 1.1, 1.2, 1.3.1 (didn't test 1.3) with Millbrook. It works fine when the message are sent in as files. Not a single message was missed.

                      But with LLP setup it just did not work as expected. I even tried sending messages with a delay but I was not getting all the messages sent by the MIK host. For this reason, we decided to setup the channel as "File Reader to Database" for getting INBOUND messages from Millbrook.

                      We'll continue to test LLP channel with newer versions of Mirth and will post our results back.
                      ==========================

                      Thanks

                      Comment


                      • #12
                        Re: Initial message sent not received

                        Thanks for the details - I believe the issue with not receiving all of the messages is due to the ACKs. With the custom ACKs, Mirth now sends back the proper codes expected by MIK as the default. (AA rather than CA, etc).

                        Because the MIK issue with sending on a different port is such a specific case (although widespread in terms of distribution), we will not add it as a feature in the GA release, however we will develop a channel and post to the repository that handles sending ACKs back on a seperate channel. We have an "ACKGenerator" function that we will expose in the JS transformer that will generate a valid ACK based on an incoming message.

                        -Chris
                        Chris Lang

                        Comment

                        Working...
                        X