Stream: conformance
Topic: Message notification - clarification of bundle content
Allan Bro Hansen (Aug 26 2016 at 06:54):
I am looking to implement a notification message for "the patient has arrived for his appointment" which is determined as a value of the appointment.
Our server already implements a FHIR appointment endpoint but does not support version-reads (vreads).
The receiving system is yet pretty unspecified so we have the possibility to state how we want it, and we want to do it in a FHIR-fashion.
Due to the lack of vread we also need to include actual appointment resource (and not just a version-specific reference to it).
We also know that the receiving system would be interested in the business identifiers of the patient of the appointment.
The message will be sent synchronously from our system but handled asynchronously from the user action (so process time is not that important).
I am uncertain whether a REST-subscription or a notification message is the better choice:
Using subscription:
We could use the subscription pattern (https://www.hl7.org/fhir/subscription.html) with a REST Hook sending an update (PUT) appointment message for every patient-arrived event. The receiving system would subsequently need to read the patient to get the business identifiers (a step I would like to be without).
Using messaging:
We could POST a notification message using a synchronous $process-message. The message would contain a reference to the appointment as messageheader.data (Messageheader should be the first resource in the bundle). I am uncertain if it is within the standard to include the actual appointment-resource as the second resource, and its patient as the third.
I can only see this subject mention in the comment of the description of messageHeader.data (https://www.hl7.org/fhir/messageheader-definitions.html#MessageHeader.data).
"
The data is defined where the transaction type is defined. The transaction data is always included in the bundle that is the full message. Only the root resource is specified. The resources it references should be contained in the bundle but are not also listed here. Multiple repetitions are allowed to cater for merges and other situations with multiple focal targets.
"
The question for you (sorry for the long introduction):
Concerning "The resources it references should be contained in the bundle but are not also listed here": Is it really expected to include all referenced objects of the appointment?
(and any comments in respect to choosing between subscription-REST and messaging are also welcome)
Allan Bro Hansen (Aug 26 2016 at 08:35):
did just change include a "not" in part of the 2. sentence from "but does support" to "but does not support" :-)
Jens Villadsen (Aug 26 2016 at 08:43):
well ... subscription-REST puts the responsibility on the subscriber to what the subscriber is interested in... it is the most dynamic approach for both parts as the criteria may vary from time to time and be arbitrary complex
Jens Villadsen (Aug 26 2016 at 08:50):
notification message sounds a bit more static as the content would be spec'ed up front
Jens Villadsen (Aug 26 2016 at 08:52):
and entirely controlled by the sender
Allan Bro Hansen (Aug 26 2016 at 09:04):
true, the subscription-REST makes it possible for the reciever to specify a different appointment ressource than the one we have - the 2 appointments still have to be compatible though.
I didn't address the "what should trigger the event"-part. Subscription also has the message-channel which offer the same possiblity for the receiver to specify a criteria. Still nothing comes out of the box - the sender still has be able to support the criteria (maybe it does, maybe it doesn't)
Grahame Grieve (Aug 26 2016 at 11:33):
there's 2 different questions here - how do you decide to notify, and how do you notify?
Grahame Grieve (Aug 26 2016 at 11:34):
you can use messaging with subscription - subscription specifies when to notify, and to use messaging.
Grahame Grieve (Aug 26 2016 at 11:34):
or you can make some other (hard coded) way to trigger, and notify using either approach
Grahame Grieve (Aug 26 2016 at 11:35):
my take was that this was a messaging use case - you should define a message code that descibes the event and package, and use the message framework
Allan Bro Hansen (Aug 26 2016 at 13:01):
Yes, my request for comments was not in respect to "what should trigger the event" but merely on how to notify.
Grahame, thx for the vote for "messaging". I would like to hear some thoughts on why subscription isn't the right choice, there is clearly an overlap in functionality.
And still there is my question: Is it really expected (mandatory) to include all referenced objects of the appointment?
Grahame Grieve (Aug 26 2016 at 20:16):
subscription is about the initiation of the contact. You can specify to use messaging, or not, when you use subscription.
Grahame Grieve (Aug 26 2016 at 20:17):
as for aggregation, there's no fixed policy, because requirements will vary
Allan Bro Hansen (Aug 28 2016 at 21:39):
sorry - my question was not precise. A better version of it: why wouldn't you consider notifaction via the REST-API (by doing a PUT appointment - https://www.hl7.org/fhir/subscription.html#6.14.6.1), the right choice?
Grahame Grieve (Aug 28 2016 at 22:45):
for me, a REST API notification implies a fairly tight binding between the systems, where as the questions around packaging and aggregation imply that the relationship is not that tight, and you need some workflow to manage the interaction.
Grahame Grieve (Aug 28 2016 at 22:45):
this points me towards messaging, though it's not a strong feeling, and there would be other considerations,
Allan Bro Hansen (Aug 29 2016 at 07:49):
thank you (I am leaning towards messaging as well)
Last updated: Apr 12 2022 at 19:14 UTC
