...

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

Data collection data dictionary STATUS: in progress, not yet completeThe following tickets are detailed in this document:

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 We will define operational areas based on the location of the schools. An OA boundary with be automatically drawn by taking an 8km radius around the school and there will be only one school per operational area
  This
  • • The relationship between the school and the operational area will be assigned
  and fixed
  • • in the process of loading locations. A school will be marked as distribution point that will have a parent attribute of the operational area.
  • Therefore, we will not treat a school as a household type location; distribution point will be the location type
  • We will manage classrooms as an attribute to the school <How <Ona: How will we manage this list?> 
  • 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 in the school workflow will be associated with that school.

  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-level intervention (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

  Location types: Distribution-point (type=school) 

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

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

  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. 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. have to map the schools 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 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 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 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/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.
  • 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 

  ...

  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) 

  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:

  ...

  Suggested Workflow <Is there already a UI and workflow for this through  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.

  ...

  • 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 

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

  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

  ...

  Proposed workflow:

  • Access list view.
  • (if needed) Filter by classroom that is being worked onas needed) Perform necessary filter/searches/sorts.
  • 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

  ...

  Drill down levels

  • District <Do we need this?>
  • SchoolClassroom
  • Age Group

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

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

  • Needs to be searchable/filterable by classroom attribute. Search requirements
    • Classroom attribute (When you want to distribute drugs by classroom, you search by classroom, and then jump into tasks from there child-by-child)
    • ?
    • ?
  • Filter requirements
    • Classroom attribute
    • ?
  • Sort requirements
    • Classroom attribute 
    • ?

  Child-specific view should , 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.

  ...