Stream: subscriptions
Topic: Get notifications of admission/discharge/transfer
Michele Mottini (Mar 28 2019 at 20:58):
How would one setup a subscription to get notification of admissions, discharge and transfers? Use simply Encounter and get all new / modified encounters?
Elliot Silver (Mar 28 2019 at 21:52):
That won't work, since not all encounters are admissions. You'd have to figure out how to discriminate admission Encounters. (When you do, please let me know how, as I've been struggling with how to distinguish those in another context.)
Michele Mottini (Mar 28 2019 at 22:21):
Admission encounters have a period with a start date but no end date - and possibly an 'inpatient' class
Michele Mottini (Mar 28 2019 at 22:21):
Discharges modify the encounters to have an end date
Elliot Silver (Mar 28 2019 at 22:21):
My understanding is that other encounters within an admission also have those characteristics.
Michele Mottini (Mar 28 2019 at 22:24):
OK - that would just make the situation worse... my point is that there seem no way to define these criteria as searches, so the only way to setup subscription is getting all modified encounters and sort them client-side - or is there something I am missing?
Elliot Silver (Mar 28 2019 at 22:25):
Not from what I can tell, but maybe you'll get more eyes on this in the implementers stream. Identifying admission/discharge encounters isn't subscription-specific.
Michele Mottini (Mar 28 2019 at 22:27):
My question is about how to setup notifications - assuming that there is a criteria
Michele Mottini (Mar 28 2019 at 22:28):
Because it seem a pretty common / basic use for notifications
Michele Mottini (Mar 28 2019 at 22:29):
(subscribe to ADT)
Josh Mandel (Mar 29 2019 at 03:37):
One question is always whether it is possible to subscribe to a slightly broader group of events. Like all changes to the encounter resource, and then you might apply logic down stream based on the location or other attributes that you care about in your specific scenario.
John Moehrke (Mar 29 2019 at 13:03):
Im with Josh, for subscription it is not going to be that noisy. Far better to get notifications that you can locally process, than to have a false-negative miss a change you should have known about.
Michele Mottini (Mar 29 2019 at 13:42):
OK, yes, that was what I got at: subscribe to all encounter (or maybe all inpatient ones) and have the client sort out things
Michele Mottini (Mar 29 2019 at 13:44):
The alternative I can think of not to burden the client is to have the server implement whatever algorithm to detect ADT and put the resulting encounters in a list, and have the client subscribe to changes to the list (that I think is possible?)
René Spronk (Mar 31 2019 at 14:47):
Messaging might be a better option than subscription, perhaps ? ;-)
Nick Hatt (Mar 31 2019 at 15:06):
Messaging and Subscription are not mutually exclusive. Subscriptions are for when you want criteria to live on the FHIR server. As the Subscription spec is now, Messaging is an option for delivery. To me, Subscription is probably overkill for most servers to implement at scale without slicing the allowed criteria down a bunch. If it's possible getting all data and filtering on the client side is probably the easiest solution for both ADT producer and consumer.
René Spronk (Apr 01 2019 at 04:20):
Largely agree - however, with messaging the sending system may (easily) base its trigger events on information/context it is aware of (e.g. user selecting some GUI button), information which isn't captured as part of FHIR resources, and as such can't be (easily) detected by a receiver.
René Spronk (Apr 01 2019 at 04:24):
A way around that would be if one could subscribe to "trigger events known to the sender", ones that could be specified in non-FHIR specific terms (like a search URL or FHIRPath).
This is probably already an option if I were to subscribe to an 'operation/named query based URL' which is related to the server side trigger event.
Michele Mottini (Apr 01 2019 at 09:43):
A bit of background on my question: in most (all?) of our installation we get ADT data via HL7v2 feeds, now we have customers developing solutions on top of our FHIR API, and they want / need some way to get notifications of 'interesting' things - without having to constantly poll for changes, and the interesting thing at the top of the list is ADT
Michele Mottini (Apr 01 2019 at 09:44):
The possibilities seem: subscribe to all Encounter (or all inpatient Encounter) changes - that is not much better than polling though
Michele Mottini (Apr 01 2019 at 09:45):
Or use some kind of custom server-side logic to detect ADT (maybe just linked to the incoming HL7v2 feeds) and base subscription on that - probably via FHIR List
Michele Mottini (Apr 01 2019 at 09:46):
The latter would be @René Spronk 'subscribe to "trigger events known to the sender"' if I understand correctly
René Spronk (Apr 01 2019 at 14:12):
@Michele Mottini yes, exactly.
John Moehrke (Apr 01 2019 at 14:29):
IHE is building both into their current FHIR IG on patient id management. We recognize that some want a classic long-standing messaging configuration, and some want an occational or dynamically initiated subscription. I do expect the list of things to subscribe to will be very small to begin with. @Luke Duncan @Ben Levy
Brian Postlethwaite (Apr 03 2019 at 12:09):
Wouldn't the non admission encounters be a part-of the admission encounter? (where in patient too I suppose)
so Encounter?partOf:missing=true
Last updated: Apr 12 2022 at 19:14 UTC
