DHIS – District Health Information System

DHIS (District Health Information System) is a management software applica-tion tool that is used by HISP to capture and analyze health data. The tool has been under development since 1996 using an iterative development process primarily based on cyclical prototyping and participation from HISP users in South Africa. Over the last years, countries like Mozambique and India have contributed more and more in this development process and have made several changes to the tool because of the new contexts DHIS has to be adapted to.

DHIS is an open-source project (see e.g. www.sourceforge.net) that encourages anyone who is interested in participating, to join the development process and use the software for free.

The health data analyzed using DHIS is primarily based on non-individual en-tities captured at facility level or aggregated health data at higher levels. The reason for this approach of collecting health data is the reduced complexity it gains in handling large amounts of health data, and at the same time be able to support decisions based on the data captured. The main argument behind this approach is that reduced complexity promotes increased sustainability and scal-ability of the system. It is much easier to scale a HIS and keep it sustainable with simple health data compared to complex name-based HIS. The trade off is less disaggregated analysis and the inability to follow up specific patients.

As illustrated in figure 4-1, DHIS has six major components that constitute the main and most important part of the application. The GUI (Graphical User Interface) is where the user enters health data that has been collected in the field, semi-permanent (survey) data, defines indicators etc. The GUI reads the desired language data (e.g. English, Portuguese, Spanish, Afrikaans, or Telugu) from the language component. All health related data is stored in the back-end database. This design has been developed to reduce the size of the database by allocating one back-end file within a suitable geographical area, and thus it is easier to scale the application. Another reason is because it enables the develop-ers more freedom to update the GUI component. Because of design reasons the back-end file is slow in handling large amount of data for analysis, and thus data is converted into the data-mart, enabling fast analysis of data using either predefined reports in MS Access or customizable pivot-tables in MS Excel. The

data dictionary, which is not yet in full use, is where information about what to collect (data elements) and the definitions of these elements is stored.

Language component Access DB

GUI Access DB

back-end Access DB/SQL

Data-mart

Data-dictionary

Reports

Figure 4-1: DHIS components

The application has been designed to be as flexible and user friendly as possible in order to operate over geographical borderlines in developing countries. The application is flexible because it allows users to configure the application for local needs that triggers decentralization. For example, data elements may typi-cally be different from one geographical area to another because of various rea-sons. Local managers can then configure the application so that it captures health data that are important within his or her area and that corresponds to reporting levels above. Furthermore, flexibility promotes decentralization be-cause managers would feel more responsible for the health data they register.

The application has been made as intuitive and user-friendly as possible. It has for instance a GUI with large buttons, icons, and on-screen help in several lan-guages (see figure 4-2). Figure 4-3 illustrates another part of the application that is much used by those who collect health data. In this screen, the user must first choose an area and for which month the health data has been col-lected, and then enter data in the data-elements displayed. If the entry is out-side the minimum and maximum values, a comment has to be included. Other features accompanying this screen are, for example, the possibility to run com-plex validation rules, see timeline graphs for a data-element, and do regression analysis for a data element.

Nevertheless, the application has experienced several problems relating to cod-ing and development. Developcod-ing in MS Access has for example made it diffi-cult to do cross-country development. Although the application is open-source, changes done to the application must be done in one central place because of

the way Access works. Furthermore, because this central place is in Cape Town in South Africa, the application has been biased towards the South African context. The ongoing (2007) development of DHIS 2 may however change this. The new version builds on the same principles as the previous version, but is completely rewritten using Java technology and frameworks like Spring and Hibernate. This technology might simplify inter-country open-source devel-opment, e.g. through the use of a revision control systems like Subversion.

Figure 4-2: GUI in DHIS: Starting screen

Figure 4-3: GUI in DHIS: Routine health data entry

4.2 Analysis of HISP’s strategy on scale and