FHIR Chat · Language · argonaut

Stream: argonaut

Topic: Language

Grahame Grieve (Jun 07 2019 at 05:46):

I've been in Europe this week talking to various stakeholders. One question that's been looming large in their minds is the intersection between consumer access and Argonaut. There's potentially a basic consensus around each country publishing an Argonaut variant spec (like Australia has) that varies some of the content rules like we have in Australia to remove the US-specific parts of it

Grahame Grieve (Jun 07 2019 at 05:46):

countries may make additional content rules that may apply to some or all of the content in some or all circumstances, but that won't change that consumer access conforms to a basic argonaut variant specification

Grahame Grieve (Jun 07 2019 at 05:47):

in general, I've been saying that there's no reason to vary the API part of the specification.... and that's broadly true

Grahame Grieve (Jun 07 2019 at 05:47):

but there's one particular issue that has emerged as real issue for Europe: language.

Grahame Grieve (Jun 07 2019 at 05:48):

In order to meet requirements in many countries, the argonaut specification should call out the existing language prarameters and note which ones should/shall be followed, and note some consequences of that.

Grahame Grieve (Jun 07 2019 at 05:49):

the basic requirement is that you should be able to ask for the records in your language, and the record provider should do their best endeavour to translate (safely) to the language you have asked for, understanding that this will be variably complete depending on the nature of the record.

Grahame Grieve (Jun 07 2019 at 05:51):

obviously, an arbitrary langauge conversion request will be mostly ineffective (e.g. an italian asking for the records from estonia in italian) but there will be some combinations that are quite well supported (e.g. asking for flemish records from the french area of Belgium)

Grahame Grieve (Jun 07 2019 at 05:52):

I'm interested in this subject generally, and if any existing argonaut implementation has run into any language issues in USA

Eric Haas (Jun 07 2019 at 05:57):

In order to meet requirements in many countries, the argonaut specification should call out the existing language prarameters and note which ones should/shall be followed, and note some consequences of that.

What does this mean exactly - what to translate? like the text for codeables or what?

Grahame Grieve (Jun 07 2019 at 05:58):

definitely display names, and then anything else you know how to

Grahame Grieve (Jun 07 2019 at 05:58):

e,g. some prepared documents come in multiple languages

Eric Haas (Jun 07 2019 at 05:59):

I see value for non english speaker in US. will add to list to discuss on call....

Grahame Grieve (Jun 07 2019 at 06:00):

I think I live in the most mono-lingual country in the world...

Rob Hausam (Jun 07 2019 at 12:15):

IPS has been working to address this, and we're also working to align as closely as possible with Argonaut. We would definitely be interested in participating in the discussion and solution. Pinging @Giorgio Cangioli for additional thoughts?

Grahame Grieve (Jun 07 2019 at 12:17):

right. A clear goal for me is that a health system can put up a server that is a valid argonaut interface, and that a client could use this interface in the appropriate ways to create a valid IPS

Grahame Grieve (Jun 07 2019 at 12:18):

note that this is not saying that you could create a valid IPS from all argonaut servers

Jenni Syed (Jun 07 2019 at 13:16):

We attempted to do this today, though we now need to include more of the language tags in the spec. However, if the underlying system is english, our translation capabilities are very limited

Jenni Syed (Jun 07 2019 at 13:16):

Also, this should be locale and not just language, as I assume dates and number formats should likely change as well (for display/narrative)

Grahame Grieve (Jun 07 2019 at 13:39):

yes for narrative. I don't know about that though

Jenni Syed (Jun 07 2019 at 14:06):

So, if someone sent in en_au, what should 01/03/2010 be interpreted as?

Jenni Syed (Jun 07 2019 at 14:07):

