5.8 mlp

Mike,

From the 5.8 Release notes:

TCP/IP MLP Support

– A new

This begs the question… Is it preferable to use the “Encoding” setting on TCP/IP or use the TCP/IP PDL and the MLLP.pdl?

James,

Do you know what happens when data arrives that does not conform to the desired “encapsulation” — does it appear in the process log, or is it simply discarded?

Mark,

That’s a good question.  I haven’t utilized (or experimented) with the new “encapsulation” option, so I can’t address how it handles incorrectly encapsulated messages.  If I get an opportunity, I might give it a shot.

Jim Cobane

Henry Ford Health

From Bill Evans deep down in the Cloverleaf development dungeons …

“Do you know what happens when data arrives that does not conform to the desired “encapsulation” — does it appear in the process log, or is it simply discarded?” It works like the PDL version and will dump all that is skipped if the EO is set to do so. There is a timeout that controls what happens after the start block appears but no end block shows up. The user may select what happens in this case. If no start block things go in the trash but may be written into the log with the right EO setting.

Why use the Tcp version instead of the PDL version? The Tcp driver in 5.8 is sub-threaded so it can receive messages while your Tps is waiting for that database to respond. Also the “scanner” (thing that looks for start/end) is twice as fast as the PDL version — few 100 microseconds but every one of them counts.)

Attend the talk “5.8 Nitty Gritty” at the user meeting for information on 5.8 changes. If your question is not answered it will be with maybe more details than you ever wanted. Answer can take minutes or days to appear but it shall appear — so says the speaker.

**Bill

What EO setting is required?  Hopefully it allows us to see a hexdump of data outside the message wrapper without seeing all the “normal” data inside the wrapper.

I’ve tested this and there is not an EO setting that will show only exceptions.

Per Mike’s request we have added this as an enhancement request for a future release.

In the meantime if you want the exceptions logged, you can continue to use PDL.

Here’s some more info from dev …

The hex dump is enabled with the Tcp EO alias set for debug as I remember. I always had a problem getting to right so … It should be the same as the EO required by the PDL version as it will show all data received. There is no way to just get the junk between messages in the Tcp version — one gets everything.

The difference between MLLP and MLLP2 can be obtained from reading the link

http://www.hl7.org/v3ballot/html/infrastructure/transport/transport-mllp.htm

There is a PDL for MLLP2 in 5.7 and later as was requested (and supplied) by a customer.

In general I would forget that MLLP2 exists as the standard has too many things that are not clearly defined when errors occur.

So reading about MLLP 2, my head started spinning and a bunch of questions came to mind.   😕

From a glance, will we need to modify PDLs to send out the new MLLP ACK/NAK, or still keep the TCL script for replies like that we have in place and just modify those scripts?

I guess what I really want to know is whether the new MLLP ACK/NAK replaces the traditional HL7 ACK/NAK, or whether the two are used in combination?

Thanks,

Bob

We just upgraded to 5.7 and are looking at using the MLP2 pdl for local connections to do the ack instead of a tps.  One less proc and less bandwith. It seems to work great but is there more to the mlp2 implemenation I need to be aware of?  It looks like it just adds two new phrases to define the ack and nak and that is all.  

Thanks,

John,

Just my thoughts here…

I don’t know much about mllp2 at this point but from what I understand I think tcp/ip length encoding would be more efficient for internal connections: vs 2 bytes vs 4 bytes plus just having to go the offset rahter than scan to the end. Perhaps the creation of the ack|nak is created in the PDL I don’t know but one proc hardly seems excessive.

Having said that, beginning with 5.8 there is no need for local threads for cross site communication.

Hi Jim,

  Yes, the ack/nak is created in the pdl.  I was playing with it in a test site ,only 4 bytes. So you no longer need a tps to send the ack just drop in the pdl.  From a conformity standard we want to stick with using the PDL tcp connections as that is what everyone is familiar with.  But cutting down the full HL7 ack to a one byte ack would still be substantial for us and one less step when setting up a local connection.  

  Yes, 5.8 is sounding really cool with that option and the threading option.  Goutham from Healthvision was just here helping us size our site for new hardware as HP is getting rid of PA-RISC and cloverleaf is not supporting Itanium at this point.  He was giving a lot of good info on 5.8.  Being we just moved from 5.2 to 5.7, going to 5.8 is not in the cards any time soon.  Which is a shame. 🙁

