RAMS-AID

RAMS-AID Research -Software solutions for vector-borne diseases

Multi-disease data management system for dengue and malaria

The text and figures below are based on the following two publications:

Eisen, L., M. Coleman, S. Lozano-Fuentes, N. McEachen, M. Orlans, and M. Coleman. 2011. Multi-disease data management system platform for vector-borne diseases. PLoS Neglected Tropical Diseases 5: e1016.

Lozano-Fuentes, S., C.M. Barker, M. Coleman, M. Coleman, B. Park, W.K. Reisen, and L. Eisen. 2011. Emerging information technologies to provide improved decision support for surveillance, prevention, and control of vector-borne diseases, In Press. In: Efficient Decision Support Systems: Practice and Challenges – From Current to Future / Book 3, C. Jao [ed.]. InTech - Open Access Publisher, Rijeka, Croatia.

A multi-disease data management system for vector-borne diseases

The Innovative Vector Control Consortium recognized the potential for using information technologies to improve vector and disease control program performance and ultimately reduce the burden of tropical vector-borne diseases such as dengue and malaria. This resulted in an initiative that led to the development of the software package described herein: a multi-disease data management system (hereafter, the system) with current capacity for dengue and malaria, and with potential for addition of other important tropical vector-borne diseases.

Key goals for the system include:

ensuring that it can be distributed without the user incurring licensing costs,
producing a flexible system that can be adapted to local circumstances by the user with no or minimal involvement of software developers,
achieving a user-friendly system with capacity to support data entry, storage, and querying, and production of maps and reports, as well as including decision support functionalities such as custom calculations and automated alerts, and
delivering a system capable of enhancing the user’s ability to carry out surveillance, engage in evidence-based decision making, monitor interventions, and evaluate control program performance.

System characteristics and licensing

The system was developed with a 3-tiered architecture (data tier–application/business logic tier–presentation tier) and is comprised exclusively of software components which can be distributed without licensing costs. It can be implemented on a single stand-alone computer, in a client/server environment where the client (user) logs in remotely to the system, or as a pool of installations with one master and one or multiple dependent installations (the system includes synchronization functionality).