(if it's in the narrative)

Giorgio Cangioli (Jun 07 2019 at 14:27):

Some functional requirements identified for the IPS are described here http://international-patient-summary.net/mediawiki/index.php?title=IPS_Functional_requirements_1#Multilingual_support.

Giorgio Cangioli (Jun 07 2019 at 14:28):

Not all of them are actually implemented (e.g. how the textual translation has been obtained)

Giorgio Cangioli (Jun 07 2019 at 14:32):

For the solution adopted for the FHIR IPS you can see https://build.fhir.org/ig/HL7/fhir-ips/general.html#translation-of-designations-and-narratives

Gino Canessa (Jun 07 2019 at 14:51):

So, if someone sent in en_au, what should 01/03/2010 be interpreted as?

This leads me to think that translations need to include a reference to what the original language was. A date provided from the system itself can be changed, but a date embedded within text (e.g., a diagnostic report) will not.

Particularly in something like en_us -> en_au, it would not be obvious that the date should be interpreted differently.

Jenni Syed (Jun 07 2019 at 15:54):

The programatic field will never change format

Jenni Syed (Jun 07 2019 at 15:54):

translations are only display/text concerns

Jenni Syed (Jun 07 2019 at 15:54):

(in FHIR, this is almost always a "text" field of some sort)

Jenni Syed (Jun 07 2019 at 15:55):

In FHIR, you represent the "base language" of the resource using the Resource.language field: http://hl7.org/fhir/r4/resource-definitions.html#Resource.language

Jenni Syed (Jun 07 2019 at 15:55):

And then a translation of a narritive or a specific string can use an extension or the div property:

Jenni Syed (Jun 07 2019 at 15:56):

language for narrrative: http://hl7.org/fhir/r4/narrative.html#lang

Jenni Syed (Jun 07 2019 at 15:57):

extension for other field translations: http://hl7.org/fhir/r4/extension-translation.html

Jenni Syed (Jun 07 2019 at 15:57):

@Grahame Grieve correct me if I'm wrong, this is the part of the spec we need to go add/changes for our implementation I think we are supposed to be making to make this consistent

Jenni Syed (Jun 07 2019 at 15:58):

the fields that are numbers or date/datetime/instant will never change their format

Ricky Bloomfield (Jun 07 2019 at 16:19):

Glad this is being discussed. I believe that US institutions should adopt the language/locale tag even if they only support English so that any future transition to multi-language support is easier. E.g., many health systems support portals in Spanish but their FHIR APIs are English only (although not tagged as English). This would be a great item to add to the Argonaut R4 discussions. Ideally we would make use of the language tag a requirement moving forward. Will serve as a good model for those outside the US to follow.

Ricky Bloomfield (Jun 07 2019 at 16:26):

Working out the behavior of the servers will be a fun task.

• Will there be a way to query to determine supported languages? Resource.language only allows for one item (presumably because it's intended to describe the language of the content in the resource itself).
• Should we add a list of supported languages to the Capability statement?
• Should we be able to determine whether the user has selected a language default in their portal?

There will be many more edge cases as we dig into it.

Jenni Syed (Jun 07 2019 at 16:30):

If we followed the web example, it's the client side (often browser) that has this setting, and the services typically honor the headers sent in

Jenni Syed (Jun 07 2019 at 16:31):

And default to something sane if unsupported (eg: the default that is in the Resource.language)

Jenni Syed (Jun 07 2019 at 16:33):

But in my experience so far, the translations aren't simple. EG: I can't do reliable translation on the fly. Comments entered raw are unlikely to get translated. Displays that come from an underlying system that only uses 1 lang are unlikely to get translated.

Ricky Bloomfield (Jun 07 2019 at 16:33):

Yeah, I think that's the most reasonable path forward. The browser would typically get its locale from the host OS, same for native apps.

Jenni Syed (Jun 07 2019 at 16:34):

So we've seen examples where the narrative ends up a bit "mixed language" depending on the fields included

Ricky Bloomfield (Jun 07 2019 at 16:36):

Agreed! On-the-fly translations are an absolutely horrible idea and shouldn't be used in a medical context. The primary US use case would be a system that had FHIR display text available in more than one language because they support multiple portal languages (and therefore already have display text in those languages). This would also apply outside the US. But in Europe it will be additionally important to be able to distinguish between systems that have completely different base languages.

Jenni Syed (Jun 07 2019 at 16:37):

We actually started adding support when we deployed for UK (and investigated gaps deploying to other regions where our EHR runs)

Ricky Bloomfield (Jun 07 2019 at 16:38):

Awesome, you're ahead of the curve! That experience will be invaluable.

Jenni Syed (Jun 07 2019 at 16:38):

The part we're missing, which is very important for the scenario that Grahame brought up, is the declaration of the "default" vs. the "translation" part. Most of the time they're asking for english in the US or British english so far. We haven't had anyone yet do spanish in us, for EG

Ricky Bloomfield (Jun 07 2019 at 16:40):

Yeah, totally agree.

Pascal Pfiffner (Jun 07 2019 at 16:40):

Not much to add, just want to +1 Jenny's comment about locale.

Grahame Grieve (Jun 07 2019 at 19:03):

so I think that we've nailed the language part in the base spec, and it's up to argonaut to decide what the minimum behavior for the base spec is

Grahame Grieve (Jun 07 2019 at 19:03):

though we might want to consider adding languages supported to the CapabilityStatement.

Grahame Grieve (Jun 07 2019 at 19:06):

I think that language translations could be more extensive depending on how much work you put into it. Obviously some things can be translated fairly easily:
- Coding.display
- generated narrative
- Attachment.title
- Preparation notes

Being able to translate those things is a configuration management issue (mostly) (not if you get them from elsewhere, of course)

Grahame Grieve (Jun 07 2019 at 19:07):

but some of the language stuff discussed in Brussels yesterday implied systems that invest more deeply in advance to ensure that more content can be safely translated - e.g. a doctor uses a template based approach, and there are templates for different languages

Grahame Grieve (Jun 07 2019 at 19:08):

I think that these are only things you'd do if there was real investment

Grahame Grieve (Jun 07 2019 at 19:08):

but the locale thing... I don't know what we do about that. I feel as though it would be wrong to infer that from the language....

Jenni Syed (Jun 10 2019 at 15:47):

@Grahame Grieve the Accept-Language header includes the locale variant. If that's included, I would assume that they want the locale specific formatting to be applied

Jenni Syed (Jun 10 2019 at 15:48):

I can test, but I think that is pretty typical on the web

Grahame Grieve (Jun 10 2019 at 15:48):

@Ricky Bloomfield wants a pop-up on this subject. Which I endorse

Jenni Syed (Jun 10 2019 at 15:50):

+1

Grahame Grieve (Jun 10 2019 at 15:58):

Someone else needs to propose it - I've used up my quota ;-)

Grahame Grieve (Jun 10 2019 at 17:26):

ok it's scheduled. I'll announce the time shortly

Grahame Grieve (Jun 10 2019 at 18:17):

pop 3.20-4.00 pm Tuesday

Grahame Grieve (Jun 10 2019 at 18:17):

location Sonora

Ricky Bloomfield (Jun 10 2019 at 18:22):

Great, I'll be there!

Ricky Bloomfield (Jun 10 2019 at 18:22):

On the calendar.

Grahame Grieve (Jun 12 2019 at 13:14):

Proposed outcomes from pop-up session yesterday:

• clients request language/locale using the http Accept-Language header
• servers SHOULD endeavour to perform reasonable efforts to translate what can be safely translated
• servers SHOULD populate the Resource.langauge element. This is reasonably based on the underlying record language, not the requested language (but MAY be based on requested language if translation is (reasonably) complete
• servers SHALL use the http://hl7.org/fhir/StructureDefinition/language extension when the language of a display etc is known to be different to the stated (or inferred) language
• servers SHALL use the http://hl7.org/fhir/StructureDefinition/translation where they wish to provide language translations
• servers SHALL follow the advice at http://hl7.org/fhir/narrative.html#lang where it comes to langauge and locale for the narrative portion of the resource
• we will define a way in FHIR R5 for a client to report to the server what the user's timezone is, and Argonaut should consider pre-adopting it (this is relevant when the server performs decision support such as medication dosing planning for the client)
• we will define a way for the server to detail what languages it can support, and argonaut should consider pre-adopting it

I think we generally believed that this should be part of the next published spec for Argonaut

Eric Haas (Jun 12 2019 at 14:08):

Third bullet is a surprise to me the .language should change? My system is en-us. and I do a good job of es-us. So the expectation is that the resource .lsnguage changes.? It is still technically a translation. So no extensions ?

Jason Walonoski (Jun 12 2019 at 14:18):

I disagree with this. Natural language translation seems like an excellent 3rd party value-add service that should not be built into a FHIR server. My 2 cents.

Grahame Grieve (Jun 12 2019 at 14:25):

Jason, what exactly do you disagree with? You disagree that servers should be able to do what they already know how to do? Why?

Grahame Grieve (Jun 12 2019 at 14:25):

Eric, why is the 3rd bullet a surprise? Which bit of it?

Jason Walonoski (Jun 12 2019 at 15:36):

I wasn't aware that FHIR servers already have the capability to translate all narratives, display values, notes -- essentially every string field -- from one language into another.

Grahame Grieve (Jun 12 2019 at 15:40):

not _all_

Grahame Grieve (Jun 12 2019 at 15:40):

but some, yes

Jason Walonoski (Jun 12 2019 at 15:50):

Is there any sandbox FHIR server that does this today? How do we test it.

Eric Haas (Jun 12 2019 at 20:14):

"servers SHOULD populate the Resource.langauge element. This is reasonably based on the underlying record language, not the requested language (but MAY be based on requested language if translation is (reasonably) complete"

The emphasized bit is the surprising part. So If the native language in Health eData's data source is en-us and the excellent and thorough translation to es-us for my spanish speaking neighbors is produced, isn't the the resources underlying record language still en-us?

Grahame Grieve (Jun 12 2019 at 21:51):

I don't know of one

Grahame Grieve (Jun 12 2019 at 21:51):

the language of the resource is spanish, no?

Eric Haas (Aug 10 2019 at 02:07):

I was looking for particular (R5) guidance in the spec and did not find any. did I miss it or is it still TBD? (We are in need of something to point to. )

we will define a way in FHIR R5 for a client to report to the server what the user's timezone is, and Argonaut should consider pre-adopting it (this is relevant when the server performs decision support such as medication dosing planning for the client)

What should be said? @GG, @Jenni Syed , @Danielle Friend , @Pascal Pfiffner

e.g. did we want to include some recommendation about timezones being returned as the applicable timezone (if that's possible, e.g. future dates)?

Grahame Grieve (Aug 10 2019 at 20:20):

the answer is that we didn't do that yet. We have 2 choices:
- a custom header
- a special parameter used whenever relevant

Grahame Grieve (Aug 10 2019 at 20:22):

an alternative is to say that client timezone is specified through the smart app launch process

Pascal Pfiffner (Aug 11 2019 at 00:54):

I believe good practice would be that dateTime elements always come in the relevant timezone, if that's applicable, e.g. when a lab was taken, when a condition was recorded, when a procedure was performed. This won't be possible for future dateTimes of course, and I know not all servers are able to fulfill this.

Pascal Pfiffner (Aug 11 2019 at 00:55):

I don't see the benefit of the client specifying its timezone in the header, what would the server do, convert to the client's timezone? That a client can easily do, it cannot however show a time in the correct time if the timezone information does not correspond to the local timezone where an event happened.

Grahame Grieve (Aug 11 2019 at 12:30):

we’ve discussed this before - the server needs to know the client’s Timezone if it’s going to to any thinking on behalf of the client, and there’s a number of situations around writing/operations/auditing where this occurs

Eric Haas (Aug 11 2019 at 16:09):

So what I am hearing is that instead of some technical guidance. Just recommend that the Server preserve the relevent source timezone?

Grahame Grieve (Aug 11 2019 at 21:04):

for read/create/update that server doesn't need to know the timezone; it just keeps and stores the existing supplied timezone. But that wasn't what drove the requirement. It's things like server side medication planning that need the client timezone

Grahame Grieve (Aug 11 2019 at 21:05):

Though, actually, I was thinking about this today - it needs the patient timezone, which might be different to the device/user timezone.

Grahame Grieve (Aug 11 2019 at 21:06):

I don't recall whether we discussed handling the requirement through a smart app launch process? But I think we ended up wanting a header

Eric Haas (Aug 11 2019 at 22:17):

I need to back up a second. I assume that we are talking about fetching data (since 90% of Argo R4 DQ is about search) and not write. So what I hear Pascal saying is the data source should preserve the source timezones. What GG is saying is that is not a problem. I don't think for Argo we have any needs for "to do any thinking on behalf of the client". So that would be out of scope for the Argo R4 DQ guide right now.

Brian Postlethwaite (Aug 11 2019 at 22:44):

Date/time values out into narratives could be different.

Eric Haas (Aug 11 2019 at 23:55):

@Brian Postlethwaite is muddying the waters.... :-) I am only trying to address Pascal's concerns. Brian can you give an example since I don't understand how it would be different?

Brian Postlethwaite (Aug 12 2019 at 01:53):

If the narrative has the time showing in it, and the zone of the client is different to the data would want to either convert it, or include the zone in there.
Think of an appointment narrative with 9:00 showing. If both the client and data are in eastern, no need to show it, however if you were a user looking from the pacific zone, you'd want to know that you're up at 6am, or at least see 9:00(eastern)

Pascal Pfiffner (Aug 12 2019 at 16:09):

Is narrative generation the only place where the server would do thinking on behalf of the client? I don't think we're talking about returning different dateTimes from resources depending on client timezone, are we?
Even (especially?) when creating resources, the client usually knows what timezone is applicable and should just provide that for the respective dateTime values and the server should persist as such. There is no guarantee a timezone always applies to all dateTime values within one resource (e.g. a lab can be taken in one but issued in another) and not within one SMART session either.

Pascal Pfiffner (Aug 12 2019 at 16:09):

For the narrative, the timezone could just always be spelt out or a new timezone header is introduced that is used for narrative generation. I don't use narrative so I don't have much of an opinion on how it should be handled.

Pascal Pfiffner (Aug 12 2019 at 16:17):

for read/create/update that server doesn't need to know the timezone; it just keeps and stores the existing supplied timezone. But that wasn't what drove the requirement.

That is actually what drives the discussion for us today, since that statement doesn't hold true and we receive a lot of dateTime in "Z".

Jenni Syed (Aug 13 2019 at 14:17):

Calclulating local dose times also needs a time zone. We have had scenarios on write where the offset was ambiguous and the timezone recorded in our system was incorrect

Jenni Syed (Aug 13 2019 at 14:17):

offset != timezone

Jenni Syed (Aug 13 2019 at 14:18):

Narrative as Brian mentions was the other scenario, which is why this came up during our localization conversations.

Jenni Syed (Aug 13 2019 at 14:18):

or other textual display fields in the body of the resource

Grahame Grieve (Aug 13 2019 at 14:18):

other textual fields that include times?

Jenni Syed (Aug 13 2019 at 14:18):

EG: generated meds dosing strings, possibly

Jenni Syed (Aug 13 2019 at 14:19):

Not dynamically translating comments or anything like that, unless the system was very ambitious

Jenni Syed (Aug 13 2019 at 14:19):

:)

Jenni Syed (Aug 13 2019 at 14:20):

Though we did leave that up to the server's choice for the localization conversation.

Jenni Syed (Aug 13 2019 at 14:21):

For things like the patient timezone (if in hospital) or the location time zone, the system hopefully knows that or can find that. The timezone we discussed was to pass the device time zone, for displays that we felt should be localized to the user

Eric Haas (Aug 13 2019 at 16:36):

Forgive me, as I am still trying to understand what the ask is here. I think Pascal's issue is offset vs converting to Z time? ( I am assuming the server converts the local offset to Z and stores? ) Is that true and why is Z worse than the original offset?

Jenni Syed (Aug 13 2019 at 17:01):

This is for display, primarily, and also for date calculation.

Jenni Syed (Aug 13 2019 at 17:01):

I'm not a fan of trying to read UTC dates and do conversions in my head :) Can't imagine how many outlook meetings I would miss

Jenni Syed (Aug 13 2019 at 17:02):

Similarly, If I was trying to predict specific administration times for a med given at 8 AM local, I would need to know the time zone to correctly generate that fully qualified time in the system

Jenni Syed (Aug 13 2019 at 17:03):

And take into account daylight savings and other "fun" time zone rules

Eric Haas (Aug 13 2019 at 17:39):

OK so converting to Z is bad and preserve the offset. got it.
@Jenni Syed I assume you are looking at this from the server perspective - what about the client's perspective?

Josh Mandel (Aug 13 2019 at 19:57):

For clients reading data: if a server returns proper ISO-8601 timestamps that include offsets based on the data-origination timezone, then clients can make us of this as needed (i.e., the client can decide whether to display in the data-origination timezone, or the local timezone, etc; the client will have all the necessary information to make this decision)

Grahame Grieve (Aug 13 2019 at 21:18):

I'm not a fan of trying to read UTC dates and do conversions in my head

welcome to my life....

Grahame Grieve (Aug 13 2019 at 21:19):

For clients reading data

Right. None of this discussion is about clients reading data.

Josh Mandel (Aug 13 2019 at 22:20):

(Except where Eric asked about that in particular.)

Pascal Pfiffner (Aug 14 2019 at 17:25):

If we say what Eric proposed that "converting to Z is bad and that preserving the offset is recommended" then yes, there's nothing else we need to say about clients reading data.

Jenni Syed (Aug 14 2019 at 17:59):

@Pascal Pfiffner can you provide more detail to that? Our system stores it in UTC and most often converts it to the display zone of the user

Jenni Syed (Aug 14 2019 at 17:59):

there are a few exceptions, but not many

Pascal Pfiffner (Aug 14 2019 at 18:05):

We receive many dateTime instances in "Z". I can check which systems if that helps.

Eric Haas (Aug 14 2019 at 18:10):

So @Pascal what is worse preserving the source offset or converting to the client local offset?

Pascal Pfiffner (Aug 14 2019 at 19:16):

Preserving the source offset on historical dates should always be the correct behavior. It's obviously not if we receive Z, in which case converting to local may or may not be correct, which is the core of the issue. The only right solution when reading historical data as a client is relying that the given offset is the applicable one.

John Moehrke (Aug 14 2019 at 19:53):

Pascal Pfiffner can you provide more detail to that? Our system stores it in UTC and most often converts it to the display zone of the user

This seems to violate Provenance. The storage request included a timezone, which may have been significant.

Jenni Syed (Aug 14 2019 at 20:22):

@John Moehrke First: nothing in FHIR has a timezone, our dates only support offsets. This doesn't give you much more than a general large strip of longitude that this might have come from :)

Jenni Syed (Aug 14 2019 at 20:22):

and that depends massively on what the "thing" is

Jenni Syed (Aug 14 2019 at 20:23):

you will, however, have the exact instant in time when it happened for anything tracked on a provenance, who did it, etc

Jenni Syed (Aug 14 2019 at 20:23):

I'm curious why the timezone itself, at the time (since time zone rules change) is a significant concern for a provenance use case

Jenni Syed (Aug 14 2019 at 20:25):

@Pascal Pfiffner I'm sure Cerner is one of those. As I said, we store most of our dates in UTC, which == Z

Jenni Syed (Aug 14 2019 at 20:26):

And for some dates, we also have the origin time zone recorded in the database, but there is no way to pass that origin time zone back w/o using an extension. We can pass an offset, but then you will fall victim to the same issue we hit when writing: going from an offset to a time zone that is trying to indicate something about an actual location can have ambiguous results

Pascal Pfiffner (Aug 14 2019 at 20:27):

With systems I meant EHRs, and I know that you folks have that limitation, yes, but I haven't checked whether it's for all your customers or a subset (since you say you convert for display)

Jenni Syed (Aug 14 2019 at 20:27):

Most of our modern browser applications will display event times in the zone of the user themselves, so that they don't have to do the conversion in their head when thinking things like "how long ago was this"

Jenni Syed (Aug 14 2019 at 20:27):

For older apps, they sometimes could display in many different zones, which was a bit confusing

Pascal Pfiffner (Aug 14 2019 at 20:27):

Ah I see. For us, the correct offset would help – we don't necessarily need to deduce location from a timezone.

Jenni Syed (Aug 14 2019 at 20:27):

I think the most important thing is what makes sense for the apps use case

Pascal Pfiffner (Aug 14 2019 at 20:30):

Yeah. We're unable to do the right thing with "Z"

Pascal Pfiffner (Aug 14 2019 at 20:31):

If we have the correct _offset_, we can at least either not do anything (if it's the same as current device offset) or indicate that this was somewhere else.

Jenni Syed (Aug 14 2019 at 20:32):

somewhere else? of just not same wall time as local? That's the part I'm trying to understand :)

Jenni Syed (Aug 14 2019 at 20:32):

For EG, if I gave you a UTC - 5:00 time, there are 8 different time zones that match that offset

Pascal Pfiffner (Aug 14 2019 at 20:32):

Haha, yeah – I meant in a different timezone. We could show the offset as-is or show the offset to current offset.

Jenni Syed (Aug 14 2019 at 20:33):

And this conversion from offset to time zone bit us when we tried to deduce a timezone from an offset passed to us in a FHIR write

Jenni Syed (Aug 14 2019 at 20:34):

(and that's just right now... historically you would need to apply the time zone rules in play around that same time)

Pascal Pfiffner (Aug 14 2019 at 20:34):

I keep conflating timezone and offset – I've only been talking about the offset that comes with dateTime / instant

Jenni Syed (Aug 14 2019 at 20:35):

Offsets are good for giving you a wall clock time. Anything in UTC format with the offset (regardless of if it's 0/Z) give you the exact moment in time which is always accurate

Jenni Syed (Aug 14 2019 at 20:35):

the wall clock time only makes sense if you can pair that with something that tells the user which wall clock :)

Jenni Syed (Aug 14 2019 at 20:36):

IE: I would hesitate to tell a doc that something happened at 8 based off an offset and not based off their current time :)

Jenni Syed (Aug 14 2019 at 20:37):

which is why most of our apps today either convert to local or to some other zone to be consistent (location zone, patient zone)

Jenni Syed (Aug 14 2019 at 20:37):

rather than displaying 3 different time contexts :)

Jenni Syed (Aug 14 2019 at 20:38):

I think it's really important to understand what we expect servers and apps to do, or what they might want to do with time zones vs. offsets and when/why we think it's significant

Jenni Syed (Aug 14 2019 at 20:38):

And then make sure the standard can handle that. I think we tried to do some of that in the localization conversation that triggered a few trackers from DevDays

Jenni Syed (Aug 14 2019 at 20:39):

But it sounds like there are definitely still concerns we may not have fully covered, that could use some documentation love and thought

Pascal Pfiffner (Aug 14 2019 at 21:14):

Yes agreed. From our POV receiving times with the correct offset allows us to always display the correct time and display the relation to the current time (if the offset is different). We cannot do that when receiving Z.

John Moehrke (Aug 14 2019 at 21:21):

I'm curious why the timezone itself, at the time (since time zone rules change) is a significant concern for a provenance use case

because the server is changing the data that the author asked it to save. Imaging the author having included a digital-signature, when the server changes the data the digital-signature will fail.

Grahame Grieve (Aug 15 2019 at 02:14):

it sounds to me like there's some grounds for adding 'timezone' to Resource.meta. If the source system populates the operating timezone of the source context, then the consuming system has more information about which time to display. If you are crossing timezones (I do it a lot), it can be very confusing - did something happen tomorrow?

Pascal Pfiffner (Aug 15 2019 at 17:03):

Resource.meta could be problematic, however. For example when I look at AllergyIntolerance.reaction.onset; it's very possible you have reactions in different timezones ¯\_(ツ)_/¯.

Pascal Pfiffner (Aug 15 2019 at 17:04):

Standard extension on dateTime (maybe also instant)?

Eric Haas (Aug 15 2019 at 18:22):

OK so summarizing at this point:

• Servers MUST keep and stores the existing supplied timezone or convert to Z(-0) time. ( assume this is current state)
• Servers converting to Z is bad for client who want to display the source time relative to the user time
• best practice is to preserve the offset
• how that offset is preserved is open question

Mikael Rinnetmäki (Aug 16 2019 at 10:32):

Is how to preserve the offset really an open question?

Mikael Rinnetmäki (Aug 16 2019 at 10:32):

I'd add to the summary (from a couple messages back) that support for timezone(in addition to the offset) would be nice to have, but how to communicate it has not yet been defined.

Mikael Rinnetmäki (Aug 16 2019 at 10:37):

(And as @Jenni Syed has explained several times, it's best to talk about timezone offset and time zone separately (should apply to the first bullet of @Eric Haas's summary - servers only store the offset, not the zone).

Grahame Grieve (Aug 16 2019 at 13:25):

note that I said to add timezone to the meta, not time offset

Jenni Syed (Aug 16 2019 at 14:46):

Our EHR already has a lot of logic around time zone, I'm not sure we would be able to change it to meet some of the proposed rules above :) Different dates on a resource may have different time zone context in our original system

Jenni Syed (Aug 16 2019 at 14:47):

If you're talking about requiring servers to maintain the time zone or offset, for eg. We have times that don't specifically store the time zone because they're patient time, and time zones that are stored because the requirements originally wanted to maintain user time zone for display

Jenni Syed (Aug 16 2019 at 14:47):

The actual times are just stored in UTC or Z time. We have several systems that cross multiple time zones

Jenni Syed (Aug 16 2019 at 14:48):

If we had a field for time zone, we could at least return the zone we had for the dates that store it

Jenni Syed (Aug 16 2019 at 14:48):

Which also implies we could start accepting that (which we would like to do)

Jenni Syed (Aug 16 2019 at 14:50):

This crazy situation was something we tried to avoid in the localization talk, esp since we often now change the times for display in our newer applications. I'm not sure how common this type of logic is :)

Jenni Syed (Aug 16 2019 at 14:50):

Between time zones and DST, I may be scarred for life... :)

