LLP Listener not processing messages (GE MIK)

[jbartels]

We just moved some software from one machine to another and I needed to get Mirth set up to recieve messages from the new box.

The sender is Millbrook and it is sending ADT^A08 messages to Mirth. According to the Millbrook logs and from a packet sniff, the messages are making it to the machine running Mirth. Mirth is not showing any recieved messages.

I am running Mirth 1.3.2 on WinXP using the LLP to File Writer channel from the file repository. I turned ACKs off but the sample channel is otherwise unmodified. I have added a rule to the Windows firewall to allow TCP traffic on port 6661 from the local network. Both Mirth and MIK are set to use the same seperators and end of message characters.

I'm sure that I'm missing something simple, but I can't put my finger on it. Any ideas?

[nshaik]

Re: LLP Listener not processing messages

I have seen similar problems on Windows XP box (but not on Window Server 2000) and when things like that happen this is what I do:

1. Stop Mirth / Disable Channel / Deploy / Close Mirth Administrator / Shutdown Mirth

2. Open Java from Control Panel / Clear Temporary Internet Files

3. Start Mirth / Open Mirth Administrator

4. Enable Channel / Deploy

5. Send a bunch of messages from MIK

and most of the time the above steps helped resolve the problem.

Hope it helps!

[albertosaez]

Re: LLP Listener not processing messages


I've realized than with Mirth 1.3.2, it takses a long time, to show the Messages (sometimes 40-70 seconds!!)

[chrisl]

Re: LLP Listener not processing messages

Try turning on debug logging (modify log4j.properties and change "ERROR" at the top to "DEBUG"). Restart Mirth and pump messages to it from Millbrook - do you see anything there in the logs?

If that doesn't solve it then I'd like to setup a test with either or both of you at some point - with Millbrook sending messages to one of our development machines in debug mode. Is it possible to point Millbrook to a public IP address? Please shoot me an email (chrisl [at] webreachinc.com) so that we can discuss the details.

-Chris

[chrisl]

Re: LLP Listener not processing messages

To speed up the display of messages, change the status refresh time in the Administrator panel. I usually set it to 2 seconds if my message volume is low.

[jbartels]

Re: LLP Listener not processing messages

Oh man this keeps getting wierder.

I followed nshaiks directions and Mirth got the messages it was supposed to and started throwing IOExceptionst. I fixed that, the MIK has to be explicitly told to put a line break after the HL7 messages (end segment 0x0C 0x0D).

Now what I'm seeing is that the MIK is sending 50 messages (ADT^A08s) and Mirth is getting 30-40. Here is what the packet sniffer showed me in one packet:

