Using update polling for prefetching when systems don't use slots

[Healthedata1]

How to represent "Null" availability using the update polling approach which is an issue for systems which don't have a concept of slots?

e.g. chunk of time (9-12) is open but not represented by slots in Server. So when a piece of that time is booked (say for example 9-10) it is represented by a smaller chunk of time (10-12). How to represent this using update polling mechanism?

Options:

• reallocate chunk of time as new slot and delete old chunk of time represented by old slot ???
• treat as a caching problem and cache reconciliation
• Use a more event driven i.e.,subscription/messaging paradigm. Repackage and resend updated slot package when triggered by an booking event.

[brandon-larue-zocdoc]

This is actually a problem for any implementation where the Slot search for updated information (diffs) only has a way to return open slots.

If I send a request for updated slots on a particular day, and a newly opened slot has appeared since my last request, it is easy to return that newly opened slot as the diff and let the client append it to their prefetched availability. But if I query for that same day, and a slot is no longer open that I had previously fetched, what does the server return?

In a slot based system, it could return a value for that removed slot with a new status (booked, blocked, etc.) but I don't believe we've articulated this anywhere. And I believe we also specified that the call should explicitly request slots with a status of "free." But that doesn't account for other potential deletion/invalidation events such as merging slots, closing schedules entirely, etc., where the slot object itself has been removed from the system (rather than a simple status change).

This is also an issue for Option 1 in your list here. What does the deletion look like?

[Healthedata1]

I updated the assumptions for the Prefetch Option and corrected a big error in my example.

• Assume that the FHIR Server maintain a version history
• My error in how I documented the update polling - this an interaction and not a search so doesn't take any search parameter like I had previously documented.

so in a nutshell get all Slots that have been updated, deleted and added. including Slots you may not be interested in.

GET [base]/Slot/_history?_since=[last-update]

[Healthedata1]

So to answer the above question. the update polling looks at all slots an does not filter on status = open. These slots need additional filtering to determine which are add, deletes, etc. If the system is unable to expose the history then this won't work and you are left polling or pub/sub which could be triggered by status changes or event driven. Certainly worth fleshing out some more!

[Healthedata1]

this is is superseded by #59