Supervision Flow
Table of Contents
Background
This document describes the need and scope of a digital platform for health campaigns, explaining the product’s features, specifications, purpose, and functionality. It also provides a descriptive view of the application along with the specification of each element.
Target Audience
This document is intended for the engineering and platform (tech teams), product management, and implementation teams to agree on requirements for the Health Campaign Management Platform (HCM).
Objectives (of this release)
To enable actors with a digital system to manage and implement health campaign activities.
a. Facilitate FLWs, supervisors, district officers, and other actors to collect and analyse data accurately, along with monitoring the tasks from registration to service delivery. Also, regular progress checks can be performed at any time and a comparative analysis can be derived at the district levels for different teams.
b. Facilitate better diagnostics with improved access to healthcare interventions for the general public.
To enable more and more adoption of the HCM platform for multiple health campaigns by providing flexibility in the UI and UX as well as product specifications.
a. Emphasis on adopting digital systems by collaborating with several healthcare initiative bodies.
b. Provide scope for future changes and improvements in the application.
Assumptions and Validations
Filling a checklist
Assumed that supervisors will record the checklist during or after they have performed the inspection.
There is no requirement to backdate a checklist or make changes to responses after a checklist has been submitted.
All checklists will be completed in one go and there is no requirement to submit an incomplete checklist as a draft.
Creating checklists
Questions types supported would be:
- Yes/No answers
- Short answer type
- Long answer type
- Multiple answers type
- Checkbox answer type
- Date answer type
- Time answer type
Role-Action Mapping
System Administrator:
a. Create, search, edit and delete checklists.
b. Assign checklists to projects.
c. Edit/delete filled checklists.
Supervisors:
a. View assigned checklists.
b. Fill assigned checklists.
Field Supervisor:
a. View assigned checklists.
b. Fill assigned checklists.
Solution
Context: Supervisors are required to perform random or scheduled inspections and record observations of the inspection activity in the supervision checklists.
The number of checklists and the number of questions in the checklist will be based on the programme’s requirements.
The system administrator must have the ability to create supervision checklists.
a. Checklists are forms with questions.
b. Current scope:
i. Ability to create/edit a questionnaire with yes/no responses: Questions and alert messages must be configurable as per the programme's requirements.
ii. Ability to insert validations/conditions on the questions present in the checklist. The use case to consider for v1: If the user selects 'No' as a response to a particular question, the user must be able to see an information tip on the checklist displaying the corrective action to be taken and must also be able to enter a justification behind selecting ‘No.’
iii. Marking a question as mandatory or optional (Validations are applicable on all questions irrespective of whether the question is mandatory or not).
iv. Localisation support is required as checklists would be required in the local language:
v. Support for the following question types required:
a. Yes/No answers
b. Short answer type
c. Long answer type
d. Multiple answers type
e. Checkbox answer type
f. Date answer type
g. Time answer type
h. Lat/Long coordinates– Must have for v1
i. Media - Good to have
vi. The system admin must be able to view all filled-in checklists and be able to edit or delete the submitted checklists (via backend, No UI).
Ability to assign checklists to particular roles: Not all checklists may be required by all supervisors. For example, a provincial supervisor may be responsible for inspecting X while a district supervisor may be responsible for performing X and Y.
a. One checklist can be mapped to multiple roles b. Users must be able to view and fill the checklists that are assigned to their assigned roles.
Users must be able to view all previously submitted checklists:
a. Good to have: Inform users if the checklist submission is due.
b. Good to have: A user must be able to view whether a particular checklist was filled or not, when it was filled, how many times it was filled (as per the programme SOP, users are required to fill the checklists x number of times during the campaign).
c. The same checklist may be filled out multiple times during the campaign.
The date of checklist submission must be tracked and the frequency of each checklist submission (linked to the user) must be recorded for reporting purposes.
The latitude/longitude coordinates must be captured at the backend and linked to the checklist submission.
Users must be able to save a checklist as a draft (good to have).
Users must be able to view and fill checklists even when offline and sync the filled checklists once internet connectivity is available.
a. Sync down and sync up support required.
Dashboard requirements:
a. Indicators to track the aggregates of all checklists filled:
i. Filter based on administrative area.
Reports:
a. Users must be able to view a report on the response trend for each question within a checklist.
b. Indicators to track the aggregates of each checklists filled:
i. Filter based on role.
Risk/Limitations
Addressed in the out of scope section.
Out of scope
Deleting a filled checklist on UI.
Editing a checklist on UI.
Design
Find the mock-ups below:
HCM Homescreen
After logging into the application, the user lands on this screen which displays daily performance (number of households registered). The progress bar must reset daily at 00:00 hours and start from 0 registrations. The action buttons related to the beneficiary are present which include:
Beneficiaries
View Reports
Sync Data
Call Supervisor
File Complaint
At the bottom, there is a card that shows how many records are unsynced for the user’s convenience to sync data. If all the records are synced, then the card must say, “All records are synced.”
The help button is on every screen of the application, and by clicking on it a user can get the walkthrough of the elements on that screen.
On the top right, the administrative area assigned to the user is displayed which will be based on the level of hierarchy. The hamburger button on the top left corner covers some other actions mentioned further.
View My Checklists
Filling a Checklist
Confirmation Screen
Acknowledgement Screen
Last updated
