Status

The following tickets are detailed in this document:

...

• 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 school We do not need to collect the classroom attribute; if any classroom data collected, it will be free text, not used for analysis.
• Children 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 area community they are registered in, and the distribution point of their registration (could be school or community).
• Schools will have 1 or 2 Drug Distribution task per eligible, depending on the child's age (from the registration attributes) 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.

Plan: NTD Point Distribution

• This should follow the IRS model for plan, where we see a map of all eligible operational areas and point and click which we prioritizeschools to be within operational areas.
• We do not need to collect the classroom attribute; if any classroom data collected, it will be free text, not used for analysis.
• Children registered ad hoc will be associated with the school operational area they are registered in.
• Schools will have 1 Drug Distribution task per eligible, depending on the child's age (from the registration attributes).

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 Point Distribution

• This should follow the IRS model for plan, where we see a map of all eligible operational areas and point and click which we prioritize. 

  Jira Legacy
  server System JIRA serverId 3420e60a-4e6f-3f80-8335-059c22bb40aa key RVL-855

• A school should be a point that is tied to an operational area. There will be just one school per operational area. 

Location types: Distribution-point (types=school, health-facility) 

Jira Legacy
server System JIRA serverId 3420e60a-4e6f-3f80-8335-059c22bb40aa key RVL-471

Distribution will always take place at the school. Task generation will involve generating tasks against entities (children) linked to the distribution-point level.

Activities/Tasks available:

...

• Register Child - does not autogenerate
• Drug Distribution- 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-855

• A school should be a point that is tied to an operational area. There will be just one school per operational area. Is this correct Sameen Babur or will there be multiple? Last time we said multiple, not sure if this changes when we take out community.

...

• 856

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

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 Mass Medicine Administration and Register Child.

In plan creation we will add a way to upload a CSV roster file. 

Jira Legacy
server System JIRA serverId 3420e60a-4e6f-3f80-8335-059c22bb40aa key RVL-

471

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

1. Generate tasks against entities (children) linked to the school 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.
2. 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
  • This targeting is determined by an endemicity attribute that is associated with the child based on the school they attend.

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. Communities or sSchools 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 Mass Medicine Administration and Register Child.

In plan creation we will add a way to upload a CSV roster file. 

Jira Legacy
server System JIRA serverId 3420e60a-4e6f-3f80-8335-059c22bb40aa key RVL-470

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

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

• 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 communities schools 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".
      • "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 (name all fields from the Registration dictionary)
• Workflow to replace amend 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?"   MB: This is a bit more complex in that we have to delete all the registered children and the tasks associated with them.  AM: Ah, I didn't consider that and thought this would be simpler. Can you suggest how we should handle this instead if they want to make changes?  MB:  It might be easiest if this is a replace.  We can also support a delete roster and then they just upload a new roster with the amended data to replace it.  The challenge more is what do they do if they want to amend things once they've started to collect data.  We probably should just not allow that as they can have the ability to add children once data collection has started.
• 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