Distribution and licensing is currently executed through the IVCC (http://www.ivcc.com/). There is no cost associated with the license (the system is a royalty free, licensed software).

The data tier includes a PostgreSQL database (http://www.postgresql.org/) enhanced with PostGIS (http://postgis.refractions.net/) to support spatial data. The business logic tier includes Java (http://www.java.com/en/) and Apache Tomcat (http://tomcat.apache.org/). The presentation tier uses Firefox (http://www.mozilla.com/en-US/firefox/ie.html), and is augmented by applications to support production of reports, BIRT (http://www.eclipse.org/birt/phoenix/), and maps, GeoServer (http://geoserver.org/display/GEOS/Welcome) and OpenLayers (http://openlayers.org/). To link the tiers, and to allow the user to make changes that automatically are reflected across the 3-tiered architecture, the system includes TerraFrame Inc’s Runway SDK application (http://www.terraframe.com/products/runwaysdk).

The system installation package includes the system itself, the system manual, and stand-alone versions of OpenOffice (http://www.openoffice.org/), the reporting tool BIRT, FWtools (http://fwtools.maptools.org/) to assist the user in transforming spatial data into well known text (WKT) format, and QCal which calculates dose/time response curves for insecticide resistance bioassays (http://sourceforge.net/projects/irmaproj/).

System adaptability

One key goal was to produce a flexible system that can be adapted to local circumstances by the user with no or minimal involvement of software developers.

The system currently handles dengue and malaria. Selection of the disease in which to work is done through a menu item called Disease. Selecting a disease of interest in the Disease menu results in the user being presented with a default menu for the selected disease. This default menu can be re-configured by the user, including:

incorporation of functionalities that are present in the system but not as a default for the disease of interest and

changes to menu label names. This provides an economy of scope as new diseases downstream can be added to the system at decreased cost through re-use of already existing functionalities.

The system also includes the capacity to:

customize user roles and their permissions,
define, by disease of interest, the status of many data entry fields, i.e., whether they are mandatory or non-mandatory,
select, by disease of interest and role, whether to show or hide a given data entry field, and
change display label names in the different disease menus.

The system includes three user-configurable information trees:

a controlled vocabulary term tree,
a universal tree for key spatial concepts, and
a geographical entity tree, where each entity is an instance of a universal (e.g., the geo entity United States is an instance of the universal Country).

The term tree, based on ontological principles following the Open Biomedical Ontologies (http://www.obofoundry.org/), is used in the system to define options in pop-up select lists for data entry fields and for pre-configured entries for rows and/or columns in data entry tables. The system is delivered with a default term tree and each data entry field or row/column configuration in a data entry table that is populated from the term tree has a pre-configured root term that defines what is included in the select list for the data entry field or which terms that are used to define table rows/columns. Both the term tree itself and the selection of root terms are completely configurable by the user, including the ability to make terms active or inactive by disease. Based on the is_a ontological relationship of the term tree, data can be aggregated to higher levels of the term tree in the system’s internal data querying tools.

Universals, as used in this system, are key spatial concepts that can be defined with regards to how they are used to support system functionalities. A small set of universals are required for specific system functionalities (health facility, collection site, sentinel site, spray zone, stock depot, and surface) and these typically will be complemented in the system by a set of user-created universals, such as country, state, county, settlement, etc.
The geographical entity tree provides a representation of the area in which the system is implemented and, for geo entities in the system which have spatial data associated with them, can be used for mapping. Geo entities have the properties of universal type, entity status (active/inactive), name and ID, type of geometry (point, polygon, etc.), and spatial data (in WKT format). Each entity is related to other entities by means of a located_in relationship defined by the total inclusion of one entity inside another: for example Colorado is located in the United States. The system default is a single root entity called Earth under which the user can build a locally relevant geographical entity tree. One benefit of the geographical entity tree, derived from its located_in relationship structure, is the potential for aggregating data to coarser spatial resolutions in the system’s internal data querying tools.

Data entry, data query, and reporting/mapping

To minimize data entry error, data entry fields make extensive use of hard-coded select lists or radio buttons, geo entities selected from the geographical entity tree, dates selected from pop-up calendars, and terms selected from pop-up select lists from the term tree.

Data querying is done through a set of unique system tools referred to as query builders, linked to specific data input screens, where the user can define a specific data query (see figure below).

All query builders include the capacity to filter a query on start and end dates and geo entities from the geographical entity tree (top pane in query builder). Additional filtering of a query can be done on specific variable fields (left pane in query builder) corresponding to the data entry fields in the relevant data input screens; this can include terms from a term tree root, values from hard-coded select lists or numerical values or ranges. The query builders also include options to export query results as .csv or .xls files, to save and re-use specific querying field combinations that are executed on a regular basis, and to upload pre-configured report templates (from BIRT) and use these to produce standardized reports (bottom pane of query builder).

Mapping is directly linked to the query builders as the system’s map generation process makes use of information that is saved in the query builders as specific named query results. Maps can combine data that are generated through different query builders, e.g., for intervention coverages and disease case locations or disease incidence, and overlaid on a map base layer showing locations of households, administrative boundaries, etc. (see example below).

Examples of system decision support functionalities

One key goal was to produce a system capable of enhancing the user’s ability to carry out continuous surveillance, engage in evidence-based decision making, monitor interventions, and evaluate control program performance. The following provides examples relevant to dengue control programs of system decision support functionalities, including pre-defined custom calculations relating to specific surveillance or control parameters and automated alerts when system thresholds for key entomological or epidemiological risk measures are reached.

Examples of custom calculations relevant to dengue include:

commonly used immature abundance indices for the dengue virus vector Aedes aegypti,
relative contribution of different container types to production of mosquito vector immatures,
incidence of disease cases and case fatality rate, and
percentages of available and visited premises within a given geographical area and time period for which prevention or control activities were carried out (this can also be broken down by prevention/control method, as defined by the user in the term tree), and percentage of visited premises that were not treated (this can also be broken down by reason for non-treatment, as defined by the user in the term tree).

Automated alerts that are triggered when threshold values are reached are perhaps the clearest examples of decision support in the system. Alerts are currently included for:

abundance indices for container-inhabiting mosquito immatures and
disease cases.

In both cases thresholds can be configured by the user to suit local conditions so that alerts are not excessive to the point of being meaningless due to lack of resources to respond to them. The system can provide alerts as on-screen pop-ups (see figure below) and/or e-mail notifications.

Range of the information handled in the system’s dengue menu

In addition to the generic system modules for administration and GIS, the latter of which includes the geographical entity tree and the functionality for map generation, the system’s dengue menu includes modules dealing with case surveillance, entomological surveillance, intervention planning, intervention monitoring, and stock control.

Case surveillance includes separate functional components for:

aggregated disease case data and
data for individual disease cases.

The module for entomological surveillance includes functional components which can handle data relating to non-container based collections of mosquito vectors, for example collection of adults by traps or active collection with aspirators, as well as container-based surveillance data for immatures which was mentioned previously. In the latter case, the system includes separate data entry screens for data collected by individual container versus data collapsed to user-defined container types. This is complemented by functionalities relating to capture of data for assays conducted on mosquito collections, including assays for pathogen detection, assays to determine killing efficacy of insecticides, and insecticide resistance bioassays, biochemical assays, and molecular genetic assays.

Intervention monitoring deals with coverage, in space and time, of different types of control interventions. This includes functionalities to handle data relating to person-days and amount of insecticide product used for the intervention as well as data for intervention coverage, by user-configured control methods, collected on a premises-to-premises basis or aggregated to larger spatial units such as blocks or neighborhoods.

The system’s stock control module helps the user to track stock levels in different storage locations and also to track cost of stock. Locally relevant stock items are configured by the user in the term tree.

Funding and partners

Funding to develop this system was provided by the Innovative Vector Control Consortium. The work was done in collaboration between Colorado State University, the Innovative Vector Control Consortium/Liverpool School of Tropical Medicine and TerraFrame, Inc (http://terraframe.com/).