[caldeveloper-l] Fwd: Re: Questiona about timezones
Michael Douglass
mikeadouglass at gmail.com
Mon Oct 1 20:03:45 PDT 2018
This discussion is taking place on the http working group list. I
believe this has the entire thread so far
-------- Forwarded Message --------
Subject: Re: Questiona about timezones
Resent-Date: Tue, 02 Oct 2018 01:11:55 +0000
Resent-From: ietf-http-wg at w3.org
Date: Tue, 2 Oct 2018 11:11:18 +1000
From: Grahame Grieve <grahame at healthintersections.com.au>
To: roberto at teamdigitale.governo.it
CC: Mark Nottingham <mnot at mnot.net>, HTTP Working Group
<ietf-http-wg at w3.org>
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 at teamdigitale.governo.it
<mailto:roberto at 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 at healthintersections.com.au
<mailto:grahame at 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 at mnot.net
<mailto:mnot at 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 at healthintersections.com.au
<mailto:grahame at 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 at healthintersections.com.au
<mailto:grahame at healthintersections.com.au> / +61 411 867 065
--
Mark Nottingham https://www.mnot.net/
--
-----
http://www.healthintersections.com.au /
grahame at healthintersections.com.au
<mailto:grahame at healthintersections.com.au> / +61 411 867 065
--
Roberto Polli
/Full Stack Developer
M. +39 3406522736/
·D
*TEAM PER LA
TRASFORMAZIONE
DIGITALE*
/Presidenza del Consiglio dei Ministri/
teamdigitale.governo.it <https://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 at healthintersections.com.au
<mailto:grahame at healthintersections.com.au> / +61 411 867 065
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.calconnect.org/pipermail/caldeveloper-l-calconnect.org/attachments/20181001/c3335521/attachment.html>
More information about the caldeveloper-l
mailing list