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.

...

This section summarizes the core features required for delivering the workflows outlined in the functional requirements document.

Android Client

The Android client needs to be able to receive clients that have been loaded in to the distribution point into a single register view that supports sorting and filtering. This register view needs to display all clients registered at the distribution point whether they have a task or not. If they have a task, the task will allow users to collect information against the client and add that the client’s longitudinal health record. Each client has these metadata tags that allow them to be filtered. These are represented in the mock-ups and data dictionaries. We want to make them generic tags that we can repurpose for other workflows in the application, allowing for greater flexibility when filtering any client list in the future.

There are a few key decisions that we need support from the developers. First, we need to figure out exactly how we want to represent a distribution point in the geographic hierarchy. Craig’s perspective is to treat them as a structure with a specific type of “distribution point” These can be created in the Android client or in the web server. Second, we need to figure out if we should represent all clients registered in a single all clients list that was recently built for Malawi and transitioned into Wellness Pass. Craig expects this is a good move for Reveal, but we need Sam G to weigh in on this. Third, we need to figure out if we want to implement modules within the existing Reveal application or if we need to implement plans and tasks in another application that we have built for OpenSRP.

UI mock-ups are available at:

Below is a list of features we need to build in the Android client:

• 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

OpenSRP Server

The OpenSRP server will need to be improved so that we can import a CSV and generate clients server side. The functional requirements includes a template of fields that they believe need to be included. We need to make a few decisions on this import. First, does the import template make sense from the developer’s perspective. For example, can the mapping be done appropriately in the server and can we create a complete client with the information presented? Second, can we create and sync clients from the server to the Android client, or do we do we need to create events for each row in the import? Third, can we make the client generator generic by design so that we could configure how we want to structure the import to be able to create multiple types of clients in OpenSRP as a generic feature? Fourth, how will we handle mistakes when a user uploads information that they don’t want to be there. What’s the lifecycle we should create to remove the likelihood of duplicates? Fifth, we need to make a decision on whether we assign each imported client to a particular distribution point in the system, the operational area, or both.

Below are a few items that we need to develop in the OpenSRP server:

• 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

The OpenSRP web UI will need to support uploading CSVs to create clients int he system. Additionally, we will need to make distribution points available in the IRS map based planning. Finally, we will need to update the manage plans form to support the MDA and NTD additional plans.

• 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

This section defines the changes to the plan generation and task process for NTDs.

Plan Definition Sample

...

Outstanding Items on the Plan Definition and Task Changes

...

We need to rethink when tasks are generated server side.

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

...

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

• Perform a security validation to reduce risks on import (see the Security section below)

• Validate the structure of each field in the template

• (Stretch) identify if there is an existing client in the system with the same information. Provide feedback to the user.

Plan Definition and Task changes

This section defines the changes to the plan generation and task process for NTDs. The most simple solution is to slightly modify the plan definition template for NTD distribution point workflows. In the long run, we need to accommodate NTDs in the dynamic tasking workflows that are scheduled to be developed in June.

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

• [Craig needs to complete this section]

Outstanding Items on the Plan Definition and Task Changes

The current Task paradigm in Reveal generates all tasks when the plan is changed to active. We have a work item to persist entities in the Android client by the end of June as well as support dynamic tasking client side. Craig has a hunch that there is a core redesign in how and when we generate tasks in Reveal. We went through a lot of pain in the past because we only allowed tasks to be generated once instead of doing it on a rolling basis while events happened in the system. We need to look at the whole picture of what needs to be delivered in June and figure out if we can work on that as part of this work. This section focuses on those changes so we can make a clear decision.

[This section needs more thought and research from Craig based on the long term timelines for Reveal.]

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

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

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

...