Stream: questionnaire
Topic: SDC EnableWhen extension
Grahame Grieve (Oct 25 2019 at 01:15):
SDC defines an extension for enable when using url http://hl7.org/fhir/uv/sdc/StructureDefinition/sdc-questionnaire-enableWhenExpression at https://build.fhir.org/ig/HL7/sdc/extension-sdc-questionnaire-enableWhenExpression.html
Grahame Grieve (Oct 25 2019 at 01:15):
the extension does not define how the expression is made aware of the context in the QR in which it is being run
Grahame Grieve (Oct 25 2019 at 01:16):
There is no way, at this time, to use this extension
Grahame Grieve (Oct 25 2019 at 01:23):
there's basically 2 sets of information to pass to the expression:
- the stack of questions in the Questionnaire
- the stack of answer items in the QuestionnaireResponse
You need this context as soon as your dependency depends on a question within the context of a repeating item above you
Grahame Grieve (Oct 25 2019 at 01:24):
The finnish project ignores this and assumes that the expression is evaluated in the context of the QR itself.
Grahame Grieve (Oct 25 2019 at 01:35):
so what I propose is that the:
- the expression is executed in the context of the QuestionnaireResponse
- there's a variable %qstack which is a collection that has the stack of answer contexts in the QR. Each is a Tuple with .answer and .question properties
- there's a variable %questionnaire that has the actual questionnaire (for simplicity, since it's also the .question for the first entry in the stack)
Lloyd McKenzie (Oct 25 2019 at 01:56):
Have you read the content about expressions in SDC? It indicates how you access answers to other questions, variables that have been defined higher in the questionnaire, etc.
Lloyd McKenzie (Oct 25 2019 at 01:56):
I don't think we need anything more.
Grahame Grieve (Oct 25 2019 at 02:12):
where are you looking? (it would probably help to reference it from the extension)
Grahame Grieve (Oct 25 2019 at 02:13):
if you are referring to this: https://build.fhir.org/ig/HL7/sdc/expressions.html#expression-extensions , then I don't see any answer to my question
Lloyd McKenzie (Oct 25 2019 at 02:25):
Some of the change requests aren't reflected yet which will let you reference the root of the Questionnaire or the QuestionnaireResponse or a particular Question in the Questionnaire. However, with variable, you can make the values of "previous" answers available.
Grahame Grieve (Oct 25 2019 at 02:27):
so I kind of feel let down, since I can't actually see what matters - perhaps you could provide details....
but it sounds like it doesn't get to the heart of the matter anyway: when you are evaluating enableWhen, you need access to stack for the item you are evaluating it's enabled-ness
Lloyd McKenzie (Oct 25 2019 at 02:35):
I'm not sure what you mean by "stack". Are you talking about all of the ancestor items? (I recall asking for an ancestor ability in FHIRPath a couple of years ago and you weren't thrilled :>)
To get around that, the expectation now is that if you're going to have an item depend on stuff that isn't a descendant of that item, you declare a variable on a higher level item that captures the necessary information. the expressions within the item then reference the variable - which is available in scope.
Grahame Grieve (Oct 25 2019 at 02:37):
That's a very hard way to go about the problem.
Grahame Grieve (Oct 25 2019 at 02:39):
The evaluator has an internal stack of the answers it is working with. It can make that available to the enableWhen expression without the need for the author to define variables
Lloyd McKenzie (Oct 25 2019 at 02:48):
By stack, do you mean just the ancestors or do you mean all preceding items?
Grahame Grieve (Oct 25 2019 at 02:49):
all the containing elements that bring you to the answer your evaluating the enabled-ness of
Grahame Grieve (Oct 25 2019 at 02:49):
I think that ancestor isn't the right word
Grahame Grieve (Oct 25 2019 at 02:57):
but maybe doing via variables is better for re-use
Lloyd McKenzie (Oct 25 2019 at 02:59):
I don't expect the tool that's rendering the questionnaire to necessarily have a clue which elements are going to be relevant for subsequent enableWhens. If it's keeping track of anything, it would either have to be all prior items (which seems kinda big/complicated) or all ancestors (which makes my XPath heart happy, but is a capability I'm surprised to hear you proposing)
Grahame Grieve (Oct 25 2019 at 03:01):
the engine needs to have the containers (=ancestors) in order to evaluate a normal enable when. It can pass that collection to the expression if we define a way. that's not the same thing as the XPath ancestor thing)
Lloyd McKenzie (Oct 25 2019 at 03:10):
Would you care to submit a change request? :)
Last updated: Apr 12 2022 at 19:14 UTC
