Resend OB Reply Help needed – Duplicate Messages Sent

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.

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.

… 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.