Stream: questionnaire
Topic: Answer text differing from code display
Morten Ernebjerg (May 13 2020 at 12:14):
Hi :wave: I am trying to understand how to best handle the following scenario:
- You have a multiple choice question where the possible answers are defined by a ValueSet containing codes (e.g. from a standard system)
- For one reason or another, the
displayvalues for these codes are not appropriate/confusing to display to the user as answer texts/labels in the UI, so other texts need to be displayed
For such cases, is there a standard way to capture the answer labels/texts that should be displayed? That is, some way of associating each code in the answer value set with a string (similar to how the code and text fields in a single item are linked together). One could of course have such a map outside FHIR (e.g. just in the UI), but it may e.g. be important for consumers of the data to know what exactly the user saw when choosing a given option.
Oliver Egger (May 13 2020 at 12:26):
for our multiple language valuesets in questionnaires we use the designation/language directly in the valueset (e.g. https://github.com/hl7ch/covid-19-prom/blob/master/input/resources/questionnaire/coronascience-question-of-the-day-QD1.xml), maybe a similiar approach can be used in your use case?
Morten Ernebjerg (May 13 2020 at 12:56):
Hi @Oliver Egger, thanks for the tip! We actually already use designations for handling multiple languages. The problem is rather cases where the standard code display (even in the right language) simply does not fit, e.g. due to the way the question is formulated or because the display text is so technical that the (lay) user will not understand what it means. For instance (not a great example, but all I could think of right now): suppose we want to use LOINC LA6255-9 ("Lives alone") to encode housing situation. A natural way to pose the question might be "What is your current housing situation?" but "Lives alone" does not fit (grammatically) as an answer (whereas "I live alone" does).
Oliver Egger (May 13 2020 at 13:34):
maybe add a designation with a different use attribute?
Morten Ernebjerg (May 13 2020 at 16:18):
Ah right, interesting point! - I had forgotten that designations are more general. However, conceptually I would prefer the text <---> code association to be attached to the Questionnaire because the latter defines the context in which the association is used/is of interest. If a given answer code is used in multiple questions and/or questionnaires with different formulations, one would otherwise have to pile designations for different contexts into the CodeSystem.
Lloyd McKenzie (May 13 2020 at 16:56):
When you define a value set, you have the option of overriding the 'display' values (and designations) with valueset-specific values
Morten Ernebjerg (May 13 2020 at 18:44):
@Lloyd McKenzie ah, I was not aware of that - does that work for any code system? I was under the impression that the display values for standard systems like LOINC were considered part of the code system and should therefore be maintained.
I suppose that would mean that if one wanted to know exactly which formulation was used for which question, one would have to generate a ValueSet for each unique set of display values?
Lloyd McKenzie (May 13 2020 at 19:10):
That's true of the value set machinery regardless of code system. The challenge is that value sets are context-specific and the code system names are context independent. Context independent names can have a negative impact on usability when you're in a context-specific circumstance.
Lloyd McKenzie (May 13 2020 at 19:11):
The questionnaire question should ideally be tied to a single value set. However, if there are language-specific designations, then it might not always be possible to know exactly what the user saw.
Morten Ernebjerg (May 14 2020 at 05:55):
I see, right, it might not be possible to remove the last bit of ambiguity. Just to make sure I get this right: Is one is free to put essentially whatever one wants in display _in a ValueSet_ (or just the expansion?), even if the code is from e.g. LOINC or SNOMED?
Lloyd McKenzie (May 14 2020 at 13:28):
Yes, though you'll get a validation warning if it differs from a known representation in the code system or any code system supplements referenced by the value set.
Morten Ernebjerg (May 14 2020 at 13:41):
OK, thanks @Lloyd McKenzie & @Oliver Egger - learning something new every day here :slight_smile:
Lloyd McKenzie (May 14 2020 at 14:32):
Zulip is good for that :)
Ken Sinn (Aug 10 2020 at 20:23):
Are Designations and the Translation Extension the preferred method to handle multi-lingual questionnaires (for question text and answer text), as per Oliver's example above? If so, would be useful to have as a proper example (a well as a guidance section) in both Questionnaire as well as the SDC. Multilingual representation seems like it might be a common use case.
Morten Ernebjerg (Aug 11 2020 at 11:20):
@Ken Sinn I would second that, we also work a lot with multi-language questionnaires. For a recent COVID-19 IG containing a screening questionnaire, we took the approach of manually generating separate, language-specific versions (as indicated by the language element) for the questionnaire & the expanded value sets with answer options (the latter generated from code systems with the added translations in designations). However, there may be preferable alternatives - as discussed in this terminology thread, such "language-doubled" resource copies is currently not really supported in IGs (e.g. I suppose IG tooling would not be able to handle it) and it was remarked that distributing expanded value sets could be brittle.
Grahame Grieve (Aug 11 2020 at 12:29):
the main terminology servers should get the language right in expansions
Grahame Grieve (Aug 11 2020 at 12:29):
agree it would be good to add an example
Grahame Grieve (Aug 11 2020 at 12:29):
want to contribute one?
Ken Sinn (Aug 11 2020 at 18:22):
If @Oliver Egger agrees to the inclusion of his example from https://github.com/hl7ch/covid-19-prom/blob/master/input/resources/questionnaire/coronascience-question-of-the-day-QD1.xml, and if it accurately represents best practices around designations and the translation extension, then I think that would be a good example.
Oliver Egger (Aug 12 2020 at 07:53):
you can sure use it, but i'm not sure about if it represent best practices
Ken Sinn (Aug 13 2020 at 14:13):
Is there any guidance/preference on whether to use the designation on the CodeSystem vs ValueSet to provide alt language displays?
Grahame Grieve (Aug 13 2020 at 21:28):
well, it really depends on access and appropriateness.
in general, if you are doing alternative language displays, you should define them in the code system just like you do with the native language displays. This way they are available where ever the code system is used
But you might not be the publishing authority for the code system you are translating. Under this circumstance, you can use a code system supplement to provide the translations. This means that the language is in scope anywhere the supplement is made available. Unfortunately, support for supplements is not yet widespread
You can fall back to putting them in the value set. This means that they are only available in the value set itself.
Grahame Grieve (Aug 13 2020 at 21:30):
note that the reason you can provide a display in the value set is because in some circumstances, the general display for a concept is not appropriate. A good example is a curated list of virus codes from SCT. Every virus concept display will have lots of text about how it's about a virus - but that's true for every concept in the value set. So the value set should (for safety reasons) provide displays that remove all the spurious text
Grahame Grieve (Aug 13 2020 at 21:31):
OTOH, it's very obvious that value set specific displays are dangerous: the could totally - or subtly - redefine the concept meaning
Last updated: Apr 12 2022 at 19:14 UTC
