Stream: implementers
Topic: Asynchronous messaging question
Sanjaai (Oct 01 2020 at 17:56):
Hi,
We are planning to develop a FHIR asynchronous messaging between two entities to exchange documents using bundle based messaged as described here under the async interaction pattern here https://www.hl7.org/fhir/messaging.html#async.
Page indicates that sender and received can get their latest messages and acknowledgements using time based queries such as
GET [base]/Bundle?message.destination-uri=[rcv]&_lastUpdated=>2015-03-01T02:00:02+01:00
We are also floating an idea to track read status(pending/read/ failed) at the server, and also provide a custom query parameter to query by read/acknowledgement status.
While I acknowledge this is technically possible, we are discussing whether this in line with general design goals of this message pattern.
Mainly, we are introducing read status and acknowledgement into the server, which are meant for the two endpoints involved.
Query parameter is representing something not tracked or contained within resources (i.e. read, pending)
Does fhir provide any other mechanism to track user activity on read/pending statuses of resources in general ( primarily meant for improve client experience, in this case )
Like to hear the thoughts from the community,
Thanks
Sanjaai
Lloyd McKenzie (Oct 01 2020 at 19:31):
I have a customer who has done something like that, but rather than trying to track 'read' status (which is hard), their workflow calls for the client to submit a batch of 'deletes' for the resources they've successfully read and written to persistent store (and which thus no longer need to be stored on the intermediary mailbox system). Obviously the mailbox retains an audit log of everything that's passed through.
Lloyd McKenzie (Oct 01 2020 at 19:31):
Anything that isn't deleted will show up on the next query and presumably get deleted then if it somehow gets missed the first round.
Ken Sinn (Nov 24 2020 at 16:35):
Follow-up question on Async Messaging.
As part of the acknowledgement message, we would like to add an additional destination/recipient on this acknowledgement. Does this break any rules and/or expectations on how Async Messaging should work?
Ken Sinn (Nov 24 2020 at 16:40):
The original message from Sender A is being sent to Destination [B, C] (two destinations). On the acknowledgement response, Destination B is responding to originating Sender A.
1) What should Destination B do with Destination C from the originating message? The guidance in the Async Messaging documentation is that Sender and Destination are inverted, but doesn't talk about how to deal w/ multiple destinations.
2) On the acknowledgement from Destination B, could Destination B "cc" Destination C on the acknowledgement?
Ken Sinn (Nov 24 2020 at 17:28):
@Lloyd McKenzie for guidance/feedback
Vassil Peytchev (Nov 24 2020 at 18:23):
In general, an acknowledgement goes from whichever destination received the message to the sender. Expecting/requiring that an acknowledgement will also go to a third party (even if it was one of the destinations in the original message) seems to be a custom/non-standard behavior.
If you have complex workflow orchestration requirements, have you looked at subscriptions, and the RESTful API?
Lloyd McKenzie (Nov 25 2020 at 22:48):
Is the question whether B is responsible for routing to C or whether it can assume that it's A's responsibility to get it to C? I would have presumed the former. In the end, there would be two acknowledgment messages, one from B and one from C with a destination of A.
Chris Mota (Nov 26 2020 at 20:57):
Basically the scenario is this:
Sender A sends the message to Org B and Org C through an intermediary messaging system.
Org B attempts to process the message (async) and determines there was a fatal-error in doing so.
Org B send the appropriate error response to Sender A via the intermediary message system, however, because it's an error Org B also wants to send the response to Org C for their records.
Lloyd McKenzie (Nov 26 2020 at 22:28):
I don't think there's any standard mechanism for C to receive B's response.
Chris Mota (Nov 27 2020 at 15:53):
Okay so then i guess in this situation, the most appropriate path forward would be for Org B to instead send a new message to Org C containing the appropriate data?
Lloyd McKenzie (Nov 27 2020 at 17:26):
Either that or A could wrap B's response and pass it on to C (if B and C don't know how to talk to each other)
Last updated: Apr 12 2022 at 19:14 UTC
