This document describes in brief the overall design principles that have been followed when developing standard configuration packages for DHIS2. It has three main compoenents, addressing principles tracker programmes [to be developed], aggregate reporting (i.e. routine data collection), and data analysis (i.e. dashboards and dashboard components).
In addition to this document outlining some general principles, an in-depth system design document is available for each disease/programme package.
Three types of configuration packages exists:
Tracker configuration packages include one particular tracker (case-based) programme, and related metadata such as program indicators and dashboards. The aggregate configuration packages include data sets for routine aggregate reporting, as well as dashboards. Finally, the dashboard configuration packages include indicators and dashboards only.
As far as possible, tracker configuration includes the necessary program indicators to populate the the data sets of the related aggregate configuration packages. The dashboards packages can either exists solely as dashboard configurations, or can be identical to the dashboard component of the aggregate configuration package.
To be developed
The aggregate reporting component of the standard configuration packages are made up for data sets and related content, including:
The data sets have all been based either on WHO recommendations and best-practice examples or published reporting frameworks (such as the "WHO Definitions and reporting framework for tuberculosis"). These data sets will in many instances have to be adjusted to fit with national reporting systems, to varying degree. On the one hand, there might be additional variables that are important in a national context which must be added. On the other hand, there might be information that is simply not available for reporting, for example if the data is not captured in the case-based registers at the clinical level. The implementation of these reference data sets will therefore often be a longer-term project. Even in contexts where they are not used directly, they can be used as models for what and how data for different diseases/programmes can be collected using DHIS2.
While the standard configuration packages are disease/programme specific, the underlying metadata has been harmonised and used across programmes as much as possible. For example, if a data element or disaggregation applies in more than one data set, the DHIS2 metadata has ben re-used.
A common gap seen in many country DHIS2 instances is that validation rules are not implemented consistently: they are either not used, or sometimes used to flag data quality issues that are unlikely, but possible. In the standard configuration packages, an effort has been made to add validation rules everywhere it is possible, but only for checks that are certain data quality issues (e.g. tests done vs positive tests).
The data analysis part of the configuration is centred around the dashboard concept. Each configuration package includes one or more dashboards. As discussed above, there are also dashboard-only version of the configuration packages.
The dashboards as based exclusively on indicators. This means that even in cases where an equivalent data element exists for a concept, an indicator will be created and used in the analytics favourites. The the dashboard configuration packages, this is a requirement, since the indicators are what allow the dashboard content to be mapped to existing data elements. However, for the aggregate configuration packages, this is clearly a trade-off, with the notable downside that we are creating "duplicate" metadata which is not strictly needed. However, there are also some advantages, which has led to the decision to use indicators only. The most important advantage is that is allows the same dashboards to be used in the aggregate and dashboard only configuration packages, without modifications. Since the standard configurations packages are aligned with a training curriculum, it is an advantage that any implementation of the dashboard is as similar as possible. Whether the aggregate or dashboard-only package has been installed, the same variables for analysis will be available.
Similar to how only indicators are used in the dashboards, only category option groups and category option group sets are used to apply disaggregations to the analytical outputs. That rationale for this is similar to the decision to use only indicators: the category option groups can be mapped to existing category options.
Finally, all analytical outputs (favourites) use relative organisation units and periods. This is necessary to make them portable across instances and over time. In some cases, some modifications are needed to set this according to the context. In those cases, this is described in the documentation for those specific configuration pacakges.
Where possible, all metadata objects from data sets and data elements to charts favourites should have a meaningful description.