Stream: subscriptions
Topic: what's needed to move FHIR Subscriptions forward?
Isaac Vetter (Apr 26 2018 at 13:25):
Hey @Christiaan Knaap , @Grahame Grieve,
We lost some traction with Subscriptions recently, but it's an important an necessary feature for applications. To move it forward in my system, I need a simple, killer use-case. Abstract, wide-open support for criteria as it's currently defined would be a massive development investment that I can't justify.
How can we identify and work together towards a killer app for FHIR Subscriptions?
Isaac
Christiaan Knaap (Apr 26 2018 at 13:45):
I haven't had many subscription use cases at hand yet, but the data update mechanisms I have seen so far often centre around 'changes to the Patients record'. So you should just be able to subscribe to a (set of) Patient(s), and receive an update if anything in their compartment changes.
And using that we could invent a 'Blue Stream': Blue Button + live updates.
Isaac Vetter (Apr 26 2018 at 14:13):
Hey @Christiaan Knaap, "Blue stream" is an awesome name. :)
Subscribing to "changes to the patient's record" as the examplar use-case is exactly why I can't make progress. The patient compartment is some 60 FHIR resources, the vast majority of which we don't yet support (and have relatively low maturity). Further, a "patient's record" is tens of thousands of discrete data elements that are simplified and mapped to FHIR (and other interoperable data models). Developers really don't want to hear about all of these changes, and even if they did the computational cost of informing them, without an additional abstraction layer (e.g. EventDefinition) is significant.
A "blue stream" would definitely be valuable, but it doesn't immediately improve care or solve a pressing need of a health system.
Christiaan Knaap (Apr 26 2018 at 14:18):
Thanks ;-)
For thinking about a killer app we would need to understand better then what is feasible in a real world EHR. Since that is very different from what a generic FHIR Server like Vonk can or cannot easily do.
Isaac Vetter (Apr 26 2018 at 17:22):
Christiaan. No doubt. Happy to talk about this anytime. I wonder if we really need clinical input.
Grahame Grieve (Apr 26 2018 at 20:50):
killer needs to work from both ends...
Isaac Vetter (Apr 26 2018 at 21:09):
ha! point taken, Grahame.
Brian Postlethwaite (Apr 26 2018 at 21:10):
The use case we are going with is the directory synchronization system
Brian Postlethwaite (Apr 26 2018 at 21:10):
Keeping provider registry information up to date. But then that's not from your side as a server
Brian Postlethwaite (Apr 26 2018 at 21:10):
(usually)
Brian Postlethwaite (Apr 26 2018 at 21:10):
The appointment scheduling availability would be another good one I would think
Brian Postlethwaite (Apr 26 2018 at 21:12):
An admission notification app that lets a community care system know when its patients get admitted to a hospital/emergency
Isaac Vetter (Apr 26 2018 at 21:13):
Hey Brian - agree with appointment / slot availability as a use-case. Does the provider directory use-case involve a centralized directory?
Brian Postlethwaite (Apr 26 2018 at 21:15):
(Provider Directory) The case we have, yes there is (and would like it to support in fhir).
And our PD server is also acting as a centralized source too, as it aggregates the content for use downstream.
Brian Postlethwaite (Apr 26 2018 at 21:16):
The Argonaut scheduling work may have some detail on the availability stuff.
Aziz Boxwala (Apr 30 2018 at 23:33):
@Isaac Vetter Sorry for the delayed response. I have been out of zulip for a bit. I have a use case I am working towards now, involving new appointments. New appointments can trigger a variety of workflows including many in systems outside of the EHR. In our project, when there is a new appointment with a particular reason or location, we want to have the patient complete a questionnaire. Often, in these use cases, the appointment is for a procedure.
Isaac Vetter (May 15 2018 at 21:00):
If you're in Germany this week at the wgm, a small group of us are talking about killer use cases for subscriptions tomorrow during lunch. Look for me or @Christiaan Knaap
Jens Villadsen (May 16 2018 at 13:48):
In that case, please have a look at https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=17163&start=0
Jens Villadsen (May 18 2018 at 11:26):
@Isaac Vetter - is the FHIR subscription resource more or less deliberately not part of FHIRcast?
John Moehrke (May 18 2018 at 15:39):
would seem that FHIRcast could work without using subscription... clearly far more reactive if one is using a form of subscription... right?
Jens Villadsen (May 20 2018 at 21:58):
@John Moehrke I don't quite follow ... can you elaborate?
Isaac Vetter (May 24 2018 at 19:59):
Hey @Jens Villadsen - yes ... based on implementer feedback of FHIRcast, we specifically moved away from FHIR Subscriptions. Rationale is here: https://github.com/fhircast/docs/issues/13
Last updated: Apr 12 2022 at 19:14 UTC
