| Table of Contents |
|---|
...
- These children are people not constrained to families
- We will define operational areas as schools
based on community-level polygons that are provided by the Eswatini team.Operational areas will have two types of distributions points within them, school, or health facility (1 or 2 of each per community). The list of students/children will be the same at all of these distribution points within a community. We want users within a community to be able to see the entire register list for that community, regardless of whether the child was registered at a school site or a health facility site. Tasks and entities will not differ based on distribution point type. Tbd, see below, if we handle these distribution points as locations or as attributes of the child.
We will manage classrooms as an attribute to the schoolChildren who are registered ad-hoc will not be linked to a location.No longer relevant since Workflow 0 not being done. Children registered ad hoc will be associated with the school operational areacommunitythey are registered in, and the distribution point of their registration (could be school or community).- Schools will have either 1 or 2 Drug Distribution tasks, depending on whether that school requires one or two rounds of dosing (will be pre-defined and based on endemicity)
Workflow
There are two main templates that will inform these workflows. The Web UI reporting and plan template contains the details of the plan and activity as well as requirements for web based dashboards. The Data collection data dictionary defines the forms and data needed for register child and drug distribution workflow.
...
Location types: Distribution-point (types=school, health-facility)
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
There are two different places is one place where distribution may take place within a community - health facility or school. Distribution looks the same (event/task form is identical) at both places. A child may show up at either the school or the health facility, and we need to be able to access that child (and any child registrations done anywhere in the community) at all distribution point locations within the community. This gives us two options for tasking
Generate tasks against entities (children) linked to thecommunityschool community level location. School vs. Health Facility becomes child-level attributes to indicate where they were registered rather than the location that entities are linked to.- Generate tasks against entities linked to the distribution-point level
AND come up with a list view option that can easily switch between or search across the tasks of multiple distribution points (schools, HFs) under a single parent (community aka operational area).
Activities/Tasks available:
- Register Child - does not autogenerate
- Drug Distribution Round 1 - autogenerates against any eligible, registered child. We need to define eligibility criteria and generate tasks based on these criteria and NOT for all entities.
Jira Legacy server System JIRA serverId 3420e60a-4e6f-3f80-8335-059c22bb40aa key RVL-856
...
- Drug Distribution Round 2 - autogenerates against any eligible, registered child in a school that is targeted for 2 rounds of distribution
Workflow 0 - Enumeration data links child to location (No longer need to support this workflow 1/29)
...
This will take place at a central location ahead of the intervention. Communities or schools will send their rosters to a central administrator who will create a plan for the intervention. The administrator will have to compile these rosters into one import for all communities; s/he will have to cross check spellings of schools so that they map correctly to the school list in Reveal. have to map the communities on the roster to operational area names or ids defined in Reveal so that the Reveal names/ids are on the roster import template.
We will follow the regular prioritization planning workflow on the Web UI, similar to IRS planning. The plan definition template can be found here: Web UI reporting and plan template We will add a plan type of NTD (Point) Distribution that will have a default activity type of Drug Distribution Distribution 1 and Register Child.
In plan creation we will add a way to upload a CSV roster file.
This likely should be done in a technical and design way that is compatible/similar/the same as Jira Legacy server System JIRA serverId 3420e60a-4e6f-3f80-8335-059c22bb40aa key RVL-470
. This case is unique in that we are uploading entities to exist within an OA, rather than importing attributes against OAs. The way we may want to treat and count these entities in the planning interface is similar to the way we want to count and treat structures in OAs. FYI Pierre Dane.Jira Legacy server System JIRA serverId 3420e60a-4e6f-3f80-8335-059c22bb40aa key RVL-834
- Components
- Question name: CSV roster
- Upload button
- Download template button
- Help text - reads "You may upload a CSV with the roster of the children in the school. You must include all required fields in the template."
- View current roster
- Workflow first roster upload
- Click Download template (template will be laid out per CSV requirements, below) –> CSV file downloads to desktop
- Complete template and save
- Select Upload, select CSV file
- Validation checks of CSV
- Required fields
- Check
communitiesschools against OAs in Reveal - Check that fields with dropdown select type, boolean type, numeric type and Yes/No type have valid entries
- Other? <What other validation checks are necessary?>
- Error message if failed:
- "Upload failed. Check your CSV to make sure all required fields are filled in".<Other error messages depending on validation checks>
- "Upload failed. Check field (field name) in your CSV to make sure it is a valid entry type
- <Other error messages depending on validation checks>
- Message if successful: "x out of y individuals were successfully uploaded"
- View/download current roster hyperlink
- This appears as a hyperlink "View current roster <file name"
- Can click on this and see the assigned ids of students, student list with attributes
- There should be a way to download this information as a CSV that looks identical to what was uploaded
- Must include the Reveal operational area id and student identifiers (
nameall fields from the Registration dictionary)
- Must include the Reveal operational area id and student identifiers (
- Workflow to replace roster
- Select Upload, select CSV file
- Confirmation message: "This upload will replace the current roster. You will not be able to recover the previous roster. Are you sure you want to proceed?"
- Restrictions
- Once a plan status is not in 'draft' the roster may not be uploaded/replaced
- Cannot edit individuals rows or parts of the roster on web, must edit CSV and replace if changes needed, or can edit on client later
CSV requirements <Will be defined once the register student form for the client is defined - will have the same requirements>
- Community - this will not be a user-facing attribute that is collected on the client since the client will auto-assign school based on OA. This is required for the web import.
- School attribute that child is associated with
- Health facility attribute that child is associated with
- Classroom -
- x
- y
- z
- Region (maps to admin unit and will match Reveal)
- Inkhundla (maps to admin unit and will match Reveal)
- School (maps to operational area and will match Reveal)
- National ID (integer)
- Does not have National id (boolean)
- Reveal ID (integer)
- Name of child (string)
- Child's allocated sex at birth ('Male', 'Female')
- Child's date of birth (date YYYY-MM-DD)
- Date of birth estimate (boolean)
- Age category (6-10, 11-15, 16-18, 'Adult')
- Currently enrolled at school ('Yes, 'No'
- Name of school attending, if from another school (string)
- School grade/form (where form 1 is grade 8) ('Form 1', 'Form 2', 'Form 3', 'Form 4', 'Form 5', 'Grade 1', 'Grade 2', 'Grade 3', 'Grade 4', 'Grade 5', 'Grade 6')
- Class number (string)
Workflow 2 - Roster import (Client) - proposed not MVP
...
- Access the list view (current list view)
- Have button somewhere for 'Reg child'
- Selecting that button takes you to the Register child form (See Data collection data dictionary)
- Completing the registration takes you to the child-specific view. Task should have generated and be visible on task view for child.
- Back button from there takes you back to list view.takes you back to list view.
- Child will be marked as coming from the community according to the registration attribute 'Currently enrolled at school' == 'No'
<How do we want to treat community children? Can we add "From community" as their classroom attribute? Otherwise we have to make that attribute non-required.>
...
Drill down levels
- Region
- DistrictCommunity
CommunitySchool- Age Group
- Individual List View of Chilren
...
- We need to define what are the key values we need to build in tables in Superset
- Disaggregation would be by any other items from data dictionary mentioned like gender, classroom, precise age, dose given, drugs taken etc.
On app indicators to be defined. See Data collection data dictionary
...
The roster CSV upload in the plan will need to have validation checks? What others, not defined above are necessary? What level of detail can we have in error messages for these checks?
Will the CSV template define the expected input types? In particular, this will be needed for input types that are select one, boolean, Yes/No etc.
Is there already a UI and workflow for much of this work through immunization OpenSRP?
...