This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Duplicate Transmissions"
Jump to navigation
Jump to search
Rene spronk (talk | contribs) |
Rene spronk (talk | contribs) |
||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
| − | {{INM Workitem}} | + | {{INM Finalized Workitem}} |
| + | {{INM Approval|20060912|INM WGM: Move to declare handling of duplicates by receiver application to be out of scope for HL7 INM (and e.g. leave to implementation guides).(10-0-1)}} | ||
| + | |||
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. | 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. | ||
| Line 6: | Line 8: | ||
**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. | **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'''. | *'''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 | + | **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 resent 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'''. | *'''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. | **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. | ||
Latest revision as of 15:37, 12 September 2006
This page documents an INM Finalized Workitem, i.e. an issue within scope of the INM Committee that has been finalized, and which (if applicable) has been included in an INM ballot.
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 resent 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?
