Data input != Data output

Indicator-driven data analysis and reporting What is referred to as a Data Element above, the key dimension that describes what is being collected, is sometimes referred to as an indicator in other settings. In DHIS 2 we distinguish between Data Elements who describe the the raw data, e.g. the counts being collected, and Indicators, which are formula-based and describe calculated values, e.g. coverage or incidence rates that are used for data analysis. Indicator values are not collected like the data (element) values, but instead calculated by the application based on formulas defined by the users. These formulas are 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 "Measles coverage <1 year" is defined a formula with a factor 100, a numerator ("Measles 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"- "DPT3doses given") / ("DPT1 doses given"). These formulas can be added and edited through the user interface by a user with limited training, as they are quite easy to set up and do not interfere with the data values stored in the database (so adding or modifying an indicator is not a critical operation). Indicators represent perhaps the most powerful data analysis feature of the DHIS 2, and all reporting tools support the use of indicators, e.g. as displayed in the custom report in the figure above. Being able to use population data in the denominator enables comparisons of health performance across geographical areas with different target populations, which is more useful than only looking at the raw numbers. The table below uses both the raw data values (Doses) and indicator values (Cov) for the different vaccines. Comparing e.g. the two first orgunits in the list, Taita Taveta County and Kilifi County, on DPT-1 immunisation, we can see that while the raw numbers (659 vs 2088) indicate many more doses are given in Kilifi, the coverage rates (92.2 % vs 47.5 %) show that Taita Taveta are doing a better job immunising their target population under 1 year. Looking at the final column (Immuniz. Compl. %) which indicates the completeness of reporting of the immunisation form for the same period, we can see that the numbers are more or less the same in the two counties we compared, which tells us that the coverage rates are comparable across the two counties. - +

Maintain disaggregated facility-data in the database === modified file 'src/docbkx/en/dhis2_implementation_guide_integration.xml' --- src/docbkx/en/dhis2_implementation_guide_integration.xml 2011-06-18 16:37:00 +0000 +++ src/docbkx/en/dhis2_implementation_guide_integration.xml 2011-06-19 11:40:33 +0000 @@ -70,6 +70,6 @@ Since there are many different use-cases for health information, such as monitoring and evaluation, budgeting, patient management and tracking, logistics management, insurance, human resource management, etc, there will be many different types of software applications functioning within the health sector. Above the issue of interoperability has been addressed, and a plan or overview of the various interoperable software applications and their specific uses, along with what data should be shared between them, is termed an architecture for health information. The role of the architecture is to function as a plan to coordinate the development and interoperability of various sub-systems within the larger health information system. It is advisable to develop a plan for the various components even if they are not currently running any software, to be able to adequately see the requirements in terms of data sharing. These requirements should then be part of any specification for the software when such is developed or procured. Below is a simple illustration of an architecture, with a focus on the data warehouse for aggregate data. The various boxes represent use cases, such as managing logistics, tracking TB patients, general patient management, etc. All of these will share aggregate data with DHIS2. Note that the arrows are two-way, because there is also a synchronization of meta-data (definitions) involved, to make sure that the right data is shared. Also, an example of the logistics and financial data applications sharing data is also shown, as there are strong links between procuring drugs and handling the budget for this. There will be many such instances of sharing data; the architecture helps us to plan better for this being implemented as the ecosystem of software applications grow. - +

