Stream: subscriptions
Topic: Subscription sends notification without changing resource
Sohrab Hejazi (Dec 03 2019 at 13:33):
Currently, FHIR Subscriptions are invoked whenever an action on a resource is performed, even if it doesn't change the resource's contents. Is it possible to configure the FHIR server to call Subscription only when the content of the resource is changed?
Vassil Peytchev (Dec 03 2019 at 14:11):
Subscriptions are being reworked at the moment to change to event-based subscriptions.
Sohrab Hejazi (Dec 03 2019 at 14:48):
Subscriptions are being reworked at the moment to change to event-based subscriptions.
I have to wait for a new release? if yes, how long does it take?
René Spronk (Dec 03 2019 at 14:58):
You always have the option to pre-adopt something ;-) .. see http://build.fhir.org/subscription.html and http://build.fhir.org/topic.html . Both are maturity level 0, so be warned: they are likely to change.
Sohrab Hejazi (Dec 03 2019 at 15:10):
You always have the option to pre-adopt something ;-) .. see http://build.fhir.org/subscription.html and http://build.fhir.org/topic.html . Both are maturity level 0, so be warned: they are likely to change.
:+1:
Grahame Grieve (Dec 03 2019 at 19:03):
I'm not sure that this actually deals with this issue. @Gino Canessa there's nowhere where we say 'only if it actually changes' (or let the client say that)
Gino Canessa (Dec 04 2019 at 01:40):
If you are asking for notifications on Update of a resource, right now it's the server's discretion on when that should be triggered (e.g., actual diffs vs anytime an operation occurs). We don't have any guidance in place for it, but will add to my list to be clarified in docs (even if just describing that it is up to the server).
I will also bring the concept up for discussion - if one or the other should be considered 'default', but am concerned that requiring either behavior won't get any consensus (whatever a system does internally, it would be significant to implement the other behavior).
That said, a topic can be defined describing the behavior (e.g., an Update which results in a detectable change) so that clients and servers can be on the same page. Depending on the outcome of the discussions, it may be easier to just define a canonical topic for each (e.g., any update to a resource, updates with changes) so that servers and clients can all be on the same page.
Grahame Grieve (Dec 04 2019 at 01:55):
My server doesn't know whether the resource has changed on update.
Gino Canessa (Dec 04 2019 at 15:59):
My server doesn't know whether the resource has changed on update.
Exactly. For your server, that will be the behavior and it is quite unlikely you will support the other. I imagine there are servers that operate in the opposite way. Whichever the server supports should be clear to clients, but whether it is via topics or general guidance/conformance should be decided.
Jenni Syed (Dec 05 2019 at 14:44):
We also most often just know something happened, not necessarily what changed. And sometimes that change may be in data that isn't exposed via the FHIR resource.
Jenni Syed (Dec 05 2019 at 14:44):
Since servers can now advertise topics, I assume they would only advertise the topics they can meet?
Jenni Syed (Dec 05 2019 at 14:46):
And (similar to what we've discussed before) sometimes it's the functional spirit of the Topic rather than the technical description. EG: an ADT type subscription - we may know an event occurred that should qualify, but it may not qualify to the exact diff as defined in the topic since that looks at field value changes.
Last updated: Apr 12 2022 at 19:14 UTC
