Resend OB Reply Help needed – Duplicate Messages Sent

[Shelbi Engle]

Hi,

We are experiencing an issue where there are a bunch of DFT messages sent at once from Cloverleaf to an HIS system just after midnight (like several hundred messages).  The receiving HIS system appears not to send back an ACK back in a timely manor due to it’s processing speed.  Cloverleaf sends the same message again until it receives a response, but the HIS has already received it, and the DFT message is posting more than once on the HIS.  

On my Inbound Replies – I have Await Replies checked and the timeout set to 15.  The Resend OB Message option is also checked.  

My Question:

How can I get Cloverleaf to NOT resend the same message (the same message ID) more than once?  I think this may have changed when we upgraded to 5.7?

Thanks!

Topic

[Jim Kosloskey]

Shelbi,

If you are using the automated resend capability introduced in 5.7 I am not sure there is any way to stop that from occurring (other than setting your timeout really high – but there is no guarantee there).

You could set your timeout to wait forever (-1) and that would stop any resends since the timeout never occurs – but you could get a lot of queued up messages so you will want to make sure your Alerts are properly set to assist in minimizing that impact.

On the other hand, if you continue to use the recovery_xx procs then you will control what you do upon timeout. However, you will need to still have some mechanism in place to handle what is reasonable to do if the timeout is reached (unless the timeout is set to wait forever).

You could also have the receiving system no accept messages with the same Control ID (MSH-10) or deploy sequence numbering. But that relies on the receiving system capable of being that intelligent.

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

[Shelbi Engle]

Thanks Jim!

I’ll see which route the client would like to take.

[Russ Ross]

Jim has answered this question nicely but I thought I would share I had the same problem long ago when I did my first real-time charge intergration to AP/Tamtron.

Their itnerface took a little bit of time to get going and cloverleaf usually had resent the same message 10 times which meant erroneous duplicate chages.

I decided then and there to never willing do a real-time charge interface.

This has not been a problem since I was the one wanting to try a real-time charge intergration until I realized it was too risky for my comfort zone.

If I was going to pursue doing a real-time charge itnerface again, I would not be comfortable relying on assumptions that high resend timeout values would always work.

I would probably insist on some sort of message sequence checking by the receiving system to make sure to get rid of duplicate resends and that no charges get skipped.

Russ Ross
RussRoss318@gmail.com

[Richard Hart]

Quote:

… or deploy sequence numbering.

The HL7 sequence number protocol works well and is used in our PAS interface.

The ‘initialisation’ task sends a ‘resync’ message until the receiving application returns a message indicating the sequence number to start comms.

The sequence number is stored (persisted) on both sides and is incremented in the sending application when a successful ACK has been received and in the receiving application when a message has been processed (good or bad)

If a message does not get an ACK within the timeout, the initialisation process is called.  If the receiving application returns a sequence number one more than the sending application, then the message must have been procssed.

[Author]

Replies