This wiki has undergone a migration to Confluence found Here
Difference between revisions of "FHIR message Page"
Jump to navigation
Jump to search
m (moved FHIR messageheader Page to FHIR message Page: Resource renamed) |
m (→Discussion) |
||
| (One intermediate revision by one other user not shown) | |||
| Line 2: | Line 2: | ||
<!--[[Category:Active FHIR Discussion]]--> | <!--[[Category:Active FHIR Discussion]]--> | ||
| − | Welcome to " | + | Welcome to "Message" discussion page. Please put any comments about this page here. Contents will be reviewed periodically. |
=Discussion= | =Discussion= | ||
| − | ( | + | #I am having a problem with the requirement in the messaging resource |
| + | ##“A message receiver must always check the incoming bundle identifier (atom feed.id), and check them against a store of previously received messages (going back a reasonable period in time). If it receives a duplicate message id that it has already responded to, it should assume that the original response was lost (failed to return to the request issuer), and resend the original response in a new bundle. If the source application gets no response to its request from the destination application within a configurable timeout period, the source application should resend the same bundle with the same atom feed.id. “ | ||
| + | ##This appears to me to be putting an application burden on the receiver. Additionally, it requires the receiver to cache original responses (“resend the original response in a new bundle”). | ||
| + | ##I do agree that “If the source application gets no response to its request from the destination application within a configurable timeout period, the source application should resend the same bundle with the same atom feed.id. “ is best practice. | ||
Latest revision as of 18:43, 2 January 2013
Welcome to "Message" discussion page. Please put any comments about this page here. Contents will be reviewed periodically.
Discussion
- I am having a problem with the requirement in the messaging resource
- “A message receiver must always check the incoming bundle identifier (atom feed.id), and check them against a store of previously received messages (going back a reasonable period in time). If it receives a duplicate message id that it has already responded to, it should assume that the original response was lost (failed to return to the request issuer), and resend the original response in a new bundle. If the source application gets no response to its request from the destination application within a configurable timeout period, the source application should resend the same bundle with the same atom feed.id. “
- This appears to me to be putting an application burden on the receiver. Additionally, it requires the receiver to cache original responses (“resend the original response in a new bundle”).
- I do agree that “If the source application gets no response to its request from the destination application within a configurable timeout period, the source application should resend the same bundle with the same atom feed.id. “ is best practice.
