DHIS2 User Manual

DHIS2 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 DHIS2 to be constantly upgraded in terms of functionality, integrated with other applications such as Excel pivot tables and GIS. Thus modularity allows DHIS2 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. Each of these modules will be discussed at greater length in this document.

DHIS2 can run both as a web based and offline application. As a web based application, the DHIS2 application can run on a central server and make use of client-server architecture. For example, at the state level, the DHIS2 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 DHIS2 can run as an independent application on individual computers in different sites such as PHCs, CHCs etc. So, if computerisation 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 centralised, 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 centralised 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, customise 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. The operating system serves as the middle layer between the software application, such as DHIS2, and the hardware, such as the CPU and RAM. DHIS2 runs on the Java Virtual Machine, and can therefore run on any operating system which supports Java. Platform independence implies that the software application can run on ANY OS - Windows, Linux, Macintosh etc. DHIS2 is platform independent, and is extremely useful in the context of public health, where multiple operating systems may be in use.

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

You must be sure that you have a current version of the Java Runtime installed on your machine. Depending on your operating system, there are different ways of installing Java. The reader is referred to this website for detailed information on getting java installed.

The DHIS 2 Live package is the easiest way to get started with DHIS 2. DHIS 2 Live is appropriate for a stand-alone type of installation. Simply download the application from here. Once the file is downloaded, you can simply double-click the downloaded file, and get started using DHIS 2.

DHIS 2 Live uses an embedded H2 database. This has several advantages - there is no need to install a separate database engine such as PostgresSql or MySql, and backup can be made by just copying the file. The whole db exists in memory, which means high performance. The disadvantage is need for RAM. It is also not suitable for mulitiuser server installations.

In general, it is recommended to work with the database through the DHIS 2 user interface, but in some situations one may need to manipulate the data directly. If one downloads H2 separately, it comes with a web interface. It can also be manipulated using OpenOffice.org, using the following procedure. This assumes that dhis2-live is located in the user's Linux home directory (represented by ~). Substitute the absolute path to your dhis2-live installation.

More tips

The server version can be downloaded from dhis2.org/download. For detailed information on how to install it please refer to the installation chapter in the implementation manual.

To create or find a user begin with clicking on the ‘user’ module displayed in the drop down menu of the Maintenance module located on the main tool bar on the top part of the displayed screen.

User names already registered will appear as a list as seen in the screen shot below.

You can search for specific user names in the user list by entering the name in the ‘filter by user name’ field as shown above.

As part of creating a user name you are required to define the user role. Do so by clicking on the ‘user role’ appearing on the left side of the displayed screen. This will lead you to the Role Management page where you will have to click on Add new to create a new role.

The following screen will open and here in the first text box you need to give Name of the Role such as Super User, Admin User, etc. The second text box called ‘Description’ gives more information about the type of User Role that is being created for e.g. State Admin User, District Data Entry.

Next you will specify the particular data set(s) that are to be made available to the particular role. You will also need to specify the type of ‘authority’ to be given to the particular user. For each of the three options namely Datasets, Reports and Authorities user can select multiple options from the scroll down menu provided against each field. A user can choose multiple options either by moving them one-by-one.

In order for particular users to be able to enter data, you must add them to both a dataset as well as an organisational unit level. You can also select multiple datasets individually by pressing the Ctrl key on the keyboard and clicking on individual datasets.

Finally when you have entered the required fields click on Save which is located on the lower part of the displayed screen. The desired user role and related authorisation will be saved to the database, and can then be assigned to a particular user.

Under particular user role there can be more than one user. To add new users go to the User options under the Maintenance module.

To add a new user, just follow these steps:

The organisational hierarchy defines the organisation using the DHIS 2, the health facilities, administrative areas and other geographical areas used in data collection and data analysis. This dimension to the data is defined as a hierarchy with one root unit (e.g. Ministry of Health) and any number of levels and nodes below. Each node in this hierarchy is called an organisational unit in DHIS 2. The design of this hierarchy will determine the geographical units of analysis available to the users as data is collected and aggregated in this structure. There can only be one organisational hierarchy at the same time so its structure needs careful consideration. Additional hierarchies (e.g. parallel administrative boundaries to the health care sector) can be modelled using organisational groups and group sets, but the organisational hierarchy is the main vehicle for data aggregation on the geographical dimension. Typically national organisational hierarchies in public health have 4-6 levels, but any number of levels is supported. The hierarchy is built up of parent-child relations, e.g. a Country or MoH unit (the root) might have e.g. 8 parent units (provinces), and each province again ( at level 2) might have 10-15 districts as their children. Normally the health facilities will be located at the lowest level, but they can also be located at higher levels, e.g. national or provincial hospitals, so skewed organisational trees are supported (e.g. a leaf node can be positioned at level 2 while most other leaf nodes are at level 5). Typically there is a geographical hierarchy defined by the health system. e.g. where the administrative offices are located (e.g. MoH, province, district), but often there are other administrative boundaries in the country that might or might not be added, depending on how its boundaries will improve data analysis. When designing the hierarchy the number of children for any organisational unit may indicate the usefulness of the structure, e.g. having one or more 1-1 relationships between two levels is not very useful as the values will be the same for the child and the parent level. On the other extreme a very high number of children in the middle of the hierarchy (e.g. 50 districts in a province) might call for an extra level to be added in between to increase the usefulness of data analysis. The lowest level, the health facilities will often have a large number of children (10-60), but for other levels higher up in the hierarchy approx. 5-20 children is recommended. To few or too many children might indicate that a level should be removed or added. Note that it is quite easy to make changes to the upper levels of the hierarchy at a later stage, the only problem is changing organisational units that collect data (the leaf nodes), e.g. splitting or merging health facilities. Aggregation up the hierarchy is done based on the current hierarchy at any time and will always reflect the most recent changes to the organisational structure. Refer to the chapter on Organisation Units to learn how to create organisational units and to build up the hierarchy.

The Data Element is perhaps the most important building block of a DHIS 2 database. It represents the "WHAT" dimension, it explains what is being collected or analysed. In some contexts this is referred to an indicator, but in DHIS 2 we call this unit of collection and analysis a data element. The data element often represents a count of something, and its name describes what is being counted, e.g. "BCG doses given" or "Malaria cases". When data is collected, validated, analysed, reported or presented it is the data elements or expressions built upon data elements that describes the WHAT of the data. As such the data elements become important for all aspects of the system and they decide not only how data is collected, but more importantly how the data values are represented in the database, which again decides how data can be analysed and presented.

It is possible to add more details to this "WHAT" dimension through the disaggregation dimension called data element categories. Some common categories are Age and Gender, but any category can be added by the user and linked to specific data elements. The combination of a data element's name and its assigned category defines the smallest unit of collection and analysis available in the system, and hence describes the raw data in the database. Aggregations can be done when zooming out of this dimension, but no further drill-down is possible, so designing data elements and categories define the detail of the analysis available to the system (on the WHAT dimension). Changes to data elements and categories at a later stage in the process might be complicated as these will change the meaning of the data values already captured in the database (if any). So this step is one of the more decisive and careful steps in the database design process.

One best practice when designing data elements is to think of data elements as a unit of data analysis and not just as a field in the data collection form. Each data element lives on its own in the database, completely detached from the collection form, and reports and other outputs are based on data elements and expressions/formulas composed of data elements and not the data collection forms. So the data analysis needs should drive the process, and not the look an feel of the data collection forms. A simple rule of thumb is that the name of the data element must be able to stand on its own and describe the data value also outside the context of its collection form. E.g. a data element name like "Total referrals" makes sense when looking at it in either the "RCH" form or the "OPD" form, but on its own it does not uniquely describe the phenomena (who are being referred?), and should in stead be called "Total referrals from Maternity" or "Total referrals from OPD". Two different data elements with different meanings, although the field on the paper form might only say "Total referrals" since the user of the form will always know where these referrals come from. In a database or a repository of data elements this context is no longer valid and therefore the names of the data elements become so important in describing the data.

Common properties of data elements can be modelled through what is called data element groups. The groups are completely flexible in the sense that they are defined by the user, both their names and their memberships. Groups are useful both for browsing and presenting related data, but can also be used to aggregate data elements together. Groups are loosely coupled to data elements and not tied directly to the data values which means they can be modified and added at any point in time without interfering with the raw data.

All data entry in DHIS 2 is organised through the use of Datasets. A Dataset is a collection of data elements grouped together for data collection, and in the case of distributed installs they also define chunks of data for export and import between instances of DHIS 2 (e.g. from a district office local installation to a national server). Datasets are not linked directly to the data values, only through their data elements and frequencies, and as such a dataset can be modified, deleted or added at any point in time without affecting the raw data already captured in the system, but such changes will of course affect how new data will be collected.

A dataset has a period type which controls the data collection frequency, which can be daily, weekly, monthly, quarterly, six-monthly, or yearly. Both which data elements to include in the dataset and the period type is defined by the user, together with a name, short name, and code.

In order to use a dataset to collect data for a specific orgunit you must assign the orgunit to the dataset, and this mechanism controls which orgunits that can use which datasets, and at the same time defines the target values for data completeness (e.g. how many health facilities in a district expected to submit RCH data every month).

A data element can belong to multiple datasets, but this requires careful thinking as it may lead to overlapping and inconstant data being collected if e.g. the datasets are given different frequencies and are used by the same orgunits.

Once you have set up the data entry part of the system and started to collect data then there is time to define data quality checks that help to improve the quality of the data being collected. You can add as many validation rules as you like and these are composed of left and right side expressions that again are composed of data elements, with an operator between the two sides. Typical rules are comparing subtotals to totals of something. E.g. if you have two data elements "HIV tests taken" and "HIV test result positive" then you know that in the same form (for the same period and organisational unit) the total number of tests must always be equal or higher than the number of positive tests. These rules should be absolute rules meaning that they are mathematically correct and not just assumptions or "most of the time correct". The rules can be run in data entry, after filling each form, or as a more batch like process on multiple forms at the same time, e.g. for all facilities for the previous reporting month. The results of the tests will list all violations and the detailed values for each side of the expression where the violation ocurred to make it easy to go back to data entry and correct the values.

Indicators represent perhaps the most powerful data analysis feature of the DHIS 2. While data elements represent the raw data (counts) being collected the indicators represent formulas providing coverage rates, incidence rates, ratios and other formula-based units of analysis. An indicator is made up of a factor (e.g. 1, 100, 100, 100 000), a numerator and a denominator, the two latter are both expressions based on one or more data elements. E.g. the indicator "BCG coverage <1 year" is defined a formula with a factor 100, a numerator ("BCG doses given to children under 1 year") and a denominator ("Target population under 1 year"). The indicator "DPT1 to DPT3 drop out rate" is a formula of 100 % x ("DPT1 doses given"- "DPT3 doses given") / ("DPT1 doses given").

