DHIS is based on a modular approach of design. A module can be seen as an independent component of application that is capable of both processing inputs as well as outputs, that is used to communicate with other modules. The modules are flexible enough to allow changes in one module without having any effect on other modules. As long as input and output stays the same, it doesn’t matter what happens inside a module. A module can then be changed without affecting other modules, which will be working as long as the output from the first module comes out as normal. This modular feature allows DHIS 2 to be constantly upgraded in terms of functionality, integrated with other applications such as Excel pivot tables and GIS. Thus modularity allows DHIS 2 to be flexible, and changes can take place in the different modules without affecting others.

Currently, DHIS2 has several modules for functions such as data entry, data quality checks, report generation etc. These modules have been categorised and presented under two core categories namely Maintenance and Services. The Services module supports data record, analysis, report generation etc. And the Maintenance module allows you to set the content and structure of the Services module.

DHIS 2 can run both as a web based and offline application. As a web based application, the DHIS 2 application can run on a central server and make use of client-server architecture. For example, at the state level, the DHIS 2 can run on a server, and the different districts act as clients, drawing upon the server application through the Internet for local use of the application.

In a standalone application, the DHIS 2 can run as an independent application on individual computers in different sites such as PHCs, CHCs etc. So, if computerization is taking place at the Block level, then the DHIS 2 will be installed separately on each of the block level computers. The disadvantage of a standalone application is that of platform dependency – where the application needs to be configured to the platform on each of the respective machines. A thick client requires a local run-time environment. For example a Windows Form application will only run on a Windows platform with the .Net framework installed. The major advantage of the offline version is that it can run without any dependency on the Internet. This allows the application to run in remote locations where there is limited or no Internet connectivity.

The main advantage of a web based solution is that it is centralized, which enables easy, on-line updating and deployment of the application. The only requirements on the clients’ side are to have web browser installed on the used computer and have an Internet connection. The hardware on the server is often more powerful than the single computer. Another advantage of the web application is that is platform independent, allowing the same software to be accessed through a web browser regardless of the client’s operating system.

Where connectivity is available, and there is need for centralized management, a web based application is useful, and a standalone application is preferred when these conditions are not available or required. However, in most cases, a mix of these two approaches would be required, with a server based deployment working for district-state-national level processing, and a standalone deployment at lower levels where connectivity is limited. The advantage of such an approach is that it is flexible, inclusive, and scalable because as facilities get Internet connectivity they can be hooked up to the network.

Software carries the instructions that tell a computer how to operate. The human authored and human readable form of those instructions is called source code. Before the computer can actually execute the instructions, the source code must be translated into a machine readable (binary) format, called the object code. All distributed software includes the object code, but FOSS makes the source code available as well.

Proprietary software owners license their copyrighted object code to a user, which allows the user to run the program. FOSS programs, on the other hand, license both the object and the source code, permitting the user to run, modify and possibly redistribute the programs. With access to the source code, the users have the freedom to run the program for any purpose, redistribute, probe, adapt, learn from, customize the software to suit their needs, and release improvements to the public for the good of the community. Hence, some FOSS is also known as free software, where “free” refers, first and foremost, to the above freedoms rather than in the monetary sense of the word.

Within the public health sector, FOSS can potentially have a range of benefits, including:

All computers have an Operating System (OS) to manage it and the programs running it. Such OS serve as the middle layer between the software application, such as DHIS 2, and the hardware, such as the CPU and RAM. The most popularly used OS is Microsoft Windows, which comes in various versions (such as XP, Vista). However, this OS costs money, and have also been reported to have security issues that makes it vulnerable to virus attacks. Operating Systems like Linux are free, and are more secure with respect to virus attacks. Usually, many of the applications will work on one OS, and not on others. Platform independency implies that the software application can run on ANY OS - Windows, Linux, Macintosh etc. DHIS 2 is platform independent, and is extremely useful in the context of public health when typically you have systems in different places running different kinds of OS.

A variety of auxiliary software can be run with DHIS 2, such as GIS (for mapping), BIRT (for reporting), Excel (for analysis through pivot table operations), Open MRS (for patient based management), and CRIS (for HIV/AIDS management). Being based on Open Standards and an Open Architecture, DHIS 2 can build bridges to speak to the other systems. Further, auxiliary modules can be developed and integrated with the core DHIS 2 application.