Ack Code AR

[Mike Shoemaker]

I’m looking for some insight into the AR ack code (application reject).  The recovery_33 proc is configured to resend 3 times and then send to the error database and move on to send the next message.  

We have a raw interface that basically forwards messages from Seimens Invision to Cloverleaf on to Seimens Openlink (why? a topic for another day).  In any event, our Openlink server is old and very stressed these days.  During an Openlink reboot, there is a short time after coming back online that the application itself is unavailable due to system resources being low with lots of stuff happening, yet the interfaces kick back on and start sending ACKs back to Cloverleaf with an AR code.  At this point cloverleaf will do the 3 checks and then error until some undetermined time in the future when the application becomes available and processing resumes. This causes a problem with a variable number of messages being skipped to the error db causing the message flow to be out of sync.

From the HL7 standard, it appears the AR code is used for message validation (MSH:9, 12, and 11) but also for a failure to process for any other reason aside from message format (system down or some internal error).  It states that the receiving system will be able to receive the messages at a later time.

So my question is, how can the same ACK code of AR mean 2 mutually exclusive things? If the MSH checks fail, thats a bad message and simply resending the message is not going to fix the problem, therefore I would want to skip the message and move on. But on the flipside, if the receiver is sending AR to ask the sender to resend at a later time, how am I supposed to know the difference between the conditions sending the AR?  Confused? I am.  At this point, my solution involves a new server for Openlink, which should avoid the low system resource situation.

Topic

[Jim Kosloskey]

Mike,

The issue is Siemens like many other vendors does not properly use the MSA segment.

Depending on the HL/7 release leve there is a place for the system sending the Acknowledgment to clarify the cause of the AE or AR. With a coded clarification it is possible for the system that gets the ack to do a triage and determine whether it makes sense to resend the message (and potentially how long to wait) or if the message is broken and thus all mesages should stop until repairs have been made.

Beginning with HL/7 V2.2 MSA-6 is the place where any real HL/7 compliant system would deploy such intelligence.

Let us know if you find ANY vendor that utilizes MSA-6 properly.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Jim Kosloskey]

Mike,

I guess I should have shared what we do when we receive AE or AR Acknowledgments without clarification (that is all of them by the way).

We treat this as a broken message and stop the interface. Thus someone needs to evaluate what the issue is and then take the appropriate action. In the case where eventually the situation corrects itself like you describe, we simply wait and then resend the offending message and restart the interface until the next time.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Mike Shoemaker]

Thanks Jim, We are doing something similar where by process when we reboot the Openlink box, we bring down the connecting Cloverleaf threads and wait a few minutes until the Openlink box calms down. Problem is this process isn’t always followed or we are off in determining when Openlink will be happy to process messages again.  I believe the new Openlink box will be beefy enough to not go into this low resources state, which by the way is impossible to test / reproduce routinely.

For all of our other interfaces, the sending systems do not ack with AR, they just don’t ack which hangs the interface until processing can resume. It is a debate about that being appropriate or not, but I personally think it makes perfect sense. The Openlink guys here claim that Cloverleaf should receive the AR and then just poll every few minutes to verify the system is ready. This seems like Cloverleaf would add to the resource issue by causing Openlink to deal with new messages and ack with an AR each time.  From my perspective, it would make more sense for them to hold the message and NOT to ack me with AR and just ack me at AA when they are ready for the message. But what do I know, according to them, if i was smart i wouldn’t be using cloverleaf 😉

[Russ Ross]

I encountered something simialr a long time ago with a vendor interface that would take a while to come up but caused problems with the ACK/NAK during start up.

I was able to work around it by setting my time out setting on Cloverleaf to something relatively high like 5 minutes.

Since we would allow for 3 NAKs before the interface shut itself down and sent out on-call alerts, that got me over this hump becuase it then allowed the vendor interface listener 10 minutes to get started and ready to receive messages.

Russ Ross
RussRoss318@gmail.com

[David Harrison]

Mike,

Just as a matter of interest, does your Seimens Invision system use OpenLink transactions or is it HL7 and OpenLink is your integration engine?

[Mike Shoemaker]

David Harrison wrote:

Mike,

Just as a matter of interest, does your Seimens Invision system use OpenLink transactions or is it HL7 and OpenLink is your integration engine?

It’s kind of complicated.  In theory we use 2 engines, Openlink for our Siemens systems (Radiology and Pharmacy) as well as some file based batch interfaces and we use Cloverleaf for everything else. This is supposedly for redundancy where we hopefully wouldn’t have ALL ancillary systems in trouble at once with an engine problem. The main problem with the theory is that Siemens “GRV3” can only be sent to 1 destination (an engine, preferably openlink from Siemens point view).  Our GRV3 is sent to Cloverleaf which the routes raw messages over to Openlink. So we still have a single point of failure (cloverleaf) but it keeps the suits sleeping better knowing they have 2 different engines.

[Author]

Replies