Most report modules in DHIS 2 support both data elements and indicators and you can also combine these in custom reports, but the important difference and strength of indicators versus raw data (data element's data values) is the ability to compare data across different geographical areas (e.g. highly populated vs rural areas) as the target population can be used in the denominator.

Indicators can be added, modified and deleted at any point in time without interfering with the data values in the database.

Standard reports in DHIS 2 is a very flexible way of presenting the data that has been collected. Data can be aggregated by any organisational unit or orgunit level, by data element, by indicators, as well as over time (e.g. monthly, quarterly, yearly). The report tables are custom data sources for the standard reports and can be flexibly defined in the user interface and later accessed in external report designers such as iReport or BIRT. These report designs can then be set up as easily accessible one-click reports with parameters so that the users can run the same reports e.g. every month when new data is entered, and also be relevant to users at all levels as the organisational unit can be selected at the time of running the report.

In the integrated GIS module you can easily display your data on maps, both on polygons (areas) and as points (health facilities), and either as data elements or indicators. By providing the coordinates of your organisational units to the system you can qucikly get up to speed with this module. See the GIS section for details on how to get started.

On of the easiest way to display your indicator data is through charts. An easy to use chart dialogue will guide you through the creation of various types of charts with data on indicators, organisational units and periods of your choice. These charts can easily be added to one of the four chart sections on your dashboard and there be made easily available right after log in. Make sure to set the dashboard module as the start module in user settings.

This is where you can create organisation units (from now on referred to as orgunits) and build up the orgunit hierarchy. Orgunits are added one by one as either root unit or a child of a selected unit. The left side menu represents the current organisational hierarchy and if you select a unit there you will see its children listed in the main list of orgunits in the middle of the screen. When an orgunit is selected in the left side menu you can also add new child units to it. To locate an orgunit in the hierarchy you can either navigate through the tree by expanding the branches (click on the + symbol), or search for it by opening the search field (click the green symbol above the root of the hierarchy). In search you can either search for the orgunit name or its code, both will only show exact matches (case-insensitive). To add a new orgunit first select its parent and then click on the Add new button in the top right corner of the list of orgunits. To add a new root orgunit make sure no orgunit is selected in the menu and click on "Add new". The details of adding a new orgunit are explained in Section 3.2.1.1, “Editing organisation units”.

Group sets can be understood as a flexible tool to add more categorisation to orgunits. Any number of group sets can be added, but as a default start all databases will have the two group sets "Type" and "Ownership". Using these group sets will simplify how reporting is done, and facilitate analysis through the use of tools such as Excel PivotTables.

While a group set like "Type" describes a measure dimension, the actual categories are represented by the groups, and the categorisation of an orgunit through the orgunit's group memberships. This can be understood as a parallel hierarchy of orgunits with the group set as the root ("Type"), the groups at level 2 (e..g "Clinic", "Hospital", "Dispensary"), and the actual orgunits at level 3. The group set can as such provide additional information and dimensionality to the data analysis as data is easily filtered, organised, or aggregated by groups within a group set.

For this aggregation to work without any duplication in the data some rules are necessary. A group set is always exclusive, which means that an orgunit cannot be member of more than one group in a group set. Therefore, when creating a new organisational unit, you will only be allowed to select a single organisational group membership for each group set. Furthermore it is possible to define whether a group set is compulsory or not, which will affect the completeness of the data when analysing data using group sets. Compulsory means that ALL orgunits must be member of a group in that group set.

We recommend that you approach the orgunit grouping in the following sequence (and one group set at a time):

It is important to keep in mind when using the "Organisational unit group" set function, that unless great care is taken, organisational units can be assigned to multiple groups of a group set. This can be checked through the "Data Integrity" module, which will report which organisational units are not members of a compulsory organisational unit group set, and which organisational units have been assigned to more than one member of a group set.

This function will allow you to add new and manage existing organisation groups and their memberships. It can be accessed by choosing Maintenance->Organisation units->Organisation Unit group from the main menu. To add a new orgunit group click on the "Add new" button in the top right corner of the list of groups.

Here you specify a contextual name for each level in the hierarchy, e.g. "Country", "Province", "District", "Health Facility", and these names will be used all over the application where levels are referred to. This page will take some time to load if the orgunit hierarchy is very big.

Here you can move orgunits around in the hierarchy by changing the parent of a selected orgunit. This process is done in three steps:

1. Select the orgunit you want to move (in the hierarchy in the left side menu) and click "Confirm" under the "Select an organisation unit to move" label.

2. Select the new parent orgunit (again by using the hierarchy in the left side menu). If no parent is selected then the orgunit will be moved up to root level (top of the hierarchy). Click on the "Confirm" button under the "Select the new parent organisation unit for the one to move" label.

3. Click on the "Move" button to apply your changes to the hierarchy.

Your changes will be immediately reflected in the left side menu hierarchy. At any time in the process (before hitting the Move button) you can click on the "Reset" button to unselect orgunit to move and the new parent.

Data elements form the basis of DHIS2. Data elements define what is actually recorded in system, e.g. number of immunisations or number of cases of malaria. The actual creation and definition of the data elements themselves are far beyond the scope of this manual to describe, but it is assumed that an administrator will be provided with a list of standardised data elements for inclusion into the DHIS2 system.

To access the data element maintenance module, choose Maintenance -> Data elements and Indicators -> Data element.

The ‘Filter by name’ will allow you to filter a range of data elements if you know either the full name of the data element, or just a part of it. Type the name into the search field and any matching data elements are displayed below. You can also choose ‘Filter by group/view all’ to narrow down a data element search within a particular data element group. In default mode, this field will display all the data elements in the application. The ‘Get PDF’ button can be clicked to generate a .pdf file of all the data elements. The 'Sort' button can be used to sort the data elements into alphabetical order.

To add a new data element, click the 'Add new' button. There are various options available from this page that allow the user to modify data elements already present in the database. Each of the options are described below in the "Editing data elements".

4.1.1.1. Editing data elements

Click the "Edit" button to modify the properties of a data element that has been previously defined.

• Name: Define the precise name of the data element in this field. Each data element must have a unique name.

• Short name: Typically, an abbreviation of the full data element name. This attribute is often used in reports to display the name of the data element, where there is limited space available.

• Alternative name: Allows the definition of an alternative name of the data element.

• Code: In many countries, data elements are assigned a code. This code can be entered in this field.

• Description: Allows a full textual description of the data element to be entered. The user should be as precise as possible, and include full information on how the data element is measured and what its meaning is.

• Active: Defines whether a given data element is active or not. Data elements marked as inactive, will not be displayed in the data entry screens.

• Domain type: Defines whether a data element is an aggregate or patient type of data element.

• Value type: Defines the type of data this data element will be used to record. Currently there are four options: number, text, yes/no (boolean), and date.

• Number type: In order to increase the robustness of data entry, DHIS2 supports several different number types. During data entry, users will be restricted to enter the defined number types only. Each of the available options are described below.

  1. Number: This number type supports any real value with a single decimal point, an optional negative sign, and no thousands separators.

  2. Integer: Any whole number (positive and negative), including zero.

  3. Positive integer: Any whole number greater than (but not including) zero.

  4. Negative integer: Any whole number less than (but not including) zero.

• Aggregation operator: Defines the default aggregation operation that will be used on this data element. Most data elements should have the "SUM" option set. This includes all data elements which should be added together. Other data elements, such as staffing levels, should be set to use the "AVERAGE" operator, when values along the time dimension should not be added together, but rather averaged.

• URL: A URL having an in-depth description of the data element can be entered in the ‘URL’ field. This could be for instance, a link to a metadata repository or registry that contains detailed technical information about the definition and measurement of the data element.

• Combination of categories: Defines which category combination the data element should have.

• Data element group sets: Click the check box to activate this option hen choose which data element group sets this data element should belong to. Available data element group sets are displayed din the upper window. Click the desired data element group set, then the "Add selected" button to add the data element to the group set. To remove a data element from a group set, click the data element group set in the lower list, and then click "Remove selected".

• Calculated: This option is available only when a data element is created.

  	Note
  	As of version 2.3, calculated data elements have been deprecated. Calculated data elements should therefore be implemented as indicators instead.

  Select the data elements that will be used to define the calculated data element, and then click "Add selected" to add them calculated data element composition list. Fill in the correct factor for the data element calculation component (defaults to 1). Component elements of the calculated data element can be removed from the definition by pressing the "Remove" button.

• Aggregation levels: The Aggregation Levels option allows the data element to be aggregated at one or more levels. When the user clicks on the Aggregation levels option, a drop down menu appears which displays available aggregation levels. The desired aggregation level is then selected by clicking the ‘Add Selected’ button. By default, the aggregation will start at the lowest assigned organisation unit. If e.g. Chiefdom is selected below it means that Chiefdom, District, and National aggregates will use Chiefdom (the highest aggregation level available) as the data source, and PHU data will not be included. PHU data will still be available for the PHU level, but not included in aggregations to the levels above. If District and Chiefdom are both selected then the District and National level aggregates will use District data as their source, Chiefdom will use Chiefdom, and PHU will use PHU. Read more about aggregation levels in the Reporting chapter i the section on data sources for reporting.

After making the required changes, click ‘Save’ to institute them. The ‘Cancel’ button aborts all changes made.

4.1.1.2. Data element translation

DHIS2 provides functionality to translate existing data elements into other languages. Simply press the translate button to get started. The following dialogue will appear.

The reference language is displayed in the upper right portion of the dialogue. Choose a locale to translate the data element into by selecting an option from the locale drop-down menu. Specify the name, short-name and description in the target language. Press "Save" to save your changes.

The "Details" section of this dialogue will allow you add a new locale if it is not already present in the database. There are two options:

• Language code

  Refers to the ISO 639-1 (two-letter code) language code. Refer to this web page for a detailed listing of language codes.

• Country code

  Refers to the ISO 3166-1-alpha-2 code. A complete listing is available here.

The combination of these two codes together, forms a "locale" code, which is composed of the combination of the location and language. A very comprehensive discussion of the technical standard (RFC 3066) is available here. This page provides a very comprehensive list of recognised locale codes.

Data element groups provide a mechanism for classifying related data elements into a common theme. For instance, two data elements "Measles immunisation" and "BCG Immunisation" might be grouped together into a data element group "Childhood immunisation". To access the data element group maintenance page, click Maintenance -> Data elements and Indicators -> Data Element Group.

Similar to the "Data element" maintenance page, data elements groups can be searched with by entering a search string in the "Filter by name" field.

To add a new data element group, click the "Add new" button and the following screen will be displayed:

Fill in the "Name" field and then select all data elements that should belong to the group from the left panel. Click the "Move selected" button to add the selected data elements to the data element group. Click the "Remove selected" button to remove all data elements from the group that have been selected in the right panel. Finally, click the "Add" button to save changes, or the "Cancel" button to discard any changes.

The data element group editor provides advanced functionality to the administrator to allow multiple data elements to be added or removed from a group. It is also possible to create new data element groups, rename existing groups, and delete groups entirely. To access the data element group editor, go to "Maintenance -> Data elements and Indicators -> Data Element Group Editor". The following screen will appear.

Data element groups area listed alphabetically in the leftmost panel. By clicking on a data element group, the current members of that group (data elements) are listed in the centre panel. Available data elements that can be added to the data element group appear are listed alphabetically in the rightmost panel. To remove an existing data element from the group, click the name of the data element in the centre panel, and then press the "Move right" button. To add data elements to the group, select them from the leftmost panel, and click the "Move left" button. Press the "Update data element group member" button to save your changes.

Data element group sets allow multiple data element groups to be categorised into a set. Data element group sets are used during analysis and reporting to combine similar data element groups into a common theme. To access the data element group set maintenance module, choose "Maintenance -> Data elements and Indicators -> Data Element Group Set". Similar to the other data element maintenance modules, new data element group sets can be added by pressing the "Add new button". Other operations include Edit, Translate, Delete and Information, similar to the other modules in this section.

Existing data element group set members can be edited by clicking the "Edit" button of the desired data element group set as seen below.

Available data element groups are displayed in the left panel. They can be moved into the selected data element group set by pressing the "Move right" button. Data element groups that are currently members of the data element group set are displayed in the right hand panel. They can be removed from the data element group set by clicking the desired data element group and pressing the "Move left" button. The ordering of the data element groups can be set with the "Move Up" and "Move Down" arrows. This ordering will be used in the datamart and reports to order the data element groups. Press the "Update" button to save any changes and the "Cancel" button to discard all changes.

Data element categories can be used to disaggregate data elements into individual atomic components. Data element categories are typically a concept, such as Gender, Age or Disease Status. Data elements such as "Number of cases of confirmed malaria" are often broken into smaller component parts to determine, for instance, the number of confirmed malaria cases of particular age groups. As an example, three data element categories: Under 1, 1-5 and Over 5 could be created. They could be assigned as categories to the data element, which would then create in the data entry screens, three separate fields for this data element namely:

Effective use of data element categories greatly simplifies the process of setting up the DHIS2 system, as the data element categories can be reused to disaggregate many different data elements. Otherwise, each of the data elements listed above, would need to be created separately. Judicious use of data element categories will greatly simplify the DHIS2 implementation, and allow for subsequent advanced analysis.

Data element categories are composed of category options. Category options must be defined when a data element category is created for the first time. Subsequent changes to the data element category, i.e. adding or deleting new category options, are not allowed once the data element category has been created.

It is critical that the proper categories and category options are defined in the initial definition step, as further changes to the category and its options will are not possible.

To access the data element category maintenance module, press "Maintenance -> Data Elements and Indicators->Data Element Category". The following screen will be displayed:

Similar to the other data element maintains modules, data element categories can be filtered by typing the name of the data element category (or a portion of it) into the "Filter by name" field. To add a new data element category, press the "Add new" button which will then display the following screen:

Type the name of the new data element category in the "Name" field in the "Details" region. Category options can be added by typing the name of the category option in the "Category option" region and pressing the "Add category option" button. Category options can be reordered using the "Move Up" and "Move Down" buttons. Categories options can be deleted by selecting the data element category option and pressing the "Delete" button. Once all data element categories options have been added to the data element category, press the "Add" button to save all changes or the "Cancel" button to discard any changes.

All data element category options must be added and defined properly in this step. Subsequent alterations to the data element category (other than reordering of the category options themselves) is not possible.

Data element category combinations allow multiple data element categories to be combined into a related set. As an example, a data element "Number of new HIV infections" might be disaggregated according to the following categories.

In this example, there would be two levels of disaggregation, consisting of two separate data element categories, each consisting of several data element category options. In most HMIS systems, different data elements are disaggregated according to a common set of categories. By combining these different categories into a data element category combination and assigning these combinations to data elements, the appropriate disaggregation levels can be applied efficiently and quickly to a large number of data elements.

To access the data element category combination maintenance module, select "Maintenance->Data element and indicators->Data element category combinations" from the main DHIS2 menu. As with the other maintains modules, you can filter the listed category combinations by entering the name (or portion thereof) of the category combination. Other operations such as "Edit", "Delete" and "Information" should be familiar to the reader.

To add a new category combination, click the "Add new" button. The following dialogue will be displayed.

Type the name of the category combination in the "Name" field, and then select the desired categories from the left panel. Press the "Move right" button to add the selected categories to the category combination. Press "Move left" to remove any categories that should not be part of the category combination.

Categories can only be added to a category combination at this step. Categories can be removed from category combinations later by editing the category combination, however, it is not allowed to add additional categories once the combination has been created. Ensure that the category combination and its respective categories is final before you create the category combination and assign it to a data element.

Data dictionaries are used to group data elements and indicators during filtering operations. They are useful for combining related groups of data elements and indicators according to the programs to which they belong. For instance a data dictionary called "MCH" could be created, and all maternal and child health data elements and indicators could be added to the dictionary. The data dictionary can be access by choosing Maintenance->Data elements and indicators->Data dictionary. The following screen will be displayed in the browser.

Provide a name for the data dictionary in the "Name" field and a description of its contents. Data elements and indicators can be added or removed from the dictionary. Click "Save" if you are creating a new data dictionary or "Add" if you are editing the contents of an existing data dictionary.

DHIS 2 provides functionality for translations of database content like data elements, data element groups, indicators, indicator groups, validation rules and more. These elements can be translated to any number of locales. A locale represents a specific geographical, political, or cultural region.

To add a translation click the Translate icon next to the element you would like to translate. Start by selecting the desired locale from the Locale select box. In the Translate screen, select your locale and enter values for the avaliable element properties. The reference property values are shown on the right. These values are the values which have been entered in the regular add or update user interface for the current object.

Translations can be enabled by selecting the desired locale under Database Language under User General Settings in the Settings module.

The dataset management function allows you to create new datasets and manage existing ones. The dialog can be reached by choosing Maintenance->Datasets->Dataset. A sample dialog is displayed below.

Section forms allow for a bit more flexibility when it comes to using tabular forms and are quick and simple to design. Often your data entry form will need multiple tables with subheadings, and sometimes you need to disable (grey out) a few fields in the table, both of these functions are supported in section forms. This function can be access by choosing Maintenance->Dataset Section.

Section forms are separated automatically by data element category combinations, which produce a spreadsheet like data entry form for each section.

When designing a section form the procedure is as follows:

A sample section form is displayed in the next figure. Notice how each data element category has been separated into a separate section, and a data entry table has been automatically generated by the system. Use of section forms in combination with data element categories can drastically reduce the amount of time which is required to create data entry forms for datasets.

When the form you want to design is to complicated for the default or section forms then your last option is to use a custom form. This takes more time, but gives you full flexibility in term of the design. DHIS2 uses a built-in HTML editor (FcK Editor) for the form designer and you can either design the form in the UI or paste in your HTML directly (using the Source window in the editor). A complete reference for use of the editor can be found here.

One of the big advantages of custom forms, is that they can be created to mimic existing paper aggregation forms. This makes data entry much easier for users, and should reduce the number of data elements which are incorrectly entered, as they are more easily identifiable when entering data from a paper form.

Once a custom form has been added to a dataset it will be available in data entry and used automatically.

	Note
	Custom forms are preferentially displayed over section forms. If a dataset has both a section form and a custom form, the custom form will be displayed during data entry. Users will not be able to select which method they wish to input data, so be sure that your custom form contains all data elements which may be required.

To add a custom form design to a dataset then first locate your dataset in the Dataset Management window and click on the Design data entry form icon under Operations (the fifth icon), see the mouse-over text to be sure.

First provide a Name for the form. There are a few important buttons in the Editor that you must pay special attention to. The blue monitor icon is the full screen mode on/off button, which can be very useful. The there is a Source button that shows the HTML code for your form.

If you already have the HTML for your form then you should start by pasting it in here. Click on Source again to go back to preview/non-HTML mode. Then there is an icon in the top right corner with a + sign on it, this will open a list of available data elements to add to your form, the Data Element Selector window.

All the input fields need to have a link to a data element or indicator. To add new data elements to the form, double-click them from the data element/indicator box as shown below. You can also select a data element/indicator and press the "+Insert" button. You can switch between either data elements or indicators by pressing the respective buttons.

You can to intermediary saving by clicking on the Save button, and this will not close the window. It is recommended to save often to ensure you do not loose your work.

When you are done or want to test your form in data entry click on <Save and close>.

The data set assignment editor is a tool for adding and removing many data sets to organisation units in batch style. Start by selecting an organisation unit from the selection tree. In the area below the tree a grid will be displayed showing all data sets as columns and the child organisation units as rows.

From the grid you can now assign or unassign data sets simply by clicking on of the corresponding icons in the grid. If you want to assign or unassign an organisation unit to all data sets you can check or uncheck the checkbox next to the organisation unit. Your changes will automatically be saved.

User names already registered will appear as a list as seen in the screen shot below.

You can search for specific user names in the user list by entering the name in the ‘filter by user name’ field as shown above.

As part of creating a user name you are required to define the user role. Do so by clicking on the ‘user role’ appearing on the left side of the displayed screen. This will lead you to the Role Management page where you will have to click on Add new to create a new role.

The following screen will open and here in the first text box you need to give Name of the Role such as Super User, Admin User, etc. The second text box called ‘Description’ gives more information about the type of User Role that is being created for e.g. State Admin User, District Data Entry.

Next you will specify the particular data set(s) that are to be made available to the particular role. You will also need to specify the type of ‘authority’ to be given to the particular user. For each of the three options namely Datasets, Reports and Authorities user can select multiple options from the scroll down menu provided against each field. A user can choose multiple options either by moving them one-by-one.

In order for particular users to be able to enter data, you must add them to both a dataset as well as an organisational unit level. You can also select multiple datasets individually by pressing the Ctrl key on the keyboard and clicking on individual datasets.

Finally when you have entered the required fields click on Save which is located on the lower part of the displayed screen. The desired user role and related authorisation will be saved to the database, and can then be assigned to a particular user.

Under particular user role there can be more than one user. To add new users go to the User options under the Maintenance module.

To add a new user, just follow these steps:

User groups allow you to send notifications to multiple users at the same time. Simply click "Add new" from the "User group" screen, provide a name for the group, and add the desired users from the "Available users" list to the "Group members" list.

The "User by organisation unit" function allows you see which users have been assigned to a particular organisation unit. Simply select the organisation unit from the tree on the left, and a list of users which have been assigned to this particular organisation unit will be displayed

To start entering data the first step is to open the correct form. Follow these steps:

By now you should see the data entry form.

Depending on how the data entry form has been implemented, you will see three different types of foms: Default forms, section forms, or custom forms. If a custom form exists, it will be displayed, followed in order of precedence by a section form, and finally a default form.

Simply start entering data by clicking inside the first field and type in the value. Move to the next field using the Tab button. Shift+Tab will take you back one step. The values are saved immediately and do not require any save/finished button click. A green field indicates that the value has been saved in the system (on the server). On a slow connection it might take some time before the values are saved.

Input validation: If you type in an invalid value, e.g. a character in a field that only accepts numeric values you will get a pop-up that explains the problem and the field will be coloured yellow (not saved) until you have corrected the value. If you have defined a min/max range for the field (data element+organisation unit combination) a pop-up message will notify you when the value is out of range, and the value will remain unsaved until you have changed the value (or updated the range and then re-entered the value).

Disabled fields: If a field is disabled (grey) it means that the field should not be filled. The cursor will automatically jump to the next open field.

Data history: By double-clicking on any input field in the form a data history window opens showing the last 12 values registered for the current field (organisation unit+data element+categoryoptioncombo) in a bar chart. This window also shows the min and max range and allows for adjusting the range for the specific organisation unit and data element combination.

Follow Up: In the data history window there is also a feature to tag or star a value. E.g. a suspicious value that needs further investigation can be kept in the system, but marked for Follow-Up. In the Data Quality module you can run a Follow-Up analysis and view all values marked for Follow-Up, and then later edit the values if proved incorrect.

When all the available values for the form has been filled in you can run a validation check on the data in the form. Click on the "Run Validation" button in the top right corner. All validation rules which involves data elements in the current form (dataset) will be run against the new data. Upon completion you will be presented with a list of violations or a simply a message that says "The data entry screen successfully passed validation". See the Data Quality chapter for information on how to define such validation rules.

When you have corrected any erroneous values and are done with the form the recommended practice is to click on the Complete button below the form to register the form as complete. This information is used when generating completeness reports for district, county, province or the national level.

The data entry module will function even if during data entry the Internet connectivity is not stable. In order to utilize this functionality, you must login to the server while the Internet is functional, but if during data entry, the Internet link between your computer and the server becomes unstable, data can still be entered into the data entry form, saved to your local computer, and then pushed to the server once the Internet connectivity has been restored. Data can be entered and stored locally while being offline and uploaded to the central server when on-line. This means that the on-line deployment strategy will be more viable in areas with unstable Internet connectivity. The total bandwidth usage is greatly reduced since forms no longer are retrieved from the server for each rendering.

When the server is able to be reached through the Internet connection, a message is displayed at the top of the data entry screen below.

If the Internet connection should disconnect for some reason during the data entry process, this will be detected by the application, and you will be informed that your data will be stored locally.

Data entry can proceed as normal. Once you have entered all of the necessary data, and the application detects that the server is back on-line, you will be informed that you have data which needs to be synchronized with the server.

Once the data has successfully synchronized with the server, you will receive a confirmation message that the data has been successfully uploaded to the server.

If you are using the default entry screen click on the element for which you want to set the min-max value. A pop-up window will appear in which you can enter the vaules. On subsequent data entry if the value entered does not fall within the set min-max range the text box will change colour to red. The user will also get a pop-up as shown below. This change in colour is a prompt to check the data entered and make necessary correction. On the data entry screen the users also have the option to add a comment on how the discrepant figure might be explained (if required). This you can do by using the drop down menu of the ‘comment’ box. In case you are using the custom data entry screen which is displayed when you deselect the ‘default data entry form’ option on the top right corner of the screen. In this case the minimum and maximum values can be added by double-clicking on the data entry box instead of the data element.

It is possible to generate the min-max value, element-wise, using the DHIS2. In such case you merely need to click on the ‘Generate min-max’ button near the upper right corner. In case of default data entry screen the min and max values, when generated, will appear on the left and right side of the data entry box. In case you deselect the default data entry form the generated values will appear on the top right end of the screen.

Indicators are composed of multiple data elements, and typically consist of a numerator and denominator. Indicators are never entered in DHIS2, but are derived from combinations of data elements and factors. Indicators are used to calculate coverage rates, incidence and other values are are a result of data element values that have been entered into the system.

To access the Indicator maintains page, press Maintenance -> Data Element and Indicators -> Indicator from the main DHIS2 menu. Similar to data elements, you can add, delete, modify and view extra information about the indicators in the system.

Indicators can be filtered by entering the name or a part of the indicator name in the "Filter by name" field. Similar to data elements, indicators can be added by pressing the "Add new" button. Other operations available from this menu are as follows.

To add a new indicator, click the "Add new" button. The following screen is displayed.

Each of the fields marked with an asterisk are compulsory. A description of each field is provided below.

To define the numerator and denominator, simply press the respective button, and the following dialogue will be displayed.

Essentially, an indicator is a formula that can be composed of multiple data elements, constant factors, and mathematical operators. In order to define a new indicator proceed with the following steps.

Indicator types simply define a factor that will be applied during aggregation. Indicator values that are calculate during a data mart export or report table generation process will appear properly formatted, and will therefore not require an additional multiplier (e.g. 100 in the case of percents) for the values to appear correctly formatted.

The indicator type maintenance panel has all of the same functions (Add new, Edit, Translate, Delete, and Information) as the Indicator maintenance section.

There are only two fields that need to be filled-in to create an indicator type, Name and Factor, as seen below. Name refers to the Indicator type (e.g. Per cent, Per thousand, Per ten thousand, etc). The factor is the numeric factor that will be applied during the calculation of the indicator.

Note

As of version 2.4 of DHIS2, the "Calculated data element" object has been deprecated. Instead, a calculated data element can be created by creating an indicator type with a factor of "1" and by setting the "Number" option to "Yes". The effect of setting the "Number" option to "Yes" will be that the indicator will effectively not have a denominator. You will therefore only be able to define a numerator, which will serve as the formula of the calculated data element.

Indicator groups function essentially the same as data element groups. Multiple indicators can be assigned to a group for easy filtering and analysis. To assign indicators to groups, simple press Maintenance->Data elements and indicators->Indicator groups. See the section on Data element groups for detailed instructions of how to use this module.

The indicator group editor module functions essentially the same as the data element group editor module, except on indicators. You can easily rearrange the groups that indicators belong to with this module. To access it, choose To assign indicators to groups, simple press Maintenance->Data elements and indicators->Indicator group editor from the main menu. See the section on Data element group editor for further instructions.

Similar to data element group sets, indicator group sets serve to create combined groups of similar indicators. For instance, you might have a group of indicators called "Malaria" and "Leishmaniasis". Both of these groups could be combined into a group set called "Vector-borne diseases". Indicator groups sets are used during analysis of data to combine similar themes of indicators. To access this module choose Maintenance->Data elements and indicators->Indicator group sets from the main menu. The following dialogue will appear.

Supply a name for the indicator group set, and then move the desired members from the "Available Indicator Groups" to the "Group members". Click "Add" to save your changes and "Cancel" to discard any changes.

In the bigger picture of HIS terminology all data in DHIS are usually called aggregated as they are aggregates (e.g. monthly summaries) of medical records or some kind of service registers reported from the health facilities. Aggregation inside DHIS however, which is the topic here, is concerned with how the raw data captured in DHIS (through data entry or import)are further aggregated over time (e.g. from monthly to quarterly values) or up the organisational hierarchy (e.g. from facility to district values).

The purpose of the data mart is to provide pre-processed data to external data analysis and reporting tools. The data mart consists of two tables, aggregateddatavalues and aggregatedindicatorvalues in the DHIS 2 database. The values in the data mart are aggregated versions of the raw data found in the datavalue table as well as calculated indicator values. Aggregation can take place over time (e.g. from monthly data to aggregated quarterly values), or along the organisation unit hierarchy levels (e.g. from PHU data to aggregated district totals). The data mart can store all kinds of such aggregated values. The data mart is as such just a processed 'copy' of the data values and it can be emptied and regenerated at any time, and the tables are read only tables. The metadata in the two data mart tables are referenced by internal identifiers, such as dataelementid, organisationunitid which refer to the tables like dataelement and organisationunit, see 'How to make use of the data mart in external tools' for more on this.

13.1.2.1. The data mart export process

The DHIS2 Data Mart handles the aggregation of data across multiple dimensions (organisation unit hierarchy, orgunit group hierarchy, time, etc) and can be controlled through this interface. Select the organisation unit levels which should be aggregated, the start date and end date, and press "Start export". The data mart process will be executed in the background, and a full report of the export process will be updated regularly so that you can determine the state of the process. See the section on "Scheduling" in the data administration module for information on how this process can be triggered to run automatically.

13.1.2.1.1. Data element categories in the data mart

Each data value for a data element has a reference to a category option combo, which is a combination of the disaggregations for the data value, e.g. (male,<5y) or (In PHU, <1y). These disaggregations are exported as they are to the data mart, and no aggregation is done on this dimension. See the data elements section for more on data element categories and the resource tables section for more information on how to do aggregation on these categories.

13.1.2.1.2. Adding new data to an existing data mart

When you add new data to an existing data mart the new values will be appended to the existing so that the data mart grows for each new process if new selections (such as new periods) have been made. If any of the selected values are already in the data mart, then the old will be replaced by the newly generated values.

Resource tables provide additional information about the dimensions of the data in a format that is well suited for external tools to combine with the data mart tables. By joining the data mart with these resource tables one can easily aggregate along the data element category dimension or data element/indicator/organisation unit groups dimensions. E.g. by tagging all the data values with the category option male or female and provide this in a separate column 'gender' one can get subtotals of male and female based on data values that are collected for category option combinations like (male, <5) and (male,>5). See the Pivot Tables section for more examples of how these can be used. orgunitstructure is another important table in the database that helps to provide the hierarchy of orgunits together with the data. By joining the orgunitstructure table with the data mart tables you can get rows of data values with the full hierarchy, e.g. on the form: OU1, OU2, OU3, OU4, DataElement, Period, Value (Sierra Leone, Bo, Badija, Ngelehun CHC, BCG <1, Jan-10, 32) This format makes it much easier for e.g. pivot tables or other OLAP tools to aggregate data up the hierarchy.

Report tables are defined, cross-tabulated reports which can be used as the basis of further reports, such as Excel Pivot Tables or simply downloaded as an Excel sheet. Report tables are intended to provide a specific view of data which is required, such as "Monthly National ANC Indicators". This report table might provide all ANC indicators for a country, aggregated by month for the entire country. This data could of course be retrieved from the main datamart, but report tables generally perform faster and present well defined views of data to users.

	Important
	It is therefore important to keep in mind that when the aggregation strategy of the system is set to "Batch", the data for each report table must also be present in the data mart.

Cross tab dimensions

You can cross-tab one or more of the following dimensions: data element/indicator, orgunit, and period, which means that columns will be created based on the values of the dimensions chosen, e.g. if indicators is selected you will get column names in the table reflecting the names of the selected indicators.

For example, if you cross-tab on indicators and periods, the column headers will say "<indicator title> <period>". The organisation units will be listed as rows. See screenshot for clarification:

If you cross-tab on indicators and organisation units, the column headers of the table will say "<indicator title> <organisation unit>". Now the periods will be listed as rows. See screenshot for clarification:

Note that the options made here regarding crosstab dimensions may have consequences for what options are available when using the report table as a data source later, for example for standard reports.

Sort order

Affects the rightmost column in the table, allows you to choose to sort it low to high or high to low.

Top limit

Top limit allow you to set a maximum number of rows you want to include in the report table.

Include regression

This adds additional columns with regression values that can be included in the report design, e.g. in line charts.

Indicators/Data elements

Here you select the data elements/indicators that you want to include in the report. Use the group filter to more easily find what you are looking for and double click on the items you want to include, or use the buttons to add/remove elements. You can have both data elements and indicators in the same report.

Data sets

Here you select the data sets that you want to include in the report. Including a data set will give you data on the data completeness of the given set, not data on its data elements. Double click on the items you want to include, or use the buttons.

There are two ways to select both what organisation units to include in a report, and what time periods should be included: relative, or fixed. Fixed organisation units and/or periods means that you select the units/periods to include in the report table when you create the report table. Using relative periods, you can select the time and/or units as parameters when the report table is populated, for example when running a standard report or creating a chart. A combination is also possible, for example to add some organisation units in the report permanently while letting the users choose additional. Report parameters is discussed below. In general, using fixed organisation units and/or time periods are an unnecessary restriction.

Fixed Organisation Units

To add fixed organisation units, click "Toggle fixed organisation units". A panel will appear where you can choose orgunits to always include in the report. If you leave it blank, the users select orgunits when running the report through the use of report parameters. Use the drop down menu to filter organisation units by level, double click or use the buttons to add/remove.

Fixed Periods

To add fixed periods, click "Toggle fixed organisation units". A panel will appear where you can choose periods to always include in the report. If you leave it blank, the users select periods when running the report through the use of report parameters. Use the drop down menu to choose period type (week, month, etc), the Prev and Next button to choose year, and double click or use the buttons to add/remove.

Relative periods

Instead of using fixed/static periods like 'Jan-2010' or 'Q1-2010', more generic periods can be used to create reusable report tables, e.g. for monthly reports the period 'Reporting month' will simply pick the current reporting month selected by the user when running the report. Note that all relative periods are relative to a "reporting month". The reporting month is either selected by the users, otherwise the current month is used. Here is a description of the possible relative periods:

Example - relative periods

Let's say we have chosen three indicators: A, B and C, and we have also chosen to use the relative periods 'Reporting month' and 'This year' when we created the report table. If the reporting month (selected automatically or by the user) is for example May 2010, the report table will calculate the values for the three selected indicators for May 2010 (= the 'Reporting month') and the accumulated values for the three selected indicators so far in 2010 (= so far 'This year').

Thus, we will end up with six values for each of the organisation units: "Indicator A May 2010", "Indicator B May 2010" "Indicator C May 2010", "Indicator A so far in 2010", "Indicator B so far in 2010" and "Indicator C so far in 2010".

Report parameters

Report parameters make the reports more generic and reusable over time and for different organisation units. These parameters will pop up when generating the report table or running a report based on the report table. The users will select what they want to see in the report. There are four possible report parameters, and you can select none, all, or any combination.

Example - report parameters

Continuing with the example on relative periods just above, let's say that in addition to 'Reporting month', we have chosen 'Parent organisation unit' as a report parameter when we created the report table. When we're running the report table, we will be asked to select an organisation unit. Now, let's say we choose "Region R" as the organisation unit. "Region R" has the children "District X" and "District Y".

When the report is run, the system will aggregate data for both "District X" and "District Y". The data will be aggregated from the lowest level where they have been collected. The values for the districts will be aggregated further to give an aggregated value for "Region R".

Thus, the report table will generate the six values presented in the previous example, for "District X", "District Y" and "Region R".

These tables enable the use of data element categories in report tables. There are two differences from regular report tables. The first is that it is not possible to select crosstab dimensions, as the columns will always be the disaggregations from the category combinations. The other is the actual choice of data. Only one category combination can be added per report, and only data elements from the same category combo can be selected.

Subtotals and the total will also be included in the table, e.g. a gender (male, female) + EPI age(<1, >1) category combo would give the following columns: male+<1, male+>1, Female+<1, female+>1, male, female,<1, >1, total.

Selecting data

Use the drop down menu to choose category combinations. The data elements using this category combination will be listed. Double click to add to the report, or use the buttons.

To make the report tables reusable over time and across orgunits they can have parameters. Four types of parameters are allowed; orgunit, parent orgunit (for listing of orgunits in one area), grand parent orgunit and reporting month. As a side note it can be mentioned that we are looking into expanding this to include reporting quarter and year, or to make that period parameter more generic with regard to period type somehow. The ability to use period as a parameter makes the report table reusable over time and as such fits nicely with report needs such as monthly, quarterly or annual reports. When a report is run by the user in DHIS 2, the user must specify the values for the report tables that are linked to the report. First the report table is re-generated (deleted and re-created with updated data), and then the report is run (in the background, in Jasper report engine).

Report tables can consist of values related to data elements, indicators or data completeness, which is related to completeness of reporting across orgunits for a given month. Completeness reports will be covered in a separate section.

There are three dimensions in a report table that identify the data; indicators or data elements, orgunits and periods. For each of these dimensions the user can select which metadata values to include in the report. The user must select one or more data elements or indicators to appear in the report. The orgunit selection can be substituted with a parameter, either one specific orgunit or an orgunit parent (making itself and all its children appear in the report). If one or more orgunits are selected and no orgunit parameter is used, then the report is static with regard to which orgunits to include, which in most cases is an unnecessary restriction to a report.

Using relative periods

The period selection is more advanced as it can in addition to specific periods like Jan-09, Q1-08, 2007 also contain what is called relative periods. As report usually is run routinely over time a specific period like Jan-09 is not very useful in a report. Instead, if you want to design a monthly report, you should use the relative period called Reporting Month. Then you must also include Reporting Month as one of your report parameters to let the system know what exactly is the Reporting Month on the time of report generation. There are many other relative periods available, and they all relate to the report parameter Reporting Month. E.g. the relative period called So far this year refers to the accumulative value for the year incl. the Reporting Month. If you want a trend report with multiple periods in stead of one aggregated period, you can select e.g. 'Months this year', which would give you values for each month so far in the year. You can do a similar report with quarters. The idea is to support as many generic report types as possible using relative periods, so if you have other report needs, please suggest new relative periods on the mailing list, and they might be added to the report table options.

Cross-tabbing dimensions

Cross tabbing is a very powerful functionality in report design, as the typical DHIS 2 data table with references to period, data element/indicator and orgunit makes more advanced report design very difficult, as you cannot put e.g. specific indicators, periods or orgunits on specific columns. E.g. by cross-tabbing on the indicator dimension in an indicator report table you will get the indicator names on the column headers in your report, in addition to a column referencing orgunit, and another column referencing period. With such a table design you could drag and drop indicator names to specific columns or chart positions in the iReport software. Similarly you can cross tab on orgunits or periods to make their names specifically available to report design. E.g. by cross-tabbing on periods and selecting the two relative periods 'Reporting month' and 'This year', you can design reports with both the last month and the accumulative annual value for given month as they will be available as column headers in your report table. It is also possible to combine two dimensions in cross-tabbing, e.g. period and indicator, which makes it possible to e.g. look at three selected indicators for two specific relative periods. This would e.g. make it possible to make a table or chart based report with BCG, DPT3 and Measles coverage, both for the last month and the accumulative coverage so far in the year.

All in all, by combining the functionality of cross tabbing, relative periods and report table parameters you should have a tool to support most report scenarios. If not, we would be very happy to receive suggestions to further improvements to report tables. As already mentioned, we have started to look at more fine-grained parameters for the period dimension as the 'Reporting month' does not cover enough, or at least is not intuitive enough, when it comes to e.g. quarterly reports.

A standard report is a manually designed report that presents manually chosen data in a manually specified layout. Still, it's highly flexible, as it can be designed to be reused over and over again, by making use of the powerful report tables.

A standard report can present any value from any table in the DHIS 2 database, but for the report design, we want the reports to be flexible, so we want to connect the reports to tables that changes through time. The report tables are therefore ideal for the report design.

Jasper iReport Designer is a tool for creating reports that can be used as Standard Reports in DHIS 2. The tool allows for the creation of standard report templates that can easily be exported from DHIS 2 with up to date data. The process of creating reports involves four major steps:

If you want to preview your report during the design in iReport, you actually have to upload your file to DHIS 2 to see how it looks.

These four steps will be describe in detail in the coming sections. In general, when you are making standard reports you should have a clear idea of how it should look before you even make the report table, as how the report table is designed has implications for how the report can be formatted in iReport. For example, what crosstab dimensions are selected in the report table has consequences for what crosstabs are available for the standard report, and it has consequences for what types of charts you can make.

13.4.2.2. Editing the report

You are now ready to edit the layout of the report. The main iReport window consists of a "Report Inspector" to the left, the report document in the middle, a "Palette" area on the upper right hand side and a "Properties" area on the lower right hand side. The "Report Inspector" are used for selecting and examining the various properties of the report, and when selecting an item in the inspector, the "Properties" panel changes to display properties relating to the selection. The "Palette" is used for adding various elements, e.g. text boxes, images and charts to the document.

Note: If you cannot see the Palette or Properties sidebar, you can enable them from the menu item called "Window" on the menu bar.

The iReport document is divided into seven main bands, divided by layout separators (the blue lines). These lines are used to decide how big each of the areas should be on the report.

The areas all have different purposes:

• Title - area for the title of the report

• Page header - area for the page header

• Column header - area for column headers (for the table)

• Detail 1 - area where the actual report data will be placed

• Column footer - area to make footer of the table

• Page footer - area for the page footer

• Summary - elements in this area will be placed at the end of the report

By default you will see that only the Title, Column Header and the Detail 1 bands have data. For most reports this is OK. The Title band is suitable for a title and e.g. a chart. Data fields entered into the Detail 1 area will be iterated over to create a table. For example, if a field called "datalementname" is placed in the Detail 1 band, all data elements in the report table will be listed here. We'll come back to data fields management just a little below.

The unused bands in the report are shrinked to add more space for your report data. You can however increase/decrease the band height as you like. There are two ways to do that. The first way is simply to drag the blue band-line as shown below.

The other way to adjust the band height is to select a band in the "Report Inspector", and then adjust the "Band height" value in the "Detail 1 - properties" area in the lower right corner.

As the fields are already present on the report, you probably don't want to do anything than just fix the layout and drag fields around. You can also resize the fields by dragging the side, top or bottom lines. If you want to change the text in the column headers, you simply double click the field and change the text.

To add the a field to the table, we simply drag it to the Detail 1 band from the "Report Inspector". The column header will be added automatically.

By double clicking the box, the text can be edited. The format of the text, such as size, font and alignment, can be adjusted with the tools above the document.

NOTE: Fields starting with "$F" present values that are retrieved from the database every time the report is run. The values here will vary, so do not change these fields unless you want a static value here!

13.4.2.3. Text

There are two types of text in iReport: «Text labels» and «Text fields» (data fields). They work in different ways, and should be used for different purposes. The main point is that text fields are just placeholders that will be filled with the correct text from the report table when the report is run, while text labels will stay the way they are when the report is run.

13.4.2.3.1. Static text

Static text are text plain text labels that can be edited normally. There are two ways to edit text labels:

• By double clicking in the text box

• By using the Static text properties in the Properties panel

13.4.2.3.2. Text fields

Text fields are formulas that will be filled from the report table when the report is run. Unlike static text, these can not be edited in a normal way. However, they can be manipulated in various ways to ensure that the desired output will be produced. There are three ways to edit the text fields:

• By right clicking on the text box and selecting Edit expression

• By double clicking the text field (not recommended, as this will not bring up the expression editor)

• By using the Text field properties in the Properties panel

Text fields can represent either numbers or text, so that they can be used both for showing for example names of district or for numeric values. It is therefore important the the Expression class, seen in the Text field properties matches the Text field expression. For the default text fields in the .jrxml file downloaded from DHIS 2 this is not a problem, but it is important when making new text fields. The two most important Expression classes are java.lang.Double for numbers and java.lang.String for text.

13.4.2.3.2.1. Example

For example, let us say you have a quarterly report where you would like to add a new column with the yearly total. You therefore add a new Static text field to the column header band, and a Text field to the details band in. By default, new Text fields are set to java.lang.String (text). However, the yearly total column will be filled with numbers. We therefore have to change the Expression class for the new text field to java.lang.Double:

When we edit the text field expression, we see the Expression editor window with all the available columns from the report table. We can see here that each of these are marked with what type they are - text or number. What we need to make sure of is therefore that the expression class we choose for the text field matches the actual expression.

13.4.2.4. Filtering the table rows

In the default table exported from DHIS 2, there are some rows that it might be better to leave out of the table, and some that it would be preferable to have at the end. For example, when making a table based on a report table with the «parent organisation unit» parameter, the default table might have a row with the national level somewhere in between all the regions. In iReport, this can be changed so that the «parent organisation unit» appears at the bottom of the table. This involves two steps that will be explained below. Note that this will not work where there is only one organisation units, and it is therefore most useful when using the «parent organisation unit» or «grand parent organisation unit» parameters in the report table.

13.4.2.4.1. Hiding the «parameter organisation unit» from the table

We exclude the "paramter organisation unit" from the table by using a property in the Details band called "Print when expression". To set a Print when expression, start by selecting the Detail band in the Report inspector, then edit the Print when expression in the properties panel.

The Expression editor window should now appear. What we must do is to create an expression that checks if the row being generated is the row with the organisation unit given as a parameter. The report table contains a column that we can use for this called organisation_unit_is_parent. To exclude the row with the parameter organisation unit, double click on organisation_unit_is_parent in the list to copy it to the expression area, then add .equals("No") at the end so that the code is:

$F{organisation_unit_is_parent}.equals("No")

This tells the report engine to only print table rows where the organisation unit is not the parent organisation unit.

13.4.2.4.2. Putting the "param organisation unit" at the bottom of the table

Instead of removing the "param organisation unit" from the table entirely, it is also possible to put it at the bottom (or top) of the table. This is done by using the sort functionality explained in the next section, and choosing to sort first by "organisation_unit_is_parent". Other sorting options can be added in addition to this, for example to make a list where the param organisation unit is at the bottom of the table, with the other organisation units listed alphabetically above it.

13.4.2.4.3. Hiding other rows

Using the expression editor it is also possible to exclude other rows from the table, in addition to the parent organisation unit as was explained above. In Ghana, for example, all regions have a «fake district» which is the name of the region in square brackets. This can also be excluded from the table using the Print when expression that was introduced above. To to this, follow the instructions above to bring up the Expression editor window. Then, we use Java expressions to test whether or not the row should be hidden.

13.4.2.4.3.1. Example - removing rows with organisation units starting with [

Example - removing rows with organisation units starting with [

($F{organisationunitname}.charAt( 0 ) != '[')

This makes the report skip any rows where the first character of the organisation unit name is [.

It is also possible to combine several of these expressions. To do this we put the expressions in a parenthesis with the two characters && in between. For example, to make a table that leaves both organisation units whose name starts with [ and the parent organisation unit, we can use the following expression:

($F{organisationunitname}.charAt( 0 ) != '[')&&$F{organisation_unit_is_parent}.equals("No")

13.4.2.5. Sorting

Often you will be making reports where the first column is organisation unit names. However, it can be a problem that the list of organisation units are not sorted alphabetically. This can be fixed in iReport through a few simple steps.

In the report inspector, right click on the name of the report (by default this is dpt) and select Edit query.

A Report query window will appear. Click on the Sort options button.

A Sorting window as show below will appear. Here, we can add our sorting options. Click the Add field button. Another small window will show up, with a drop down menu where you can choose Sort by organisationunitname to have the table sorted alphabetically by name.

Click OK - Close - OK to close the three windows. The table should now be sorted.

13.4.2.6. Changing indicator/data element names

By default, the reports from DHIS 2 uses the short names for indicators and data elements in reports and charts. In some cases these are not always very meaningful for third parties, but with some work they can be given custom names through iReport. This is useful for example if you are making a report with indicators as rows and periods as column, or for charts with indicators.

To change the names of an indicator or data element, we have to edit its «expression» or formula, for example by right clicking the text box and choosing Edit expression to bring up the Expression editor.

Next, we have to insert some Java code. In the following example, we will be replacing the shortname of three indicators with their proper names. The code searches for the shortname, and then replaces it with a proper name.

($F{indicatorname}.equals("Bed Util All")) ? "Bed Utilisation - All Wards"

:

($F{indicatorname}.equals("Bed Util Mat")) ? "Bed Utilisation - Maternity"

:

($F{indicatorname}.equals("Bed Util Ped")) ? "Bed Utilisation - Paediatric"

:

$F{indicatorname}

From this, we can see a pattern that is reusable for more general cases.

• For each indicator or data element we want to change the name for, we need one line

• Each line is separated by a colon :

• We finish the expression with a «regular» line

Each line has the same format, where the red text is the shortname, the blue text is what we want to insert instead.

The same expressions can be used for example when having indicator names along the category axis of a chart.

13.4.2.8. Groups of tables

There are cases when it can be useful to have several tables in one report. This can be done using Report groups. Using this functionality, one can for example create a report one table for each indicator, or one table of each organisation unit. In the following, we will go through the steps needed to make a report with three indicators, each represented in one table. It is important that the report table does not crosstab on indicators when we want to make groups of tables based on indicators.

In our example, the .jrxml file downloaded from DHIS 2 will by default have one column for organisation unit and on for indicators (assuming we have chosen periods as the only crosstab dimension). We start by removing the indicator column, since this in not needed in our case, and realign the other fields to fit the report.

Next, we create out Report group. Go to the report insepctor, right click on the report name (dpt is the default) and choose Add Report Group.

A window will appear, with a report group wizard. Select a name for the group, in this case we choose «Indicator». In the drop down menu, we can select what columns in the report table we want the groups to be based on. So, if we wanted one table for each organisation unit, we would choose organisation unit name as the report object to group according to. However, since we are grouping by indicators in this example, we choose indicatorname. Then click next.

The next step is to select whether or not we want a separate Group header and Group footer band for each report group. In this case, we choose to include both. Click Finish, and the group bands should appear in the report.

If you upload and run the report, it will now create one table for each indicator. However, it will not look very good as there will be no header row over each table - only one header at the top of each page. Also, there is no indication as to which table is showing which indicator. In the following, we will fix this.

Instead of having the title row in the column header, we can instead move it to the Group header. This will make the heading show up above each individual table. Furthermore, we can add a heading to each table with the name of the indicator.

Move the column headers from the Column header band to the Indicator group header band.

Next, add a text field to the Indicator group heading band, and edit it’s expression to display the indicator name.

The report should now have three tables, one for each indicator. Each table will have a heading with the name of the indicator, and also a table header row.

13.4.2.8.1. Sorting and grouping

When using grouping, some precautions must be taken with regards to sorting. Notably, when adding sorting parameters, whatever parameter is used as basis for the grouping must come first. Thus if you are grouping the report by indicator, and want sort the organisation units alphabetically, you have to choose to sort first by indicator, then by organisation unit name as shown below. For instructions on how to add sorting, see the sorting section above.

13.4.2.9. Charts

By default, a 3D bar chart is included in the .jrxml file that is downloaded from DHIS 2. This is set up so that only data from the «parameter orgnisation unit» (often the parent or grand parent) is used. Usually, this is a good solution. Since it is the default, we will start by looking at bar charts, before looking at line charts.

13.4.2.9.1. Bar charts

Bar charts are the default chart type in DHIS 2. In this section, we will look at how to make a bar charts like the one above, comparing the value of one inidcator in several districts. To edit the default chart in iReport, right click on it and choose Chart data.

A window will appear. By default, the Filter expression is filled in so that only data for the parent organisation unit will be displayed. If for some reason you do not want this, simply delete the text in the text box. In this case we do NOT want the filter, as we are making a chart showing a comparison across districts. To continue, click the details tab.

Under details, you see the list of series for the chart. By default, one series is created per crosstab column. In this case, we are looking at data for one indicator for the whole of 2010, for a number of districts. The indicator is along the crosstab dimension.

To make changes to a series, select it and click modify. Another window will appear where there are four areas that can be edit. The three first are required, but it is sufficient to add an empty quote («») in one of the first two.

The first box is a text field where the name of the series can be inserted or edited. This is the field that will be used to fill the text in the legend box (shown below).

However, if you want to have the name of each bar along the x-axis of the chart instead of using the legend, this can be done by adding whatever text you want to present in the Category expression field, or by inserting an expression to have it filled automatically when the report is run. In this case, we want to have one bar for each organisation unit. We therefore edit the category expression by clicking on the button to the right.

As the expression, we chose organisationunitname, as shown below.

When we are finished, the series editor should look like below. Click OK, then Close to close the Chart Details window.

If you add a good description in the Category expression area, you can leave out the legend box. This is done in the Report properties panel of iReport, where you can also edit many other details of the chart.

We can also add a title to the chart, for example the name of the indicator. This is also done in the Chart properties panel, under Title expression.

The Expression editor window will appear, where you can enter the title. Note that the title must be in quotes, as shown below.

The chart is now ready.

13.4.2.9.2. Line charts

Line charts can be useful in many circumstances. However, to make line charts the report data (report table) must be suited for it. Thus if you want to make a line chart, it is important that the report table does not have periods in the crosstab dimension. Examples where this is useful is if you are making a report for a single organisation unit with one or more indicators, or if you are making a report with one indicator and one or more organisation units.

Below, we will go though the steps needed to make a report with a line chart showing the development of three indicators over one year, for one organisation unit. We start by making a report table with the choices shown below:

When we open the resulting .jrxml-file in iReport, the default line chart is included. Since we want to make a line chart, we delete this chart and drag a new chart element into the report from the Palette panel.

As soon as we drag the Chart element into the report, a window will appear. We choose the Line chart, as shown below.

A chart wizard will appear. Click next in the first step, then Finish in the next - we will add the data later.

Next, adjust the size and position of the chart in your report. Then, we will add one data series for each of our three indicators. Right-click on the chart and choose Chart data. If you are making a chart with one indicator and several organisation units, you probably want to make a filter expression so that only data from the paramter/parent organisation unit is used in the chart. To do this, add this line to the Filter expression area:

$F{organisation_unit_is_parent}.equals("Yes")

In our example, we only have on organisation unit, so this is not necessary. Next, click the details tab to see a list of the series in the chart. For now, this list is empty, but we will add one series for each of our three indicators. To add a series, click the Add button.

In the window that appears, enter the name of the first of the indicators in the Series expression window. Remember to put the name in quotes. In the category expression (along the x-axis) we want the months, so we use the button next to the field to open the Expression editor and add periodname.

In the value expression, we add the actual data values for our first indicator. Use the Expression editor again to do this. When we are finished, the window should look like the one below, only with different names according to the indicator.

You can then Click OK to close the window. Follow the same steps to add a series for the other indicators.

Close the window, and the data for the line chart should be ready. However, some additional adjustments might be needed - most of these can be found in the Line chart properties panel. For example, when making a month by month chart as we have in example, there is often not enough space for the month names along the category axis. This can be fixed by rotating the labels by for example -40 degrees, by using the property Category Axis Tick Label Rotation.

Many other options are available to give the chart the desired look.

13.4.2.10. Adding the Report to DHIS 2

We can now switch to DHIS 2 and import our report. Go to the Report Module in DHIS 2, and select "Standard Report". In the "Standard Report" screen, click "Add new", or edit an existing one.

In the following screen, there are several actions we need to take. First, enter a name for the new "Standard Report". Second, for design, click "Choose File" and find the .jrxml-file you have edited in iReport. Then we select the report table that we used as a basis for the report in iReport. Click add, and it should move to the "Selected report tables" area. Finally, click save.

The report is now available as a "Standard Report" in DHIS 2:

The two thematic layer panels let you use your data for thematic mapping. All you need to do is selecting your desired indicator/dataelement-period-map combination, then the organisation unit level and finally the parent to define the boundary. If your database has coordinates for these organisation units they will appear on the map.

You may choose between legend types: automatic and predefined. Automatic means that the application will create a legend set for you based on your what method, number of classes, low color and high color you select. Method alludes to the size of the legend classes. Set to Equal intervals they will be “highest map value – lowest map value / number of classes”. Set to Equal group count the legend creator will try to distribute the organisation units evenly. Choose Fixed bounds and you may define your own class break values, type e.g. “20,40,60” using a comma to separate each of them. The legend will appear as an even gradation from the start color to the end color. Predefined legend sets are described in Section 15.3.2, “Register legend sets” .

Low radius and high radius only have effect on points (facilities) and decides the the circle radius for points with the lowest and highest value.

The map view combo box lists all map views (favorites) saved by the user. The settings that are stored in the map view is automatically applied to the thematic map panel. Favorite map views are described inSection 15.3.1, “Register favorite map views” .

All available layer options are now grouped together in the thematic layer menu, see picture below.

Edit layer: Opens up the layer configuration window, see the thematic mapping screenshot.

Refresh: Refreshes the map boundaries, data and legend. Usually not necessary.

Clear: Clears the entire layer, i.e. the configuration window, the map and the legend panel.

Filter: Opens up the filter window and lets you filter out organisation units from the map by value. See the picture below.

Search: Opens up the search window and lets you search for and locate organisation units on the map. See picture below.

Labels: Opens up the label window and lets you add labels to the organisation units on the map. See picture below.

Opacity: Set the layer opacity/transparency to 10, 20, 30, 40, 50, 60, 70, 80, 90 or 100%. Higher values of opacity make the layer more transparent, so that the underlying layer is more visible. An opacity level of zero will provide a fully opaque layer.

History: Provides you with a list of your 10 previous maps/selections. They are temporary and thus gone when the application is restarted.

This layer displays icons that represent facilities based on the facility type. Currently, "Type" is the only supported group set. Polygons will not show up on the map, so make sure to select a facility level. Click an icon on the map to open the context menu with two options. "Show information sheet" provides you with data for several data elements for this organisation unit. The data element group and period type are "system settings" called "Infrastructural data elements" and "Infrastructural period type". The second option in the context menu is "Relocate" and lets you graphically move the organisation unit to a different location. The new coordinate will be stored permanently.

This layer displays icons that represent areas/polygons like provinces, districts etc instead of facilities/points. Thus, in this layer you are not supposed to select a facility level, but instead a level of provinces, districts etc. In order to render this layer you need to create a predefined legend set of images, described in Section 15.3.2, “Register legend sets”.

Click the "Favorite map views" button (star icon) on the toolbar to get the context menu. The first option is "Manage favorites" which opens up a window where you are supposed to type the name of the favorite and select the layer you want to save. If you are an administrator you can check the "System" checkbox to make the favorite available to all users. From the bottom combobox you may delete a favorite or add it to the DHIS 2 dashboard.

Example usage (vaccination coverage): Firstly, create the legends that are going to constitute the legend set. The first one could be "Low bad" (display name), 0 (start value), 30 (end value), red (color). Then create "Medium" / 30 / 70 / yellow and finally "High good" / 70 / 100 / green. Now, open the "legend set" panel, type e.g. "High is good" as display name and select the desired legends below. Multi-select your three legends by pressing and holding the Ctrl/Shift button when selecting. Then click the register button to store the legend set. Assign indicators/data elements to your legend set in one of the two last panels. Select the legend set in the combo box and multi-select items in the list below. Click the assign button to update the legend set. Please see the referred window in section 1.1.

Click the image icon on the map toolbar and the print window will open. Title: Image title, will appear as a headline in the image. Layers: Choose whether polygons, points or both will be printed. Width/Height: The pixel resolution of the image. Choose among the predefined "small" (800x600), "medium" (1190x880), "large" (1920x1200) or type the exact number of pixels yourself (type the number only, avoid text like "px"). If you want to exclude the legend from the image, untick the legend checkbox. Finally click the export button to print the image (PNG). Please see the referred window in section 1.1.

Click the two-way arrow icon on the map toolbar to enter measuring mode. Now, click your desired start location on the map and a dotted line will follow the cursor toward your destination. Single click to create a line point, double click to finish the line. To exit measuring mode, click the toolbar icon again or close the window.

Overlays are geographical layers that do not have any direct linkage to data in the database. Examples include roads, rivers, airports, ports, and other geographical information that you may want to display on your map, but that is not necessarily linked to data contained in the DHIS database. The Register Overlay panel will allow you to add new layers and determine how they will be represented visually on the map.

The export option can be made use of by selecting it as follows. The import or export is available only when the selected organisation (source/destination) has defined datasets. This is because datasets help to define which data is to be or is being exported. Further, which specific data elements get exported is determined by the composition of the dataset being exported. If there are no datasets defined for an organisation unit, it indicates that no data values are registered for this level of organisation or lower. To access the main Import-Export module, choose Services->Import-Export

The exported data values are stored in an ‘xml file’. The file name is defined by the name of the source organisation unit and the period to allow the receiving organisation unit to identify the source and the period of the export file. The XML is placed in your home directory (On Windows this is normally C:\Documents and Settings\ under the sub-directories /dhis / import-export.

Once the data export screen is displayed, select the Organisation unit, period and dataset for which data export should be selected.Finally click on the export option that will be available on the lower left side of displayed screen. If there are no datasets defined for an organisation unit, it indicates that no data values are registered for this level of organisation or lower.

A pop-up save option will appear on the displayed screen (see picture below) prompting the saving of the exported data. You may save the export folder on your desktop or any other folder by selecting the ‘Save to Disk’ option from the pop-up prompt.

The DHIS 1.4 Metadata export functionality provides the same functionality as the standard DHIS 2 metadata export, except that the resulting file can be used to transmit metadata information to DHIS 1.4 systems.

The DHIS 1.4 Metadata export functionality provides the same functionality as the detailed DHIS 2 metadata export, except that the resulting file can be used to transmit metadata information to DHIS 1.4 systems. Simply select the data elements and indicators that you want and click "Export" to begin the export process.

Auctor natoque ve vulputate quam. Quam duis posuere risus felis mus class tempor eu sociosqu. Risus duis penatibus turpis, tristique dictum enim est. Quisque mi pulvinar ultrices, fusce diam porttitor mi hendrerit viverra, augue leo vestibulum rutrum. Ridiculus dictumst luctus. Eros.

Data can be imported into different instances of DHIS 2 through the use of the DXF data exchange format. There are two screens that are used to import data, with default and advanced options.

The default data import menu can be accessed by clicking the "Import" from the main Import-Export screen.

By clicking the "Browse" button, you can select a file from you local file system. This file may have been received by email, copied from another users system, or received on a CD for example. Simply select the file that you wish to import.

There are three separate options for importing data.

There are two ways to import data from a DHIS 1.4 database; 1) through the 1.4 XML-based export files, or 2) directly from the DHIS 1.4 data file (.mdb). Both are accessible from the DHIS 1.4 Import menu under Import in the Import-Export module.

It is critical that all data integrity violations which are present in the DHIS 1.4 database be fully resolved before attemtping an import into DHIS 2. You can check the data integrity of DHIS 1.4 through the CORE Module->Advanced->Data integrity checks. A report will be generated of all data integrity violations which should be resolved prior to importing into DHIS 2.

17.3.2.2. DHIS 1.4 XML Import

Import thof XML data from DHIS 1.4 is also possible using the standard DHIS 1.4 export format. Just be sure that the DHIS 1.4 export format has been set to "DHIS 2.0" as illustrated in the screen shot below. After the data has been exported by DHIS 1.4, you can import the data by choosing "Services->Import-Export->DHIS 1.4 Import->DHIS 1.4 XML Import" and proceeding via the procedure outline in the previous section.

Each data element must be assigned to a data set. Values for data elements will not be able to be entered into the system if a data element is not assigned to a data set. Choose Maintenance->Datasets->Edit from the main menu and then add the "orphaned" data element to the appropriate data set.

Some Data Elements have been allocated to several Data Element Groups. This is currently not allowed, because it will result in duplication of linked data records in the PivotSource recordsets that `feed` the pivot tables. Go to Maintenance -> Data Element Groups to review each Data Element identified and remove the incorrect Group allocations.

Some data elements have been allocated to several data element groups that are members of the same data element group set. All group sets in DHIS are defined as exclusive, which means that a data element can only be allocated to one data element group within that group set. Go to Maintenance -> Data elements and indicators ->Data element groups to review each data element identified in the integrity check. Either remove the data element from all groups except the one that it should be allocated to, or see if one of the groups should be placed in a different group set.

Data Elements should not be assigned to two separate data sets whose period types differ. The recommended approach would be to create two separate data elements (for instance a monthly and yearly data element) and assign these to respective datasets.

All data sets should be assigned to at least one organisation unit.

Although this rule will not affect data quality, it generally does not make sense to have two indicators with the exact same definition. Review the identified indicators and their formulas and delete or modify any indicator that appears to be the duplicate.

All Data Elements and Indicators must be assigned to at least one group, so these Indicators need to be allocated to their correct Data Element and Indicator Group. Go to Maintenance -> Indicator Groups, and allocate each of the `Orphaned` Indicators to its correct group.

Violations of this rule may be caused by an incorrect reference to a deleted or modified data element. Review the indicator and make corrections to the numerator definition.

Violations of this rule may be caused by an incorrect reference to a deleted or modified data element. Review the indicator and make corrections to the denominator definition.

Some indicators have been allocated to several indicator groups that are members of the same indicator group set. All group sets in DHIS are defined as exclusive, which means that an indicator can only be allocated to one indicator group within that group set. Go to Maintenance -> Data elements and indicators ->Indicator groups to review each indicator identified in the integrity check. Either remove the indicator from all groups except the one that it should be allocated to, or see if one of the groups should be placed in a different group set.

Organisation units cannot be both parent and children of each other, directly nor indirectly.

All organisation units must exist within the organisation unit hierarchy. Go to Organisation->Hierarchy Operations and move the offending organisation unit into the proper position in the hierarchy.

All organisation units must be allocated to at least one group. The problem might either be that you have not defined any `compulsory` OrgUnit Group Set at all, or that there are violations of the `compulsory` rule for some OrgUnits . NOTE: If you have defined no `compulsory` OrgUnit Group Sets, then you must first define them by going to Maintenance -> Organisation units->Organisation unit group sets and define at least one `compulsory` Group Set (the group set `OrgUnitType` are nearly universally relevant). If you have the relevant group sets, go to Maintenance -> OrgUnit Groups to review each OrgUnit identified and add the relevant Group allocation.

These organisation units have not been assigned to the any organisation unit group within one of the compulsory organisation unit group sets. When a group set is defined as `compulsory`, it means that an organisation unit must be allocated to at least one organisation unit group within that group set. For instance, all organisation units must belong to one of the groups in the `organisation unitType` group set. It might belong to the `Hospital` or the `Clinic` or any other `type` group - but it must belong to exactly one of them. Go to Maintenance -> organisation unit->Organisation unit groups to review each organisation unit identified in the integrity check. Allocate all organisation units to exactly one group.

Some organisation units have been allocated to several organisation unit groups that are members of the same organisation unit group set. All group sets in DHIS are defined as exclusive, which means that an organisation unit can only be allocated to one organisation unit group within that Group Set. For instance, one organisation unit cannot normally belong to the both the 'Hospital' and 'Clinic' groups , but rather to only to one of them. Go to Maintenance -> organisation unit->Organisation unit groups to review each organisation unit identified in the integrity check. Remove the organisation unit from all groups except the one that it should be allocated to.

The organisation unit groups listed here have not been allocated to a group set. Go to Maintenance->Organisation unit->Organisation unit group sets and allocate the Organisation unit group to the appropriate group set.

All validation rules must be assigned to a group. Go to Services->Data quality->Validation rule group and assign the offending validation rule to a group.

An error exists in the left-side validation rule definition. Go to Services->Data quality->Validation rule and click the "Edit" icon on the offending rule. Press "Edit left side" and make the corrections that are required.

An error exists in the left-side validation rule definition. Go to Services->Data quality->Validation rule and click the "Edit" icon on the offending rule. Press "Edit right side" and make the corrections that are required.

To create a new SQL view, choose Maintenance->SQL view and click the "Add new" button.

The "Name" attribute of the SQL view will be used to determine the name of the table that DHIS2 will create when the view is materialized by the user. The "Description" attribute allows one to provide some descriptive text about what the SQL view actually does. Finally, the "SQL statement" should contain the SQL view definition. Only SQL "SELECT" statements are allowed and certain sensitive tables (i.e. user information) are not accessible Press "Save" to store the SQL view definition.

In order to utilize the SQL views, simply press the "Execute query" button from the "SQL View management page. Once the process is completed, you will be informed that a table has been created. The name of the table will be provided, and is composed from the "Description" attribute provided in the SQL view definition. Once the view has been materialized, click on the "View" button .

This approach is for data-entry on a smart phone with a mobile browser by navigating to the URL of the DHIS2 instance, for example: the full URL link for demo on dhis2.org http://apps.dhis2.org/dev/mobile/index.action . And your mobile browser will automatically detect the DHIS2 application where the server URL is given (e.g: http://apps.dhis2.org/dev). Here is the login form to access the application with user-name and password. Click on "Login" to continue or "Reset" to reset:

After logging in, there are the list of functions:

- Data Entry: Entries for aggregate data with defined/assigned dataset by organisation-units

- Name-based Data Entry: Entries data for the beneficiaries by organisation-units, beneficiaries and programs/program-stages.

- Beneficiary Registration: Registry a new beneficiary

- Beneficiary Enrollment: Enroll a beneficiary to one or many programs

- Messages: Manage the messages and discussions from the server. Message reply is available.

- Reports: The output reports from the server

- Settings: User-information (e.g: First-name, Surname, Phone number, E-mail) and the Interface language.

- Feedback: the extra function for creating a new message to send to the server. The new created feedback from this will be listed under "Messages"

- Logout: to log out the application

- Desktop version: navigate to the desktop version of DHIS2 for administration. This require a lof of resources from the client mobile, for example: the sufficient memory to load the pages. Not recommended for the nornal GPRS/3G/... phones.

The list above will be explained in details:

Data connection availability can be a problem in many of the contexts where DHIS2 mobile reporting would otherwise be a good solution for getting data directly into DHIS2. If that is the case for you, you might want to consider trying the SMS based solution described in a separate document. Keep in mind that even though a data connection is currently required for communication between the server and the mobile phone, it is only required when initializing or updating the mobile application and when sending reports to the server. The phone stores all entered data locally, so it it can work fine with only temporary access to a data connection on a regular basis.

The server side component of the web based solution is included in the general build of DHIS2.

In order to configure the DHIS2 web-based mobile reporting, you should follow the following steps.

Like facility reporting module, sever side of activity reporting included in DHIS2 war file.

Basically, server side setup for activity does not require any additional step. The mobile application use the same user name and password as the web-based application. Make sure that the user is assigned to the correct organization unit.

In short, if a user is able to enter data for activity reporting in DHIS2 web-based application, he/she is able to download and enter data in mobile application.

Though the previous steps is all that should be needed for testing the solution more detail configuration of the datasets may be required and are described in the following sections.

20.3.4.4. Language support

Multi-language support is available.

DataSet and DataElement are translated through web-based function. Default language on server is used on mobile in cases requested language from mobile is not available.

The phone numbers of the cell phones used for reporting with the mobile application needs to be registered in DHIS 2 in order for the data to be imported and stored in the database. A phone number has to be registered for a user, and the user can only be associated with one organisation unit!

The phone number must include the regular phone number as well as the country code without + or 00 . E.g. for a Norwegian number, having the country code 47 and phone number 98765432 , the phone number to store is 4798765432 .

If you've got a phone and a computer with Bluetooth, you will in the most cases be able to send the .jar file (the mobile application) via Bluetooth from the computer to the phone. When using a cable, and also in some cases for phones with Bluetooth, you might have to install some software to be able to communicate with the phone. E.g. Nokia PC Suite for Nokia phones.

Once the mobile application is installed on the phone, open it and navigate to the last page in the application. Select settings, and enter the number of the SIM card in the GSM modem. This works both with and without country code.

If there are several GSM modems installed on several computers running DHIS 2 and you want to report to all of these, you can enter the numbers of the SIM cards installed in these GSM modems as well in the remaining fields in your mobile application. When clicking send, the application will now send the registered data to all the registered numbers at the same time.

Navigate to the Mobile module via Services -> Mobiles

20.4.5.1. Start the SMS Service

From the start-page DHIS2, go to Maintenance >> Mobile Configuration:

Then choosing the "SMS Service Configuration":

The SMS Service Configuration main-page with descriptions:

(The above screen-shot example with no gateway in the Gateways list)

If having no gateway registered, clicking on the "Reload Configuration" or "Start SMS Service" will have no use and a warning message appeared, see this screen-shot example:

Add or Update Gateway:

Currently, there are 4 gateway types:

Then fill in the information for the gateway (the screen-shot example with BulkSMS Gateway):

(The information for the gateway is from the Gateway providers)

After adding successfully the gateway, the service will automatically started.

20.4.5.2. Sending SMS

From the start-page DHIS2, go to Maintenance >> Mobile Configuration. Then navigate to "Show send SMS form":

At this moment (DHIS version 2.8), this is the one-way sending out the SMS messages from the servers to the recipients (with mobile phone numbers).

See the below example form to send out the messages to the recipients' numbers individuals or mobile number of registered Organisation Unit or by mobile number of the users assigned with Organisation Unit.

Below is an example screen-shot with listing of phone numbers (using ";" between the numbers in the list):