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.
...
We need to build a REST API in the OpenSRP server that can receive the CSV file and perform the event generation
We need to build the foundation for a server side task generator in OpenSRP that can generate tasks as a service when the CSV is uploaded. This task generator will be improved upon in the coming months so that we can move the Nifi flows that generate tasks for Focus Investigation, IRS and MDA to Java server code so that the task generation system functions better.
Note that this will involve engaging the queuing software in OpenSRP so that we don’t overwhelm the server with a spike of activity.
We need to build an import template pattern that is configurable for OpenSRP. This would allow us to create a server side configuration that validates the template that was received and create the events. Ultimately, this will be able to be used generically to import events and, optionally, tag them to the appropriate jurisdiction and plan.
We need to be able to define settings that map the event/client metadata tags to the labels in the CSV template, sync them down to the Android client and make them available for display and filter in the Android client. 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.
See the subsection labeled CSV Upload to Event Generator
We need to be able to generate clients by using a CSV upload. Each row will present an event
Outstanding questions or on this section:
How do we roll back these items in the event someone messes up?
We need to define the logic behind generating
(Business question) Users don’t have a view into all of the entities that are registered to a distribution point. Therefore, they have no idea if their list was uploaded correctly. How should we mitigate this?
In other words, how will we handle mistakes when a user uploads information that they don’t want to be there. What’s the life cycle we should create to remove the likelihood of duplicates?
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
...
We need to develop the following features in the OpenSRP Web UI in order to deliver the features above.
UI for uploading CSV files to send to the OpenSRP server’s REST API
Change the manage plans form so that users can either select jurisdictions or distribution points
Adjust the manage plans and add new plan view to include MDA plan types and NTD plans
Web UI Reporting Needs
...
The reporting needs are defined in the data dictionary from Akros. This will require changes to the Canopy flow to make sure the data is available to the data warehouse and Superset.
[This section needs to be enhanced by showing the reporting needs and differentiating the current reporting process so the development is straightforward. Isabel Shaw will do this.]
CSV Upload → Event Generator
We need to develop a server side client event generator that generates clients events server side for each row that’s available in the import. We aim to make the CSV entity event generator generic so that we can import different types of entities into OpenSRP in the future. We need to pass in reference the event template with the CSV that shows field mapping of the so that we can identify which fields should be mapped to which events when they are created. This template should be defined within the OpenSRP server so that it’s 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
...
[This section needs to be enhanced by showing the business logic that’s executed when the CSV is uploaded. Craig Appl will do this]
CSV Validator
CSVs need to go through a validation process that can generate an event that will sufficiently generate a full clientclient when the event is loaded in the Android device. This section defines the details of the CSV Validator.
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.
[This section needs to be improved by identifying how we will address duplicates. Craig Appl will update this.]
Plan Definition and Task changes
...
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
...
We need to validate the assumption that we will support importing rosters against active plans.
Do we only import rosters against active plans?
Should we support importing rosters against plans in draft state?
Should we generate tasks when a plan is shifted to active like we currently do?
...