0000  00 02 e3 4b 19 d2 00 16  9d 50 51 c3 08 00 45 00   ...K.... .PQ...E.
0010  03 12 3b 1a 40 00 7e 06  c3 56 ac 19 97 0d ac 19   ..;.@.~. .V......
0020  0c 35 0f 69 1a 05 05 5c  0d 4a d6 aa 37 d9 50 18   .5.i...\ .J..7.P.
0030  fa f0 72 55 00 00 0b 4d  53 48 7c 5e 7e 5c 26 7c   ..rU...M SH|^~\&|
0040  4d 49 4b 2d 41 49 47 5e  4d 49 4b 2d 41 49 47 5e   MIK-AIG^ MIK-AIG^
0050  47 55 49 44 7c 7c 74 72  69 53 54 52 55 43 54 5e   GUID||tr iSTRUCT^
0060  74 72 69 53 54 52 55 43  54 5e 47 55 49 44 7c 7c   triSTRUC T^GUID||
0070  32 30 30 37 30 31 30 35  32 31 32 34 31 34 7c 7c   20070105 212414||
0080  41 44 54 5e 41 30 38 7c  32 39 45 41 36 41 32 44   ADT^A08| 29EA6A2D
0090  2d 32 39 41 37 2d 34 31  62 39 2d 42 35 39 46 2d   -29A7-41 b9-B59F-
00a0  44 33 36 38 43 39 31 36  45 30 35 39 7c 50 7c 32   D368C916 E059|P|2
00b0  2e 33 7c 7c 7c 7c 4e 45  0d 45 56 4e 7c 41 30 38   .3||||NE .EVN|A08
00c0  7c 32 30 30 37 30 31 30  35 31 36 32 34 31 34 7c   |2007010 5162414|
00d0  7c 30 31 0d 50 49 44 7c  31 7c 35 31 7c 7c 7c 53   |01.PID| 1|51|||S
00e0  6d 69 74 68 5e 42 61 62  79 5e 42 7c 7c 32 30 30   mith^Bab y^B||200
00f0  36 30 31 30 31 30 30 30  30 30 30 7c 4d 7c 7c 7c   60101000 000|M|||
0100  31 32 33 20 4d 61 69 6e  20 53 74 72 65 65 74 5e   123 Main  Street^
0110  5e 46 6f 72 74 20 57 61  79 6e 65 5e 49 4e 5e 34   ^Fort Wa yne^IN^4
0120  36 38 32 35 7c 7c 28 32  36 30 29 5e 5e 5e 5e 5e   6825||(2 60)^^^^^
0130  32 36 30 7c 7c 7c 7c 7c  7c 31 32 33 2d 34 35 2d   260||||| |123-45-
0140  36 35 34 32 7c 7c 7c 7c  7c 7c 7c 7c 7c 7c 7c 4e   6542|||| |||||||N
0150  0d 50 56 31 7c 31 7c 4f  7c 5e 5e 5e 34 38 5e 5e   .PV1|1|O |^^^48^^
0160  5e 5e 5e 53 6f 75 74 6c  61 6b 65 20 50 65 64 69   ^^^Soutl ake Pedi
0170  61 74 72 69 63 73 7c 7c  7c 7c 34 37 5e 50 65 64   atrics|| ||47^Ped
0180  69 61 74 72 69 63 69 61  6e 5e 57 61 6c 74 65 72   iatricia n^Walter
0190  5e 45 5e 5e 5e 5e 5e 26  26 55 50 49 4e 7c 7c 7c   ^E^^^^^& &UPIN|||
********************LOOK HERE**************
01a0  7c 7c 7c 7c 7c 7c 7c 7c  7c 7c 0d 1c 0d 00 0b 4d   |||||||| ||.....M  
01b0  53 48 7c 5e 7e 5c 26 7c  4d 49 4b 2d 41 49 47 5e   SH|^~\&| MIK-AIG^
********************LOOK HERE**************
01c0  4d 49 4b 2d 41 49 47 5e  47 55 49 44 7c 7c 74 72   MIK-AIG^ GUID||tr
01d0  69 53 54 52 55 43 54 5e  74 72 69 53 54 52 55 43   iSTRUCT^ triSTRUC
01e0  54 5e 47 55 49 44 7c 7c  32 30 30 37 30 31 30 35   T^GUID|| 20070105
01f0  32 31 32 34 31 34 7c 7c  41 44 54 5e 41 30 38 7c   212414|| ADT^A08|
0200  41 37 30 41 34 36 37 37  2d 33 39 32 44 2d 34 64   A70A4677 -392D-4d
0210  65 34 2d 42 46 34 43 2d  39 37 36 37 43 32 42 38   e4-BF4C- 9767C2B8
0220  43 36 37 33 7c 50 7c 32  2e 33 7c 7c 7c 7c 4e 45   C673|P|2 .3||||NE
0230  0d 45 56 4e 7c 41 30 38  7c 32 30 30 37 30 31 30   .EVN|A08 |2007010
0240  35 31 36 32 34 31 34 7c  7c 30 31 0d 50 49 44 7c   5162414| |01.PID|
0250  31 7c 35 32 7c 7c 7c 41  6d 6f 73 5e 42 61 62 79   1|52|||A mos^Baby
0260  5e 47 7c 7c 32 30 30 36  30 32 30 31 30 30 30 30   ^G||2006 02010000
0270  30 30 7c 46 7c 7c 7c 31  33 33 30 20 4d 65 64 69   00|F|||1 330 Medi
0280  63 61 6c 20 50 61 72 6b  20 44 72 69 76 65 5e 5e   cal Park  Drive^^
0290  46 6f 72 74 20 57 61 79  6e 65 5e 49 4e 5e 34 36   Fort Way ne^IN^46
02a0  38 32 35 7c 7c 28 32 36  30 29 5e 5e 5e 5e 5e 32   825||(26 0)^^^^^2
02b0  36 30 7c 7c 7c 7c 7c 7c  31 32 33 2d 34 35 2d 36   60|||||| 123-45-6
02c0  38 38 38 7c 7c 7c 7c 7c  7c 7c 7c 7c 7c 7c 4e 0d   888||||| ||||||N.
02d0  50 56 31 7c 31 7c 4f 7c  5e 5e 5e 34 38 5e 5e 5e   PV1|1|O| ^^^48^^^
02e0  5e 5e 53 6f 75 74 6c 61  6b 65 20 50 65 64 69 61   ^^Soutla ke Pedia
02f0  74 72 69 63 73 7c 7c 7c  7c 34 37 5e 50 65 64 69   trics||| |47^Pedi
0300  61 74 72 69 63 69 61 6e  5e 57 61 6c 74 65 72 5e   atrician ^Walter^
0310  45 5e 5e 5e 5e 5e 26 26  55 50 49 4e 0d 1c 0d 00   E^^^^^&& UPIN....

