FHIR Chat · Tagging Batched/Included Resources · subscriptions

Stream: subscriptions

Topic: Tagging Batched/Included Resources

view this post on Zulip adam strickland (Jul 29 2021 at 17:57):

Hi @Gino Canessa , I've been thinking about the tagging scenarios we spoke about yesterday and had some ideas. Overall these are the scenarios we're trying to cover:

  1. Batching - where you send multiple events as a single notification
  2. Including - where you conduct _include directives for every notification and add to the notification
  3. Including and Batching at the same time!

We're starting with the assumption that you cannot list a given resource more than once in a bundle, and so needing to reference a resource more than once in a bundle means you need to tag that resource somehow (I'm going with an id-only perspective for now, but unclear how more/less complex 'Full Resource' is).

I have some ideas/examples in this gist based on your focus/grouping examples. Let me know what you think.

view this post on Zulip Gino Canessa (Jul 29 2021 at 18:14):

Hi Adam, thanks! Though one of us has the logic backwards =). My understanding is:

  • The focus is needed if there are included resources. E.g., if the focus is an Encounter, but additional Encounter instances are included, a receiver has no way of knowing which one triggered the notification. Because this is a very lightweight addition, I am leaning towards making this 'always' instead of 'sometimes', in order to simplify usage.

  • Tagging Bundle.entry with an event number is only needed if you are batching multiple events together (so that a receiver can tell which resource / resources belong to which event). Since this is an 'advanced' scenario (e.g., a server that wants to batch requires additional logic anyway), I am leaning towards leaving this extension as 'optional'.

Does that sound correct?

view this post on Zulip adam strickland (Jul 29 2021 at 20:44):

Yeah I accidentally flipped the logic compared to what you initially wrote, for 2 reasons:

  1. We need the focus for batched notifications, in the case where a single resource needs to be included more than once (IE, the focus of multiple events in the bundle). The resource would show up multiple times in the focus, but only once in the entry. Unclear how focus would handle versioning for full resource payload types though.
  2. If we insist on focus being present for batched notifications, we no longer need to tag focus entries with an event. We can know immediately that a resource was the topic for a specific event. We could then just use a tag when a resource was included, and for which event.

I'm not sure if my re-structuring is any better :grinning: . To clarify, in your scheme how do we indicate in a batch that a resource was the focus of more than 1 event?

view this post on Zulip adam strickland (Jul 30 2021 at 15:19):

I think there's a third option as well. Instead of focus and entry-tagging as 2 separate handles, we could introduce 2 different entry tags:

  1. A foucs-for-event tag that tells you this was the focus of a given event, and could be repeated multiple times if a resource was the focus of multiple
  2. An included-for-event tag that tells you this was included for a given event, and similarly could be repeated multiple times.

I feel like having these 2 tags is generic enough for both the id-only and full resource use cases, since we don't have to figure out how to include versioning in the focus header.

view this post on Zulip Gino Canessa (Jul 30 2021 at 17:55):

Yes, I think I like the two extensions better too. To be clear, I don't like two extensions, just that it gives the best usability. Also, if we get enough experience with them in R4, we may be able to propose adding them to R5 as STU elements on bundle instead of extensions (particularly if we make them generic enough).

To that end, how do you feel about something like focus-of-group and in-group?

edit: with the group being the event number in this case

view this post on Zulip Josh Mandel (Jul 30 2021 at 18:09):

I think something like subscription-notification-focus-for-event and subscription-notification-included-for-event (or... something that adds words like "notification" or "event" that align with the concepts we define in our docs) would be good. (e.g., we have a property called SubscriptionStauts.eventsInNotification, and we should ideally re-use some of these words)

view this post on Zulip Gino Canessa (Jul 30 2021 at 18:11):

Fair

view this post on Zulip Josh Mandel (Jul 30 2021 at 18:20):

(To be clear, I'm not suggesting these super-long names directly; they're a bit of a mouthful ;))

view this post on Zulip Gino Canessa (Jul 30 2021 at 18:29):

Yep - I was thinking about trying to name them in generic ways as a favor to 'future me', when I want to propose making them either standard extensions or trying to add a set to Bundle. But in reality, that's irrelevant to the current use case so would be better to deal with in the future.

view this post on Zulip Steve Atwood (Jul 30 2021 at 21:57):

FWIW, I feel like some of the awkwardness here stems from the fact that the Bundle is trying to represent a collection of "events" along with related resources, but there isn't actually a great representation of the event itself. For my implementation, we are internally using the AuditEvent resource type to model the actual event itself, which provides a natural grouping structure since it can include a list of references to the "focus" resource as well as any related resources. This also allows us to capture additional metadata about the event itself (rather than the focus resource) such as timestamp, event id, etc. Admittedly, AuditEvent is a bit heavy, has too many required fields, and is not really optimized for this use case, but just wanted to put that out there as food for thought. I feel like the lack of a structure to separate the "event" from the "resource" is part of the challenge here.

view this post on Zulip Josh Mandel (Jul 30 2021 at 23:16):

That's interesting. Do you have examples (or could you sketch one) of how you use AuditEvent to represent a focus + related other resources?

view this post on Zulip Steve Atwood (Aug 09 2021 at 22:09):

@Josh Mandel sorry for the slow response - was on vacation last week. I mocked up a fake example of a subscription bundle with AuditEvent payload here: https://pastebin.com/15SqXM1V . The "entity" array provides a way to group multiple resource references for the single event and the "entity.role" allows us to identify the role played by each resource. I also like that the FHIR reference data type used in "entity.what" offers flexibility to use a "logical identifier" (e.g. patient SSN in my fake example) for scenarios where we don't have a literal reference to a resolvable FHIR resource but still want to convey some useful information for the recipient to look up that entity by some other means (FHIR or non-FHIR).

Last updated: Apr 12 2022 at 19:14 UTC


An HL7 Website -