Request for Proposals Electronic Community Event-Based Surveillance (eCEBS) module integrated with IDSR/DHIS-2

Rating: 
No votes yet

REQUEST for PROPOSALS

Electronic Community Event-Based Surveillance (eCEBS) module integrated with IDSR/DHIS-2

Background

Global Health Security (GHS) is one of top priorities for Rwanda as signatory of International Health Regulations (IHR, 2005). Since the ratification of the regulation on June 15, 2007, Rwanda has been striving for its efficient implementation. Among other efforts to observe international standards and requirements of IHR 2005. To that regard the Rwanda’s Ministry of Health (MoH), through Rwanda Biomedical Centre (RBC) has established Epidemic Surveillance and Response (ESR) division; with the prime mandate to oversee all technical implementation of the regulation; including but not limited to Surveillance of events of potential public health epidemics as well as ensure Preparedness and Response to epidemic outbreaks when occurred.  

To date, disease surveillance in Rwanda has been primarily based in health facilities and hospitals and involves detecting and responding to important health events by collecting information about what makes humans and animals ill or die. However, communities are considered to be at the frontlines of early identification and detection of events that can quickly spread to the larger regional and international scale and at the same time, communities are at the first to suffer consequences of epidemic outbreaks; hence, they should be first agents of prevention, preparedness and response to potential epidemic events.

Management Science for Health (MSH) in partnership ESR division of RBC are developing a comprehensive Community Event Based Surveillance (CEBS) model. This model is defined as: “An organized system of Village Lookouts trained to notice and then rapidly inform authorities about local community events that may be dangerous to public health and could constitute potential risk to public health”. These Lookouts then work with National and District authorities to investigate and respond to emergencies as required. The system which is considered to be an expansion of existing disease surveillance system of IDSR beyond health facilities into communities; is expected to ensure early detection and reporting of potential Public Health Emergencies of International Concern (PHEIC). Example of such emergencies include but not limited to Ebola, yellow fever, Lassa fever, Rift Valley fever, West Nile fever, dengue fever, cholera, pneumonic plague, smallpox, pandemic flu, severe acute respiratory syndrome -SARS, and Zika virus disease among others. One of main component of the model under development is an electronic Community Event – Based Surveillance system (eCEBS).

SCOPE OF WORK:

Working in collaboration with the MSH Global Health Security project team  Rwanda and the US, and the Epidemic Surveillance and Response (ESR) Division of the Rwanda Biomedical Centre (RBC), under the Guidance of the MSH Project Manager and the Health Management Information Systems Team Lead, the eCEBS Development Partner will:

  1. Develop the eCEBS module according to the technical System Requirements Specification (SRS) in Annex 1
  2. Develop a User Guide and the required system documentation
  3. Provide trainers to conduct 4 training events (1 day each, to be organized and paid for by MSH) for prospective eCEBS users, including community lookouts from 10 sectors in Rusizi and Rubavu districts as well as eCEBS administrators/super users at central ESR office.
  4. Undertake ongoing preventive and curative maintenance of the system.
  5. Implement system refinements and enhancements to improve its performance as required.

 Applications due: September 3, 2018.   

Submit applications to ecebs@msh.org

Specify key activities and timeline, and relevant past experience. No more than 6 pages. 

Include a budget. 

Applications from individuals will not be considered. 

Award decision: September 10, 2018

Period of Performance: 

September 17, 2018 – May 31, 2019

Deliverables:                                                             

1.      Functional eCEBS module.   Due: November 31, 2018

2.      Submission of final source codes documentation (soft copy), detailed system documentation and a User Guide.   Due: November 31, 2018

3.      Submission of system source codes documentation   Due: November 31, 2018

4.      4 trainings in Rusizi and Rubavu    Due: December 31, 2018

A final report summarising notable issues with eCEBS development, implementation, maintenance and recommendations for the next steps    Due: May 31, 2019      

---------------

ANNEX 1.

USER REQUIREMENTS

Electronic Community Event-Based Surveillance (eCEBS)

1.1         Purpose of the system

The system is expected to accomplish the following functions:

CEBS has three primary functions:

  • Registration of system users,
  • Reporting unusual health events (Triggers), such as potential outbreaks or cluster of deaths (human and animal) with the same signs or symptoms, from all sources (active surveillance) at the earliest possible stage.
  • Relay feedback and communication between local levels (peer lookouts), health care facilities, Vets, and District levels.
  • Record follow up data about the persistent events that were previously reported with indication of latest status.
  • Push verified and confirmed outbreaks of suspected cases immediately reportable priority diseases of to eIDSR.

