Stream: subscriptions
Topic: Detecting data that no longer qualifies
Jenni Syed (Sep 30 2018 at 16:08):
@James Agnew @Isaac Vetter @Christiaan Knaap Some discussion here at the table with @Grahame Grieve around changing the notification rules for servers. Challenge: A subscription right now will notify on v1 of a resource, but then an update (or delete) to that resource may make it no longer qualify. When that happens, the current spec calls out that there won't be a notification.
Jenni Syed (Sep 30 2018 at 16:09):
Proposal is to make it so that a server will notify on change when the current version qualifies for the subscription or the previous version did so that scenarios like this can be caught
Jenni Syed (Sep 30 2018 at 16:10):
IE: I create a subscription for all temperatures that are over 105 F. A nurse charts a temp that qualifies. Subscriber is notified. Nurse later goes in and updates that b/c she had a bad reading or fat-fingered and changes it to 104 F.
Jenni Syed (Sep 30 2018 at 16:11):
On the previous subscription, that 104 wouldn't trigger a notify, so the subscriber won't know that something happened that they likely care about. With the new requirement, they would be notified since the previous version of the resource qualified.
Jenni Syed (Sep 30 2018 at 18:32):
@Grahame Grieve One gotcha we were discussing with @Christiaan Knaap is that the _list and other "referential" queries could complicate this logic. IE: you now have to know that it no longer qualifies because the content of a referenced List or value set changed.
Jenni Syed (Sep 30 2018 at 18:33):
Also, will we detect that something no longer qualifies because you're no longer authorized to view??
Grahame Grieve (Sep 30 2018 at 18:56):
I have no idea about the second permissions question
Grahame Grieve (Sep 30 2018 at 18:56):
wooah. Someone's asking the hard questions
Grahame Grieve (Sep 30 2018 at 18:56):
the first.... you remove things from your criteria... the kind of things you get notified about change. The subscriber gets to deal with that
Christiaan Knaap (Oct 01 2018 at 19:42):
Imagine client A starts a subscription on Observation with criteria based on a List (either by the _list parameter or a regular reverse reference). And now client B changes the list. How is client A supposed to deal with that on it's own. The server will have to detect that the client A needs to be notified of Observations that are now in the list or are no longer in the list. Possible but potentially costly for generic servers. Not sure whether it is at all possible for 'facades' like those on the EHR systems.
Brian Postlethwaite (Oct 01 2018 at 19:52):
If A isn't controlling the list, then they might want to have a subscription on that too
Isaac Vetter (Oct 01 2018 at 19:53):
<deleted>
Jenni Syed (Jan 12 2019 at 18:13):
It looks like we forgot to get a tracker on this. @Grahame Grieve I don't see anything in the r4 release about this - it says the same caveat about deletes. I can log a tracker assuming there isn't one.
Grahame Grieve (Jan 12 2019 at 19:05):
right. nothing changed in R4
Grahame Grieve (Jan 12 2019 at 19:06):
we talked about delta based subscriptions - back in Madrid, actually, but then the talk stopped
Jenni Syed (Jan 13 2019 at 19:48):
After the discussion offline with Grahame, logged GF#19976 to clarify the complexities, including adding an example about the security use case
Last updated: Apr 12 2022 at 19:14 UTC