Jenni Syed (Aug 16 2019 at 14:51):

(also, 45 minute offsets?? really Australia??)

Pascal Pfiffner (Aug 16 2019 at 20:11):

@Eric Haas , taking what Mikael and Jenni said, your summary points might be:
- Servers MUST store the existing supplied timezone offset or convert to Z(-0) time. (the latter just because it's current state)
- Servers converting to Z is bad for clients (they want to display the correct time independent of the current user location)
- best practice is to preserve the offset
- how the actual timezone is preserved is open question

Pascal Pfiffner (Aug 16 2019 at 20:13):

And @Grahame Grieve , wouldn't a standard extension on dateTime and possibly instant be preferable to sticking a timezone on Resource.meta? The latter breaks down for e.g. AllergyIntolerance.reaction.onset.

Grahame Grieve (Aug 16 2019 at 20:14):

(also, 45 minute offsets?? really Australia??)

umm: That's the Chatham Islands, which is not part of Australia (no, it's part of some little irrelevant country called New Zealand @David Hay )

Grahame Grieve (Aug 16 2019 at 20:17):

wouldn't a standard extension on dateTime and possibly instant be preferable to sticking a timezone on Resource.meta? The latter breaks down for e.g. AllergyIntolerance.reaction.onset.

A standard extension on dateTime all over the place seems to invite problems. if it's all the same, or required to be, why do it? if it's all different, why do it?