There are TWO HL7 messages in ONE TCP packet. Now one of two things needs to happen. I need to get Mirth to split the packet or I need to get the MIK to not combine things like that.

Chris - email me directly about getting our test MIK to send some messages to you. [email protected]

[chrisl]

Re: LLP Listener not processing messages

Interestingly enough, Mirth can handle multiple HL7 messages in a single TCP payload, however it ACKs each one separately. I'll shoot you an email so we can figure out exactly what is happening.

-Chris

[chrisl]

Re: LLP Listener not processing messages

I spoke too soon - the two messages in one packet is the exact problem. Mirth is designed to take several messages in a single payload/connection, however the actual code stop receiving data from the sending system after the first message was validated.

We've implemented a fix for this and I believe it is a serious enough issue to warrant a 1.3.3 build. At the very least I'll do a private build and make it available to anyone that needs it before the official 1.3.3 release.

Thanks!
-Chris

[albertosaez]

Re: LLP Listener not processing messages

Hi.

I think I've detected a problem in the MLLP used by Millbrook.

According to MLLP protocol this is how messages should be sent at wire-level (C-4, Appendix C [http://www.hl7.org/Special/IG/final.pdf] pgs 306-308),

<SB>HL7_MESSAGE1<EB><CR><SB>HL7_MESSAGE2<EB><CR><SB>HL7_MESSAGE3<EB><CR>

(SB=0x0b, EB=0x1c, CR=0x0D)

But, the sniffer&#039;s output shows an extra null byte (0x00) before the <SB> code of the new message.

01a0  7c 7c 7c 7c 7c 7c 7c 7c  7c 7c 0d 1c 0d  *00* 0b 4d   |||||||| ||.....M

When Mirth can&#039;t find the <SB> code, it reads the full socket and launch an IOException with the text "Message violates the minimal lower layer protocol: no start of message indicator received"

I this the IOException you&#039;ve detected? If it&#039;s, it would be easy to change LlpProtocol.java to change the behaviour.

[chrisl]

Re: LLP Listener not processing messages

The other issue is that Mirth stops reading from the socket when it gets the first end of message. This needs to be updated as well.

-Chris

[jbartels]

Re: LLP Listener not processing messages

Ergh. I had a really detailed post with some more info and my browser crashed. Heres the short version:

albertosaez - The IOExceptions I got were from the end of message (0x1c) not being followed by a CR (0x0d). After that I received no exceptions from the 2-in-1 messages.

all - It appears that the MIK violates spec by not adding the <CR> unless configured to and that it violates the spec by adding the NULL before messages. The MIK and Mirth can be configured to cope with this.

Mirth is violating the standard by not processing two messages within one low level message.

I will make a wiki entry with the findings of this thread later this week. If you are a GE VAR you can monitor this issue via secure.millbrook.com. Go to the Case Management area and look for case #207528 . I have informed GE of the findings here and will post updates here or to the wiki if GE comes back with anything useful.

[chrisl]

Re: LLP Listener not processing messages

This will all be solved in 1.3.2.1.

[jbartels]

Re: LLP Listener not processing messages (GE MIK)

A tech from GE called me back on Friday (at 4:55PM ) and poked around with a few things.

Changing the end sequence from ?\x1c\x0d? to ?\x1c \x0d? seems to force the MIK into sending one HL7 message per TCP packet. I need to test that a bit more to make sure thats what it really does. If it does Mirth will need to look for 0x1c 0x20 as the end of message sequence.

Furthermore my fears about the quality of the software and its documentation were confirmed. GE has released all of their MIK documentation to the public, both pages of it. The techs rely on experience and trial-and-error to sort out the MIK. The tech (Jason) was capable and knew his stuff though, props to him.

[Jack]

Re: LLP Listener not processing messages (GE MIK)

I know this is a dated thread but I have some experience with receiving messages from Millbrook. The "00" at the end of your example completely hosed a PACS interface I was working on. What it did to us is create a TCP zero window condition and the interface would hang until manually reset. GE doesn&#039;t seem motivated to fix it. We noticed that we have about two days of window before the interface hangs. So our work around is to run a cron job every night to restart the interface.

Jack

[jbartels]

Re: LLP Listener not processing messages (GE MIK)

Jack,

I hate that people have to use outdated software like that, but it does make me feel a little better that other people are having issues with it. My employer is a GE VAR and doing what I can to explore alternatives to the MIK and get people thinking about it.

Are you recieving the full range of MIK messages? Can you spot any particular reason or condition that it comes every 2 days?