Some projects have workflows whereby a supervisor needs to review reports submitted by other healthworkers. The CHT often supports these workflows either through supervisor tasks or by keeping track directly in the reports list using the “Review” feature. There’s even a way for offline supervisors to replicate specific reports that would normally not be accessible based on their replication depth (by utilizing the
Does your project use “review” workflows whereby a supervisor reviews reports submitted by other healthworks? If so, can you share a brief summary of how you are achieving these workflows? Are you using any of the features mentioned above?
@kunwarl @Jane_Katanu @raymond @kitsao @derick @elijah @Victor_ZUGADI @iesmail @vchelule @yrimal
@michael true…Just to mention some of these supervisor review workflows through supervisor tasks include confirming reported deaths; approving muted individuals/HH; and verification of reported community events based surveillance signals.
In addition, depending on the supervisors’ hierarchy and access rights, there is an option to delete or edit reports in the app.
Supervisor tasks for confirmation of death outcomes submitted by CHWs using
- Every death reported by CHWs generates a task (death verification) for the TRACE team to verify, IF AND ONLY IF the patient is an NCD, HIV or EID patient. Death verification tasks currently are triggered to the Senior CHWs (SCHWs) since tasks can only be completed by offline users.
- All other deaths by household members not in the IC3 programs (HIV, NCD, EID) do not require a death verification report.
The chart below summarizes the process.
A similar approach was taken for the TB workflow with senior CHWs getting tasks for suspected cases as detailed below
Sputum collection for presumptive TB cases
- CHW screens all household members for TB, submits a screening form, refers if necessary.
- CHW escorts suspected case to the SCHW home for TB sputum collection - and completes a task detailing the count of samples collected and delivered for testing. SCHW updates cough register.
The chart below summarizes the process.
cc @elijah @Jenny
Another workflow that entails review workflows is Event-based surveillance.
Event-based surveillance that is conducted in health facilities for Meningitis, Cholera and Measles
- Detected cases of meningitis, measles and cholera in the community are reported at health center level.
- Reported cases are escalated to the
district -> region -> national levels for effective support and response.
- At each level above the facility, if a sample (uniquely identified) is tested, there would be no need to further escalate it up. However, the results must be cascaded down to the health center.
The sequence diagram below is a summary of the signal flow.
How did we achieve this?
- Signal passing
- 4 level hierarchy, all levels have replication depth 1 (each level can see the places just under them)
- Passing up: If you want to pass up (eg. alert validated), report’s
place_id is your parent
- Passing down: If you want to pass down (eg. alert status), use
additional docs to create a second report with
place_id equal to place that created original alert
- Conditional passing (only pass validated signals)
- How to pass a “copy”, eg (validated alert, changing details, preserve original content)
Pass all data from the alert into the validation form using modifyContent. Prepopulate the form using
inputs if the corresponding value is set, otherwise set it to the user’s input - see screenshot below for a sample.
Having the validation form use the data as default, see this thread.
That way, we were able to move and review data up and down the hierarchy seamlessly.
@michael we have supervisor review for our Mute person, Mute household and Death reporting workflows.
A brief summary of how this is accomplished:
||Mutes household member, Muting Request Approval task for supervisor generated
||Mutes household, Muting Request Approval task for supervisor generated
||Reports household member death, Death Report Approval task for supervisor generated
||Approves household member mute request, muting_approved additional doc generated for household member
||Approves household mute request, muting_approved additional doc generated for household
||Approves household member death, death_report_confirm additional doc generated for household member
||Or, Disapproves household member mute request, muting_rejected additional doc generated, assigned to household member
||Or, Disapproves household mute request, muting_rejected additional doc generated, assigned to household
||Or, Disapproves household member death, death_report_reject additional doc generated, assigned to household member
||Household member marked muted if supervisor approved, normally if not
||Household marked muted if supervisor approved, normally if not
||Household member marked deceased if supervisor approved, normally if not
To bypass replication depth limitations for example between the supervisor and the patient, we use the