As for AllergyIntolerance.reaction.onset - sure, it could contain multiple dates from different timezones. But it's not (usually) going to contain times at all, let alone have the timezones matter. This one will usually contain year or at the most year/month

Pascal Pfiffner (Aug 16 2019 at 20:19):

Yes sure, it makes sense to discuss this in light of pragmatism vs. being able to model the world.

Grahame Grieve (Aug 16 2019 at 20:19):

(also, 45 minute offsets?? really Australia??)

oh no. I just learnt something. Eucla (a little town) observes it's own timezone. http://www.confluence.org/photo.php?visitid=10280&pic=7. Never heard of that. And I see it has no official sanction

David Hay (Aug 16 2019 at 20:37):

Yep Aussies and New Zealanders are just like a big happy family - of course, you do get envious comments from siblings from time to time, but we understand that - not everyone can live in godzone

Eric Haas (Aug 17 2019 at 00:54):

Godzone notwithstanding, I stand corrected not being precise enough with the concept of offset and timezone. I think that @Pascal's summary is where we are at right now. except point 4 should be"

• Whether and how the actual timezone is preserved is open question

Eric Haas (Aug 17 2019 at 01:14):

Is there any appetite for defining a name value pair for a meta.tag for Argo T4 and plan to use new meta time-zone element in R5 that GG is proposing?

