There are several approaches to implementing workflows. The task based approach is one solution that does not require any entities schemas changes when the workflow changes.

Principle of the task based workflow

The workflow should start based on a trigger. In Django, it could be managed by a signal listener part of a Workflow Implementation Module. When the signal is launch (the trigger can be a scheduled task, event from a module or user manual trigger through UI) then the listener could generate the task and start the entity workflow.

Once the task is created:

• follow FHIR task model https://hl7.org/fhir/task.html

• it should be assigned to a user or a group of users (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: Codesystem-task-status - FHIR v6.0.0-ballot2

• 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. Nevertheless, an access mask should be applied to ensure that the task executioner won’t update part of model that he/she is not supposed to update. This mask should be provided by the BE based on the Workflow Implementation Module and will allow to limit the update possibility of fields in GUIs by limiting the visible fields in the GUI to show just what is needed to complete a specific task and reduce confusion for the user.

No actions on entity would be available. Instead, the task action will be (example):

• assignment if not assigned

• start

• rejection

• …

• completion (businessStatus will be ask then)