Eclipsys Sunrise non-Standard ACKs – How to Handle?

It has been two jobs ago and about two years.

I know we just threw away their acks they are a low level kind of thing just saying that they got a packet.

The other I can’t recall exactly. I have asked the people I know who are still at that location. But I’m not get a response.  

But if memory servers me correctly.  I just copied like the RAW_HL7 ack proc renamed it and replaced the MSH…..  stuff with a simple hex 06.

Let me start by saying that I have never worked on SCM before, however, I have worked with other systems that work this way.

I smell a skunk in the woodpile. Here’s what I smell…

I believe the system is set up incorrectly.

Here’s what should happen:

Cloverleaf sends a message to SCM’s receiver.

SCM’s receiver sends the message to a filer.

The SCM filer puts the message in the database and acks the receiver with x06.

The SCM receiver then acks Cloverleaf with the HL7 ack.

So it sounds like the SCM receiver and filer are using the wrong ports to ack on. They should be acking on some internal port number.

The SCM receiver should be HL7 acking Cloverleaf on the same port that the message came from. You shouldn’t have to see x06 at all.

But then again, I could be smelling popcorn instead of a skunk.

Hi Joseph,

Most of our connections to SCM are through their interface engine, eLink (AKA: eWebIT), and I’m not that familiar with the details of the setup for how the ACKs work in both directions.  However, I found that a programmer who has since left us must have at least one SCM connection directly with Cloverleaf, because he created a modified version of our standard ACK proc that returns the “short ACK” that SCM expects.  A snippet of the code that might be useful to you follows:

           if [cequal $ack_type “AA”] {

               set ACK [ctype char 6]

           } else {

               set ACK [ctype char 21]

           }

           set obMsg [msgcreate -type reply]

           msgset $obMsg $ACK

I don’t think you have to worry about the other mllp envelope hex characters (0B … 1C 0D), as that will be handled by the protocol.

If you are still stuck next week, I might have some more time then to dig into how SCM is sending out ACKs.

Greg Eriksen

Greetings,

We had several HL7 interfaces to the Eclipysis application and there was no special ACK handling required beyong the usual MSH|MSA standard processing.

I suspect that the application group for SCM in your case needs to re-configure their protocol to reply with the standard.  

Prevail upon them to fix their side – doable based on our experience.

Good luck!

We are now in the functional testing about to begin the integrated testing for SCM.  I aquired a pdl driver from some very generous Clovertechers which made the setup very easy.  

When you set up the threads use the attached pdl as the protocol driver. You essentially end up with 2 protocol threads one which the data is sent to SCM and one that is setup to receive the final ACK from SCM this thread is setup as a static route with itself as the destination and a proc of hcitpsmsgkill.

So far this has worked fine, if you have any other questions e-mail or call me.

Jim

Bob is correct only if your contract with them has Eclipsys doing all of the integration work using e-link. Unfortunately we have the community model and the e-link component was not included in phase 1 of our project, thus I was volunteered to do all of the integration work conforming to their standards. It actually works out better this way because our organization maintains control of how the data is translated.

Jim

We have had the iSoft version of this product  in production for a number of years and use the PDL’s above.

We send ADT messages on one thread, LAB messages on another thread and receive ACKS on a third thread.

The iCM interfaces are flaky and often require a manual stop/start of iCM interfaces and Cloverleaf threads if communications have been stopped!

The two message delivery issues we have had were during a (pre go-live) historical load are detailed below.  This was a few years ago and may not affect the Eclipsys version. We still have memory leaks in the iCM interfaces and they are bounced regulaly!

Sending messages as fast as iCM could process them, the communication would start having TCP issues and a restart would be required.  This appeared to be happen less with 3.5.5P (our then prod Cloverleaf) than with test (5.2.1).  The Cloverleaf logs indicated a non TCP reply and this was verified by the network guys who pointed the finger at iCM, but the vendor could offer no support!

When there were a large number of message queued in the MSMQ and the server crashed, the MSMQ was NOT recoverable.   This may have been fixed with a MSMQ update a while ago.