• name = time zone
• values bound to codes derived from the tz database? : https://en.wikipedia.org/wiki/Tz_database ( hoping somebody already has this...)

Eric Haas (Aug 17 2019 at 01:17):

@Pascal Pfiffner if there were a timezone in the meta would that fix the issue clients have "wanting to display the correct time independent of the current user location" if everything was converted to Z time?

Pascal Pfiffner (Aug 17 2019 at 01:42):

Yes: if we get dateTime in Z, we can take a look at the timezone in meta and convert the Z dateTimes to the correct date/time. That is with the caveat that there might be dateTimes in the resource that apply to a different timezone (like AllergyIntolerance.reaction.onset), but for most cases this would probably be more correct than having no option to converting to the correct timezone. Also, do we need to say something about Resource.meta specifying a timezone and then dateTimes in that resource specifying offsets that do not match that timezone?

Grahame Grieve (Aug 17 2019 at 02:18):

no because they can be corrected

Eric Haas (Aug 27 2019 at 17:58):

OK here is a strawman proposal for the US Core and timezones/ time offets : hoping to get some feedback from @Jenni Syed and @Pascal Pfiffner before tomorrow's call.....

http://build.fhir.org/ig/argonautproject/R4/branches/master/general-guidance.html#timezone-and-time-offsets-strawman-proposal

