Stream: terminology
Topic: Designations vs. language-specific resources for VS and CS
Morten Ernebjerg (Aug 06 2020 at 14:14):
(This question is related to the recent discussion about designation and code system supplements, but is slightly more general so I'm opening a new thread.)
Both ValueSet and CodeSystem support the inclusion of language-specific labels through designations. At the same time, they have the language element. That means that one (seemingly) has two ways of handling multiple languages for these resource types:
- Create a separate copy of each resource (with translated labels) for each language and indicate the latter in the
languageelement - for ValueSets, one could e.g. generate expansions in each language (and drop the designations) - Have only a single copy of each resource (in some base language) but always include all translated labels in designations (leaving it for the consumer to pick out the right one).
On an IG I worked on recently, we used a combination: we did (2) for CodeSystem, but then generated one expanded ValueSet set per language, as in (1), since it allows the consuming systems to be less sophisticated (no need to know about designations).
My questions is: Is there general guidance on which approach is preferable (or, conversely, illegal) in a given use cases, and for VS vs. CS resources?
Lloyd McKenzie (Aug 06 2020 at 14:36):
You don't want multiple instances of a resource with the same canonical URL and same 'version' on the same server. That means that you should use designation. The 'language' element indicates the primary language of the resource content, but it's not the intention (even with non-canonical resources) to have different copies of the same resource with different language declarations.
Morten Ernebjerg (Aug 06 2020 at 14:53):
I was under the impression that the Accept-Language header was meant to allow pulling the same resource in different languages from the same URL (with the language in the header matching that in the language element of the returned resource, if present). Was that simply a misunderstanding? - if each resource can only exist in one (declared) language, it seems there will only ever be a single language code that will produce a hit when put in the Accept-Language header (for a given URL).
Lloyd McKenzie (Aug 06 2020 at 15:01):
I was not familiar with that use. That would mean real-time translation of the resource - as there'd be no way to update the resource and specify multiple languages. @Grahame Grieve ?
Grahame Grieve (Aug 06 2020 at 19:50):
pulling the same resource in different languages from the same URL
yes. How that is achieved is up to the server. But there's no facility for anything like this through an IG, except by using designations. It would be possible that when we (a) distribute expansions and (b) do the langauge support in the publisher (both planned future enhancements) that we would distribute expansion language packs, but then it would still be up to the IG consumer to decide how to handle those expansions
Grahame Grieve (Aug 06 2020 at 19:50):
generally, note that while distributing expansions might be simpler, it's inherently fragile.
Michael Lawley (Aug 06 2020 at 20:46):
If you want to separate translations into separate CodeSystems, then CodeSystem supplements are the way to go. This has the advantage of decoupling the translation from the base CodeSystem which may make maintenance simpler / more flexible. But, it is more moving parts and requires a more sophisticated terminology server.
For translations of the display for a code in a single CodeSystem, then I believe you should use a designation with a use value of display (based on examples in the FHIR spec, but missing from the bound ValueSet - there is a ticket for this).
If you are generating multiple ValueSet expansions (one per language), then the ValueSet.expansion.parameter should include an appropriate value for displayLanguage.
Morten Ernebjerg (Aug 07 2020 at 12:20):
Thanks for all the input! Just to consolidate my understanding so far:
- A server may be able to generate (or hold, e.g. in cache) copies of the same resource - as defined by (canonical) URL and version - in different languages, as indicated by the
languageelement (and, for expanded VSs,expansion.parameter) - These language variants can then be targeted using GET with the
Accept-Languageheader - However, there is no FHIR API mechanism for writing/updating such variants via HTTP, so the server has to get /generate them by some other mechanism.
Is that correct?
Grahame Grieve (Aug 07 2020 at 12:23):
pretty much. There's nothing to stop a server adding some mechanism for writing, but we haven't talked about it before
Morten Ernebjerg (Aug 07 2020 at 12:25):
You mean smt. like adding Content-Language headers to POST requests (not sure if that is even HTTP valid)?
Grahame Grieve (Aug 07 2020 at 12:32):
maybe. I agree
Tim Berezny (Sep 29 2020 at 00:03):
Morten Ernebjerg said:
Thanks for all the input! Just to consolidate my understanding so far:
- A server may be able to generate (or hold, e.g. in cache) copies of the same resource - as defined by (canonical) URL and version - in different languages, as indicated by the
languageelement (and, for expanded VSs,expansion.parameter)- These language variants can then be targeted using GET with the
Accept-Languageheader- However, there is no FHIR API mechanism for writing/updating such variants via HTTP, so the server has to get /generate them by some other mechanism.
Is the suggestion here that I could
GET HealthcareService/123
...and it would come in French or English by including a different Accept-Language header in the request? That sounds neat ... is it FHIR-legit?
Grahame Grieve (Sep 29 2020 at 01:04):
yes that's how it works, though its must more likely to be supported for $expand rather than a simple get
Jose Costa Teixeira (Apr 06 2021 at 14:12):
In this case, could the valueset still contain the display text in multiple languages?
Jose Costa Teixeira (Apr 06 2021 at 14:14):
In fact, generally, the CS supports multi-language, but if we want the VS to contain content in 2 languages, can we use the translation extension for that?
Jose Costa Teixeira (Apr 06 2021 at 14:20):
(to me that seems the way to do it, but I don't know if there is another, more sensible /orthodox way of doing it)
Jose Costa Teixeira (Apr 06 2021 at 14:20):
Use case: user has an offline questionnaire which has some contained VS and they want to switch languages
Michael Lawley (Apr 07 2021 at 01:40):
Expansions can include multiple designations for a code. Each one can indicate the language it is from.
Jose Costa Teixeira (May 12 2021 at 09:24):
I presume that for a given concept (or in an entire CodeSystem), the display and the definitions SHALL be in the same language, right?
Jose Costa Teixeira (May 12 2021 at 09:25):
we cannot use a display in a language and the definition in another language.
Can someone confirm?
Rob Hausam (May 12 2021 at 09:37):
@Jose Costa Teixeira That's an interesting and good question. I think the probably obvious assumption would be that it is normally expected that would be the case. We don't have any particular structure that supports it to be otherwise (i.e. using a different language for the display and the definition) or makes it particularly useful to do that, but I don't think that it is strictly prohibited, either. In the comments for Resource.langauge it notes that "Not all the content has to be in the base language." This is probably worth some further exploration - especially if you some use cases in mind where this would be needed.
Jose Costa Teixeira (May 12 2021 at 09:38):
I've seen one idea where the definition was used for describing the concept in another language, and it felt strange.
Jose Costa Teixeira (May 12 2021 at 09:38):
I felt that we should rather use the designations for that
Jose Costa Teixeira (May 12 2021 at 09:39):
but then I did not find any explicit guidance on this
Rob Hausam (May 12 2021 at 09:42):
I think you are right. And we should probably clarify this - and either explicitly support it, or provide guidance or rules that discourage or even prohibit it. You might consider submitting a tracker?
Michael Lawley (May 12 2021 at 22:56):
Note that SNOMED CT uses the FSN (Fully Specified Name) as the source-of-truth (almost definition) of a concept. It also allows for translations of the FSN as well as the Preferred Term (i.e., display). I think calling a translation of the FSN also the FSN is a bad idea, but that ship has sailed.
Grahame Grieve (May 13 2021 at 01:50):
well, technically, the language of the resource applies to both display and definition equally
Michael Lawley (May 13 2021 at 04:43):
That makes things very hard when you do an ValueSet/$expand?displayLanguage=fr&includeDefinition=true and only some of the codes have translations, so your codes have displays that are a mix of en and fr while the language of the resource might be en since all the meta-data (copyright, etc) is en.
Michael Lawley (May 13 2021 at 04:44):
However, you can always define display in languages other than that of the resource by using a designation and specifying a use of display (or, in R5, the redundant preferred-for-display)
Grahame Grieve (May 13 2021 at 05:03):
yes but honestly, that would be hard whatever so I'm not going to lose sleep over that one
Last updated: Apr 12 2022 at 19:14 UTC
