Stream: implementers
Topic: valueCodeableConcept in Questionnaire.item.option
Ville Lindholm (Jun 06 2017 at 13:09):
When implementing multiple choice questions in a Questionnaire resource, it would be practical to have the possibility to use item.option.valueCodeableConcept for making answer choices with a code attached to them. Right now only valueCode is permitted, but if one were to use valueCodeableConcept instead, the displayed text would be in valueCodeableConcept.text, and the code (with system, code and display fields) would be totally separate from the "UI element", i.e. valueCodeableConcept.text. We will probably do this using an extension, but I think it would be a good thing to have in STU4 also (makes a lot more sense than valueCode). Where can these suggestions be made?
Lloyd McKenzie (Jun 06 2017 at 13:19):
You can make a change proposal using the "propose a change" link at the bottom of every page in the spec. This possibility has been talked about before. There are two challenges - CodeableConcept also allows for multiple codings and when there's the ability to have code or text, there's usually carefully controlled behavior about whether the text is instead of or in addition to a code - and which codes can be accompanied by text and which can't. As a result, the current recommendation is to use a nested question for the text value. That gives you full control over when it gets captured.
Robert McClure (Jun 06 2017 at 14:59):
@Lloyd McKenzie Is there someplace i can see an example of the suggested approach?
Lloyd McKenzie (Jun 06 2017 at 15:56):
There are several examples of nested questions with enableWhen controlling their appearance. There aren't currently any with a string value for a code though.
Ville Lindholm (Jun 06 2017 at 16:24):
Alright, thanks! I think we'll go with an extension, nested questions seem like an unnecessarily complex way of doing something that I would think is quite a popular use case. You're right that CodeableConcept has problems, I'll try to think of a good suggestion now that I found the suggestion link ;)
Lloyd McKenzie (Jun 06 2017 at 16:33):
Extensions won't be recognized by most systems. Note that there is an open-choice data type to use if you want to capture either a Coding or a string.
Ville Lindholm (Jun 06 2017 at 16:36):
I want to capture a coding, always, but I want to display something else to the user than just the code (or its 'display' value).
Ville Lindholm (Jun 06 2017 at 16:37):
So if the choice strings are "A" and "B" I want to associate a code to each choice and send that back in the QuestionnaireResponse.
Ville Lindholm (Jun 06 2017 at 16:39):
choice as in, option, to use FHIR terms :)
Lloyd McKenzie (Jun 06 2017 at 16:39):
What are you wanting to display other than the code or its display value?
Lloyd McKenzie (Jun 06 2017 at 16:40):
You mean the label? I.e. the "(a)" in "(a) blue"?
Ville Lindholm (Jun 06 2017 at 16:40):
Just some more human readable string than what the code itself provides.
Ville Lindholm (Jun 06 2017 at 16:41):
And depending on the user settings, in different languages
Ville Lindholm (Jun 06 2017 at 16:41):
We used to put that string in valueCode.display, but now we need to use it for other things, and it didn't feel right to do in the first place :)
Lloyd McKenzie (Jun 06 2017 at 16:48):
Well, the intention is that you use valueCode.display. There's an extension on 'string' to convey translations
Ville Lindholm (Jun 06 2017 at 16:51):
Alright, maybe I have to rethink our whole structure there. Thanks for the tips!
Brian Postlethwaite (Jul 04 2017 at 05:40):
Or you can use an OpenChoice type, which permits either a coded value, or a valueString.
Last updated: Apr 12 2022 at 19:14 UTC