Jenni Syed (Aug 27 2019 at 18:05):

Our server would likely provide a timezone for specific dates. When we store time zone, it's because the date can be different from the "base" for the resource

Jenni Syed (Aug 27 2019 at 18:05):

I know offset seems good for the way some apps use it, but would like some feedback from other apps and how they display. EG: if they display a zone with it, the offset isn't going to be enough

Jenni Syed (Aug 27 2019 at 18:06):

We also need a timezone sent in so we can localize narratives

Jenni Syed (Aug 27 2019 at 18:07):

EG: for some use case... Just because the offset is -5 for part of the year, it doesn't mean it was the same time zone because the user is currently in -5. Daylight savings time sucks

Jenni Syed (Aug 27 2019 at 18:11):

I'm not a super fan of using the tag field - why not just an extension?

Josh Mandel (Aug 27 2019 at 18:31):

Advantage of an extension is that the same extension URL and syntax can be used at the Resource.meta level or at a specific field level (e.g. MedicationRequest.authoredOn)

Eric Haas (Aug 27 2019 at 19:30):

tag was simpler but I see Josh's point.

Eric Haas (Aug 27 2019 at 19:31):

I don't understand what this means...

Our server would likely provide a timezone for specific dates. When we store time zone, it's because the date can be different from the "base" for the resource