• 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)
• Does not have National id (boolean_
• National ID (integer)
• Reveal ID (integer) . MB: Is this an ID that will be provided or one the system needs to generate? AM: System gen = OpenSRP id. National ID is provided. SB: Not the OpenSRP IP, they want the ID to follow a specific pattern
• Name of child (string)
• Child's allocated sex at birth ('Male', 'Female')
• Child's date of birth (date YYYY-MM-DD)
• Date of birth estimated (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

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.

MB: Out of scope.  Need better clarity of what an android plugin is. It's pretty rare to use android to do file management / data loading etc.   Might be better if they have a way to email a special email address a CSV file to load the data in the system.  Validation becomes complex here though.  It would be helpful to think this through better and try and clarify scope. AM: Fair, we had brainstormed this as a nice to have anyway. 

Workflow 3 - Register child (client) 

Jira Legacy
server System JIRA serverId 3420e60a-4e6f-3f80-8335-059c22bb40aa key RVL-472

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) . MB: Is this linked to a specific school or operational area? Please clarify. AM: School view! Schools will be points in OA and may be 1:1 school:OA or many:1 school to OA, but we only need a view at school level.
• 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.
• Child will be marked as coming from the community according to the registration attribute 'Currently enrolled at school' == 'No' .  MB: Does this just meant they weren't on the imported list?  I see limited value in this designation. AM: No. There may be school-going children who were missed on import. Value is to be able to disaggregate reporting between school-going and not. I.e. to know how many not school going we reach in school workflows, does that meet what our estimates are, etc.

<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.> SB: I think that was anwered in the previous line, but we will have a Yes/No for Enrolled at School, so we can compare the number of children reached that are school-going vs. not

470

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

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

• 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 Reveal 
    • Check that fields with dropdown select type, boolean type, numeric type and Yes/No type have valid entries
    • Error message if failed:
      • "Upload failed. Check your CSV to make sure all required fields are filled in".
      • "Upload failed. Check field (field name) in your CSV to make sure it is a valid entry type
    • 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 (all fields from the Registration dictionary)
• Workflow to replace roster
  • A roster can only be replaced if they have not started to collect data in that plan. Once they start to collect data, any changes must be made through the client.
  • 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. 
  • If a plan has data collected against it, 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

• 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)
• Does not have National id (boolean_
• National ID (integer)
• Reveal ID (integer), not autopopulated, this will be defined and entered by country protocol
• Name of child (string)
• Child's allocated sex at birth ('Male', 'Female')
• Child's date of birth (date YYYY-MM-DD)
• Date of birth estimated (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) - Out of scope for MVP

Workflow 3 - Register child (client) 

Jira Legacy
server System JIRA serverId 3420e60a-4e6f-3f80-8335-059c22bb40aa key RVL-472

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

• Access the list view (current list view) . This will be a school-view of the list. We will have 1 school (point) per operational area.
• 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.
• Child will be marked as coming from the community according to the registration attribute 'Currently enrolled at school' == 'No' . This attribute is needed so that we can disaggregate children in reporting based on whether or not they attend school.

Workflow 4 - Edit child (edit)

...

1. Registration info is incorrect
2. Child has moved classrooms . MB: Editing classrooms.  Will classroom list be free text or some kind of pulldown.  Will the classrooms be predined or given some name.  if a unique name, then pulldowns will be harder to do. AM: In this use case, free text is fine, so . Classroom will be stored as a free text attribute on the child, we do not need to manage a classroom list - it will be a free text attribute for the child entityor a separate classroom entity. It is understood that this means we will not be able to disaggregate on classroom.
3. Other reason

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

• 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

...

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 dictionaryMB: do kids get a single dose one time or is there follow-up.  Eg. Will they come back to the school at a later date for another round. AM: I'm adding details on task gen shortly but publishing to save work (we may need two tasks). SB: It has been decided that they will only be receiving one roundeach child. Drug distribution may happen by classroom or not. This will be a drug distribution task; each child will only have one round of drugs and therefore one task generated. See Data collection data dictionary. 

Task generation must happen in two places:

...

• Coverage
• Performance

Drill down levels

• Region
• District Inkhundla
• Community School
• Age Group
• Individual List View of Children

...

• 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 below are new components we believe to be needed for the UI. 

Jira Legacy
server System JIRA serverId 3420e60a-4e6f-3f80-8335-059c22bb40aa key RVL-502

MB: for android right?

(Android) 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 child list view and is an icon somewhere on that screen.

(Android) Child list view (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)

• Search requirements (all based on child-level attributes in data dictionary registration details)
  • Classroom
  • National ID
  • Date of birth
  • Name (surname/given)
• Sort requirements
  • Classroom
  • National ID
  • Date of birth
  • Name (surname/given)
• Filter requirements
  
  • School grade/form
  • Age category
  • Sex
  • School-going vs. non-school-going

(Android) Child-specific view, accessed from the child list 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.

(Web) Reporting views in line with above.

Justification

Dependencies

Notes

Questions to consider in technical scoping

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?

...