DHIS Background

The District Health Information Software (DHIS) was developed by BEANISH/HISP in 1997. It is called the District Health Information Software (DHIS) because the key issue in South Africa after apartheid was to integrate the various types of data and reporting from different health programs within the district health system, and to provide tools to district mangers to analyse their local information.

The solution was to establish a district database where data from all facilities (health centres, hospitals, clinics etc.) and health programs (e.g. mother and child health, immunisation) registered and managed. Managers could then get comprehensive reports correlating data from various sources. Demographic data (census) and data about infrastructure (e.g. number of beds, equipment) and personnel (number of doctors, nurses etc.) were also included. An indicator engine (module) makes it possible to combine and correlate different types of data into indicators; immunisation coverage (number of e.g. vaccines/target population), average length of stay (in-patient days/discharges), bed-occupancy (in-patient days/ beds), resources per population (e.g. doctors per population, beds per population) etc. Various modules are used to analyse and present the data, including GIS and OLAP modules. The DHIS has been continuously improved since 1997, and since it was internationalised in 2000 several other countries has adopted and started to use the DHIS; Mozambique, Malawi, Tanzania, Ethiopia, Botswana, Cuba, India, China and Vietnam.

The DHIS, once developed and tailored for a South African province is today a global software package used by 10 countries in Africa and Asia. A key challenge for DHIS as the BENAISH/HISP network has grown is to support the increasing variety of requirements coming from very different contexts. However, the global health domain certainly has some degree of standardisation and the DHIS tries to base its core on international standards for health information while at the same time offer local flexibility to tailor the software to the different local context (countries, provinces, districts). This flexibility has always been one of the major strengths of the DHIS software, but as the BEANISH/HISP network and the DHIS user base has grown rapidly over the last few years, and the field of ICT constantly offers new possibilities (e.g. users are demanding web-based solutions), the DHIS is now struggling to meet the users? needs. Another issue related to supporting a global network with software is to provide the possibility for local modifications and add-ons to the global software suite. The current version of the DHIS has a very monolithic architecture that makes it difficult to locally add new features or modules.

Software and versions

The current version of the DHIS (1.3) is based on VB and the MS Office suite which has certain limitations, such as unnecessary license costs, desktop-orientation, and a dependency on operative system and database server. The rationale for developing DHIS version 2.0 is to develop a fully open source, platform independent and web-enabled version of the DHIS. Another version of the DHIS, the version 1.4 is also in development and it is important to understand that the decision to base version 1.4 to some extent on MS Access was triggered by the need to design and implement major innovations that have gradually emerged over the last 5-6 years, without simultaneously have to deal with a major technology shift. So 1.4 will largely drive the conceptual development of the DHIS the next year while version 2.0 is focusing more on implementing all those new designs and concepts on a new technological platform. DHIS 2.0 in turn will probably enable and trigger another round of mainly conceptual development towards version 3.0 and so on and so forth.

Overall requirements

The DHIS 2.0 can be regarded as a hybrid application suite that should cater for at least three main user needs:

1. The need to rapidly design data collection tools for a variety of purposes.

2. The need to efficiently capture or import/collate this variety of data in an "integrated" manner, then to monitor the processing and flow of this data, and finally to communicate with various stakeholders in the process.

3. The need to analyse relatively large and complicated data sets quickly and efficiently.

Another way of saying the same is that the term "hybrid" denotes that the
DHIS actually needs to combine the typical properties of a flexible transaction database with the typical properties of a data warehouse and some properties of a communication tool.

Some of main technical requirements have already been discussed;
1. Fully Open Source Software
2. Operative System and database server independency
3. Modular architecture

Furthermore, there is an increasing demand from the users in countries were the ICT infrastructure has been rapidly improving over the last few years that the DHIS is web-enabled. However, there are still quite a few users from regions without network or even telephone lines. This means that the DHIS must provide both web-based and standalone solutions and scale the web-enabling based on the infrastructure at hand;
4. Web-enabled system where the infrastructure allows for it

Architecture and modules

Given the BEANISH/HISP network of 10 different countries, the need to balance between global and local requirements, and to allow for local flexibility to modify and improve the software a modular architecture has been chosen. The idea is to have a core module that all users will have to use, and then additional modules that can be installed from a pool of globally available modules to add the features and functionality that the local setting demands. If the available modules do not meet all the local requirements, the architecture will support extensions and new modules to be added to the local system.

Figure 1 above illustrates the different modules that make up the DHIS 2.0.

Figure 1 DHIS 2.0 modules

Technologies

The technological choices were mainly based on the following requirements:

1. Fully open source software
2. Platform independency (OS and database)
3. Web-enabling
4. Modular architecture
5. Support all existing functionality in DHIS 1.4
6. The need to support both networked and standalone user environments

Based on the above needs we have chosen to base the application on the following lightweight java frameworks and tools like The Spring Framework, Hibernate, WebWork, Velocity, and Maven. Java provides platform-independency as the java runtime environment supports all operative systems. Hibernate is framework that provides object-relational mapping, a strategy to allow for database independency. By using Hibernate the DHIS 2.0 supports the use of any relational database management server. The Spring Framework is a lightweight container that takes care of the assembling of modules and the communication between them. WebWork is a java web application development framework that simplifies the development process. Velocity is a java-based template engine that together with WebWork supports reuse and a decoupling of the presentation layer from the business layer. Maven is a build tool that supports a flexible configuration of a modular application. Based on an XML configuration file Maven couple together modules and build a running release of the DHIS 2.0 application that is tailored assembly of modules to cater for the local need of functionality (see Figure 3). Figure 2 below illustrates how the architecture and technologies play together to support the technical requirements.

Figure 2 DHIS 2.0 architecture

Figure Description: The role of Spring Framework in this picture is to provide intra- and inter-module communication by injecting the communication links into the Java implementations, and to provide Aspect Oriented Programming/Cross-cutting Themes, seen here as the Transaction Support intercepting the API and the implementations without inflicting the intercepted parts. The communication lines configuration is specified in XML in each module, making each module pluggable and replaceable.

Figure 3 Maven and modular architecture

Figure Description: The XML file seen on the figure is used to specify which modules are bundled together in the application.

The challenge of supporting both networked and standalone users was addressed in two ways; 1) by providing a layered architecture where the data and business layers can be used by both desktop and web presentation layer modules, and 2) by basing the application on lightweight java frameworks that only need small and simple servlet containers (e.g. Tomcat, Jetty, Resin) to run either locally (without a network) as a standalone system using the web browser, or as a web application running the application.

User requirements

The user requirements can be divided into the following groups:

1. Data registration (design input forms, data capture)
2. Database/system setup (setup organisational hierarchy, metadata (what to collect, analyse))
3. Data processing (validation, aggregation)
4. Import/export (between health units/offices in the organisational hierarchy)
5. Indicator support (define formulas, calculate values)
6. Data analysis and reports (report designer, web-based report viewer, GIS, pivot table (OLAP) module)
7. Internationalisation
8. Patient record management (Integrate with third party FOSS)

A basic stripped down configuration of the DHIS 2.0 should include a standard data entry module, the database setup, indicator support, data validation and aggregation, import/export, a standard report module and internationalisation. Furthermore, this basic configuration should where needed, be extended with more flexible or advanced modules selected from the DHIS 2.0 suite or supplemented by locally developed modules that cater for specific local requirements and needs that are not covered in the global DHIS 2.0 distribution.