Stream: implementers
Topic: Async failure of multi-recipient message
Lloyd McKenzie (Dec 15 2016 at 16:32):
When transmitting a FHIR message, you can indicate multiple recipients. The initial message is posted to an endpoint which ensures the message gets appropriate fanned out and delivered to its target recipients (possibly with numerous additional systems intervening). If the message fails at one of the intermediaries, is there a "proper" way to indicate the failure to deliver to all recipients short of sending a separate message for each intended recipient? If so, what would that convention be? (My concern is that if I send a message from A to B, C and D, it'd be a bit confusing to have a response message from Z to A saying the message couldn't be processed.)
Grahame Grieve (Dec 15 2016 at 17:54):
is this a message of consequence?
Lloyd McKenzie (Dec 15 2016 at 18:35):
Yes - It asks for something to be done or delivers something, but sends it to additional recipients as "ccs"
Grahame Grieve (Dec 15 2016 at 20:37):
how do they know which is which?
Lloyd McKenzie (Dec 15 2016 at 21:19):
The payload distinguishes.
Grahame Grieve (Dec 15 2016 at 21:25):
how does the payload distinguish which is cc:?
Lloyd McKenzie (Dec 15 2016 at 21:27):
Extension on Communication.recipient
Grahame Grieve (Dec 15 2016 at 21:29):
that matches the message header?
Lloyd McKenzie (Dec 16 2016 at 01:28):
Composition is targeted to practitioners, one of whom is "primary". Practitioner will live at one of the targeted systems
Paul Knapp (Jan 02 2017 at 10:35):
Are the receivers all peers? From the designation of one as 'primary' you'd expect that the implication of that one not being delivered may not be the same as other not being delivered. It appears as though the message to the 'primary' is the message of consequence and the others are really notifications. If the primary fails then the notifications should be recalled.
Paul Knapp (Jan 02 2017 at 10:41):
If as you say the communication is requesting action, will all of the recipients know to look for the extension to determine that they are not supposed to provide the action? Should this be elevated, for safety reasons, from being an extension to being an infrastructure concept and therefore meta element?
Lloyd McKenzie (Jan 02 2017 at 16:01):
The receivers are all peers, but yes there's a difference in expected behavior. If message delivery isn't successful, then the content would be delivered in other ways (fax, phone, mail) so I don't think there'd be a need to reverse the notifications. The question of whether this should be a "must-understand" is a good one.
Lloyd McKenzie (Jan 02 2017 at 16:02):
Thoughts on the original question?
Paul Knapp (Jan 03 2017 at 07:34):
Yes this must be a 'must understand' as you are modifying the meaning of an action request where the the presence of the extension means for some to not follow the request and perform the action since this is just a notification.
Paul Knapp (Jan 03 2017 at 07:36):
Also, if you fail to deliver the action request by any means I don't see how you have any choice but to reverse the notification. When is situation dependent.
Last updated: Apr 12 2022 at 19:14 UTC
