Stream: subscriptions
Topic: Bundle with Extensions
Grahame Grieve (Nov 22 2019 at 09:39):
Have we discussed, instead of defining extensions to stick in the Bundle that does a notification, instead defining a new bundle type 'subscription' that has a first resource 'SubscriptionStatus' - this resource could allow a client to reset it's listening stream too
David Hay (Nov 22 2019 at 09:56):
using extensions on Meta does feel a bit like working around a design decision (ie Bundle not supporting extensions)...
Gino Canessa (Nov 22 2019 at 10:11):
Yes, we discussed this at the FHIR-I session at the last WGM in Atlanta... I will try and find the vote/notes from it.
Gino Canessa (Nov 22 2019 at 10:15):
It was discussed with GF#23859, but does not appear to have made it into the notes. Likely because of the note: "(Note, this resolution was lost and then re-written by reviewing minutes.)"
Gino Canessa (Nov 22 2019 at 10:17):
I can't remember if there wasn't enough interest to vote or if there wasn't enough to pass... I'm fine with making a new issue to bring it up at the next FHIR-I call.
Gino Canessa (Nov 22 2019 at 10:27):
Tagging @Josh Mandel because I remember discussing it with him after the session
Josh Mandel (Nov 22 2019 at 15:34):
Indeed at the first FHIR infrastructure session at the last working group eating we talked through three options. The sentiment in the room was "don't create a new bundle type if history could work", but I wouldn't mind revisiting if there was interest in adding first class properties for notifications.
Gino Canessa (Dec 11 2019 at 20:26):
Per feedback, I am going to start modelling out the new resource to use when Subscriptions are sending bundles (to replace the current extensions on bundle.meta).
Having gone through renaming Topic to SubscriptionTopic, I am in no hurry to rename another resource. So, it's poll time again - please vote for your favorite name for the above-mentioned resource so that I don't have to do it twice!
At first pass, the resource will include: subscription-event-count, subscription-status, subscription-url, and possibly subscription-topic-url and bundle-event-count.
It will be required as entry[0] in notification bundles. I've listed everything I've heard suggested so far in alphabetical order. Please feel free to add if there is something logical that I've missed. Polling will be open until I get around to defining the resource :-)
Thanks!
Gino Canessa (Dec 11 2019 at 20:26):
/poll Subscription Bundle Resource Name (to replace extensions)
SubscriptionHeader
SubscriptionInfo
SubscriptionMeta
SubscriptionNotificationHeader
SubscriptionNotificationInfo
SubscriptionStatus
Josh Mandel (Dec 11 2019 at 20:54):
(For me, the key consideration is: we want the name of this resource to work in the context of Bundle.entry[0] for notification bundle, and also in the context of an operation like "tell me the volatile status details of this subscription" (say, Subscription/:id/$status.)
Gino Canessa (Dec 11 2019 at 20:58):
Re: Josh: True, it has been asked (and is being discussed) if the volatile fields such as eventCount shouldn't be moved out of the Subscription resource (e.g., to prevent creating a new version of the resource for every notification sent by the system). With this new resource being added, it makes that decision easier (for me at least).
Jenni Syed (Dec 12 2019 at 15:47):
So, informal poll/question: do we feel like we're doin this just to work around the limitation on bundle and that it should be a capability? Or do we really feel this is something that should live separately from Subscription?
Gino Canessa (Dec 12 2019 at 15:54):
So, informal poll/question: do we feel like we're doin this just to work around the limitation on bundle and that it should be a capability? Or do we really feel this is something that should live separately from Subscription?
Yes.
=)
Seriously though, I feel like either piece is enough to stand on its own - the fact that both can use the same solution means that the decision was easier (for me at least).
Gino Canessa (Mar 30 2020 at 16:52):
By popular demand: there is a new poll for the additional subscription resource.
Edit: updated poll type
Gino Canessa (Mar 30 2020 at 18:46):
Updated the poll above, had accidentally set to Quiz instead of Form. If you took it already, please do the new one.
Vassil Peytchev (Mar 30 2020 at 19:41):
I voted again, I hope I got it right :wink:
And just to clarify, the reason I was looking for another vote is that I believe there is a significant value for defining a Notification that goes beyond its use with explicit subscription.
Gino Canessa (Mar 30 2020 at 19:47):
Yep, have the vote. That was the problem with the first one - since it was a quiz type it just told me how many people agreed with my arbitrary input sorting.
Personally, I'm not fussed about the name at all - I just don't want to rename it once I've created it in the spec.
Last updated: Apr 12 2022 at 19:14 UTC
