This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Duplicate Transmissions

From HL7Wiki
Revision as of 09:20, 4 July 2006 by Rene spronk (talk | contribs)
Jump to navigation Jump to search

Discussion: How should an HL7 Application (this is NOT a Messaging Infrastructure question) react to a duplicate Interaction ? For the purpose of this discussion, a duplicate interaction is defined as an interaction with one and the same Transmission.id as an interaction that has already been processed and responded to.

There are 2 basic options: HL7 either does or doesn't prescribe how systems should deal with duplicate transmissions. If HL7 prescribe the behaviour there are 3 ways of dealing with the duplicate transmission:

  • Ignore it.
    • Simply ignoring a duplicate won't work at the HL7 layer, for we have a sending system that may be waiting for a response. It may have resend the message because (for one reason or other) it didn't receive a response.
  • Reject it.
    • Rejecing a duplicate won't work at the HL7 layer, for we have a sending system that may be waiting for a response. It may have resend the message because (for one reason or other) it didn't receive a response. Sending a "reject" to the duplicate is better than just ignoring the duplicate, but doesn't really help the sender, other than to inform the sender that it should create a NEW interaction (different Transmission.ID) with the same contents.
  • Send the same response (if any) as has been sent for the original interaction.
    • This fully satisfies the requirements of the sending system, but puts a burden on the recieving system, for it has to keep a record of all interactions it has sent.
    • For the Dutch implementation guide we wrote some quite complicated rules:
      • If the duplicate interaction has no receiver responsibilities, ignore it at the receivers end.
      • If the duplicate interaction has receiver responsibilities, then you need to respond with a duplicate of the response interaction as has been sent by the receiver when it originally received the interaction.
      • In order to detect duplicates and be able to send duplicate responses we now require that all systems have a 48-hour log of all messages sent/received. Maybe we need a shorter timeframe than 48 hours, time will tell.

Discussion

  • Do we want HL7 to prescribe the way to deal with it ? No one size fits all solution.
  • Does the way to deal with duplicates depend on message infrastructure used ? – No, that just affects the amount of lost messages.
  • What is a valid reason to resend with the same message.id ? – should one always use a new Message.id on a resend ?
    • Replay messages obviously contains duplicate message.ids.
    • From sender perspective: no application response [although one was expected], what should a sender do ?
  • Do we need a “this is a duplicate of message x” attribute ?

Business Process Duplicates

  • Detection of duplicate order (via business ID) is different from a duplicate Transmission (message.id). How do we want to deal with this?