State 16

[Mike Willeson]

We have an unusual issue we have seen in the last few months.

We have 1 certain patient that has something unusual in their patient record in our EMR.  We have been looking for it, but have not been able to find it yet.  The issue is that this certain character or whatever it is, prevents our downstream system from processing the ADT message.

So essentially, clover goes into a State 16 for that message and all processing on that thread ceases and messages back up.

I have a specific question about ack handling, or the lack of ack handling.

Right now, under the Inbound Replies, our thread is set to ‘Await Replies’ with a Timeout of 60.  We are using cl_check_ack under the TPS Inbound Reply.  Under the Timeout Handling button we are using the ‘Resend OB Message’ option.

My question is can we somehow configure our timeout handling to move the error to the error database after the 60 second timeout is reached and move on to process the next message?

Thanks in advance.

Mike

Topic

[Rob Lindsey]

Basically what you need to do is to keep track of the number of retries and move the data message out of the way if it goes past a certain number.

The Proc   validate_reply   does this but requires a different setup on the outbound tab of the thread.  Below is from the Notes in the tclproc on my system:

# Notes:

#               Needs the following procs to run correctly:

#                       save_ob_msg (OB DATA TPS)

#                       kill_ob_save (IB REPLY TPS — AFTER THIS PROC!)

#                       resend_ob_msg (REPLY GEN TPS)

#

#       This proc requires an argument for the following

#

#       {ACKTYPE AA} or {ACKTYPE CA}

#       {MAXRETRIES 1} or whatever you need.

We have used this in the past but changed to cl_check_ack.

Hope this helps out.

Rob

[Jim Kosloskey]

Mike,

It sound like the receiving system is trying to process the message before acknowledging.

In my opinion they should not be doing that. They should just acknowledge receipt of the message. If there are issues with the content of the message then that should appear in an error subsystem (log or whatever) on their system to be worked by them.

Many systems have a configuration option to either acknowledge without processing or process first and frequently the default is process first. Many of the vendor’s field personnel in these cases don’t even know there is such an option or what it means. You may be able to get that changed by just asking.

That would solve your State 16 issue without doing anything (of course the issue about what is wrong with the data still remains).

But if they insist they have to process the message before acknowledging then I think it is eminently reasonable to require them to send an negative acknowledgment when there is an issue (using the appropriate fields in the acknowledgment to let Cloverleaf not only know there was an error but what the error was even if it is something like ‘found an unexplainable error’).

You would then need some code (if you don’t already have some) to handle the acknowledgment and you can take whatever action you want with the held message including some sort of notification to someone who would need to investigate.

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

[Mike Willeson]

Thanks Jim.  I agree with you.  Thanks Rob for the ideas.

I am not confident they will attempt to resolve their issue or change.  I will pursue handling the timeout on this side and move on to the next message.

As a side note, I will sympathize with the vendor a little bit as I found myself in a similar situation back in the late 90’s.  I was working for a vendor who was interfacing with a hospital where the “Clovertech board famous” Jim Cobane was working.

Their system was sending me a particular message our system just couldn’t digest and we were stuck.  I could not figure out how to move beyond it.  Jim removed the message and we were caught on a couple of subsequent messages for the same person which Jim also removed.  Problem solved.  

Until a couple months later when the exact same person became stuck again.  Jim removed the one message and we never had the issue surface again.

Jim may not remember it, but I remember it well.  So, Iguess whatever goes around comes around….    🙂

[Jim Kosloskey]

So how will you differentiate between a timeout that occurred because the receiving system is hung versus a legitimate timeout because something between Cloverleaf and the receiving system is slow enough to cause the timeout?

If you happen to have a network issue for example, you could throw a lot of errors into the Error DB causing you a lot of work.

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

[Author]

Replies