ifrcgo / cbs Goto Github PK

Purpose:
Persons with responsibility for validating Volunteer reports within a geographic area are assigned during the creation of a CBS project #37 (database #13 ). We now need to link these validators to the Volunteers who are reporting within their geographic area (#13 Variable "Escalation POC") .

Conversation:

• Points into polygons?

Confirmation:
Fake Volunteer sends an SMS that triggers a notification for "Escalation POC" to react.

Purpose:
The CBS platform is not public by design, rather access is given based on geographic area of responsibility (RCRC staff) or desire to stay up to date (partners). A humanitarian authentication service, Humanitarian ID, should be used for login.

Design:
Design similar to social media "login with", although limited to DMIS and HID.

Authentication documentation:

• Humanitarian ID: https://github.com/humanitarianresponse/hid_auth (POC: [email protected])
  Related tickets: This issue is related to #20 and #21

Confirmation:
User select "login" from CBS landing page #56 , is directed to login authentication page #31, redirected through appropriate authentication site, and finally lands on the CBS homepage #58 .

Could we have claims on every user saying which national society (Tenant) they have access to.
This is not the Azure AD tenant ID - but something that enables us to check for authorisation if a particular user in a bounded context has access to the national society it claims to have.

Would it be an idea to have Identity Server infront of all this and augment the tokens with more information and let UserManagement interact with this and provide the mapping between users and what national societies they have access to.

See also #327, #328, #510