Eric Haas (Aug 27 2019 at 19:32):

What is assumed to be the base date for the resource?

Jenni Syed (Aug 27 2019 at 19:37):

Usually? it's where the patient was

Jenni Syed (Aug 27 2019 at 19:37):

eg: encounter's location tz

Jenni Syed (Aug 27 2019 at 19:38):

again, in our system :)

Jenni Syed (Aug 27 2019 at 19:38):

and for things that are based on encounters

Jenni Syed (Aug 27 2019 at 19:38):

we store user TZ for dates when the user was elsewhere

Jenni Syed (Aug 27 2019 at 19:38):

also, FHIR doesn't have a concept of storing a location's tz today

Jenni Syed (Aug 27 2019 at 19:39):

which hasn't bothered me too much b/c I'm not sure how prevalent this type of logic is

Eric Haas (Aug 27 2019 at 19:40):

so based on the guidance I was under assumption that the the"base" tz represented in the meta.tag (or meta.extension)?

Eric Haas (Aug 27 2019 at 19:41):

and to Josh's point other datetimes that don't agree with that should get their own extension...

Brian Postlethwaite (Aug 28 2019 at 04:36):

I think a standard extension for timezone that can be used makes sense to me, and was planning to apply it on the location resource internally. But do see the needs here for elsewhere.
In directories this is also interesting as will apply it to the availability times. In HealthcareService and prac role.
So interested if we have different usages/meanings for the zone info, and should they be different extensions?