1.2         System users:

The system will support various users at different levels and varying roles. Groups of identified users are:

i.    eCEBS System Administrator
ii.    CEBS lookouts (Village Leader, Community Health Worker, Community Animal Health Worker or other selected community volunteers)
iii.   
iv.    National level staff (One Health partners)

1.3         Data flow/Process Flow Diagrams:

Figure 1: CEBS User Registration

Figure 2: Community Level Event Notification

Figure 3:Health Event Investigation & Confirmation

1.      Requirements Specification

2.1.Functional requirements

Definitions of table headings:

Table Header

Table header description

Ref

The reference for each unique requirement

Requirement

The name of the requirement

Process Step

The map to the Business process diagrams

Description

The description of the requirement including high level details.

Mandatory/ Desired

This column indicates if the client considers the requirements to be mandatory or desired. Mandatory requirements should be prioritised.

2.1.1.       Registration of Users

Ref

Requirement

Process

step

Description

Mandatory /Desired

FRRU01

Add user details

1

The user is able to register a new user and assign a system-generated unique identifier (User identifier).

The user is able to capture details including lookout names, village, Cell, Sector, district, telephone number and nearest Health Centre in the catchment area. The system shall indicate mandatory fields.

The user is able to edit fields prior to saving.

 

M

FRRU02

Search User

4

The user is able to search existing/registered user

M

FRRU03

Edit/Delete User

7

The user is able to edit users’ details including deployment to a different location or Delete the user who is no longer a lookout

M

FRRU04

Send error message

5a

The system is able of sending an error message to the user who attempted and failed to register. The message should describe the error and suggest how to correct it.

M

FRRU05

Confirm user registration

5b

The system is able to send a notification to the user to confirm the registration

M

FRRU06

Check and Prevent double registration

4

The system is able to check that the user attempting to register is not already registered. The system will use multiple check variables such as National ID, Phone number, names and location

M

FRRU07

Save User

4

The system is able of save details of the user. It should accept either new record or edited records.

M

FRRU08

Notify Central level on new registration

6

Send email and SMS to ESR selected staff about new user registration request

M

FRRU09

Approve/Reject registration

7

The user is able to approve or reject the registration request

M

FRRU10

Generate userID

7

The system is able to generate unique identification number of the registered user

M

2.1.2.      Community – level Event Notification

Ref

Requirement

Process

step

Description

Mandatory /Desired

CEN01

Enter toll free number

1

The user is able to enter the toll free number or telephone number of the message recipient

M

CEN02

Enter message content

1

The user is able to enter a Short Message about the community event to be notified

M

CEN03

Send/submit message

2

The user is able to send/submit the message to the number that pre-specified number

M

CEN04

Check and generate error message

3

The system verifies message content for errors and generate error message

M

CEN05

Send error message

3b

The system sends error message to the initial sender and propagate the message to peer lookouts in the same village

M

CEN06

Send feedback

3

The system sends feedback message to the initial message sender

M

CEN07

Copy feedback to peers

3

Send copy of the feedback to peer lookouts in the same village

M

CEN08

Assign ID to the event

3

The system is able to create and assign a unique ID to the event

M

CEN09

Send SMS to notify HC staff

4

The system is able to send event notification to selected HC staff including Head of HC (Titulaire), Environmental Health Officer, Data Manager, etc.

M

CEN10

Confirm change of the event status

8

The system is able to send sms about confirmation latest status of the event that has changed, with mention of “False” or “Improved” or “Worse” status

M

CEN11

Send SMS to confirm outbreak

6b

The system is able to send message to lookouts confirming that the notified event is confirmed to be a potential epidemic outbreak

M

CEN12

Send SMS to close event

6a

The system is able to send SMS to lookouts and HC staff that the notified event is closed

M

CEN13

Push outbreak details to eIDSR

6

The system is able push the confirmed outbreak to eIDSR with details such as location, onset date, aggregate number of affected population (human or animal)

M

2.1.3.      Event Investigation and Confirmation

Ref

Requirement

Process

step

Description

Mandatory /Desired

EIC01

Push outbreak details to eIDSR

14

The use is able push the confirmed outbreak to eIDSR with details such as location, onset date, aggregate number of affected population (human or animal)

M

EIC02

Link Community Event to eIDSR case registration

15

The system is register the community event as an ordinary case in eIDSR

M

EIC03

Close Community Health Event via web application

11

The user is able to close the community health event via a web application/interface

M

EIC04

Send SMS to lookouts about latest status of the event

18

The system is able to send SMS to lookouts from the village where initial notification came from, about latest status of reported event

M

EIC05

