Our observation forms provide a way to enable/disable some fields in a form based on implementation specific form conditions configuration. The wiki page for configuring it is available here.
Rule Type 1: When a single select radio option for the question “Baseline, Employment within the past year” is selected as “Other”, then enable a form field “Baseline, Other employment”. Otherwise disable it. Rule Type 2: When “Baseline, WHO registration group” is selected as either “Relapse”, “Treatment after loss to followup”, “Treatment After Failure to Drugs”, then enable a text box “Category IV tuberculosis classification”. Rule Type 3: For the question “Did patient start treatment”, if there is no answer, disable certain fields, if the answer is true - enable & disable certain fields, if the answer is false - then enable & disable certain fields
We want the form conditions to be part of the form definitions.
The advantages are
- The form is complete by itself and might not depend on any extra files except for the i18n. This will be helpful with our vision of form banks. They can operate independently.
- The form conditions can be simple. Today, they are very verbose. With the availability of control ids, it’s easy to identify. Also, today we are limited to using Concept Names as the keys. If a form uses 1 concept at multiple places, then these form conditions will NOT work.
- One form can define conditions specific to its own control and can be managed separately unlike one huge file maintaining skip logic of all the forms.
The disadvantage are
- Form size can grow
- One time migration effort is involved for our existing implementations
- Some standard evaluators of form conditions is provided out of the box, but we need to provide a flexibility to add more by Implementers (more on this later).
A sample form defn with form conditions might look something like this. Line 71 is function defn & Line 45 is function usage.
The parameter that is sent to the function can include some contextual information like patientContext, visitContext, formContext (contains metadata), the value that is being selected for the current control etc. This information is useful for writing effective form conditions.
We are yet to spike out and see how things work. But wanted to get some preliminary inputs from the community. Thank you.