FHIR Chat · answerValueSet invariant

Stream: questionnaire

Topic: answerValueSet invariant

Joee Garcia (Sep 02 2020 at 02:05):

I'm working on updating the core Questionnaire resource based on the change request to remove 'choice' and 'open-choice' types (See https://jira.hl7.org/browse/FHIR-20396). Since we're removing these types, this invariant on 'item' is not applicable anymore:

que-5: Only 'choice' and 'open-choice' items can have answerValueSet

I've discussed this with Lloyd and he thinks, this invariant should be updated so answerValueSet should only be allowed for 'coding', 'string' and 'url' type questions. Any thoughts or concerns?

Brian Postlethwaite (Sep 02 2020 at 22:48):

url type questions?

Paul Lynch (Sep 02 2020 at 22:51):

Can a ValueSet contain something other than Coding?

Joee Garcia (Sep 03 2020 at 14:48):

According to Lloyd, you can only get codes on ValueSets but you can treat them as strings (ie you can have codes like "Canada", "U.S." and treat them as strings for an address part). For url, he said there are places where you actually have a list of URLs as pseudo codes so it should be applicable, too.

Paul Lynch (Sep 03 2020 at 15:26):

That would require the form renderer to know that if there is an item of type 'string' or 'url', it should convert Codings into strings by taking just the code part. Is there something in the specification that suggests the form renderer should do that? When showing the list for the user to pick from, would it then show the code attributes rather than the display attributes?

Lloyd McKenzie (Sep 03 2020 at 15:31):

We should probably add some explicit language making clear that's possible - care to submit a change request? :)

Paul Lynch (Sep 03 2020 at 15:34):

I am not sure it is a change I want. Who is it that wants answerValueSet for items of type string or url? Why wouldn't you just use type "coding"?

Lloyd McKenzie (Sep 03 2020 at 18:11):

Because the element you're mapping to is type string - e.g. Address.country or Address.state, HumanName.prefix, etc.

Paul Lynch (Sep 03 2020 at 18:42):

If you are creating a StructureMap to extract from Questionnaire to something containing an Address or HumanName, presumably that StructureMap could handle an answer with a Coding, couldn't it? It doesn't seem like form renderer's role to know how to convert a Coding to a string.

Lloyd McKenzie (Sep 03 2020 at 18:59):

It's commonly done in profiles - so it seems to make sense to allow it in Questionnaire too...

Paul Lynch (Sep 03 2020 at 19:12):

When displaying a list of Codings, the user normally sees the display strings, and that it was goes into the field when they pick one. Making a special case for putting the code property into the field does not sound right to me, especially when the value in the response is not the full Coding. There would need to be some way to state how the Coding should be converted to a string and there is more that one option for that.

Brian Postlethwaite (Sep 03 2020 at 21:43):

The string support in open-choice isn't for the valuieset, its for an answer where it isn't in the set.

Paul Lynch (Sep 03 2020 at 22:04):

That's true currently, but see the top of this thread for context.

Brian Postlethwaite (Sep 03 2020 at 23:38):

Lloyd is right that in Structure Definitions you can "bind" a valueset to a text field like city, which will then check that the display value is in the field. (from my understanding)
And I think he's suggesting that Questionnaire should support that too.

Lloyd McKenzie (Sep 04 2020 at 01:30):

Yup

Paul Lynch (Sep 04 2020 at 13:56):

Joee Garcia said:

According to Lloyd, you can only get codes on ValueSets but you can treat them as strings

I thought this meant the code was in the field. Is the code or the display value in the field? It is not clear which of them one would want. Possibly, one would combine the two into one string with some separator.

Brian Postlethwaite (Sep 04 2020 at 21:03):

Not for things like a state or postcode or even city. You'd want to only see the display value.

Paul Lynch (Sep 09 2020 at 16:53):

So there are seem to be at least two use-cases with different desired outputs (codes, or display values). If you were picking an ICD-10 code, you might want both code and display in the field. It sounds like there should be some FHIRPath to construct the value from the Coding.

Joee Garcia (Sep 17 2020 at 21:17):

Can we make use of candidateExpression (which will be renamed to answerExpression) with a FHIRPath in constructing the value for the Coding? If so, how can we reference the answerValueSet in the FHIRPath?

Lloyd McKenzie (Sep 17 2020 at 22:02):

Sorry @Joee Garcia - just saw this. We could have taken some time to discuss on the call. I'm not sure I understand the question - can you expand/give an example?

Paul Lynch (Sep 17 2020 at 22:55):

I don't think candidateExpression and answerExpression are the same thing.

Paul Lynch (Sep 17 2020 at 22:59):

candidateExpression's description says, "NOTE: the set of candidate expressions is intended to be a starter set, not exhaustive. The user should be free to enter or look-up additional values." But, answerExpression is the complete list for the field.

Joee Garcia (Sep 17 2020 at 23:02):

My understanding for this ticket J#21332 is that we are changing candidateExpression to answerExpression. Is this not the case?

Paul Lynch (Sep 17 2020 at 23:06):

Yes, I was just looking at that. I don't see how that works though. answerExpression will resolve to some list of items. That is all the user has to choose from, though they could enter a string. My understanding of candidateExpression was like "here is a list of medications based on your record, but you can enter others" and then the user could either pick one of those or get any other medication using answerValueSet. The user of answerExpression precludes the use of answerValueSet. (For references answerExpresion is documented in J#25960 and J#28386.)

Joee Garcia (Sep 18 2020 at 19:41):

Paul Lynch said: