Stream: smart/scheduling-links
Topic: Capacity when slot is busy
Cooper Thompson (Mar 11 2021 at 19:32):
What is the intent of the capacity extension when a coarse grained slot is full (status=busy)? Should we report how many slots were previously available? Or how many appointments were booked in that coarse grained slot? Or 0 indicating there is no longer any capacity.
Example: 300 slots were available for 100 doses. 100 appointments have been booked, and the remaining slots are unavailable for booking. Should the capacity be 300, 100, or 0?
Brett Marquard (Mar 12 2021 at 13:49):
My immediate reaction is zero. But I would love others to chime in.
Josh Mandel (Mar 12 2021 at 13:51):
The intention of the capacity extension is to aggregate functionally identical slots.
Josh Mandel (Mar 12 2021 at 13:52):
What this means here is in a fine-grained world we would have a pile of individual slots for vaccination appointments that were either available or booked. Let's say you had 100 slots in the day and 70 were available in 30 were booked. That would be 100 slot resources.
Aggregating slots is intended as a pure performance optimization; so if you are lumping things together, you would have a slot with status of busy and capacity 30; and a slot with a status of open and a capacity of 70.
Josh Mandel (Mar 12 2021 at 13:54):
That said, looking at your example @Cooper Thompson:
Josh Mandel (Mar 12 2021 at 13:54):
I would expect to see a capacity of 100 on the busy slot. (Because if you were doing this with fine-grained slots, you would be causing the 200 "no longer possible" slots to disappear from the schedule or marking them with an entered an error status when you determine if they were no longer viable on your schedule.)
Josh Mandel (Mar 12 2021 at 13:58):
As a thought exercise, you could imagine creating an aggregated slot with capacity 200 and a status of "entered-in-error", which would show you how "slots are conserved" across all these changes -- but I don't see any advantage to actually materializing this in your published list.
Josh Mandel (Mar 12 2021 at 14:00):
My usual questions apply:
- Is this explanation clear?
- Is it reasonable behavior to expect?
- Should we document something additional in the spec to capture this?
Brett Marquard (Mar 12 2021 at 15:56):
Definitely should document this scenario in the spec.
Cooper Thompson (Mar 12 2021 at 17:57):
I think our first draft may just omit the capacity extension on busy slots. I need to chew on the Slot representation implications Josh was suggesting a bit more. Our data model for slots is just so different than the FHIR Slot model it gets hard to think about how to map things into it.
Cooper Thompson (Mar 12 2021 at 18:11):
Our issue is that we might have a single (Epic) slot that can be available for multiple purposes. It could be available for a COVID vaccine (1st dose), COVID vaccine (2nd dose), a (non-COVID) well-child visit, or (non-COVID) a existing patient office visit. Those different purposes might have different lengths (COVID 1st dose shots are 5 mins, 2nd dose are 10, well child is 15, office visit is 30). Generally, we could expose that one timeslot as four different Schedules, with multiple different Slots (of varying lengths) that represent the same time for a given person (or group of people). Also, the person may have limit that says they have 32 15-minute slots available during the day, but are only willing to book 30 slots (so they have time for lunch or charting or whatever). There may also be a limit on the number of COVID 1st dose appointments based on the number of vials available. Once the time on the schedule is booked for one of the 4 purposes, or if the daily limit is hit, or if the vial limit is hit, then we need to deactivate all the other slots associated with that time. This may be more than 4 slots, since the slots have varying length. E.g. we might have exposed 20 COVID vaccine slots for a given hour, but only 2 slots in that hour for the office visit. If we book an office visit, that will "cancel" 10 COVID vaccine slots.
Josh Mandel (Mar 12 2021 at 18:16):
Generally, we could expose that one timeslot as four different Schedules, with multiple different Slots (of varying lengths) that represent the same time for a given person (or group of people)
Yes, that makes sense. Indeed the examples you give here seem perfectly reasonable. What conclusion does this drive towards? I think (as suggested above) removing slots from your COVID schedule when you determine they're not going to be used for COVID vaccinations seems right (so that slots on the COVID schedule are either booked for COVID vaccinations or are available to be booked for COVID vaccinations). Is there a different approach you'd prefer?
Cooper Thompson (Mar 12 2021 at 18:19):
Ok - so the capacity is just the sum of Appointments that are booked with that specific type of slot, and is not really related to the capacity that was listed on the coarse-grained slot when it was "free".
Josh Mandel (Mar 12 2021 at 18:22):
I like to think about this from a granular perspective first (for intuition at least): If you start with 300 free slots on your COVID schedule, and you book 100 of them, and you cancel 100 of them, then you have:
- 100 available slots and
- 100 busy slots
And sure, you can collapse the 100 busy slots into a single coarse-grained slot, but the meaning is the same: a booked capacity of 100 on your COVID schedule.
is not really related to the capacity that was listed on the coarse-grained slot when it was "free".
I'd describe this as "related"... but we may be splitting hairs over wording here, if we agree on the interpretation :-)
Cooper Thompson (Mar 12 2021 at 18:49):
By the "not related" part, I meant that you could have a free capacity of 300, but a busy capacity of 0, 50, 100, 200, or 300 depending on what happened with other Schedules. If you have a free capacity of 300 for COVID vaccines, but all that time gets consumed by non-COVID appointments, then the coarse "busy" slot for the COVID schedule would have a capacity of 0, and it wouldn't be obvious to a client where that 300 capacity went, since it would be on unrelated Schedules (that we aren't planning to expose). And the other schedules might use different duration appointments, so even if you knew about the other Schedules, the counts wouldn't add up.
Josh Mandel (Mar 12 2021 at 19:02):
Gotcha -- and yes, I think that makes sense. (I'm not hearing a proposal for a different approach, right?)
Cooper Thompson (Mar 12 2021 at 19:30):
I'm not proposing something different, I think I just want omitting capacity on busy slots be ok. Right now, the spec makes it optional, so I think I'm fine.
Josh Mandel (Mar 12 2021 at 19:31):
Sure, but to ask differently: is there something our spec might say instead that would cause you to be comfortable with (or more likely to start) communicating booked capacity details?
Cooper Thompson (Mar 12 2021 at 20:02):
Right now, my main reason for not sending it for busy slots is an internal issue (partly performance, partly internal complexity and short timelines). It might be worth clarifying what capacity means for a busy coarse slot, but that clarity, or lack thereof, wouldn't change our behavior, at least in our first draft implementation. We will be sending capacity for free slots.
Josh Mandel (Mar 12 2021 at 20:13):
Thanks, appreciate the clear and direct perspective on this!
Ryan Owens (Mar 17 2021 at 20:53):
FWIW, my organization will have some of the same challenges as Cooper's. Slots can effectively disappear for a number of reasons which we do not intend to expose through this feed.
Josh Mandel (Mar 17 2021 at 22:12):
That makes sense re: slots disappearing (e.g. because they drop off of a schedule altogether); but @Ryan Owens are you saying that you (like Cooper) wouldn't be able to publish information about any booked slots?
Ryan Owens (Mar 18 2021 at 14:03):
I can't say for sure about that at this time, but our position from the very first sample format (prior to moving to FHIR) was that we would prefer to not publish the number of total slots or filled slots. Our preference was to publish a relative level of available slots such as "available, limited or none" as trying to publish accurate, meaningful numbers introduces a variety of challenges.
Josh Mandel (Mar 18 2021 at 14:10):
Gotcha. We have a precise way to say "none" already ;)
If it's useful to define an additional extension for concepts like limited versus somewhat limited versus lots of capacity we can do it, but I worry that interpreting these values would be difficult in the context of different sites (say, for small clinics vs mass vaccination sites).
If we instead said that slot capacity could be populated with a best effort estimation, would this be an improvement in your view @Ryan Owens ?
Henry Wei (Mar 19 2021 at 22:28):
Hi; popping into this thread after a kind USDSer activated this ex-PIF. :)
One UX research finding from providers I’ve seen is that “best effort” should degrade gracefully — eg FHIR R4 Slots and an analogous IETF standard are very specific in terms of exact times, but “not available Tuesday” or “available Friday morning” are good concepts to represent if the provider — sometimes a mom and pop shop — uses a proprietary CRM system, or doesn’t use a full-bore calendaring system or EHR.
The other finding is that “next availability” is often a good minimally-viable field to consider, rather than trying to aim for all availability. While this sounds insufficient, when refreshed often it provides people searching for availability with a lot of utility when multiple locations / results are returned.
Thanks,
Henry
Last updated: Apr 12 2022 at 19:14 UTC
