FHIR Chat · Different enableWhen support?

Stream: questionnaire

Topic: Different enableWhen support?

Lloyd McKenzie (Mar 05 2021 at 17:36):

EnableWhen is a weird beast. It's not totally clear whether it makes the 80% rule - and we have a more generic solution (enableWhenExpression) that covers everything enableWhen allows plus more - and it's not clear that it's significantly more complex to support. Also, we have some forms that have a design approach of "skip to Question X" which is somewhat clunky to implement using enableWhen.

How comfortable are we that we want to lock this down into "can't break compatibility going forward"?

Jean Duteau (Mar 05 2021 at 17:37):

enableWhen and enableWhenExpression were backwards for our questionnaire purposes. We had the "skip to question" version of the rules. Based on the answer to this question (or some external parameters), we need to say go to the next question and, as you said, that is clunky or downright not doable using enableWhen.

Lloyd McKenzie (Mar 05 2021 at 17:39):

It should be doable (curious what couldn't be expressed if not), but definitely can get super clunky.

Ilya Beda (Mar 09 2021 at 10:42):

I think that replacing enableWhen with enableWhenExpression is a good idea. It is much easy to support the only enableWhenExpression rather than try to implement all weird options for enableWhen.
We can provide a tool that automatically converts old enableWhen elements to enableWhenExpression notation.

Paul Lynch (Mar 10 2021 at 21:48):

I like the idea of a "skipToItem" extension, though I wonder would should happen if a question is skipped but its own enableWhen logic (or its group's) says to show it. I think implementations would need separate flags for both.

Elliot Silver (Mar 10 2021 at 21:59):

Does "skipTo" need to be partnered with "backTo"? Assuming that for each question I have "next question" and "previous question" buttons, and use skipTo to jump from Q2 to Q5, would the "previous question" button take me Q4 or Q2? Does it matter if Q3 and Q4 are enabled, but skipped? Can you skip an enabled question?

I like enableWhen because it means I don't need to learn (the even more poorly documented than SDC) FHIRPath or CQL to turn on or off particular questions. If enableWhen is replaced, enableWhenExpression needs to have solid examples that correspond to the basic use cases that enableWhen covered.

Paul Lynch (Mar 10 2021 at 23:02):

I think skipToItem would override enableWhen(Expression). A back button would have to skip over any skipped or disabled items.

Brian Kaney (Mar 11 2021 at 03:47):

Great thread ...

I do like the skipTo idea having built many questionnaires and the code to implement form filler behavior.

I was thinking of skipTo as a way of specifying an alternative exit edge from an item (where the default exit edge is either the next child, or next sibling item). As enableWhen is an entry condition (similar to condition in Plan/ActionDef.action), I don't think one would override the other (e.g. enableWhen logic would still apply).

But I don't think this idea should be conflated with trying to specify item navigational state (e.g. backTo). It is a special case if the form filler experience is one-question-at-a-time (as opposed to seeing all items at once, or broken down by group, or other hierarchy).

Ilya Beda (Mar 11 2021 at 14:33):

@Elliot Silver I am not using CQL, so I can't help with it.
However, FHIRPath is well documented and it is very simple to convert enableWhen to FHIRPath powered enableWhenExpression.

  enableWhen:
  - question: has-claim-number
    operator: "!="
    answer:
      Coding:
        system: http://snomed.info/sct
        code: "373066001"
        display: "Yes"

QuestionnaireResponse.repeat(item).where(linkId='has-claim-number').answer.children().code ~ '373066001'

Leveraging FHRPath boolean logic http://hl7.org/fhirpath/N1/#and makes complex expression more flexible and readable than enableBehavior.

I am using two FHIRPath implementations.
javascript-based is https://github.com/HL7/fhirpath.js
python-based is https://github.com/beda-software/fhirpath-py

Both of them contains data-driven tests that can be used as examples of FHIRPath expression

https://github.com/beda-software/fhirpath-py/tree/master/tests/cases
https://github.com/HL7/fhirpath.js/tree/master/test/cases

Elliot Silver (Mar 11 2021 at 16:27):

@Ilya Beda , perhaps I was inaccurate when I said FHIRPath is not well documented. What I meant was, there is no easy entry point to learning FHIRPath. I can look at what you wrote, and understand what it means, but I couldn't have gone from the enableWhen to your expressions myself.

Apparently FHIRPath is a subset of CQL, or vice-versa.

Lloyd McKenzie (Mar 11 2021 at 17:58):

FHIRPath is a subset of CQL

Tilo Christ (Mar 27 2021 at 20:59):

Lloyd McKenzie said:

EnableWhen is a weird beast. It's not totally clear whether it makes the 80% rule - and we have a more generic solution (enableWhenExpression) that covers everything enableWhen allows plus more - and it's not clear that it's significantly more complex to support. Also, we have some forms that have a design approach of "skip to Question X" which is somewhat clunky to implement using enableWhen.

How comfortable are we that we want to lock this down into "can't break compatibility going forward"?

Maybe it depends on the point from which you are starting. I am currently implementing a Questionnaire filler app in Flutter using Dart. That means I don't have a ready-to-use mature Open Source FHIRPath implementation at my disposal. enableWhen vs enableWhenExpression is making the difference between 50 lines of if-then logic vs. writing a FHIRPath engine from scratch. Seeing how most of my use-cases are trivial (similar to the SDC samples, "if female then ask pregnancy") I would like to keep the simplistic option.

Ilya Beda (Mar 29 2021 at 15:53):

There are a lot of open-source FHIRPath implementations you can use as an example.
Also, there is no need to implement the whole spec you can implement a small subset that meets your needs.
Finally, FHIRpath is one of the FHIR core elements, so you have to implement it anyway.

Lloyd McKenzie (Mar 29 2021 at 16:10):

It's not accurate to say that you have to implement FHIRPath anyway - a Questionnaire rendering tool could easily have no support for FHIRPath.

Tilo Christ (Mar 29 2021 at 16:23):