Notify higher levels about active event

19

The system is able to send sms and email notification to Sector, district and national level authorities (both administrative, Health and agriculture) about active event

M

EIC05

Display dashboard with quick statistics

 

The system is able to display quick statistics about reported event via a web interface. Such statistics would include numbers on reported events disaggregated by notification period, location, status, and Confirmation status

M

 

 

 

 

 

2.2.Non-Functional requirements

  • Compatibility and interoperability with eIDSR,
  • Hosted internet-enabled web platform – preferably hosted in Rwanda
  • Supported for computer and GSM phones and smartphone
  • Accessible through web applications
  • Transaction logs for system audit

2.3.Services required:

  1. Software customization/adaptation of system to these requirements
  2. Configuration and testing of software on agreed upon platforms
  3. Training of system administrators and ESR team
  4. Preparation of user guides for each type of user
  5. Annual maintenance/support contract

2.      Message content:

2.1.   User Registration

Sender

Recipient

Transmission channel

Message purpose

Message content (English version)

Message content (Kinyarwanda)

Selected lookout

eCEBS

GSM phone

Registration

REG LN (Lookout Name) VN (Village Name) HC (FOSAID) CL (Cell Name)

Phone # automatically transmitted

Gusaba kwiyandikisha

eCEBS

Lookout

SMS Service

Registration confirmation

Community volunteer x from village Y is successfully registered as CEBS lookout

Umukorerabushake X wo mu mudugudu Y ashoboye kwiyandikisha mu bacunga indwara indwara z’ibyorezo

eCEBS

Lookout

SMS service

Error notification

Registration failed. Restart the process

Kwiyandikisha byanze. Ongera utangire bundi bushya

eCEBS

eCEBS Admin at Central level

SMS service

Notify Central Level about the registration request of a new user

Community volunteer ______ with telephone number _____ is requesting to be eCEBS look out. Please Approve or Reject

N/A

2.2.   Community – level Event Notification

Sender

Recipient

Transmission channel

Message purpose

Message content (English version)

Message content (Kinyarwanda)

Lookout

 

GSM

Alert unusual health event

ALERT TYPE:

-          HI or HD or AID

-          Number of cases

-          CMT (free text )

Abantu x bararwaye cyane. Bafashwe n’indwara itazwi kandi idasanzwe

eCEBS

 

SMS service

Feedback to sender and copy to peer lookouts

Your notification is successfully received and recorded with Event Number ____

Ucunga indwara z’ibyorezo __ yohereje ubutumwa burebana n’indwara y’icyorezo cg urupfu rudasobanutse yateye mu mudugudu Y. Ubutumwa bwawe kwakiriwe neza, kandi bwahawe numero _________

eCEBS

 

SMS service

Notify HC staff of suspected health event

A suspect health event has occurred in village X, cell Y. For further information, please contact Lookout Z.

Hari indwara y’icyorezo ikekwa mu mudugudu wa X, akagari Y. Ku makuru yimbitse hamagara Ucunga indwara z’ibyorezo Z.

HC staff

 

GSM

Confirm that a reported event should be investigated

CONF EVID_______

ST (FALSE, IMPROVE, WORSE)

CMT________________

 

eCEBS

 

SMS service

Report that incidence status has changed and provide guidance

Event # ____that was notified from Village X, Cell Y has changed status to ______(False alarm or Improved or worse)

Icyorezo cyahawe # _____ cyamenyekanye mu mudugudu X akagari Y cyahinduye isura. Ubu ni (Nticyari cyo, Kiragenda kigabanyuka cg Byabaye bibi kurushaho)

eCEBS

 

SMS service

Alert to DH focal point and hierarchy phone

There is suspected health event that was notified from village X, cell Y sector Z, confirmed by Name of HC staff and Phone #.

Hari amakuru yatanzwe ku ndwara y’icyorezo ishobora kuba yateye mu mudugudu wa X, akagari Y Umurenge Z

eCEBS

 

Web API

Confirm outbreak

Change of event status to a confirmed outbreak or closed or false alarm by IDSR FP at the HC or DH

N/A

eCEBS

 

SMS service

Confirm event

Suspected event #____ that was notified from village X, cell Y and sector Z is confirmed to be epidemic outbreak of disease _______

Icyorezo cyacyetswe gifite # ____ cyamenyekanishijwe bivuye mu mudugudugu wa X, akagari Y Umurenge Z, cyemejwe nk’icyorezo cy’indwara___________

eCEBS

 

SMS service

Close Event

Notification of suspected event #______is closed

Imenyekanisha ku ndwara y’icyorezo # X rirafunzwe