Stream: smart/scheduling-links
Topic: Consumer: VaccineSpotter.org
Nick Muerdter (Apr 21 2021 at 08:06):
:wave: Hi! For background, I’m behind VaccineSpotter.org, which has been trying to collect open appointment information from various pharmacy websites. But I’m really excited to see this effort and want to try to provide whatever help I can from a API-consumer side of things.
So to try and help test, I've put together a demo version of my site that uses only the SMART scheduling data from here: https://smart-demo.vaccinespotter.org I’ve pulled all of the SMART scheduling links I found on the spreadsheet into a test version of VaccineSpotter’s database, just to see how it would work with an existing setup like mine. This version of the site isn’t currently refreshing (since I know a lot of this is test data), but I could easily refresh it things change. And probably of less interest, but the source code is messy and inefficient, but here on GitHub: https://github.com/GUI/covid-vaccine-spotter/blob/smart-scheduling/src/providers/Smart/Appointments.js
Based on putting this together and what I’ve encountered over the past couple months with Vaccine Spotter, I have just a few items of feedback on the overall spec. But I should preface this with the fact that having this spec is amazing! So thank you to everyone involved!
- Time Zones: I don’t see location time zones anywhere in the spec. Technically, you could include timezone offset information in the slot's ISO8601 times, but this isn’t indicated anywhere, and I haven’t seen any providers actually doing this (relying purely on offsets can also get funky around DST). You could determine the time zone of the location from geocoding, but it looks like some providers may also be providing local times but in UTC (eg,
2021-04-21T09:00:00.000Zis returned in the API, but that would be 4AM local time, which doesn’t seem right), so the conversions may not be technically correct if you’re relying on parsing the ISO8601 format. I can dig more into this tomorrow and provide more details about what providers this may affect. -
Dose Numbers: If the schedule extension for vaccine doses indicates doses 1 and 2 are available, I would interpret that as I could either schedule my first or second dose at the specific time slots associated with this schedule, is that correct?
However, one situation that’s maybe semi-related: Is there any way to indicate that the pharmacy can actually book all required doses? I've heard from many users that have struggled with pharmacy websites saying that they have open appointment slots for the first dose, but then once you get further down the booking process, you can’t actually book anything at all because the pharmacy doesn’t have a 2nd dose that’s also bookable at the appropriate time in the future after your first dose. So in these cases, even if a provider has a lot of 1st dose slots open, they may not actually be bookable if the provider requires you book both doses at the same time. So I’m curious if you all have ideas of how this situation could be handled in the spec (if at all), since I know that's been a big pain point. For Vaccine Spotter, I’ve come up with a concept of whether “all doses” are bookable for certain providers, but that involves looking ahead to future time slots, and all of that gets messy, so just wondering if there’s maybe a better way this could be handled.
-
Sub-Brands: This is probably the least important issue and there are potential workarounds, but just thought I’d ask. For certain pharmacy providers, they have many brands their stores might operate under (eg, Kroger has King Soopers, City Market, etc). I realize these providers may choose a variety of ways to publish their data, so this may be a more specific question for them, but I’m just curious if there would be any recommendations for how to represent this data. Ideally, I’d like to be able to easily group the stores by these brands that users are actually familiar with. In the spec, this information may be embedded in the location name, or could be possibly be derived from the location’s URL, but I’m not sure there’s anywhere this is super clearly separated out if you wanted to be able to programmatically handle these type of brands. But this may be out of scope, and that’s also fine.
Sorry this got long! Hope this feedback is helpful, but happy to talk more about any of this if there are any questions. Thanks again for everyone's involvement in this!
Josh Mandel (Apr 21 2021 at 15:10):
Hi @Nick Muerdter -- thanks so much for joining us, and for pusing on the Scheduling Links API and sharing this feedback. I'll break out a few sub-topics here and will @-mention you from them.
Josh Mandel (Apr 21 2021 at 15:18):
Dose Numbers: If the schedule extension for vaccine doses indicates doses 1 and 2 are available, I would interpret that as I could either schedule my first or second dose at the specific time slots associated with this schedule, is that correct?
Yes @Nick Muerdter that's the intention. And if a site wants to break this down into two separate calendars (e.g. to allocate more time for dose 1 slots, for check-in paperwork or counseling) that's fine too.
Josh Mandel (Apr 21 2021 at 15:21):
However, one situation that’s maybe semi-related: Is there any way to indicate that the pharmacy can actually book all required doses? I've heard from many users that have struggled with pharmacy websites saying that they have open appointment slots for the first dose, but then once you get further down the booking process, you can’t actually book anything at all because the pharmacy doesn’t have a 2nd dose that’s also bookable at the appropriate time in the future after your first dose.
To my mind, the advice here should be: publishing a slot is an indication that it's a bookable slot. If you know it's not actually bookable (e.g., because you're going to require a 2nd appointment 4 weeks later and you have none available) then you shouldn't advertise it as a free slot. I'd rather see organizations gravitate toward this kind of workable definition of when to publish a slot, vs spreading complex (and rapidly evolving) business logic out into every consuming application. Would love to understand if others disagree.
Nick Muerdter (Apr 21 2021 at 17:04):
Only publishing slots that are actually bookable (account for future appointment needs) sounds ideal to me. Not sure how big of a deal this is for publishers, but since I know this issue has spanned multiple providers on their current websites, would this be worth calling out somewhere in the spec if others are also in agreement? Thanks for all the feedback!
Josh Mandel (Apr 21 2021 at 17:13):
Fair enough -- I added a note with https://github.com/smart-on-fhir/smart-scheduling-links/pull/32 to clarify this expectation (as "SHOULD")
Josh Mandel (Apr 21 2021 at 17:32):
For your demo at https://smart-demo.vaccinespotter.org/WI/#location-216902673 @Nick Muerdter, I'm assuming the Walgreens data is coming from https://github.com/jmandel/wba-appointment-fetch ? If so, I wouldn't expect to see a specific time listed, since the Slot is a "coarse-grained" one ("we have capacity in the next 5 days" is all you really get). Now, I'm very much aware of the fact that we need more granular data from providers, and we're working on this; but wanted to get your thoughts on how best to render coarse-grained info when it's all you have. I assume "4/20/2021, 7:00 PM CDT" is a placeholder or interim behavior you've built just for the demo?
Nick Muerdter (Apr 21 2021 at 17:51):
@Josh Mandel: Yes, it's based on that data. So right now I'm just taking the start time as-is from the slots feed (since that's what Vaccine Spotter currently does based on how I currently get slot data). I haven't done anything to specifically handle these typeof coarse-grained slots, so I'm just taking the "start":"2021-04-21T00:00:00.000Z" value, and treating that as the display time. Obviously, I'd need to actually handle coarse-grained slots if I were using SMART data, but is there anything that indicates this is a coarse grained slot in the data, other than just seeing that the start and end time are maybe too long?
Josh Mandel (Apr 21 2021 at 17:56):
is there anything that indicates this is a coarse grained slot in the data, other than just seeing that the start and end time are maybe too long?
No, right now it's just duration. We could add an explicit marker (e.g., an is-coarse-grained extension) if it's helpful, or happy to explore other ideas. But roughtly: if you see a slot that's 8h long in the context of COVID-19 vaccines, it's probably good to display something like a date instead of a precise start time)
Josh Mandel (Apr 21 2021 at 17:58):
(To be clear, we're working to drive toward actual appointment dates/times; but we don't want to hold back on publishing what we can today.)
Nick Muerdter (Apr 21 2021 at 18:12):
Yup, that makes sense. My existing data model just doesn't account for these type of course grained situations (since I hadn't previously encountered them), but that should definitely be doable.
Rob Brackett (Apr 22 2021 at 15:43):
We could add an explicit marker (e.g., an is-coarse-grained extension) if it's helpful
Is having a capacity extension enough to imply that it’s coarse? I guess I can imagine a case where a real, single slot could accommodate more than one person, but that doesn’t seem like a thing anybody’s doing. (OTOH, family booking _is_ an equity issue we’ve been talking about at USDR.)
Josh Mandel (Apr 22 2021 at 16:38):
There are two dimensions of "coarseness" here -- one is temporal, and the other is capacity. Publishers can create temporally-fined-grained slots that support capacity>1 (e.g., for a large vaccination site processing 20 people in every 15 minute slot).
Rob Brackett (Apr 22 2021 at 17:48):
Ah, I had thought from reading the spec that publishers were expected to publish multiple slots with the same start/end time in the "site that processes 20 people in every 15 minute slot" case. But if that reading was wrong, that definitely does make this more complex.
Rob Brackett (Apr 22 2021 at 17:50):
On the one hand, this seems like something a client can handle for COVID-19 since we know an actual appointment will always be 15-30 minutes, but for other, future schedules types it seems like the missing info is the expected length of a real appointment (not sure that’s what we want in the API since it forces clients to do more work, but it seems like underlying knowledge that’s needed, at least).
Maybe some better language around what we’re asking here is: is this slot an appointment time, or a time range during which appointments can be booked?
Rob Brackett (Apr 22 2021 at 17:56):
(As a side note, it feels like the way slots are discussed in FHIR’s Schedule documentation (http://hl7.org/fhir/schedule.html#12.12.1.1) and the way they’re discussed in the Slot documentation (http://hl7.org/fhir/slot.html#scope) don’t agree when it comes to this particular issue. Maybe it was an earlier reading of the Schedule docs that lead me astray.)
Last updated: Apr 12 2022 at 19:14 UTC
