Stream: workflow
Topic: Acknowledging a message
Grahame Grieve (Dec 02 2019 at 03:16):
I've just been asked a question that I don't know the right answer to. Here in Australia, we send messages through a SMD wrapper - a web service wrapper. The messages might be v2, CDA, PDF....
Grahame Grieve (Dec 02 2019 at 03:17):
we don't have any acknowledgements right now. THat is, you send a message, and you have no way of finding out whether it arrived or not, or whether it's been accepted, if it's a referral
Grahame Grieve (Dec 02 2019 at 03:17):
someone just asked me... what's the right FHIR resource to return an acknowledgement like this?
Grahame Grieve (Dec 02 2019 at 03:17):
and I don't know?
Grahame Grieve (Dec 02 2019 at 03:18):
ProcessResponse..? but that's gone?
Communication...? But that's general. How would you know if was an acknowledgement message
Grahame Grieve (Dec 02 2019 at 03:20):
a bundle with a message header?
Vassil Peytchev (Dec 02 2019 at 03:50):
If you are sending a FHIR message, there are mechanisms to receive an acknowledgment message: http://build.fhir.org/messaging.html#patterns
But you are talking about accepting a referral - the underlying communications should not be concerned with the status of the referral, that is at the workflow level. The status of the referral is (usually) managed by a Task (based on the ServiceRequest that is the referral). If you want to bring FHIR messaging and referral management together, you can then have something like this:
Referral Request --> FHIR message with MessageHeader.focus pointing to Task, with Task.status set to requested, and containing the rest of the relevant resources
Synchronous Ack --> FHIR message with MessageHeader.respopnse.code of OK
Referral Accept --> FHIR message with MessageHeader.focus pointing to Task, with Task.Status set to accepted
Of course, there are many variations possible to the above, for example the synchronous ack may have a focus of Task as well, with Task.status set to received.
Grahame Grieve (Dec 02 2019 at 03:51):
you might note that I said nothing about FHIR messaging
Grahame Grieve (Dec 02 2019 at 03:52):
but it does look like Task is the thing in R4
Grahame Grieve (Dec 02 2019 at 03:54):
the receiving system is informing the source system about the progress of it's task to process the message it received
Vassil Peytchev (Dec 02 2019 at 04:13):
"a bundle with a message header" led me astray :-)
If you have a messaging system that has no inherent acknowledgment mechanism (except something that is considered too low level), then you need the content to fulfill that purpose. I am all for combining various standards in a single implementation guide, but in my opinion, it is better to provide a layer in the content that deals with the states of the information exchange. Just throwing a FHIR Task in the mix of other standards without other FHIR pieces involved might not be what you are looking for.
Grahame Grieve (Dec 02 2019 at 06:01):
no but I think it was what the person was looking for. Obviously it's less easily applicable if you didn't start with FHIR, but it's still an applicable idea even if you didn't
René Spronk (Dec 04 2019 at 16:46):
Notifications don't result in Tasks.. whereas there are plenty of notification scenarios where you'd like to have an ack.
John Moehrke (Dec 04 2019 at 16:49):
this is dependent on the kind of notification.. each kind of notification have different pro/con. where the notification mechanism is a FHIR Message, there is an ack...
Last updated: Apr 12 2022 at 19:14 UTC
