Re: Questiona about timezones

hi

Quoting from an API lead for one of the major health record systems in the
world:

------
Internally, we have some variation on how this is handled, and it depends
on context. A specific date can have a zone tied to it. This is usually to
capture context of the user that entered data, so that an app can choose to
display that later.

In addition, we have a location that captures the local zone of the
patient. This is so you can translate from a "local time" to a real instant
in time correctly - like the med dosages. This is most common (for us) in
inpatient scenarios. However, I would imagine that a consumer-facing app
would need to do something similar when there is no encounter (for example)
that would have a location tied to it. Note: we don't have a "zone" on the
Location in FHIR, - so right now, someone would have to extrapolate this
from geolocation, if it existed.

Finally, we have apps where the use case makes more sense to convert all
times to the local user's time zone. This is "client side" logic usually.
>From a server perspective, this isn't normally an issue it has to deal with
except for the Narrative and other displays we return. I know we have a
translation extension + the capability to add language tags to narratives
now. It would be nice if I could only choose to return the "original" + the
requested translation, and this is the main scenario I can think of that
would start to push for headers

The assumption being that the "translation" would take Locale as well as
zone preferences into consideration

------
Grahame


On Mon, Oct 1, 2018 at 11:07 PM Roberto Polli <
roberto@teamdigitale.governo.it> wrote:

> Hi Grahame,
>
> I think that your proposal is interesting. Can you please share some use
> cases?
>
> Adding a `Content-Timezone` means adding another representation modifier,
> which has some implications when you have to audit request and responses.
>
> The `Timezone` header instead seems to me overly complex.
>
> Let me know,
> R.
>
>
> Il giorno lun 1 ott 2018 alle ore 12:54 Grahame Grieve <
> grahame@healthintersections.com.au> ha scritto:
>
>> ok thanks. I'm not sure I have the time personally. I'll ask around in
>> the health standards community to see if there's anyone who wants to take
>> this up and push it.
>>
>> Grahame
>>
>>
>> On Mon, Oct 1, 2018 at 4:18 PM Mark Nottingham <mnot@mnot.net> wrote:
>>
>>> Hi Grahame,
>>>
>>> This has come up a few times. While getting it into Web browsers would
>>> be difficult (thanks to the inherent privacy issues, as well as the
>>> existence of other solutions), defining it for non-browser applications
>>> simplifies the problem somewhat, and based on the number of times it's come
>>> up, might see some take-up.
>>>
>>> Personally, I like the proposal in:
>>>
>>> http://www.w3.org/mid/DBDF1A48B00F2042B20953D2ACE4968806A0ADE526@sha-exch14.shared.ifeltd.com
>>>
>>> If you (or someone else) wanted to sketch out a proposal in an
>>> Internet-Draft, we could discuss it and decide whether there's consensus to
>>> adopt.
>>>
>>> That said, the gating factor is likely to be finding someone who's
>>> willing to put in the work of editing a document. If we can find people to
>>> help in that process, would you be willing to do so?
>>>
>>> Cheers,
>>>
>>>
>>>
>>>
>>> http://www.w3.org/mid/DBDF1A48B00F2042B20953D2ACE4968806A0ADE526@sha-exch14.shared.ifeltd.com
>>>
>>> > On 26 Sep 2018, at 11:18 am, Grahame Grieve <
>>> grahame@healthintersections.com.au> wrote:
>>> >
>>> > Hi
>>> >
>>> > We've run into a problem with the FHIR HTTP API to do with timezones
>>> (FHIR = HTTP API for healthcare). TImezones are hard to deal with, and we
>>> can't nail everything down (duh!). There's cases where the server needs to
>>> know the client's timezone to perform certain tasks correctly on behalf of
>>> the client, and the client wants to know the server's timezone to fully
>>> understand certain outputs
>>> >
>>> > The classic response is for this to be handled by javascript client
>>> side, but that doesn't work for a data (json) API. Note also that in
>>> principle, servers should not have a timezone, but in practice, every
>>> clinical system in the world does have a timezone, and it matters a whole
>>> lot. If we care about legacy data, we have to have the client knowing what
>>> the server defaults to... and we really care about legacy data. And various
>>> clinical protocols have operational ties to timezones, not just offsets
>>> (giving medications at the right time really does matter)
>>> >
>>> > Has anyone got any comments on this?
>>> >
>>> > I like the header described in
>>> https://tools.ietf.org/html/draft-sharhalakis-httptz-05 and would
>>> specify it for both directions, but that's not blessed by the http-wg?
>>> >
>>> > Grahame
>>> >
>>> > --
>>> > -----
>>> > http://www.healthintersections.com.au /
>>> grahame@healthintersections.com.au / +61 411 867 065
>>>
>>> --
>>> Mark Nottingham   https://www.mnot.net/
>>>
>>>
>>
>> --
>> -----
>> http://www.healthintersections.com.au /
>> grahame@healthintersections.com.au / +61 411 867 065
>>
>
>
> --
> Roberto Polli
>
> *Full Stack DeveloperM. +39 3406522736*
> ·D
>
> *TEAM PER LATRASFORMAZIONEDIGITALE*
> *Presidenza del Consiglio dei Ministri*
> teamdigitale.governo.it
>
> Il Team per la Trasformazione Digitale, salvo eccezioni, comunica con le
> altre Amministrazioni via posta elettronica ordinaria e non posta
> elettronica certificata, in conformità a quanto previsto dall’art.47 del
> Codice dell’Amministrazione Digitale.
>


-- 
-----
http://www.healthintersections.com.au / grahame@healthintersections.com.au
/ +61 411 867 065