Hey guys, don’t get off on a tangent here.  MLLP2 is a different animal see this web site

 http://www.hl7.org/v3ballot/html/infrastructure/transport/transport-mllp.htm

Hey guys, don’t get off on a tangent here.  MLLP2 is a different animal see this web site

http://www.hl7.org/v3ballot/html/infrastructure/transport/transport-mllp.htm

Charlie, that’s what prompted my question.  It seems to me that the one byte ACK/NAK is going to be in addition to the HL7 ACK MSH|…MSA|AA…  Did I read that right?

Robert and Charlie,

  Goutham actually pointed me to the mllp2 pdl.  At least the way we were wanting to use it, for local connections. The client side was still staying as a standard mllp pdl.  Just using the MLLP 2 pdl as a cheap way of setting of the server connection so we don’t have to write a new reply tps for local connections.

  Robert, you are correct, the documentation really is confusing on whether or not you still need a standard HL7 Ack/nak also,

  Charlie, this is why I joined the conversation.  It appears you and Goutham have differing opinions about using the mllp2 pdl. Can you two put your brilliant heads together can give us some guidelines on when we should use the new pdl over the existing ones?

Thanks,

Since MLLP2 is a different animal and still not in general use that I know of, if it were me, I would not use it.

However, if you feel you can manipulate it and it works for what you are doing, go for it.

I went live on CL5.8R2 on RHEL 5.3 Tuesday, Jan 18th.  As part of testing, I converted all of my threads to the new built-in encapsulated TCPIP protocol.

I already knew during testing that the threads were sluggish responding to commands such as pstart and pstop.  I use scripts to start and stop processes and threads.  However, we have about 20 outbound threads over VPN and the release notes state that the new protocol would handle the looping issue on VPN threads.  Sooooooooooo, I went with them.

I was pleased with the go-live through Tuesday but by Wednesday morning, I was starting to get concerned.  I email error logs nightly and Wednesday morning’s email was over 2MB – much of it “Can’t connects” which were expected – but there were a huge number of timeouts on threads – lots of them even on threads where I was connecting to another thread on the same server to ‘hop across’ processes.  I had threads that process 18,000 lab result messages/day (I know, not a big number) falling behind, writing partial messages and causing timeouts.  I had inbound threads not acking the sending systems in a timely manner.

The last straw came in the form of a phone call in the wee hours Thursday.  No lab results to our EHR in over four hours.  I logged in and everything was a mess.  I even had queues stacked up in the routes in net monitor – something I’d NEVER seen in over 12 years.  Over the course of a couple hours of looking at traces, I narrowed it down to a pair of connections to one server – somehow, these two threads had everything else ‘locked up’ for lack of a better term.  I killed the listeners on that server and bang – everything caught right up.

I spent the next couple hours converting all of my threads back to the mlp_tcp pdl and CL5.8 is now running like a charm again.  No timeouts, no backed up threads – and the threads respond to commands almost instantly.  I will go back to stopping/starting my VPN threads every half an hour to mitigate the looping logging problem – it’s a small price to pay for having a system that runs smoothly.

I will say this though – when I use a client and server pair to hop from one process to another, the server thread has to be up first or the client thread will never connect.  In CL5.5 and prior versions, it didn’t matter what order you brought them up in.

Just something to be aware of.

PS: I’m in no way bashing the product.  CL has been rock solid for as long as I’ve used it and I expect it will continue to be.

Anyone else is using built-in encapsulated TCP/IP protocol? If so, are you seeing any issues?

I just had to go back to using “old” pdl-tcpip with mlp_tcp.pdl after troubleshooting an inbound connection. During the troubleshooting I discovered (using tcpdump) that HL7 ACK messages, generated by the engine, did not have start block and end block bytes. As far as I know only one connection was affected (and we are trying this out in our test sites) and a few others that I had built using new thread templates (with built-in encapsulated TCP/IP protocol) are working OK.