Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Excerpt

In order to add more flexibility to openIMIS workflows we need to bring flexibility to define the visibility and There is several approaches to implement workflows; my (Patrick Delcroix ) preferred ones is the task based approach because it does not require to change the schemas of the entities when the workflow changes.

Principle:

The workflow should start based on a trigger, in the django realm it could be manage by a signal listener part of a workflow implementation module. when the signal is launch (the trigger) then the listner could generate the task and start the entity workflow.

Once the task created:

  • follow FHIR task model

  • it should be assigned to a user or a group of user ( basic group implementation could be role + locations but real group entity could make more sense in the long run because the uncouple the access/right management and the workflows.)

  • it should have a status: https://build.fhir.org/codesystem-task-status.html

  • the businessStatus will depend on the implementation workflow, it should document the result of the task execution,

Once the task is completed then based on the implementation workflow and the businessStatus resulting of the task execution the next action could be done (new task, entity update etc … )

Task execution

the task execution might required to validate the entity data or to add information therefore the task page should “include“ the entity page but a access mask should be applied to ensure that the task executioner won’t update part that he is not supposed to update. this mask should be provided by the be based on the workflow implementation module.

it will allow to limit the update possibility of fields in GUIs. This

it would allow to limit the visible fields in the GUI to show just what is needed to complete a specific task and reduce confusion for the user. It will also allow for business rules.

But no entity actions would be available, instead the task action will be (example):

  • assignment if not assigned

  • start

  • rejection

  • completion (businessStatus will be ask then)