Stream: questionnaire
Topic: enableWhen operator for range?
Ajay Kanduru (Nov 20 2018 at 15:01):
How do we specify range of a value in enableWhen, for example to enable when question value is 0 to 10? The operator codes don't seem to cover the use case...
Astrid Corinna Wolff (Nov 20 2018 at 15:06):
I think in R3 you could only define a set of enableWhen statements each covering one of the allowed numbers since several enableWhen statements are always combined with a logical OR:
- enableWhen value=0
- enableWhen value=1
- ...
- enableWhen value=10
In R4 you could specify enableBehavior = all (which means a logical AND) and then you would only need the following conditions:
- enableWhen value >= 0
- enableWhen value <= 10
Ajay Kanduru (Nov 20 2018 at 16:54):
@Astrid Corinna Wolff The problem with that approach is that you cannot add another enableWhen, say doing OR with different question.
Ideally, I would like to see operator code expanded or add some additional attributes in enableWhen, without the use of enableBehavior.
Lloyd McKenzie (Nov 20 2018 at 18:23):
There's a new enableWhenExpression extension being introduced in SDC that gives you the ability to do full expression logic
Brian Postlethwaite (Nov 20 2018 at 19:24):
Using fhirpath as the expression language
Astrid Corinna Wolff (Nov 21 2018 at 08:13):
That's an interesting approach - thanks for the hint.
However, using the extension from SDC would mean that I can't be sure that all clients will know and understand this extension and there might be some that could not handle it and therefore, the enableWhen statements within might not be executed at all and the actually depending items might always be displayed.
Lloyd McKenzie (Nov 21 2018 at 17:38):
That's true even for core elements. Not every system that implements Questionnaire will necessarily support enableWhen. It's part of core because we believe "most" systems will support it, but there's never a guarantee.
Ajay Kanduru (Nov 24 2018 at 15:17):
It feels like there can be a simpler solution. Something like including answerRange in answer[x] might work better, isn't it?
Lloyd McKenzie (Nov 24 2018 at 20:06):
Adding things to core always makes things easier for some, but harder for everyone else. When we try to include the needs of everyone in the core spec, the specification becomes overwhelmingly complex. Extensions for uncommon behavior is the best way we've found to manage the complexity.
Yunwei Wang (Apr 07 2020 at 20:38):
(deleted)
Last updated: Apr 12 2022 at 19:14 UTC
