Stream: hapi
Topic: Questionnaire Validator
Grahame Grieve (Jul 13 2019 at 00:47):
@Oliver Egger I believe that you wrote the enableWhen part of the InstanceValidator, which I'm currently fixing to cope with getting the answer from the right context (see https://chat.fhir.org/#narrow/stream/179255-questionnaire/topic/enable-when). I don't understand why there's a DefaultEnableWhenEvaluator. Under what circumstances would it be useful or necessary (or even valid) to replace that implementation? I'm planning to inline it into the validator...
(@Lloyd McKenzie @James Agnew )
Oliver Egger (Jul 13 2019 at 06:04):
@Grahame Grieve , I'm not aware of any work done by me with enableWhen in the InstanceValidator, so I'm not much help here, please apologize
Grahame Grieve (Jul 13 2019 at 09:24):
ok I apologise. I don't know why I had it my head that you wrote that code
Lloyd McKenzie (Jul 13 2019 at 23:27):
Only thing I can think is that it was added to deal with the extension. In theory,additional extensions could be added in the future
James Agnew (Jul 15 2019 at 02:18):
@Grahame Grieve - The EnableWhen logic was written by @Matti Uusitalo (cc @Eeva Turkka ) I believe
Eeva Turkka (Jul 15 2019 at 05:52):
We added the extension point to allow some custom enable when rules based on extensions in Finnish profiles. So it is necessary for us to replace that default implementation for our system, but we did implement the logic to the default implementation in addition to that in case someone else would need it.
(@Okko Kauhanen was also involved)
Grahame Grieve (Jul 15 2019 at 11:46):
so I don't follow.... you have modifier extensions?
Eeva Turkka (Jul 15 2019 at 12:03):
We have modifier extension for evaluating enablewhen-condition in a questionnaire, yes. The condition used is fhirpath-expression and we are currently using STU3 in the system. The questionnaires are here: https://simplifier.net/finnishphr/~resources?category=Example&exampletype=Questionnaire
Grahame Grieve (Jul 15 2019 at 13:04):
ok so I see the extension, but it doesn't make a difference to the way that enableWhen works or is evaluated - it's a parallel thing?
Eeva Turkka (Jul 15 2019 at 13:14):
We treat it like "if there's this modifier extension, the fhirpath-condition in the extension of the question resolves the enablewhen to either true or false" and if there isn't that extension, we call the default "super" implementation that we expect to work as fhir says. It doesn't change the basic logic of enableWhen like "should there be an answer to this question or is an answer allowed here". Some of the questionnaires will have "normal" enable whens that don't have the modifier extension logic.
Grahame Grieve (Jul 15 2019 at 13:46):
hmm. so the extensibility wasn't really right. I'll add an extension point for controlling this
Juuso Oksanen (Sep 30 2019 at 08:18):
Is there a new implementation for this extension point? We noticed while migrating HAPI from 3.8.0 to 4.0.0 that the EnableWhenEvaluatorSupplier has been removed from the FhirInstanceValidator.
Grahame Grieve (Sep 30 2019 at 10:46):
I removed it since it was broken (the design was broken). And we couldn't figure out why it should be extensible
Eeva Turkka (Sep 30 2019 at 10:54):
Is there a way we could implement support for the modifier extension of the enableWhen behaviour that wouldn't be broken by design?
Grahame Grieve (Sep 30 2019 at 11:08):
what modifier extension
Eeva Turkka (Sep 30 2019 at 12:06):
The one mentioned earlier in this thread: https://simplifier.net/finnishphr/fiphr-ext-questionnaire-enablewhenenablewhen
Some questionnaires have a fhirpath condition on some questions instead of the standard enable when (and we are still using STU3, but I believe it will be the same in R4).
Okko Kauhanen (Oct 02 2019 at 08:54):
FHIRPath-based item visibility logic is vital for our project. We have already built our implementation around it.
The standard enableWhen structure cannot express complex criteria. Extending the enableWhen-structure does not help either, so a parallel implementation is needed.
If this is a bad design choice, how should we proceed?
A similar official extension has been in development, but for some reason, it did not get included in R4:
http://hl7.org/fhir/2018Sep/extension-questionnaire-enablewhen.html
"This is only permitted when the containing item does NOT have any enableWhen elements."
"Context of Use: Use on Element ID Questionnaire.item or Element ID Questionnaire.item.item"
Grahame Grieve (Oct 25 2019 at 00:53):
ok, getting to this.... the extension should not be a modifier extension
Grahame Grieve (Oct 25 2019 at 00:56):
does this capture the correct meaning of the extension?
<?xml version="1.0" encoding="UTF-8"?> <Questionnaire xmlns="http://hl7.org/fhir"> <id value="questionnaire-enableWhen-test" /> <language value="en-US" /> <text> <status value="generated" /> <div xmlns="http://www.w3.org/1999/xhtml" lang="en-US"> <p>enableWhen test</p> </div> </text> <url value="http://hl7.org/fhir/us/hai/Questionnaire/questionnaire-enableWhen-test" /> <status value="draft" /> <item> <linkId value="condition" /> <text value="condition" /> <type value="boolean" /> <required value="true" /> <repeats value="false" /> </item> <item> <extension url="http://phr.kanta.fi/StructureDefinition/fiphr-ext-questionnaire-enablewhen"> <valueString value="QuestionnaireResponse.descendants().select(item).where(linkId='condition').answer.value.ofType('boolean')" /> </extension> <linkId value="enable-when" /> <text value="enable when condition true" /> <type value="boolean" /> <required value="true" /> <repeats value="false" /> </item> </Questionnaire>
Grahame Grieve (Oct 25 2019 at 01:06):
@Okko Kauhanen what did you about passing in the current context to the FHIRPath expression when you are evaluating it?
Grahame Grieve (Oct 25 2019 at 01:35):
see discussion here: https://chat.fhir.org/#narrow/stream/179255-questionnaire/topic/SDC.20EnableWhen.20extension
Last updated: Apr 12 2022 at 19:14 UTC
