FHIR Chat · Contiguous Events · subscriptions

Stream: subscriptions

Topic: Contiguous Events

adam strickland (Sep 13 2021 at 14:47):

Is there anywhere in the spec that says the events referenced in a subscriptionStatus need to be contiguous? In all the example scenarios/payloads I've seen that has been the case, but I'm wondering if we need to make that explicit somewhere.

The reason this has come up is that the addition of the notificationEvent element provides the flexibility to include discontiguous events (I can put 38 and 36 in the list, but not 37) and that this might break clients that were relying on eventsSinceSubscriptionStart and eventsInNotification to tell them which events were included before even parsing notificationEvent.

In the example of sending 38 and 36, the current spec would say the eventsSinceSubscriptionStart is 38 and eventsInNotification is 2, and the client may conclude that you've sent events 38 and 37. If the client already received those events (but not 36), it may not realize you've included an event it is interested in.

If others agree this is an issue, then I think the solution is to make a rule saying notificationEvent should be contiguous (I have an idea for a FHIRPath query for this), and that it's length should equal to eventsInNotification.

I think the story for $events and $status is a bit more complicated, but before going into that I'd like some feedback on the above. I've run into the above issue and more while trying to write a generic state machine for a subscription client that covers the lastReceived event, the current connection status and any known (but missing) events.

Josh Mandel (Sep 13 2021 at 15:54):

This touches on our "reliable delivery" discussion from last week's call. I agree @adam strickland that for all of the channels we have defined in the spec, and for all future channels that don't assume reliable delivery, notification events should be contiguous.

Josh Mandel (Sep 13 2021 at 15:56):

I don't know how to formalize that as a constraint without enumerating channel types that it applies to as part of a constraint expression -- but even without that detail, I'm curious about your fhirpath expression idea; it's a cool puzzle and may well turn out to be useful!)

adam strickland (Sep 13 2021 at 16:41):

Thanks Josh, I was thinking something like this:
eventsInNotification.exists() implies contiguous..., where contiguous means:

1. Select a collection of event numbers from eventsInNotification
2. Create a collection of expected numbers based on max value in event numbers and eventsInNotification
3. Insist the events numbers collection is a superset and subset of expected numbers

If we wanted to be more strict and say that eventsInNotification is contiguous and descending order, we could probably streamline this. I think that would be worth doing.

adam strickland (Sep 13 2021 at 18:17):

@Steve Atwood what do you think about the above? Before putting a restriction on notificationEvent.eventNumber I wanted to make sure that doesn't conflict with your use case. If it doesn't, then it makes defining this much easier.

Steve Atwood (Sep 13 2021 at 18:32):

Thanks @adam strickland . I think Gino's recommended workaround for my "reliable distributed channel" use case was just to assign relative sequential eventNumbers in the notificationEvent element, so I believe that would still be compatible with the constraint you are outlining. For example, if I have a notification with three events, I guess I would set eventsInNotification=3, eventsSinceSubscriptionStart=3, and notificationEvent.eventNumber=[1,2,3]. The event numbers in this case would obviously be meaningless outside the context of that particular notification but I think it would satisfy the constraint.

Josh Mandel (Sep 13 2021 at 20:16):

Oh that's even better, Steve. Keeps the numbers consistent with our existing scheme at least within a message, even if they're don't have all the same behaviors across messages arriving within a short timespan.

Josh Mandel (Sep 13 2021 at 20:16):

And that means we don't need to insert channel type logic into Adam 's fhirpath expression.

Last updated: Apr 12 2022 at 19:14 UTC