Benefits of using Event vs Search Criteria for Pub/Sub

[Healthedata1]

On our call today we discussed this topic and its not clear whether using a Subscription with a scheduled search criteria of is any different or better or worse than event trigger ( what would the event be?). I am assuming slots are updated continuously so any subscription that pushes slots would be batched based upon some time interval in either case. ( Should that batch period be an element?)

so one could imagine a search based trigger as follows (FHIR sub/pub is 'cold')

• initial load of all slots for X ( expose only open slots to end user)
• subscribe with criteria "search for all slots for X" ( catches all slots that change from open to closed or vice versa, or new slots)

We did note that deleted slots would not be updated and the end user might discover that she cannot book the appointment that is listed as available. So we may need to repeat initial load every so often to flush out the deleted slots

for events I can only imagine it this way:

• initial load of all slots for X ( expose only open slots to end user)
• subscribe for all slots when event = time to publish the slots?

Assuming deleted slots still would not be updated as above

[brandon-larue-zocdoc]

Scheduled search criteria would still have to account for the updatedSince concept, right? Ex: Give me all events since last search so I can push to the feed? Or some other layer maintain a state and then send only the diffs?

And why aren't deleted slots accounted for? Why is that not just another event that would be part of the search or event based model?

For event based, will there be some sort of time horizon defined? Or will I see events months or years in the future? This will also result in a large number of "slot open" events every ~midnight as days cross this horizon. The server will need to account for this in a different way as they were not explicitly opened by some action, rather they newly met a search criteria. Not sure we can get away from at least some pieces looking like "search" even in an event-based model.

[daliboz]

Are we essentially talking about the difference between CDS Hooks and the existing Subscription model? (I don't think we're trying to roll our own/new thing) I know it was brought up on the call, but there is ongoing work on Subscriptions that could change the way that works in future releases.

[Healthedata1]

The way I understand the FHIR sub/pub model. The publisher would only push slots that changed since the subscriber subscribed - which is the same as updatedSince. The benefit is on the Server side since they can control the times they push the data instead of responding to multiple search requests. I agree that slots will go stale and lots of new ones will be created every day and the Client would need to specify how far into the future they want to look. I am unclear how events would work and why I pinged Isaac for his feedback.

[isaacvetter]

Hey @Healthedata1 ,

My take is that subscriptions are best used for targeted notifications of events. While a FHIR server should probably be able to batch notifications, we shouldn’t try to schedule notifications because that’s functionally the same as using a query to poll. I think that schedules or polling should be discouraged when dealing with events. The ability for the subscribing app to specify the criteria/filter is what’s most valuable about Subscriptions – not just slurping a ton of data out of a FHIR server.

The basic idea with using event-based Subscription is that the subscribing app specifies both an event and a search-based filter or criteria.

The event is represented as an EventDefinition resource. The EventDefinition resource contains a snippet of FHIRPath (or CQL). Here's an example Fully capable FHIR servers could allow subscribing clients to both create an EventDefinition, specifying their own FHIRPath to be executed and then subscribe to that event. Less fancy FHIR servers could simply statically publish well-known EventDefinitions ahead of time.

The criteria / filter is represented as a FHIR search (just as it's documented now in the spec). The criteria "filters" the event, such that the subscribing app only hears about the instances of that event that it cares about.

Using FHIRPath, it's definitely possible to refer to things in the past. Note that Bryn's example eventdefinition does exactly this. This will allow you to subscribe to recently deleted Slots.

Your question of -- how far in the future should the FHIR Server publish future slots? That's a tough one. In reality, the scheduling software probably instantiates templates only when a user attempts to put an appointment within a future slot, right? How about doing it then?

[Healthedata1]

After discussing this over the past 3-4 weeks. I don't see any clear cut benefits for either the client or server for Subscription vs Pollling for slots when doing a Pre-Fetch:

Issue	Polling	FHIR Subscription
Need for an 'initial load' of slots	Maybe	Yes
Able to get jsut a diff?	Using an "updatedSince parameter	Yes ("cold" sub)
Deleted slots discovered	Yes	No
New slots discovered	Yes	?
Search Based	Yes	Yes
Event Based	No	Yes
Batching	Yes	No
Support	REST	Rest-Hooks/websockets
Patient PHI	NO	NO
Authentication	SMART on FHIR authorization	SMART on FHIR authorization/messaging ?

[Healthedata1]

I think our polling based options are:

1. Stick to search based polling operation for pre-fetching open slots

   • which is just a periodic overwrite of all open slots

2. or 1. + updates using an updatedSince param that Brandon suggests (ty!)

   • FHIR already defines this here: http://build.fhir.org/http.html#history which selects resources that have been created, updated, or deleted. Assuming the server supports versioning, a client system wishing to know what resources have been created/updated/deleted, can intermittently perform a history request including the _since parameter. e.g. , GET [base]/Slots/_history{?[parameters]&_since=[instant]&_format=[mime-type]}
   • would need all statuses to find new opens and removes deleted and status not = open.

[Healthedata1]

One other thing with pre-fetching slots would need some business rules to go along with them to create valid Appointments

• Additional transaction - possibly a GraphDefinition Resource in FHIR or something else or an out of band exchange.
• I think we need to document this as a need but is future scope for the IG

Thoughts?

[Healthedata1]

We have not really dived into the slot search during a pre-fetch:

slots searches

For prefetch would need to retrieve the slots for all the participants in the service:

e.g. the room, the nurse, the doctor, the machine.

So these 2 questions need to be answered:

1. what are the slot search parameters

   options:

   • by category or some tag - fetchable slots, ?
   • by service-type* or a constrained list of 'visit-types' ( see Github issue #39)
   • appt-type
   • specialty
   • start-time*
   • schedule
   • status*
   • schedule

Example:

- Fetch all the open slots with a start time 'A' and I as the client will figure it out.
- Fetch all the open slots with a start time 'A' of some category 
-Fetch all the open slots with a start time 'A' for these 'visit-types'

2. Is this a search or an operation?
   • There is an issue with the "visit-types" conflating service and appt type in the resource. see Issue #39

[brandon-larue-zocdoc]

I would say the "Need for initial load" for polling is a clear No, as the first search would not pass an updatedSince and just get all open slots within the search range. This could also be done to recover from any downtime events or other edge cases, and performed purely on the client side. This way you build one piece of functionality to account for both initial loading and ongoing updates.

For parameters, you'll want a startDateTime and endDateTime to determine the search "window."

[Healthedata1]

Decision to go with Polling for updated slots. "option2"

[Healthedata1]

applied pub/sub for prefetch scenario