This document defines the software requirements for the distribution point features for Reveal. A distribution point is a centralized location where individuals meet to receive care. The primary workflows are funded under a grant for Neglected Tropical Diseases (NTDs) which focuses on distributing medication among children who are attending schools in Eswatini. The functional requirements are outlined on NTD School Workflow and the data dictionary. This document applies those functional requirements into the Reveal technical architecture.

...

• Register view of all clients registered to receive care at that distribution point

• Add, Update, and Archive client registration information

  • This includes assignment of up to three metadata tags (class, grade, etc) that need to be defined server side.

• Generate tasks in the Android client:

  • When a client is registered

  • When a form is saved

• View of all tasks assigned to all clients in the system

• Individual client view that displays all tasks assigned and their status with the ability to edit the underlying form

• Search, Sort, and Filter the all clients view

  • Search

    • Client First and last name

    • By school identifier

    • By system identifier

• Filter

  • By task type

  • By task status

  • List clients who do not have a task assigned

  • By metadata point 1, 2 and 3

...

• Track metadata points against entities. We have three points that need to be dynamically assigned in the app. We need to “tag” each client in the register view to up to 3 of those points so they can be searched against.

  • This also needs to be supported in the CSV upload.

• CSV Upload to Client Generator

  • We need to be able to generate clients by using a CSV upload. Each row will present an event

OpenSRP Web UI

• Upload CSVs to create entities in the system

• Adjust the map based planning to include schools (points on the map)

• Adjust the manage plans and add new plan view to include MDA plan types and NTD plans

• Add reporting for NTDs based on the inputs from Akros (Isabel Shaw , we need details to be included here)

Plan Definition and Task changes

We need to make a few This section defines the changes to the plan definition generation and task generation process.process for NTDs.

Plan Definition Sample

We will add the following attributes to a plan definition. All core task sections are defined in The All Events Data Dictionary

Outstanding Items on the Plan Definition and Task Changes

• We need to rethink when tasks are generated server side.

  • Prior workflows were done on a large bolus of structures.generated tasks at one time when the plan was transitioned from draft to active

  • We have the dynamic tasking feature which may overlap

  • We need to

• Task Data Elements

CSV Upload → Client Generator

We need to develop a server side client generator that generates clients server side for each row that’s available in the import. We aim to make the CSV entity generator generic so that we can import different types of entities into OpenSRP in the future. We need to pass in the event template with the CSV that shows field mapping of the CSV to event objects or make it so that system administrators can configure these entities and evolve their generation over time.

Workflow:

• (Outside of the system) The user creates a template based on the structure that’s defined for the project

• User chooses a plan and uploads a CSV

  • Details are passed in with the CSV to show what types of entities to generate and the mapping of the template.

• CSV is parsed server side and validated (We need to develop a CSV validator)

  • An error is returned to the user if the CSV is invalid.

• An event is created for each row in the OpenSRP server

• (Existing functionality) A client is created in the server for each event

• (may be out of scope) A task is generated for each entity that’s created (based on the plan that’s created)

CSV Validator

CSVs need to go through a validation process that can generate a full client. This section defines the details of the CSV Validator.

Field Template

Security

This section defines security requirements for these features.

• Users should not have the capability to download large lists that contain personally identifiable information about the clients.

  • Access to download rosters will, at maximum, provide identifiers that can be linked to people registered in the system.

• All uploads need to be validated to include the following:

  • Valid CSV architecture with UTF-8 encoding

  • Individual fields are parsed and validated to remove exposure to SQL injection threats

  • Individual fields are parsed and validated to remove exposure to cross-site scripting threats

  • (We probably need to add more here)

Things to be discussed from scoping so far

...