Triggering Mini-Forms in O3 Forms

Development
, ,
5

Assume that “hidden” means “not shown” and “shown” means “not hidden”, then I suppose this is just a matter of which version form authors find easier to reason about.

I’ve got a few cautions here those:

  • Supporting both showWhen and hideWhen will be more challenging than supporting just one or the other
  • Since we’re already using hideWhen, adding showWhen would either mean supporting both or basically breaking any form that’s been developed using hideWhen

I don’t like the idea of using a form schema to define a workflow. I think that’s an anti-pattern that should be discouraged. Forms that embed workflow-specific logic become, by their very nature, program and even clinic specific, meaning they can’t be effectively shared across implementations.

Embedding workflow-related logic in forms also makes it hard to maintain a GUI form editor because the form being edited moves further and further away from the relative simplicity that makes it easy enough to maintain a working GUI form-based editor.

I think having component forms is obviously fine and adding some hideWhen support to component forms is a great idea, but we should not be trying to use this to define workflows. I do agree that we need to make things easier for users to move between forms and I’m very happy to discuss how we can implement these sort of customisable workflows. I just don’t think they belong inside individual forms. Perhaps we add some hooks that implementations can override to, e.g., move to the “next” form after a previous form has been completed (and we could feed these hooks relevant patient details, user details, and even values from the previous encounter).

This is the strongest argument I can think of for why these “component forms” should just be separate forms.

First, supporting this will require reworking the form engine itself, the form app, and the fast-data-entry stuff, as well as the offline stuff, all of which are designed premised on the idea that each form operates on a single encounter.

Second, supporting viewing the entered data in forms already will require us to have each “form component” as a separate, self-contained form.

A few comments here:

  • Roles should always be groupings of permissions, and those permissions should be what we use to control access to resources. Roles themselves should not be treated as security privileges (e.g., instead of having a rule that says role === 'Doctor', we should have a rule like privilege === 'Assess ART Adherence' and assign that privilege to the Doctor role. This is because it allows us to be more agile, e.g., when the clinic decides next week that doctors are too busy to do all the ART adherence assessments and they want the nurses to do that, we just need to add a privilege to the Nurse role.
  • In general, I don’t love driving what parts of a form might be filled out based on who a user is. I can see that when viewing a form, it might be critical to hide sensitive sections for some users, but those users should not be able to fill out the same form. Hiding or showing sections of a form based on facts about the patient seems perfectly fine, i.e., if a form skips questions related to pregnancy for a patient who cannot be pregnant, I can’t see it raising any questions. However, if I’m browsing a form and there’s a required section that’s completely blank because the form was originally filled out by someone with fewer privileges than me, that seems like bad UX that’s likely to lead users to mistrust the completeness of that particular form and maybe the EHR as a whole.

I don’t think it necessarily helps us one way or the other; adding support for hideWhen expressions to pages and sections is a great idea and we should implement it immediately. I’m much more ambivalent about using them to hide answer options, but I think that warrants a whole different discussion…