FHIR Chat · Why creating multiple language questionnaires are so HARD? · questionnaire

Stream: questionnaire

Topic: Why creating multiple language questionnaires are so HARD?

Koray Atalag (Jan 27 2021 at 12:33):

I'm trying to create a Questionnaire with multiple language translations.
Using the translation extension is non-intuitive but possible on some elements. However I was not able to find a way to represent multiple languages for answerOption > valueCoding

Am I missing something fundamental or is this not possible with R4?

Some example (from EQ-5D)
"item": [
{
"linkId": "CFL3F6qDfpxshEFKt",
"text": "MOBILITY",
"type": "choice",
"required": true,
"answerOption": [
{
"valueCoding": {
"code": "1",
"display": "I have no problems in walking about"
}
},
{
"valueCoding": {
"code": "2",
"display": "I have slight problems in walking about"
}
},
{
"valueCoding": {
"code": "3",
"display": "I have moderate problems in walking about"
}
},
{
"valueCoding": {
"code": "4",
"display": "I have severe problems in walking about"
}
},
{
"valueCoding": {
"code": "5",
"display": "I am unable to walk about"
}
}
]
},

Jose Costa Teixeira (Jan 27 2021 at 13:15):

The language translation extension should be useful there

Jose Costa Teixeira (Jan 27 2021 at 13:19):

If you use AnswerOption, you can add a translation in your coding.display

John Manning (Jan 27 2021 at 14:11):

Do you have an example? @Jose Costa Teixeira That may be helpful for some of our efforts too.

John Manning (Jan 27 2021 at 14:11):

We're handling translations separately from FHIR, as linked by code

Jose Costa Teixeira (Jan 27 2021 at 14:29):

{
  "valueCoding": {
  "code": "1",
  "display": "I have no problems in walking about",
  "_display" : {
    "extension" : [
      {
        "extension" : [
          {
            "url" : "lang",
            "valueCode" : "nl-BE"
          },
          {
            "url" : "content",
            "valueString" : "Geen problemen met lopen"
          }
        ],
        "url" : "http://hl7.org/fhir/StructureDefinition/translation"
      }
    ]
  }

Jose Costa Teixeira (Jan 27 2021 at 14:39):

(note that I had forgotten a comma, now I just fixed the example)

Morten Ernebjerg (Feb 01 2021 at 08:28):

I'm a bit late to this, but I thought I'd mention an alternative approach to this that we have been using for the problem of multi-language questionnaires. Whether it is better or worse probably depends on the details, happy to hear any thoughts on this (we have struggled a lot with cross-language usage, too). We do as follows:

1. Add translations for code at the CodeSystem level using designation entries (CodeSystem.concept.designation). In R4, you can also use this to "decorate" existing code systems with translations by creating a CodeSystem supplement with content = "supplement" and supplements pointing to the CodeSystem you are adding to.
2. Do language-specific expansions of the needed answer ValueSets using the translations in CodeSystems & set the language element accordingly.
3. Generate language-specific Questionnaire resources from simple home-made JSON templates & non-FHIR translation files, setting the language element accordingly
4. Use the expanded value sets in the right language for the allowed answers (in some scenarios, we directly embedded them in the questionnaire as contained resources).

The advantage is that the output resources are specific to a single so the the consuming application does not need to handle any translation logic/understand the translation extension. Also, the code display translations are are in one place (CodeSystem) and does not need to be duplicated in individual resources. The downsides are that one needs a pipeline generating the language-specific resources (we wrote our own), and that one in the end has different copies of the final resources for different languages. In essence, this approach puts the work in the generation of the resources, rather than the consumption.

Last updated: Apr 12 2022 at 19:14 UTC