Stream: subscriptions
Topic: Subscription notifications with 'includes'
Lloyd McKenzie (Sep 11 2020 at 14:53):
We're looking at using subscriptions for Da Vinci CDex, where the subscription would be to monitor the Task that had solicited a set of information. We'd want a subscription notification to fire when the Task was updated, whether to link to a status or to point to the requested data. I created some examples based on the subscription R4 IG. One thing I wasn't super sure about was how to handle 'included' data in the notification. Specifically, if the subscription notification includes data, we'd want not just the Task that had been updated (which would have a Bundle.entry.request.method of PUT), we'd also want the record(s) that the Task pointed to with Task.output (e.g. DocumentReference, Observation, whatever). At the moment, I'm using a Bundle.entry.request.method of 'GET' for this. See https://build.fhir.org/ig/HL7/davinci-ehrx/Bundle-subscription-notification-with-document.json.html for an example. My questions:
a) Is it legal to pass back both the 'focus' of the subscription as well as certain related resources?
b) If it is legal, how does the SubscriptionTopic define what comes back? (And is it configurable at the time you subscribe?)
c) Is GET the appropriate method to list for a resource that's just 'included' but wasn't (necessarily) modified as part of the event that triggered the notification?
(@Matthew Chambers FYI)
Josh Mandel (Sep 11 2020 at 15:09):
I don't think we prohibit returning additional bundle entries beyond the "event triggers" responsible for the notification, but...
1) We don't specify how to ask for them / how to describe the inclusions, graph links, elements, etc that you want. Our plan has been to leave this out of scope for R5 (but you could handle it with an extension on the SubscriptionTopic)
2) We don't have a way to differentiate Bundle entries that count as "events" from Bundle entries that are "extra," so you'd want to be sure to differentiate these. Our plan has been to define something similar ("TODO: Each entry must be annotated to indicate whether it was gather before or after the event which caused the notification....") so perhaps this could be generalized to tag things as extra.
Lloyd McKenzie (Sep 11 2020 at 15:51):
Is there any intention to standardize a mechanism for such tagging in the R4 backport, or are we skipping it for now on the grounds that the specific mechanism hasn't yet been landed for R5?
Josh Mandel (Sep 11 2020 at 15:59):
TBD as far as I'm concerned. But in principle the point of the back-port is to take stuff we think is sorted out for R5, and shoehorn it into R4. Given that we think there's some TODO left for R5, I think it'd be fair game for the backport.
Gino Canessa (Sep 11 2020 at 16:03):
My logical preference is that any changes happen in R5 first and then are reflected in the backport.
That said... :shrug: if it's something we feel needs to be defined (so far there has been resistance to defining it), I'd probably be putting the changes in both at the same time for testing.
Grahame Grieve (Sep 11 2020 at 16:10):
Gino and I talked about using a GraphDefinition for this but people are obviously shy of all the complexity for all sorts of good reasons. but the complexity is real
Gino Canessa (Sep 11 2020 at 16:13):
Yep - IIRC my thoughts were to add to the SubscriptionPayloadContent set to signify additional modes.. potentially GraphDefinition, GraphQL, etc..
Gino Canessa (Sep 11 2020 at 16:14):
Though we also tossed around another field/extension so you can do fun things like GraphDefinition id-only vs full resource
Gino Canessa (Sep 11 2020 at 16:28):
For reference, there was also discussion (and I don't recall a resolution) whether those definitions would live in the Subscription or SubscriptionTopic. @Lloyd McKenzie , this would be for part b of your question - what does your use case need? I can see:
- topic includes a single definition
- topic includes a set of definitions to choose from in the subscription
- subscription allows arbitrary definitions
as all being viable to define. Haven't played with it to figure out implementation differences, but what would you be asking for (all else being equal)?
Lloyd McKenzie (Sep 11 2020 at 16:43):
We're just starting to explore, so not completely sure what we need. My guess is that ideally we'd have two configurable options - Task only or Task + a defined set of data. I'm pretty sure we'd be satisfied with a hand-wavy textual description of what the includes were - no one on EHR or payer side would implement GraphDefinition to figure out the data inclusion programmatically. The specific topic would get hard-coded - at least for the near-term. Whether Task-only and Task+outputs were one topic with separate definitions selectable at time of subscription or whether they were separate topics, I'm not sure much matters. I suspect the latter would be less complex, but it makes for a longer list of possible topics. Given that in my use-case, we're not browsing a topic registry, that doesn't much matter.
Gino Canessa (Sep 11 2020 at 16:50):
Fair enough. Since I'm not familiar with Task usage, would something like include chaining work?
Lloyd McKenzie (Sep 11 2020 at 16:51):
Yes, the intention is that it would be based on _include. (At the moment the needed search criteria to chain on Task.output isn't defined in core, so the IG would need to define one for R4, but that's easy enough. Change request is in for R5.)
Josh Mandel (Sep 11 2020 at 16:56):
Bundle.entry.search.mode comes pretty close to differentiating triggering from included resources, but of course it's only allowed on search type bundles today.
Lloyd McKenzie (Sep 11 2020 at 17:00):
Y. In R5, given that we're defining a new Bundle type, I think allowing mode to be included there is appropriate. Even the 'outcome' code could theoretically be relevant. And the semantics of the push are similar to search. Only thing is that search.score doesn't seem to be terribly relevant - could put a constraint only allowing that for Bundle type of search. In R4, we could put an extension on Bundle.entry to convey the search.mode (given that the existing invariant would prohibit it for history.
Last updated: Apr 12 2022 at 19:14 UTC