Purpose:
Data and system access is based on assigned geographic responsibility ( #37 - e.g. "Roxanne" is responsible for covering "Northern" district in "Sierra Leone." Therefore, "Roxanne" CBS website user interface allows access to all data in "Northern".) How do we assign non-directly responsible users access to this information at various levels (e.g. "Anine" from Norwegian Red Cross in helping at country level, or MOH want to view data at "Northern" level)?

Conversation:

Confirmation:

In the event that an alert is issued in #43, a prefilled form is to be sent to [Escalation UID] as defined by the hierarchy in #13

A form is linked to alert UID in #43.

The form should collect data that confirms or dismisses the issued alert while also collecting a narrative open text response by [Escalation UID]. The form is also the method for escalating the alert to the next level in the hierarchy, triggering #53 via #50.

Example form:

The alert form should contain:

• Per report, the name of the volunteer and mobile phone number is displayed
• Per report, an option to tag the report with FALSE, CONFIRMED or CANNOT CONFIRM

Constraints:

• If additional cases are associated with the alert ID as defined in #43, the form is updated with the new cases. (QUESTION: Push alert form update, or new alert form created? Does Escalation POC need to redo investigation?)

Use case:
As a regional CBS coordinator, I am interested in a quick overview of all countries that have active CBS projects within my region. For example, as a CBS coordinator for Africa, s/he may be interested in quick filtering to all projects within her region (e.g. Madagascar, Somalia, Sierra Leone, Cameroon, DRC, Guinea, Mali, Uganda, and Kenya are currently supporting CBS projects)

One must be able to go in and deactivate a volunteer

Purpose:
As a project owner, I want to define how (SMS reporting structure), what (health risk), where (admin boundaries), and who (point of contact) for a new CBS project (part 2 of "Create a New CBS" - #35) that way the scope of the Project is clearly stipulated.

Conversation:
How (what SMS reporting structure):
The Project owner needs to identify how a Data Collection volunteer will be reporting per project (select one). There are two options: "Single event reporting" (Number#Number#Number) #44 or "Daily aggregated reporting" (Number#Number#Number#Number#Number) #46

• "Single event reporting" hint: "Volunteer sends report after each event."
• "Daily aggregate event reporting" hint: "Volunteer sends report at end of each day."

What (Health Risk):
The project owner needs to select up to 5 Health Risk that will be affiliated with a CBS project (ie Health Risk that a Data Collector will be collecting information on). This list is supplied here - Admin Bounded Context (#33).

Where (Location):
The project owner needs select where the CBS project will be running (e.g. part of a country or whole of a country). The baseline map information will be stored here (#42 )

Who (Data Verifier)
The project owner needs to assigns a Data Verifier (role) to cover a geographical region where a Data Collection Volunteer (role) will be working. Contact Information for Data Verifiers (role) will come from the User Management bounded context.

Examples of how Location and Assignment of Data Verifier can overlap.

Map format:

Table format:

We need a code of conduct for contributors

@RFMoore @aninek how should a "level 2 form" look? What information do we need to gather when an alert has been escalated to this level?

The alert forms in #49 and #53 is sent to the person responsible to investigate the alert, as defined in the hierarchy in Admin.

The link to the alert form is sent by SMS and email.

Purpose:
All text messages will be stored in #48 as "Original message". Accurate volunteer reports will follow either of the two reporting structures:

• [Number] # [Number] # [Number] (two hash - single event #44 )
• [Number] # [Number] # [Number] # [Number] # [Number] (four hash - aggregate event #46)

We want to map how two hash reports fit into the the four hash database.

Conversation:

Event is defined by Event UID in Event database #33
Sex is defined as Male =1, Female =2
Age is defined as <5 =1, >5=2

Database structure: Converting previous two hash text messages into four hash database.

Related background tickets:

• SMS to database #25
• How events are stores: #33
• Background on single case reporting: #44
• Background on aggregated case reporting: #46
• Report database #48
• Get SMS format flag from CBS form definition #37
• Mapping of phone to location #26

Constraints:
Original report is always kept as its own variable.

Confirmation:
All example two hash text messages sent and recorded in 4 hash system database.

In a non-outbreak context, as a volunteer I need to report if I have detected health risk in my area.

Reporting format:

Event # sex of case # Age group of case

Events are coded by numbers according #33
Sex of cases is coded as Male=1, Female=2
Age group of case is code as <5 = 1, >5=2
Report example 1#2#1 = Cholera in female <5 years

Related to #46 #45

• Container Registry
• CosmosDB
• KeyVault
• EventHub

Purpose:
Storage location for staff users (system user) information.

Conversation:
Required fields:

• User UID: Interger (GUID, System generated)

• FirstName: Free text

• LastName: Free text

• FullName: Combination of FirstName and LastName for type aheads

• Age: Integer (Birth year)

• Sex (Options: Male, Female, Others)

• National Society (Options: pull from FDRS)

• Preferred language (Options: English, French, but flexible for the addition of more languages)

• Country / Location / place / village: (Drop down admin boundary see #37) Required down to admin boundary 3. If not auto fetch then manually fill location names. OR assign lowest level administrative boundary based on GPS location.

• Mobile phone number: Validation rules for Mobile phone number should be applied - and localized.

• Email address: Normal email validation.

• Role: Dropdown list based on logged in user info (Options:System Admin, Data Coordinator (can create project, read, write, and remove submitted data, delete project, remove registered user, change user role), Data Manager (can't create a project, can assign role to a user except Data Coordinator, Data Verifier (can register data collector, read and update data in its admin boundary), Data Collector (Can read read and update its own data), Data Consumer (read only user), System Admin (can't create project, can't assign a role, can read, write, change, remove data, can't remove users)

• Escalation UID: references the User UID

• Assigned project: Updated from CBS project list

• Date of activation (#65): System recorded

• Status (active, deactivated)

• Registered By: (logged in user from system

• Last updated: System recorded. Revision history for tracking changes in User data, especially GPS.

Constraints:
Users are automatically stored with role "Volunteer" with no authorisation/access to other information than their own.

When users are added as in definition of CBS project #37 their status is updated to reflect their location responsibilities. Assign administrative access based on geographic responsibility #58 (#62).

Example user data

Speadsheet: https://docs.google.com/spreadsheets/d/1voDFeLxiKjbNpKXtUE4se0-lNqMTZVdA6bv0lSDIwXg/edit#gid=335422100

Confirmation:
Pull User information for new CBS project - point of contact #37

Consider the following:

• FAKE
• CAKE

Suggest running builds on AppVeyor and possibly also a Travis version - to make sure it compiles correct on Linux as well.

Some of the .NET Tools we would like to use don't necessarily run on Linux on .NET Core or even Mono. Meaning that we should use AppVeyor as the primary build for .NET.
For instance, if we would get sponsorship and chose to use something like NDepend for monitoring code quality, this only runs on Windows for now.

Depending on the versioning regime, we want to deploy Container images to the Red Cross registry.

Context based build. Everything in Source folder should then have a SLN file associated and also a Docker file associated.

+-- Source
|   +-- <Bounded Context>
|   |    <Bounded Context>.sln
|   |    Dockerfile

Suggest we have a build per bounded context and use the filtering in AppVeyor to accomplish this.

It is fully possible to generate Docker images and publish in AppVeyor as well. Read more here

We might not need something like Travis at all, since Docker could also then be our build for Linux. The best possible way to use Docker for this purpose is to use its support for multiple FROM statements - one where you do the build and one where you package what should be part of the image. Read more about it here.

An example of a Dockerfile that does this:

# Build the .NET part
FROM microsoft/dotnet:2.0.0-sdk AS dotnet-build
WORKDIR /src
COPY ./NuGet.Config ./
COPY ./Source/Common/. ./Common/
WORKDIR /src/YourProject/Web
RUN dotnet restore
RUN dotnet publish -c Release -o out

# Build the static content part
FROM node:latest AS node-build
WORKDIR /src
ADD package.json ./
COPY ./Source/. ./Source/
COPY ./Modules/JavaScript.Build/. ./Modules/JavaScript.Build/
RUN ["npm","install","-g", "gulp"]
RUN ["npm","install"]
WORKDIR /src/Source/YourProject/Web
RUN ["gulp", "html", "javascript", "less", "content"]

# Build runtime image
FROM microsoft/dotnet:2.0.0-runtime
WORKDIR /app
COPY --from=dotnet-build /src/YourProject/Web/out ./
COPY --from=node-build /src/Source/YourProject/Web/wwwroot ./wwwroot
EXPOSE 5000
ENTRYPOINT ["dotnet", "Web.dll"]

Remember to update documentation (Markdown files) and folders throughout the system

Purpose:
As admin, we need to ensure that we have "data verifiers" covering all designated areas of responsibility. If order to ensure all geographical areas are covered we require a base map. (#37)

Conversation:
Information required for Geo:

• IFRC Region (Mandatory) - Text (may become separate ticket)
• Admin 0 (Country) (Mandatory) - polygon
• Admin 1 (Mandatory) - polygon
• Admin 2 (Mandatory) - polygon
• Admin 3 - polygon
• Admin 4 - polygon
• Admin 5 - polygon
• Admin 6 - polygon
• Red Cross and Red Crescent Branch and Chapter (sub-branch) locations - Points (may become separate ticket)
• Population

Where to find:
Administrative Boundaries
The Humanitarian Data Exchange (HDX) host humanitarian/government approved geographic boundaries compiled by UN-OCHA. Often times admin boundaries are reported from Admin 0 (country level) to Admin 2 (district), although some countries go even lower (e.g. Countries of interest: https://docs.google.com/spreadsheets/d/1voDFeLxiKjbNpKXtUE4se0-lNqMTZVdA6bv0lSDIwXg/edit#gid=697028005).

IFRC Regions
The IFRC contains higher level regional aggregation (e.g. "Cameroon" is located in "Africa" region). This data is available here:

Red Cross and Red Crescent Branch locations
This data is available here:

Population
Original source WorldPop, available via HDX.

Constraints:

• We are interested in using the latest available information (sync with HDX? sync with original source?)

Confirmation:
Related issues: #37 is dependent.

Have a Table on the ReadMe.MD file on the root that holds all the build shields per project.
There will be a build per bounded context and we need to reflect the status here.

Also, all build details should be available on the Documentation Site - meaning the index.md should hold this as well in the Documentation folder

If under conditions as described below are met, an alert is to be issued. The alert should have a unique ID that links to the volunteer SMS reports (#25) that triggered the alert as well as any other reports received while the alert is active.

The system should issue an alert if the number of cases reported within a certain timeframe within a specific geographical area exceeds the threshold value defined per event in [Admin] #54 (https://github.com/IFRCGo/cbs/projects/1).

Question: do we need a database for time series?

If there's already an active alert for the specific disease and geographical area, a new alert should not be issued but the cases should be linked to the active alert ID.

If an alert has previously been triggered, but later manually closed by a health coordinator, and new cases are reported that puts the system in a countionous alert state (continuously above threshold value), the previously closed alert ID should be reopened and the new cases linked to this alert ID.

Global coordinator:

Country coordinator:

District coordinator: login

Partner: login from HID

Remember to update documentation (Markdown files) and folders throughout the system

Look at using something like CLA Assistant or CLAHub

Use DocFX like DocFX to automatically package documentation

Relates to Alerts - escalation of alerts.

• Getting Started
• General contribution
• Debugging
• Editor settings
• How to create issues @ GitHub
• Logging
• Runtime Exceptions

When a volunteer gets registered, the system should automatically send out an SMS confirming the volunteer has been registered.

This should be done in all cases - be it from the mobile app, the manual entry on the Web or the volunteer registers via SMS

Have a look here for whats expected

Purpose:
Take all variables from ticket #48 as output of health event API

#168 Purpose:
As a coordinator (Country or Global), I want to create a new CBS project.
Alternative for global coordinator to create and hand over role/responsibility to the project owner.

Form design:

Form fields for user data selection/entry:

• National Society: Dropdown (https://docs.google.com/spreadsheets/d/1voDFeLxiKjbNpKXtUE4se0-lNqMTZVdA6bv0lSDIwXg/edit#gid=300464142 )
• Project/data owner: Default filled current user name (#13 ). If deleted, type ahead from User database. In type ahead consider showing additional identifying information because some countries often have the same name (e.g. Muhammed Diallo).
• Name of project: Free text

System registers: date (DD/MM/YYYY HH:MM:SS GMT)

Button at bottom of form, titled "Create" that redirects to form #37 (or combine all tickets into one CBS project details page)

In an outbreak setting, volunteers need to be be able to send an aggregated report with number of cases of health events detected that day.
This is the default reporting format and priority.

Format:

Events are coded using numbers according to the health risk within the Admin bounded context #33

Validation Rules:

Related to #26

Purpose:
We need a repository for cleaning, disaggregating, and analyzing reports.

Conversation:
The following variables should be captured from volunteer reports:

How to replicate UID 2 - #45
Alert UID is attributed to Alert UID variable in all related reports
Constraints:

• Use standard date time format, time based on GMT.
• All text messages are retained in "Original Report" variable, regardless of whether they are accurately reports or trigger alerts/error messages.

Related ticket: #46 #44 #37
Example dataset:

JSON: https://drive.google.com/open?id=0B3JnixYdZxDEaXgwY0o3UUVvNVk

Spreadsheet: https://docs.google.com/spreadsheets/d/1voDFeLxiKjbNpKXtUE4se0-lNqMTZVdA6bv0lSDIwXg/edit#gid=335422100

Confirmation:
Text three examples to SMS shortcode and observe in database.

Purpose:
When a CBS project has been created (#35) and defined (#37), the project owner should be able to confirm that the suggested health risk case/event definitions and alert thresholds are applicable to their community.

Example table shown to user:

Fields are pulled from (#33 - event database) based on health risk selection in (#37 - CBS form). Fields are "greyed out" and not editable by default. Each row has an edit button at the end. When clicked "alert threshold" variable becomes numeric text editable. The new thresholds need to be saved with timestamp (do not overwrite original) #60 #55
Future feature: Community case definition can be edited #59.

A tick box is shown at the end of form stating
"the events and case definitions have been agreed with National MoH" (should not be required to tick - as this process of MoH approval might be lenghty and NS may need to demonstrate system in order to obtain approval).

Next box redirects to create new CBS project page 4 #62

Purpose:
We want to connect SMS reports with our system for cleaning and issuing alerts.

Conversation:
The inbound API must contain:

<Phone number> <timestamp> <original message> 

Confirmation:
Reported SMS is visible in the report database #48

When an health coordinator has sent a form, the system must escalate the alert to the next level in the hierarchy or close the alert. If the form beeing evaluated is level 1 (#49) and the alert is to be escalated, the system shall generate and send level 2 form ( #53), etc.

The system must also trigger a volunteer feedback in #47 providing details on the outcome of the investigation

If an SMS report sent by a volunteer triggers a new alert in #43, the volunteer should receive an SMS message. If multiple volunteers have contributed to the triggered alert, all volunteers received an SMS.

The message should contain:

• A short message that says that the reported case(s) issued an alert. Message defined in Admin.
• Name and mobile number of the health coordinator that will follow up the alert
• A "key message" describing what actions to take as defined in Admin

When the form response has been evaluated in #50, depending on the outcome a feedback is to be sent by SMS to the volunteers providing details on the outcome.

Purpose:
We need a location to store Health Risk, community case definitions, and suggested thresholds (for SMS escalation) in the administrative interface in order to reference in a new CBS project.

Conversation:
Each event has a designated code (numeric - continuous list) which is used for volunteer reporting (#46 - Defaulting reporting - Aggregate and #44 - Default reporting - single case) and does not change between countries and projects.

Data to populate new Health Risk storage (Health Risk TAB): https://docs.google.com/spreadsheets/d/1bfbfaTr6jx3ia7tOEZxDMDk-qrWAfS9vCoH2N-TG9zM/edit#gid=0

Constraints:

• Must be able to add/remove Health Risk, including values (e.g. Update the Community Case definition).

Confirmation:
New CBS form "Health Risk" drop-down #37 is pre-populated with "Health Risk Name".

One must be able to reactivate a deactivated volunteer

Volunteer should be able to deactivate themselves by sending SMS "Stop CBS"
Coordinator / project owner should be able to deactivate a volunteer in the system

SMS "Start CBS" should reactivate the volunteer if sent from a deactivated phone number stored in user database #13