Stream: subscriptions
Topic: List Subscription and referenced instance changes
Bill Wallace (Jun 16 2020 at 14:46):
How should the R5 SubscriptionTopic look like for a List? In specific, suppose the List has a few different types contained in it, say ImagingStudy, DiagnosticReport, Observation and ServiceRequest. How would one create a single topic that allowed one to get add/remove notifications from the list for specific items. That is, I'd like to see something like the notification from https://build.fhir.org/notification-id-only.json.html but with enough information in it to tell what item is being affected, and whether it is getting added, removed or updated.
One option is to just have four subscriptions/topics, but that explodes quickly as the number of referenced types increases, and the topic should be on the List, rather than being on the child objects.
Another option is to allow the notification to include the id of the parent element, but also the id of the referenced element to be monitored, as a "subTopic". The subTopic names would correspond to particular id's in the resourceTrigger (which would become a multi-valued element)
Also, the resource trigger would need to add a new type beyond create, update, remove, which would be of type "include" or "revInclude".
"topic": "http://example.org/FHIR/R5/SubscriptionTopic/admission",
"subTopic": ["listAdd", "remove"]
}
},
{
"fullUrl": "https://example.org/FHIR/R5/List/2",
"request": {
"method": "PUT",
"url": "List/2",
"subTopic": [{ RESOURCES_FOR_ADDED_ITEM - as ID or as full item }]
},
"response": {
"status": "201"
}
Lets see if there is any interest in this first before it gets further fleshed out, but having some way to monitor general lists of references in objects seems like a useful approach, and being about to add multiple identified resource triggers as a "subTopic" seems to be one way to accomplish this. I'm not sure this is quite right yet, but having some way to get the include/revInclude changes seems fairly important, and this mechanism also gives a way to distinguish between create/add/delete events when multiple ones get listed. Sometimes that doesn't matter, but it can be important if you want to distinguish those.
Gino Canessa (Jun 17 2020 at 16:39):
Hi Bill, I've been mulling this over to make sure I understand the use case and the workflow proposed. Largely, I am struggling with how much of this belongs in the subscription specs.
For example, if a subscription topic is for update on List, every change to that list would be sent to the client, who could compare the 'last' known version with the current version of the list and process from there. This is far simpler for the server, and only marginally harder for the client.
Alternatively, there could be an IG for this, which could define an extension on Subscription to add the additional information. E.g., use the same update on List, but only when the List.entry meets additional criteria.
Overall, I'd like to think on this a bit more (DevDays is using a lot of mental bandwidth this week), but also wanted to respond. My gut reaction is that this feels heavy for something that appears to be a narrow use. I'm not opposed to being convinced, I'm just not there yet.
Josh Mandel (Jun 17 2020 at 16:46):
Yeah, my take has been: if we can get Topics working in R5, we'll be off to a good start. I'd push off a serious discussion of sub-topics until we get some experience with Topics.
Last updated: Apr 12 2022 at 19:14 UTC