Pascal Pfiffner (Aug 28 2019 at 12:06):

Thanks @Eric Haas ! To point 3 and 5 – dateTime that have a time but no offset are invalid, so I don't think you need to specify those options. And agree, we don't have to use Meta.tag for the timezone, we could just use a standard extension on Resource.meta for the "base" TZ, and the same extension can be used directly on dateTime and instant.

Eric Haas (Aug 28 2019 at 16:05):

OK updated guidance to extension and fixed the algorithm:
http://build.fhir.org/ig/argonautproject/R4/branches/master/general-guidance.html#timezone-and-time-offsets-strawman-proposal

Eric Haas (Aug 28 2019 at 20:52):

Latest Argo was significant push back to support of timezones. am conducting a poll to see what if any of this we propose adding to Argo R4/US Core. I still think its a good blue print for future work in R5.

Brian Postlethwaite (Aug 28 2019 at 21:27):

the 3/4 char codes are not from the tz database, as you noted in the terminology track. Should be the America/New_York format.

Brian Postlethwaite (Aug 28 2019 at 21:32):

Wondering if there was a reason to put this in meta, and not a root level extension (just as with Resource.language) like the below example showing it as how you might have it in the whole resource, vs on a specific value

<Observation xmlns="http://hl7.org/fhir">
  <language value="en-au" />
  <extension url="http://hl7.org/fhir/us/core/StructureDefinition/tz">
    <valueCode value="America/New_York" />
  </extension>
  <subject>
    <reference value="Patient/example" />
  </subject>
  <effectiveDateTime value="2019-08-29T06:30:00+10:00">
    <extension url="http://hl7.org/fhir/us/core/StructureDefinition/tz">
      <valueCode value="Australia/Syndey" />
    </extension>
  </effectiveDateTime>
</Observation>

Brian Postlethwaite (Aug 28 2019 at 21:34):

The Meta only makes sense to me if you were just going to use a Meta.tag value rather than an extension

Eric Haas (Aug 29 2019 at 03:09):

see this for common timezones valueset : https://chat.fhir.org/#narrow/stream/179202-terminology/topic/timezone.20codes/near/174419755

Eric Haas (Aug 29 2019 at 15:13):

I totally missed this extension when searching the extensions: http://hl7.org/fhir/StructureDefinition/tz-code

Eric Haas (Aug 29 2019 at 15:14):

and http://hl7.org/fhir/ValueSet/timezones

Eric Haas (Aug 29 2019 at 15:17):

This is not searchable in the registry as 'timezone' only 'tz' - I'm making a tracker to change the name to fix that

Eric Haas (Aug 29 2019 at 15:18):

as well as tz-offset which is technically incorrect

Eric Haas (Sep 23 2019 at 10:24):

I would like to confirm that the Accept-language header reference is : https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.4

Pascal Pfiffner (Sep 23 2019 at 17:50):

Since https://www.ietf.org/rfc/rfc2616.txt is not hyperlinkable I'm thinking that's a good link to put?

Last updated: Apr 12 2022 at 19:14 UTC