FHIR Chat · Time zones for slots, locations · smart/scheduling-links

Stream: smart/scheduling-links

Topic: Time zones for slots, locations

Josh Mandel (Apr 21 2021 at 15:11):

@Nick Muerdter wrote:

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.000Z is 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.

This is a super important issue. I want to focus on "fine-grained slots" (at least to start) for this evaluation, because slots like "all day on May 2" or "from May 2 through May 5" are basically just a hack/stop-gap.

Josh Mandel (Apr 21 2021 at 15:13):

The one thing we want to enforce is that slot times are valid FHIR instants, meaning they specify a precise point in time, including a timezone specifier. This value doesn't necessarily need to be in the timezline of the location, so for instance using UTC times (Z suffix) is okay as long as they're actually correct (e.g., if your Boston clinic opens at 9a ET, and you choose to populate a Slot.start in UTC, then it needs to be for T16:00:00Z).

Josh Mandel (Apr 21 2021 at 15:15):

I'm thinking at a minimum, then, we should add clarification that:

1. Slot start and end times SHALL include an offset specifier that correctly reflects the time of start
2. Slot start and end times SHOULD be expressed az UTC times (Z suffix) or with offset that matches the local timezone

Josh Mandel (Apr 21 2021 at 15:16):

This should ensure that slot times are correct, and not expressed with some arbitrary offest. Clients should be able to convert these as needed (e.g., for localized display to a user).

Josh Mandel (Apr 21 2021 at 15:17):

Now the second question here from Nick: should locations advertise their local timezones / offsets in some explicit way? I'm not convinced on this, because I think it's easy to "get wrong" and I think the main use case for clients would be to show times to a user in the user's local timezone which would always be possible with (1) and (2) above. If a client really needs to translate a time to "at-location," this can be done with public reference data sets.

^^ I'm willing to be convinced otherwise; this is my attempt at solving the smallest piece of the problem I can to keep everyone un-stuck. Feedback is most welcome!

Robert Scanlon (Apr 21 2021 at 16:00):

Would it be useful for our validation tools to flag a warning for slot times that "don't quite seem right" when converted to local time? e.g. anything before 7am or after 10pm? Or configurable when you run the test?

Nick Muerdter (Apr 21 2021 at 16:02):

Yeah, I agree that getting the times correct (regardless of whether its returned in UTC or with an offset) is the most important part. So maybe this is just something that needs to be clarified. Or this could also just be an issue with some of the early data that will be corrected later on. But since I've seen what look like incorrect times across multiple producers, it seems like maybe this is something that could use some extra clarification or examples.

For reference, here are the times in each producer's slots that I've pulled in:

• CVS: "2021-04-21T09:00:00.000Z" (doesn't seem right)
• Kroger: "2021-04-21T08:00:00.000Z" (doesn't seem right)
• SMART Samples: "2021-03-02T14:00:00.000Z"
• Walgreens: "2021-04-21T00:00:00.000Z" (doesn't seem right)

Nick Muerdter (Apr 21 2021 at 16:03):

@Robert Scanlon: Yeah, I think that type of check could be useful. But it looks like some produces are trying to represent full-day availability, so maybe there would need to be an exception for times that are midnight-midnight?

Josh Mandel (Apr 21 2021 at 16:07):

Would it be useful for our validation tools to flag a warning for slot times that "don't quite seem right"

Yeah, I think these kinds of heuristics can go a long way.

Nick Muerdter (Apr 21 2021 at 16:09):

Regarding having the location's local time zone, yes, it could be determined by the API consumers by geocoding the location, so it's not as essential. But I think displaying slot times in the location's local time zone and not the user's local timezone may be preferable, or at least that's what I've settled on. I'm not sure how much of an edge-case this is, but I know a lot of people use Vaccine Spotter to find appointments for people in other time zones (eg, people booking appointments for their parents in another state or volunteers booking appointments for people across the country). In this case, it seems most useful to know when the local time of the appointment is, since if I'm in CA and booking something for someone in NY, it can get confusing if everything I'm seeing looks like the appointments are at 4AM on my local computer, but I would actually need to tell the person I'm booking for that it's at 7AM. So again, maybe this is more of an edge case, but I guess that's why I've seen the location's time zones as useful.

Josh Mandel (Apr 21 2021 at 16:13):

SMART Samples: "2021-03-02T14:00:00.000Z"

This one I can speak to: the time was intentional ("9a ET opening time for a MA-based pharmacy, expressed in UTC")

Source snippet

OPENING_TIME = 'T09:00-05:00';

const openingTime = (date: string): string => {
  return new Date(date.slice(0, 10) + OPENING_TIME).toISOString();
};

Josh Mandel (Apr 21 2021 at 16:14):

But I think displaying slot times in the location's local time zone and not the user's local timezone may be preferable, or at least that's what I've settled on.

That's fair; I'm thinking that public data sets should let you do this even if the FHIR $bulk-export data don't include any specific details here. I will raise the question in #implementers > Time zone for locations though to see if there's any other common advice.

Josh Mandel (Apr 21 2021 at 16:18):

For all the "doesn't seem right" examples @Nick Muerdter, I agree... but they're being used in "coarse-grained" slots that don't actually specify what time of day the appointments are available, so I'm not really sure how to fix them. The key point for me is that when publishers get around to posting fine-grained slots, they'll need to populate timestamps with accurate offsets.

Josh Mandel (Apr 21 2021 at 16:23):

Added https://github.com/smart-on-fhir/smart-scheduling-links/pull/30 -- happy to take additional suggestions before we merge.

Robert Scanlon (Apr 21 2021 at 16:23):

It might be important to get offsets right enough for course grained slots to at least have it be the right day when converted to the local timezone.

Josh Mandel (Apr 21 2021 at 16:26):

Now that's a bit of pragmatism I could get behind ;-)

Josh Mandel (Apr 21 2021 at 16:28):

@Cooper Thompson given how Epic is populating "midnight" slots? (tried to check but I'm getting no locations or slots from https://fhir.epic.com/interconnect-fhir-oauth/api/epic/2021/Scheduling/Utility/covid-vaccine-availability/$bulk-publish right now)

Robert Scanlon (Apr 21 2021 at 16:29):

Having 2021-04-21T00:00:00.000Z could really mean 6PM local time on 4-20, but it is suspicious. Especially if they are all listed as that.

Josh Mandel (Apr 21 2021 at 16:30):

I wish these coarse-grained slots could just express a date instead of an instant, but the FHIR model requires an instant. But coarse-grained slots are a hack.

Robert Scanlon (Apr 21 2021 at 16:31):

Yup, I find it a little surprising that the base resource constrains this down to an instant

Josh Mandel (Apr 21 2021 at 16:31):

So @Robert Scanlon , how would you precisely express this constraint?

Robert Scanlon (Apr 21 2021 at 16:56):

Yeah this is tough -- I honestly don't have a great answer. I do like the language in there about operating hours at most, and then it is just a matter of some of these probably being technically wrong right now (and I'm not sure how adding more constraints on top of this would help). It would be nice if even getting the intended date wrong was 'even more wrong', but you could imagine situations where there is a slot from 11:45PM - 12:15AM local, so coming up with any hard rules is tough.

Josh Mandel (Apr 21 2021 at 17:01):

OK -- well I'm going to treat my PR as "strictly better" than what we have now, even if there are still some known gaps.

Josh Mandel (Apr 21 2021 at 17:08):

Merged https://github.com/smart-on-fhir/smart-scheduling-links/pull/30 -- thanks for the review + suggestion @Nick Muerdter ; I incorporated your example.

Last updated: Apr 12 2022 at 19:14 UTC