Stream: questionnaire
Topic: calculatedExpression item that is not read-only
Diane (Nov 11 2021 at 23:30):
In http://build.fhir.org/ig/HL7/sdc/expressions.html#expression-extensions there is a notation that 'In most cases, 'calculated' answers should be marked as 'readOnly', however in some cases it may be legitimate to override a calculated element, for example if the calculation cannot be made due to non-available information, but the user still knows the calculated value.'
If the item is not marked as "readOnly", what is the expectation in the spec? That the user will be able to edit the answer? How is this implemented in LHC-Forms?
Paul Lynch (Nov 12 2021 at 16:29):
Yes, the expectation is that if not marked readOnly, the user will be able to edit it even if there is a calculatedExpression, but in that case the calculatedExpression should stop calculating. LHC-Forms' implementation of calculatedExpression was written before that behavior was settled, and just makes the field readOnly whenever there is a calculatedExpression. I had meant to change that, and added code to stop the calculation if the user edited it, but I see that I missed removing the setting of the readOnly flag. Do you have a case where you have a calculatedExpression and also want the user to be able to edit?
Diane (Nov 13 2021 at 01:26):
Maybe. It is the recalculating ability that I need along the way, which initialExpression doesn't provide. For several of our questions, I use initialExpression as a workaround because I need the user to be able to edit, but my tests show that calculatedExpression is less prone to population errors because it allows recalculation along the way. The initialExpression often doesn't re-calculate correctly when too many answers are changed as the questionnaire is completed. This happens where there is a series of questions where if they are done if the correct order and the user doesn't need to change any answers along the way, then then the final answer populates correctly using initialExpression. I have used the newly implemented enableWhen extension to try to force the order of question completion so that the chance of changing answers is minimized. So, I have a sort of workaround for now. But, there really needs to be a populate expression that works (and allows editing) that recalculates along the way.
Tilo Christ (Nov 15 2021 at 17:20):
Would there be a need to somehow flag the questionnaire response item as being manually entered? I am just thinking about saving a questionnaire with a manually overridden calculatedExpression in non-completed state to a server and then retrieving it again later for completion. How would the filler know that it should again not be read-only. Something similar to the "userSelected" flag in Coding.
Lloyd McKenzie (Nov 15 2021 at 20:09):
The specification says that if the value is different from the calculated value at time of load, presume it's been manually edited.
Brian Postlethwaite (Nov 15 2021 at 20:41):
And if the other data is changed then it will be recalculated and overwritten again. Very subtle interactions there.
Diane (Nov 16 2021 at 01:54):
Agreed. @Brian Postlethwaite what does your form filler do? Do you have this implemented so that the user can manually override?
Brian Postlethwaite (Nov 16 2021 at 02:13):
I've only just completed that functionality, and haven't really tried it out in those specific cases.
So it's likely undefined what behaviour will be when reloading a fork like that. We anticipate that the calc field will be read only, and another field for a custom value.
Diane (Jan 10 2022 at 22:41):
I would like to discuss this topic (and Brian's implementation) at the Connectathon this week.
Last updated: Apr 12 2022 at 19:14 UTC
