Stream: fhir/infrastructure-wg
Topic: Datatype proposal?
Brian Postlethwaite (Sep 21 2021 at 14:35):
PA are considering adding a new datatype for use in several resources (and also in extensions)
https://jira.hl7.org/browse/FHIR-25381
Anyone else want to comment on this?
For Available Times.
Gino Canessa (Sep 21 2021 at 14:59):
I'm not sure what is being proposed. Is it for a primitive type like a time span, a complex type similar to how Quantity works, or an extension?
Brian Postlethwaite (Sep 21 2021 at 15:02):
http://hl7.org/fhir/r4/healthcareservice.html
image.png
Extract this backbone element as a complex datatype (I guess like quantity) that we will then be able to share between HealthcareService, Location, PractitionerRole, and also as an standard extension to put on contactpoint
Gino Canessa (Sep 21 2021 at 15:11):
Thanks for the clarification! A couple of quick questions:
If I wanted to say I was available from 8:00 PM Tuesday to 8:00 AM Wednesday, would it be using two elements:
- Tuesday 8:00 PM to 11:59
:59PM (edit: forgot time has no seconds), and -
Wednesday 12:00 AM to 8:00 AM?
or something like: -
Tuesday, start 8:00 PM and no end, and
- Wednesday, no start and 8:00 AM end?
Second question is about time zones - given that time prohibits including one, is there a plan for discovery?
Brian Postlethwaite (Sep 21 2021 at 15:32):
There is another extension already for the timezone. that can apply
Brian Postlethwaite (Sep 21 2021 at 15:33):
As for the overnight availability, great question, and didn't have a good answer, but I guess you could put Tue 8pm - 8am
Brian Postlethwaite (Sep 21 2021 at 15:34):
(or alternately using the no start/end as you described, probably something we should explicitly define)
Gino Canessa (Sep 21 2021 at 15:36):
I'd ask for explicit guidance on the expectations... Tue 8pm - 8am would be ambiguous between Mon-Tue vs Tue-Wed otherwise.
If you're adding the a data type, I'd ask that includes the Timezone as well, as a favor to me if nothing else :-)
Brian Postlethwaite (Sep 21 2021 at 15:37):
I thought we had that timezone already, but my memory doesn't serve right - it's an Australian extension, and I was intending to bring it to international - not sure if I logged it - will hunt it down.
https://build.fhir.org/ig/hl7au/au-fhir-base/StructureDefinition-au-timezone.html
image.png
Brian Postlethwaite (Sep 21 2021 at 15:41):
https://jira.hl7.org/browse/FHIR-33018
Gino Canessa (Sep 21 2021 at 15:41):
There's an extension for timezone, but I'd ask for a first-class member of the structure so that it's generally added instead of requiring an extension to be included. I'd personally prefer a mandatory element, but that's just me =).
Brian Postlethwaite (Sep 21 2021 at 15:42):
That would be modifying the time datatype...?
Gino Canessa (Sep 21 2021 at 15:42):
No, I'm referring to the container structure (e.g., availableTime.timezone)
Brian Postlethwaite (Sep 21 2021 at 15:42):
you would have 2 timezones, one for start and one for end.
Gino Canessa (Sep 21 2021 at 15:42):
It doesn't work on the time datatype alone because it influences which day is resolved as well.
Brian Postlethwaite (Sep 21 2021 at 15:42):
9am eastern, to 5pm west coast
Brian Postlethwaite (Sep 21 2021 at 15:43):
Business hours anytime in Australia, don't know if you do the same thing anywhere over in the USA
Gino Canessa (Sep 21 2021 at 15:43):
... I'd prefer to force people not to do that though =). If you want to display in odd timezone configurations, that's a display thing, not a data storage thing.
Gino Canessa (Sep 21 2021 at 15:45):
If you are adding the TZ to time, I'd argue it's better to just use boundary instant types so each slot is just a range. It would make 'Mon-Fri 8:00 AM - 8:00 PM' more verbose, since you'd need to express each range individually, but would be much more specific.
Gino Canessa (Sep 21 2021 at 15:47):
(this is why I was processing the original intent as possibly a time range type - so that it would be simpler to add a series of time ranges)
Brian Postlethwaite (Sep 21 2021 at 15:47):
Oh, and that extension you have can't be used with time...
Brian Postlethwaite (Sep 21 2021 at 15:48):
Which is what that request is.
Josh Mandel (Sep 21 2021 at 15:48):
But how do you say "8a" with an instant? Aren't you limited to describing a specific 8a (on a specific day, rather than "Mondays in general" or "every week")?
Brian Postlethwaite (Sep 21 2021 at 15:53):
The use we're talking about is time, not dateTime/instant. which is just 8am
Gino Canessa (Sep 21 2021 at 15:53):
Josh Mandel said:
But how do you say "8a" with an instant? Aren't you limited to describing a specific 8a (on a specific day, rather than "Mondays in general" or "every week")?
Oops (:embarrassed:) - not quite sure how I got there missing that. Yeah, that's a problem.
Gino Canessa (Sep 21 2021 at 15:59):
Josh was cutting me off at the pass since that's the direction I was moving - trying to simplify via something like TimeSpans. But, there's isn't a good type that allows for a day of the week without a full date.
Brian Postlethwaite (Sep 21 2021 at 15:59):
Which is what we're describing above in the request...
Elliot Silver (Sep 21 2021 at 15:59):
I'd suggest reviewing the behavior of range, and making sure the semantics of matching, etc. are as close as possible.
I think there is value in being able to say 9am-5pm local time vs. 9-am-5pm Eastern. I also have a concern about 1am-4am EDT on the day we switch to EST. This is obviously a challenge any time we specify a time that spans the switchover, but if the time zone is included, is there a further complication (e.g., does it mean open until the next 4 am EDT, which is 6 months away? :-D).
Just from a FHIR styling POV, should it be "dayOfWeek" (singular), even though multiple days can be specified?
Brian Postlethwaite (Sep 21 2021 at 16:02):
it's not EDT/EST that we have in there, it's the IANA timezone e.g. 'Australia/Brisbane' which will resolve to a specific offset on a specific date
Grahame Grieve (Sep 21 2021 at 16:12):
procedurally, this would be like Dosage, and owned by PA. It's allowed, and I'm not sure that FHIR-I has any say in it, actually. At least procedurally. Obviously there's going to be informed comment, as has happened.
Grahame Grieve (Sep 21 2021 at 16:13):
you would have 2 timezones, one for start and one for end.
How on earth could a service end in a different timezone from it's start?
Brian Postlethwaite (Sep 21 2021 at 16:14):
Telehealth services available Australian business hours.
It's availability times, not a single service instance time.
Grahame Grieve (Sep 21 2021 at 16:15):
I still think that's weird
Brian Postlethwaite (Sep 21 2021 at 16:16):
How would you describe that use case of the support service being available Australian business hours?
(Lots of national programmes do that - where they aren't a 24 hour service)
Grahame Grieve (Sep 21 2021 at 16:17):
8 to 8, myself, and adjust to local time zone.
Josh Mandel (Sep 21 2021 at 17:02):
Schema.org has a structure like https://schema.org/OpeningHoursSpecification
Josh Mandel (Sep 21 2021 at 17:02):
It uses a time datatype under the hood -- https://www.w3.org/TR/xmlschema-2/#time
Josh Mandel (Sep 21 2021 at 17:03):
[Definition:] time represents an instant of time that recurs every day. The ·value space· of time is the space of time of day values as defined in § 5.3 of [ISO 8601]. Specifically, it is a set of zero-duration daily time instances.
and this allows an optional time zone indicator
Gino Canessa (Sep 21 2021 at 17:09):
Yes, but since the FHIR time format specifically forbids a timezone, I think it would be simpler to have a single one for the range rather than one for each boundary. If someone wants to enter/display with different zones for the boundaries (or even a different one altogether), that is a presentation issue.
Brian Postlethwaite (Sep 21 2021 at 17:13):
Issue with the schema.org time is that it's using the offset, which has the EST vs EDT issues. Where the extension that we have in FHIR is the IANA timezone which derives to the offset on a specific date.
Gino Canessa (Sep 21 2021 at 17:16):
As an aside, I would be curious to see how many apps do the IANA resolution correctly vs. just matching liters and using the offsets themselves.
(edit: because time is unreasonably hard for some reason :-/ )
Elliot Silver (Sep 21 2021 at 17:32):
Grahame Grieve said:
8 to 8, myself, and adjust to local time zone.
The use case I'm thinking of is use of a national service, but only 8-8 during my local time. That is, it is available 8 am-8 pm Eastern, if I'm calling from an Eastern area code; 8 am-8pm Central (which is 9 am-9pm Eastern), if I'm calling from a Central area code, etc.
Elliot Silver (Sep 21 2021 at 17:38):
Do you need to specify how availableTimes stack? Is there a need for an "except" element? (Can I say M-F 9-5, except Tuesday 12-1? Or M-F 9-5, Thursday to 8?)
Brian Postlethwaite (Sep 21 2021 at 18:58):
In the relevant resources there is an available (this datatype) and an exceptions list that marks where it's not applicable, usually has stuff like public holidays in it - but these are defined as a period, and a description - which is quite specific, rather than the general nature of availabilities..
Last updated: Apr 12 2022 at 19:14 UTC
