Introduction
Dengue virus, which is transmitted primarily by the yellow fever mosquito Aedes aegypti, is
the most common cause of arboviral disease in tropical and subtropical areas of the world.
Annual worldwide cases are estimated to exceed 50 million for dengue fever (DF) and range
from 250,000-500,000 for the more serious dengue hemorrhagic fever (DHF) disease
manifestation. The dengue situation in the
Americas has become critical in recent years with a steadily rising case load and increasing
ratios of DHF to DF cases. In
the absence of a vaccine against dengue virus, control of the mosquito vector is the primary
option for preventing and controlling dengue outbreaks.
In developing countries with critical needs for prevention and control of infectious diseases,
large amounts of data are often being collected but only rarely processed and analyzed in a
rational manner allowing for evidence-based decision-making. This is, in large part, because
information is collected on paper forms which then gather dust on the shelf until they finally are
discarded. Lack of electronic systems for data entry, storage and analysis creates untenable
situations where a poor factual basis for decision-making results in decisions of uncertain quality
regardless of the competence of the decision-maker. At Colorado State University, we are
addressing these issues for one important mosquito-borne infectious disease, dengue, through
development of a computer-based Dengue Decision Support System (DDSS).
Use of electronic devices, such as laptops, Personal Digital Assistants (PDAs) or cell phones
for capture of data in the field and direct input into a central database is an aspect of
the DDSS project. Potential for use of such devices would add value to the DDSS through streamlining of data capture and entry and
removal of the time-consuming and error-prone step of entering data from paper sheets filled out in the field into the DDSS database using electronic data entry screens in the desktop/laptop
version of the DDSS software. Compared to laptops or PDAs, cell phones are less expensive and also eliminate the need for physical means of data transmission via USB flash drives etc.
Use of cell phones exploits existing communications infrastructure and also introduces near real time monitoring and potential for rapid feedback to field data collectors. There also are aspects
of improved data integrity, including removal of the need for interpretation of paper forms filled out with substandard penmanship and removal of the tedious and error-prone process of
manual entry of data from paper forms into an electronic database. Further, there is an explosive growth of mobile telephone networks in the developing world and the International
Telecommunications Union predicts that 75 percent of people in Latin America will own a cell phone within the next 3 years
(http://www.itu.int/net/home/index.aspx).
Using cell phones, vector control teams can visit homes near where the cases occurr ed. Capture data from the field
and either send it directly to the main server, or saving it in a local cell phone database (e.g., to save internet connection time
or when server is not available. Figure 2 shows the workflow of the vector control activities. An agent visits selected addresses in the infected area. However, instead of collecting data on paper forms, the agent uses the cell phone data collection application. Data collected by the application can be sent
directly
to the center where the main server that runs the DDSS resides (i.e., the health
institute that is performing the study).
|
Architecture
The cellphone application is developed using the Android platform.
Android offers royalty free and open source development environment including, the operating system,
the VM, Eclipse plug-in developing tool, an emulator for testing the application before installing it on a phone,
and tools for encrypting and publishing the application. All the client side applications are developed in Java,
a local database (residues on the cell phone), is used by the application. The database is developed with SQlite,
which is the database system that Android supports.
In order to provide a robust application, the cell phone can connect to the main server using three options:
- Continuous Internet Access: the user collects data and sends it instantly to the main server over the web. This option can be used when the cell phone is always connected to the web and data collected is needed instantly.
- Periodic Indirect Access: The user collects data and saves it in the application database. When the user finishes his or her daily task, the user sends the data to the main server over the web. Using this option, operational cost can be minimized since the cell phone does not have to be connected always to the web. The user can use the cell phone Wi-Fi to access the web from a designated point. Therefore, there will be no cost on sending the data.
- Desktop/laptop Data Transfer: The user collects data and saves it in the application database.
When users return to the center, collected data on the phones are downloaded to a desktop or labtop.
This option can be used when the cell phone cannot access the web.
Figure 3 shows the main
components of the cell phone application. The application has two units for interacting
with the DDSS application on the main server: (1) Web Interface, which performs a set of web services to get data from the DDSS application, and (2) SMS Interface, which processes messages sent from the DDSS application. The Core unit performs calls to the other units in the application including The DB layer which is used to manage the local database, and the user interface unit, which includes a set of forms for getting inputs from users.
|
Workflow
1. Application Installation: When the application is installed on the cell phone, the application performs several web service calls
to the main server using which, the application gets the tasks assigned to the cell phone, the types of these tasks,
related settings to these tasks, and the agents information. After the application gets installed, the login screen is
called and displayed.
2. Authorization and authentication: The application only saves
information for users and tasks that are authorize to work on the cell phone. Cell phone is
authenticated
using the phone IMEI number and the SIM card number. The agent is
identified by a pre-chosen username and password. The agent provides his/her username upon which, the application loads tasks assigned to the
user and activates the dropdown list of tasks. The user then provided his/her password and chooses a task to work on.
Figure 3 shows the login screen before and after the agent enters the username. The figure was taken while running the application on the Android emulator with specs of a NexusOne phone.
| Figure 3: Login screen, before (left) and after (right) the agent enters username. |
 |
 |
3. Task management: The agent can view and manage assigned subtasks using two forms. The first form, shown in Figure 4 (left), displays the subtasks assigned to the agent. An agent can choose a subtask and perform data collection. Subtasks are a set of addresses
of premises assigned to an agent. Subtasks are categorized into 3 groups
- Available premises: These are the
premises that the agents need to visit and survey. When the agent starts his/her job, all premises will be of this category.
- Premises to revisit: Sometimes an agent might visit a premise and arrange with the residents to come back on a later time. Such premises are added to this list. The agent can choose premises from this list to revisit on the scheduled time. However, if the agent cannot do the revisit, or the task
administrator decides not to perform revisiting, the subtask can be saved without surveyed information.
- Completed Premises: Premises that an agent visits and successfully collected data for them are considered completed. Moreover, if an agent was not allowed to enter the house, or did not find anyone in the house, such premises are also considered completed.
Furthermore, the agent has the option of
viewing the status of all assigned subtasks. As shown in Figure 4, left screenshot, the agent can sent all completed subtasks to the main server. This option can be used by the agent when the connection is not available when the premises were visited.
| Fingure 4: Task Managment. |
 |
 |
4. Data collection: The application provides a GUI that the agent can use to collect data for a premise. As shown in figure 5, the agent first selects the status of the premise (entry granted, no one home, entry denied, or revisit). If entry is granted, The rest of the form gets enabled and the agent can use the form to collect data. The data form displays a list of containers types that can be found either inside the house or outside (i.e., in the backyard) . These container types are sent to the application when it is installed. Therefore, can be changed depending on where the application is going to be used. For each container type, the agent reports how many such containers are found, how many of them contain water, how many contain pupae, and how many contain larvae. As shown in Figure 5, the agent can either type in the numbers or use the +/- button to increase/decrease the numbers. The application performs the following validations:
- The number of containers that contain water should not exceed the total number of containers.
- The number of containers that contain larvae should not exceed the number of containers with water, since larvae do not live in dry containers.
- The number of containers that contain pupae should not exceed the number of containers with water, since pupae do not live in dry containers.
Using the "send" button, the agent can send the collected data directly to the main server. The agent can also choose to save the data locally in the database and sent all collected data periodically.
Figure 5: Data collection form: On the left, selection of premises status. On the right, filling data for containers. |
 |
 |
|
| |
|
