Stream: questionnaire
Topic: Variable scope
Paul Lynch (Oct 15 2020 at 17:05):
http://hl7.org/fhir/R4/extension-variable.html says, "The name of the variable will be added to FHIRPath's context when processing descendants of the element that contains this extension." What about when processing the element (item) itself? The LHC-Forms implementation supports calculatedExpression referencing variables defined on the same item. I suppose that it not necessary, but it is nice to have all the expressions listed together on the same item.
Lloyd McKenzie (Oct 15 2020 at 17:09):
Yes, should add for the current node too. Change request for us to clarify?
Paul Lynch (Oct 15 2020 at 17:22):
Very good! We will have at least one thing to vote on at today's call. J#29264.
Lloyd McKenzie (Oct 15 2020 at 17:27):
No call today
Lloyd McKenzie (Oct 15 2020 at 17:28):
(I'd already cancelled it - have a conflict)
Lloyd McKenzie (Oct 15 2020 at 17:28):
SHould be an easy approval item for next week though
Paul Lynch (Oct 15 2020 at 17:29):
Okay-- and thanks for the reminder.
Brian Postlethwaite (Oct 19 2020 at 23:57):
Um, on the same node?
Just let me assume that they wouldn't be able to see each other.
Paul Lynch (Oct 20 2020 at 12:22):
@Brian Postlethwaite Why not? It already possible to construct a variable and a calculatedExpression that "see each other" on different nodes. It seems like an unnecessary and complicating restriction to require that you can't refer to variables on the same item. The same issue arises between variables. If your formula is complicated, you might want to define on the same item:
varA = complicated expression
varB = (varA + ...)/(varA + otherVar)
You would not want to require that varA and varB be different items, which might require the introduction of a new group item into the form simply for sake of putting a variable on it.
Paul Lynch (Oct 20 2020 at 14:59):
If you are worried about dependency loops, that possibility is warned against in section on expression dependencies. It is up to the Questionnaire author to avoid such situations, and rendering system is supposed to detect them and produce an error message.
Lloyd McKenzie (Oct 20 2020 at 15:06):
Variables could even refer to other variables. The key is to make clear that order of appearance matters and to define the order in which evaluation needs to occur
Paul Lynch (Oct 20 2020 at 15:09):
I had the same thought, that we should specify that, but now I am not sure the order of evaluation matters. My understanding is you keep evaluating things until the values stabilize.
Paul Lynch (Oct 20 2020 at 15:12):
From 5.4.1: "However, in some cases, updates to later elements may trigger an update to earlier elements, which then cascade through again. Systems should allow for this and allow for iterative updating of expressions until values reach a stable state - or until an unstable looping condition is detected. "
Lloyd McKenzie (Oct 20 2020 at 15:24):
I'm thinking more about whether forward referencing of variables is allowed. I.e. can you declare a variable that depends on bar, then declare bar (within the same element)? I would think that would be somewhat hinky. However, if no one thinks it's a problem, I'm fine with not defining any constraints.
Paul Lynch (Oct 20 2020 at 15:32):
I don't know why you would write it that way, but it should not cause a problem (except maybe make it run a little slower, because it would need an extra iteration of evaluation). Variables can depend on fields which initially do not have a value, but they have to get processed anyway. A variable depending on another variable that doesn't have a value is handled the same way, and does not need to care whether that other variable is "defined" yet. Of course, some implementation might keep a list of defined variables, I suppose, and then have an issues with Questionnaires that were using forward-references. Perhaps it is better to be explicit about whether that is allowed or not. But, if we disallow it, I would like it be worded in such a way that it does require that systems that don't care do extra error checking that is not necessary.
Brian Postlethwaite (Oct 20 2020 at 23:37):
My engine was evaluating the expression, putting it into the variable then permitting its use. So it couldn't use other variables not already declared, as they don't exist (yet) - not in scope.
But I guess they could use ones at the same level declared before them.
Paul Lynch (Oct 21 2020 at 17:20):
J#29329, "Allow variables to be in scope on their own element"
Brian Postlethwaite (Oct 13 2021 at 22:44):
Is there anything preventing a variable be "re-defined" on a child item?
Brian Postlethwaite (Oct 14 2021 at 00:52):
And now that I'm implementing support for this, what is the scope of a variable on a repeating group?
While processing, does it contain the nodes of all items, or just the repetition that it is processing at a time (asking as this would impact aggregates)
Brian Postlethwaite (Oct 14 2021 at 00:56):
Not a particularly valid example, but I think it kinda shows the potential issues
(wanting to have the height/weight variables on a per item basis)
image.png
Brian Postlethwaite (Oct 14 2021 at 02:38):
Also wondering if there's a way to access properties/extensions from a coding (or answerCoding) from the response (while using expressions)
Lloyd McKenzie (Oct 14 2021 at 02:55):
Yes. We've said that it's an error for the name to exist multiple times within the same scope.
Brian Postlethwaite (Oct 14 2021 at 20:59):
Another example for the variable scope context discussion
image.png
Last updated: Apr 12 2022 at 19:14 UTC
