Status

Web UI reporting and plan template STATUS: in progress, not yet complete

Data collection data dictionary STATUS: in progress, not yet complete

Requirements

Assumptions

• These children are people, not constrained to families
• School will not become household type, distribution point will be location type
• There will be one school per operational area
• This area will be assigned and fixed in the process of loading locations
• We will manage classrooms as an attribute to the school <How will we manage this list?> 
• Children who are registered ad-hoc will not be linked to a location.

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.

Plan: NTD School (Point Distribution)

Activities/Tasks available:

• Register Child - does not autogenerate.
• Drug Distribution - autogenerates against any eligible, registered child.

Workflow 0 - Enumeration data links child to location (No longer need to support this workflow 1/29)

• The Eswatini team will be doing an in-field house-to-house registration, "enumeration" prior to the distribution, likely in Feb. This will be to collect data on how many children there are, and where they live. They will capture GPS points against all students, potentially through ODK or another tool. Reveal using family module registration would be an option, however, we may not have the bandwidth for support.
• We will also be doing remote, satellite based enumeration of structures in these areas.
• We would like to be able to link students to structures based on the GPS coordinates that are collected against students in registration. When students are treated, would like the business status to change on the map client and web view. This requires students to somehow be linked to enumerated locations in Reveal. These GPS coordinates would be loaded as an attribute against the student and loaded as a location in Reveal, duri
• Options
  1. Create families that students are linked to, based on the GPS coordinates that are collected against them. This breaks key assumption that we do not need to do family creation or link students to families or link across school and community.
     1. Would require all students in one house to have same GPS coordinate to determine who is in which family.
     2. These families would have to be an attribute in the student roster load CSV.
        1. This load would have to do a lookup on enumerated structures based on family GPS coordinate.
        2. Would allow us to evaluate multiple students for the business status. 
  2. Import GPS point for each student. This does not follow typical location-person linkages in Reveal. We do not typically have a point location for an individual.
     1. Import GPS locations of students as locations in Reveal 
     2. GPS point would be an attribute in the student roster load CSV.
        1. Link would have to be created here
  3. Use Reveal for in field enumeration and family registration
• For all three workflows, the business status on the map then updates as students are treated in the school. 

Workflow 1 - Plan Creation w. Roster import (Web)

This will take place at a central location ahead of the intervention. Schools will send their rosters to a central administrator who will create a plan for the intervention. The administrator will have to compile these roster into an import for all schools; s/he will have to cross check spellings of schools so that they map correctly to the school list in Reveal.

We will follow the regular planning workflow on the Web UI. The plan definition template can be found here: Web UI reporting and plan template We will add a plan type of NTD School (Point) Distribution that will have a default activity type of Drug Distribution and Register Child.

In the plan creation form, we will add a question for uploading a CSV roster file.

• 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 schools against OAs in system for schools
    • Check classroom attributes against classroom list <how will we manage classrooms
    • 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>
  • View 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
• 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>

• School - this will not be a user-facing attribute on the client since the client will auto-assign school based on OA. This is required for the web import
• Classroom -
• x
• y
• z

Workflow 2 - Roster import (Client) - proposed not MVP

Some schools may not send their roster to the central administrator for a load ahead of the activity. We would like to support a roster load on the client through some Android plug. We suggest this is not MVP for a pilot as we expect all schools in the pilot to send their rosters ahead of time. Any changes that need to be made to the roster at the point of interaction, can be done through Workflow 3.

Workflow 3 - Register child (client)

There are a few cases where the schools may need to register children on the client:

1. School did not upload roster ahead of time and needs to register all children. This may be common in community schools or other schools that do not have the same admin capabilities, or may occur if the timing of registration and drug campaign do not align well.
2. Students were missed on roster.
3. Non-enrolled students who come from the community and need to be added ad-hoc. This may happen significantly in some areas.

Child registration will follow similar UI and workflow in the client as family member registration, however, children will not be attached to families, so the UI for entry into child registration will be different.

Suggested Workflow <Is there already a UI and workflow for this through  immunization OpenSRP?>

• 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.

<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.>

Workflow 4 - Edit child (edit)

We may need to make edits to a child if:

1. Registration info is incorrect
2. Child has moved classrooms
3. Other reason

Suggested Workflow <though this may already have a UI in the immunization OpenSRP workflow>

• Access the list view
• Select a child
• Access child-specific view 
• Access edit view for the registration info
• Selecting that button takes you to the Register child form where you can make edits

Workflow 5 - Collect data against child

When drug distribution occurs, teachers will distribute drugs to and collect data against each child. Drug distribution may happen by classroom or not. This will be a drug distribution task. See Data collection data dictionary

Task generation must happen in two places:

• Based on children added through webUI on roster
• When children are added ad-hoc in the client

Proposed workflow:

• Access list view.
• (if needed) Filter by classroom that is being worked on.
• Access child-specific view
• Access child-specific task view
• Complete task
• Child-task view updates color based on business status logic. See Data collection data dictionary
• Go back to full list view - task color for that child also updated here

Reporting

Dashboards to be defined, likely two types. See Web UI reporting and plan template

• Coverage
• Performance

Drill down levels

• District <Do we need this?>
• School
• Classroom

Need to disaggregate likely by age, gender, and classroom

• We need to define what are the key values we need to build in tables in Superset

On app indicators to be defined. See Data collection data dictionary

Mock-Ups

Views/UI

The below are new components we believe to be needed for the UI.

Child registration - there needs to be a place in the client where we can add a new child. I would guess this is from the chid list view and is an icon somewhere on that screen.

Child list by school (This could be the same as the task list, however, we would want to see all children, regardless of task status. So if there is ever a reason a child would not have a task, then we might need a separate view for all children that is not task based)

• Needs to be searchable/filterable by classroom attribute. When you want to distribute drugs by classroom, you search by classroom, and then jump into tasks from there child-by-child

Child-specific view should contain

• There is a task view for the child. I imagine this to look similar to the family task view, but be for an individual.
• There is also an edit view for the registration info that starts from this child-specific view. Could also be similar to editing family member registration.

Justification

Dependencies

Notes

Questions

How will we manage and maintain a list of classrooms for each school? 

• When will these be added to the system?
• Will these be editable? 

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?

Is there already a UI and workflow for much of this work through  immunization OpenSRP?

Test Case