=== modified file 'src/docbkx/en/dhis2_implementation_guide_organisation_units.xml' --- src/docbkx/en/dhis2_implementation_guide_organisation_units.xml 2011-06-18 21:38:16 +0000 +++ src/docbkx/en/dhis2_implementation_guide_organisation_units.xml 2011-06-19 11:40:33 +0000 @@ -27,7 +27,7 @@ Organisation unit groups and group sets In DHIS 2, organisation units can be grouped in organisation unit groups, and these groups can be further organised into group sets, and together they can mimic an alternative organisational hierarchy which can be used when creating reports and other data output. In addition to representing alternative geographical locations not part of the main hierarchy, these groups are useful for assigning classification schemes to health facilities, e.g. based on the type or ownership of the facilities. Any number of group sets and groups can be defined in the application through the user interface, and all these are defined locally for each DHIS 2 database. An example illustrates this best: Typically one would want to provide analysis based on the ownership of the facilities. In that case one would create a group for each ownership type, for instance “MoH”, “Private” and “NGO”. All facilities in the database must then be classified and assigned to one and only one of these three groups. Next one would create a group set called “Ownership” to which the three groups above are assigned, as illustrated in the figure below. - + In a similar way one can create a group set for an additional administrative level, e.g. local councils. All local councils must be defined as organisation unit groups and then assigned to a group set called “Local Council”. The final step is then to assign all health facilities to one and only one of the local council groups. This then enables the DHIS 2 to produce aggregate reports by each local council (adding together the data for all assigned health facilities) without having to include the local council level in the main organisational hierarchy. The same approach can be followed for any additional administrative or geographical level that is needed, with one group set per additional level. Before one can go ahead and design this in DHIS 2, a mapping between the areas of the additional geographical level and the health facilities serving in each area is needed. A key property of the group set concept in DHIS 2 to understand is exclusivity, which implies that an organisation unit can be member of exactly one of the groups in a group set. A violation of this rule would lead to duplication of data when aggregating health facility data by the different groups, as a facility assigned to two groups in the same group set would be counted twice. With this structure in place, DHIS 2 can provide aggregated data for each of the organisation unit ownership types through the “Organisation unit group set report” in “Reporting” module or through the Excel pivot table third-party tool. For instance one can view and compare utilisation rates aggregated by the different types of ownership (e.g. MoH, Private, NGO). In addition, DHIS 2 can provide statistics of the distribution of facilities in “Organisation unit distribution report” in “Reporting” module. For instance one can view how many facilities exist under any given organisation unit in the hierarchy for each of the various ownership types. In the GIS module, given that health facility coordinates have been registered in the system, one can view the locations of the different types of health facilities (with different symbols for each type), and also combine this information with a other map layer showing indicators e.g. by district. === modified file 'src/docbkx/en/dhis2_implementation_guide_pivot_tables_and_mydatamart.xml' --- src/docbkx/en/dhis2_implementation_guide_pivot_tables_and_mydatamart.xml 2011-06-18 17:08:15 +0000 +++ src/docbkx/en/dhis2_implementation_guide_pivot_tables_and_mydatamart.xml 2011-06-19 11:40:33 +0000 @@ -4,7 +4,7 @@ Pivot Tables and the MyDataMart tool Excel Pivot Table (see screenshot below) is a powerful and dynamic data analysis tool that can be automatically linked to the DHIS 2 data. While most reporting tools in DHIS 2 are limited in how much data they can present at the same time, the pivot tables are designed to give nice overviews with multiple data elements or indicators, and organisation units and periods (see example below). Furthermore, the dynamic features in pivoting and drill-down are very different from static spreadsheets or many web reports, and his makes it a useful tool for information users that want to do more in-depth analysis and to manipulate the views on the data more dynamically. This combined with the well-known charting capabilities of Excel, the Pivot Table tool has made it a popular analysis tool among the more advanced DHIS users for a long time. - + With the recent shift towards online deployments, the offline pivot tables in Excel also provide a useful alternative to the online reporting tools as they allow for local data analysis without Internet connectivity, which can be an advantage on unstable or expensive connections. Internet is only needed to download new data from the online server, and as soon as the data exists locally, working with the pivot tables require no connectivity. The MyDatamart tool, which is explained in detail further down, helps the users to maintain a local data mart file (small database) which is updated over the Internet against the online server, and then used as an offline data source that feeds the pivot tables with data.

Pivot table design @@ -27,7 +27,7 @@ With online deployments and the use of one single central server (and database) the local use of pivot tables becomes more difficult as Excel connects to the database directly to fetch the data. This means that Excel (and every local computer using DHIS2) would need connection details and access to the database on the server, which is not always wanted. Furthermore, the refresh (update the pivot table) operation in Excel completely empties the table before reloading all the data again (new and old), which leads to big and duplicated data downloads over the Internet when connecting to an online server. The solution to these problems has been to build up and maintain an updated "copy" of the central database in each local office where they use Excel pivot tables. These local databases are called data marts and are built specifically for serving as data sources for data analysis tools like Excel. The MyDatamart tool is a newly developed (May 2011) tool that creates a datamart file on a local computer and helps the users to update this against a central server. The pivot tables in Excel connect only to the local datamart and do not need to know about the central server at all. The use of MyDatamart dramatically reduces the download size when routinely updating the local Excel files against the central server compared to a direct connection from Excel. It also brings comfort to the local level users to have a copy of their data on their local computer and not to rely on a Internet connection or server up-time to access it. The figure below explains how the linking between the central online server (in the clouds) and the local offices works. - +

Using Excel pivot tables and MyDatamart - a work-flow example === removed file 'src/docbkx/en/dhis2_implementation_startup_strategies.xml' --- src/docbkx/en/dhis2_implementation_startup_strategies.xml 2011-02-12 16:14:18 +0000 +++ src/docbkx/en/dhis2_implementation_startup_strategies.xml 1970-01-01 00:00:00 +0000 @@ -1,5 +0,0 @@ - - - - Startup Strategies -