Stream: subscriptions
Topic: outbound events
Jens Villadsen (Sep 05 2017 at 12:29):
Imagine the following flow:
When the client issues a subscription, the server acknowledges the subscription and returns a bundle including the subscription as well as the evaluated result of the criteria (initial result set). Now, whenever a change occurs that would result in a different result set according to the criteria, a change/update is sent - this could be either an update, create or delete on one of the resources in the set. If this is done e.g. over Server-Sent Events (SSE) or Web sockets, order is also guaranteed over the same connection without having the server deal with a client behind a firewall. Clients will therefor not need to ever query again for the given criteria/predicate, meaning that the clients can be developed as almost pure event driven applications and that the load for handling queries from clients is lowered considerably. Can you dig it? (While there may be general security issues related to emitting events embedding content, this scheme may be a great fit for own/approved applications).
Just a thought
Jens Villadsen (Sep 05 2017 at 12:29):
@Grahame Grieve there you go
Brian Postlethwaite (Sep 05 2017 at 22:17):
Is this the equivalient of the CCOW stuff?
Isaac Vetter (Sep 05 2017 at 22:36):
Hey Brian - yes, but on FHIR!
Brian Postlethwaite (Sep 05 2017 at 23:11):
Looks good, except I'm not convinced on the ImagingStudy, Patient,Encounter properties.
The context of the user session is not always that simple. A session with a group for example, or a mediation session.
Then all the other resource types other than ImagingStudy that could be open
Jens Villadsen (Sep 06 2017 at 06:41):
My description of the flow is pretty generic and could in principle be implemented on any RESTful server that supports an outbound eventing mechanism. I can't see why CCOW shouldn't be supported in some FHIR'ish way
Isaac Vetter (Sep 06 2017 at 12:47):
Looks good, except I'm not convinced on the ImagingStudy, Patient,Encounter properties.
Yeah, you're exactly right. I think that 0..1 patient and encounter meets the 80+% use-case. We're suggesting ImagingStudy simply because it fits the first use-case.
Would you recommend adding additional elements for each of the other resource types that could be included in a session?
Brian Postlethwaite (Sep 06 2017 at 19:41):
I'd be more likely to suggest something along the lines of OpenResources 0..* (Any)
Brian Postlethwaite (Sep 06 2017 at 19:43):
or maybe a pair:
focusedResources and SupportingResources
Grahame Grieve (Sep 08 2017 at 03:27):
I'm not following this discussion - where did the resource specific stuff come from.
Grahame Grieve (Sep 08 2017 at 03:28):
we could work this by adding an extension to the subscription asking for an initial dump on the specified channel of all the existing matching resources
Grahame Grieve (Sep 08 2017 at 03:28):
this wouldn't work for the topic type subscriptions we're talking about on the other channel
Grahame Grieve (Sep 08 2017 at 03:34):
I figured out where the resource stuff came from - crossing topics.
Last updated: Apr 12 2022 at 19:14 UTC
