DHIS2 Metadata Assessment
DHIS2 Implementation Team
2022-12-06
Target server: https://his.rbc.gov.rw/hmis/
Metadata issues
Checks which could not be run
Users
- Total users: 2317
- Total disabled users: 2301
- Total users logged in within 7 days: 5
- Total users logged in within 30 days: 8
- Total users logged in within 90 days: 8
- Total users logged in within a year: 1249
- Users who have never logged in: 32
- Percentage of users who are disabled: 99 %
- Number of users who have superuser: 47
- Percentage of users who have superuser: 2 %
Distribution of last user logins
Distribution of users within the hierarchy
Guidance section
This section of the report contains guidance information which provide more context and expiation of each of the checks.
Categories
Categories without category options
Level: Warning
Issue count: 0 (0%)
Introduction
Categories should always have at least a single category option.
Recommendation
Any categories without category options should either be removed from the system if they are not in use. Otherwise, appropriate category options should be added to the category.
Additional default category option combos based on category option.
Level: Critical
Issue count: 0 (0%)
Introduction
There should only be a single ‘default’ category option combination in the system. Having multiple default category option combinations may lead to irregularities in both data entry as well as analytical outputs.
Recommendation
All references to the additional default category option combination should be replaced with the desired default category option combination.
Category options with no categories
Level: Warning
Issue count: 19 (4%)
Introduction
All category options should belong to at least one category.
Recommendation
Category options which are not part of any category should be removed or alternatively should be added to an appropriate category.
Category option combinations with disjoint associations.
Level: Severe
Issue count: 24 (2%)
Introduction
Under certain circumstances, category option combinations may exist in the system, but not have any direct association with category options which are associated with the category combinations. This situation usually occurs when category options have been added to a category and then the category is added to a category combination. New category option combinations are created in the system at this point. If any of the category options are then removed in one of the underlying categories, a so-called disjoint category option combination may result. This is a category option combination which has no direct association with any category options in any of the categories.
Recommendation
The disjoint category option combinations should be removed from the system if possible. However, if any data is associated with the category option combination, a determination will need to be made in regards of how to deal with this data.
Category option combinations with incorrect cardinality.
Level: Severe
Issue count: 14 (1%)
Introduction
All category option combinations should have exactly the same number of category option associations as the number of categories in the category combination. If there are two categories in a category combination, then every category option combination should have exactly two category options.
Recommendation
Category option combinations which have an incorrect cardinality will be ignored by the DHIS2 analytics system and should be removed.
Category options with more than one membership for a category.
Level: Severe
Issue count: 0 (0%)
Introduction
Category options should usually be recycled where possible between categories. The exception to this rule however, is when you have a category combo with multiple categories, and within those cateogries, a category option is shared. As a simple example, lets say you have a category called “Sex” with options “Male”“,”Female” and “Unknown”. There is also a second category called “Age” with options “<15”, “15+”, and “Unknown. A category combination called”Age/Sex” is then created with these two categories, which share the option “Unknown”. ´
Recommendation
The recommended approach to dealing with this situation is to create a new category combination, using two new categories. Using the example from the introduction, you should create two new category options called “Unknown age” and “Unknown sex”. A new category combination can then be created with these new categories, which do not share category options. All data which is potentially associated with the old category combinations, would need to be reassigned to the new category option combinations.
Category combinations not used in any metadata
Level: Warning
Issue count: 18 (NA)
Introduction
Category combinations which are unused in any datasets, data elements, programs or data approval workflows may be safe to delete. In some cases, category combinations may be created, but never actually used for anything. This may lead to situations where users and implementers are confused about which category combination should actually be used. In general, it should be safe to delete unused category combinations, except in situations where existing data has been associated with them.
Recommendation
Check to see if any data is associated with the category combination before attempting to delete it. Category combinations which are not currently used in any metadata objects may still be valid for legacy reasons, but they should be reviewed to be sure they are still needed. Otherwise, it should be safe to remove them from the system.
Category combinations with no categories.
Level: Warning
Issue count: 5 (4%)
Introduction
All category combinations should be associated with one or more categories.
Recommendation
Category combinations without categories are not usable by DHIS2. They should either be removed or the correct cateogries should be added to the category combo.
Category options combinations with no category combination.
Level: Warning
Issue count: 6 (1%)
Introduction
All category option combinations should be associated with a category combo. In certain cases, when category combinations are deleted,the linkage between a category option combination and a category combination may become corrupted.
Recommendation
Check if any data is associated with the category combinations in question. Likely, the data should either be deleted or migrated to a valid category option combination. Any data which is associated with any of these category option combinations will not be available through either the data entry modules or any of the analytical apps.
Duplicated category option combinations within a category combination.
Level: Severe
Issue count: 84 (8%)
Introduction
Within each category combination, a unique set of category option combinations should exist. In certain circumstances, duplicate category option combinations may exist in the system. This usually results from changes to category combinations after they have been created, or direct manipulation of the various category tables in the database. This may result in certain data element/category option combinations not appearing or being unavailable in the data entry screens and/or analytics apps.
Recommendation
Duplicated category option combinations within a category combination will require you to merge category option combinations together. This will require direct manipulation of the database, and should always be conducted first in a testing environment. Only after you have thoroughly tested your procedure, and have confidence that it works, should you perform the procedure on your production environment. The DHIS2 implementation team has created a series of SQL functions to help you remove these duplicated COCs from your system.
Categories with the same category options
Level: Warning
Issue count: 5 (4%)
Introduction
Categories with the exact same category options should be considered to be merged. Categories with the exact same category options may be easily confused by users in analysis. The details view will provide a list of categories which have the exact same category options. For each duplicated category a number in parantheses such as (1) will indicate which categories belong to duplicated groups.
Recommendation
If category combinations have already been created with duplicative categories, it is recommended that you do not take any action, but rather ensure that users understand that there may be two categories which are duplicative.
If one of the categories is not in use in any category combination, it should consider to be removed from the system.
Dashboards
Total number of dashboards
Level: Info
Issue count: 2439 (100%)
Introduction
Total number of dashboards in the system.
Recommendation
DHIS2 should contain useful dashboards for users.
Dashboards that have been viewed 1 time or less in the past three years
Level: Warning
Issue count: 1243 (50%)
Introduction
Dashboards that are not viewed by users can indicate limited data use, that the dashboards have not been designed with an intention of reuse (for example as part of a training exersice or one-off data analysis), or that the user owning the dashboard is not longer active.
Recommendation
If the dashboards are relevant and useful but not view, efforts should be made to increase data use (e.g. review sharing settings, communicate with users, plan training exercises etc). In other cases, users with superuser permission should be able to delete dashboards by looking up the name or in batches. You should also confirm that the dashboard is not in use by any push analysis before removing it from the system.
Dashboards that have not been opened in the last 12 months
Level: Warning
Issue count: 1928 (79%)
Introduction
Dashboards that are not viewed by users can indicate limited data use, that the dashboards have not been designed with an intention of reuse (for example as part of a training exersice or one-off data analysis), or that the user owning the dashboard is not longer active.
Recommendation
If the dashboards are relevant and useful but not view, efforts should be made to increase data use (e.g. review sharing settings, communicate with users, plan training exercises etc). In other cases, users with superuser permission should be able to delete dashboards by looking up the name or in batches. You should also confirm that the dashboard is not in use by any push analysis before removing it from the system.
Dashboards with no content
Level: Info
Issue count: 806 (33%)
Introduction
All dashboards should have content on them. Dashboards without any content do not serve any purpose, and can make it more difficult to find relevant dashboard with content.
Recommendation
Dashboards without content that have not been modified in the last e.g. 14 days should be considered for deletion.
Data elements (aggregate)
Total count of aggregate data elements
Level: Info
Issue count: 7724 (100%)
Introduction
Overview of the number of aggregate data elements in the system.
Recommendation
DHIS2 should contain useful data elements for users.
Aggregate data elements not used in any favourites (directly or through indicators)
Level: Warning
Issue count: 2628 (34%)
Introduction
All aggregatge data elements that are captured in DHIS2 should be used to produce some type of analysis output (charts, maps, tables). This can be by using them directly in an output, or by having them contribute to an indicator calculation that is used an output.
Recommendation
Data elements that are not routinely being reviewed in analysis, either directly or indirectly through indicators, should be reviewed to determine if they still need to be collected. If these are meant to be used in routine review, then associated outputs should be created using them. If these data elements are not going to be used for any type of information review, consideration should be made to either archive them or delete them.
Aggregate data elements assigned to 1 or less orgunit
Level: Warning
Issue count: 2267 (29%)
Introduction
Data elements which are part of an aggregate dataset should be assigned to at least one organisation unit.
Recommendation
If the dataset is active, then review the organisation unit assignments. If the dataset is not active, then the dataset and its associated data elements should be removed from the system.
Aggregate data elements not in any data element groups.
Level: Warning
Issue count: 3948 (51%)
Introduction
All data elements should be in a data element group. This allows users to find the data elements more easily in analysis apps and also contributes to having more complete data element group sets. Maintenance operations can also be made more efficient by applying bulk settings (ex. sharing) to all data elements within a data element group.
Recommendation
Data elements that are not in a data element group should be added to a relevant data element group. If the data elements are not needed, they should be deleted.
Non-numeric data elements which have an aggregation operator other than NONE
Level: Warning
Issue count: 78 (1%)
Introduction
Data elements which are not numeric (text, dates, etc) should have an aggregation operator set to NONE.
Recommendation
Open the affected data elements in the Maintenance App and change their aggregation type to NONE. Alternatively, these can be altered via the API.
Data elements (tracker)
Total count of tracker data elements
Level: Info
Issue count: 45 (100%)
Introduction
Overview of the number of tracker data elements in the system.
Recommendation
DHIS2 should contain useful data elements for users.
Tracker data elements not in any data element groups.
Level: Warning
Issue count: 37 (82%)
Introduction
All data elements should be in a data element group. This allows users to find the data elements more easily in analysis apps and also contributes to having more complete data element group sets. Maintenance operations can also be made more efficient by applying bulk settings (ex. sharing) to all data elements within a data element group.
Recommendation
Data elements that are not in a data element group should be added to a relevant data element group. If the data elements are not needed, they should be deleted.
Datasets
Total number of data sets
Level: Info
Issue count: 256 (100%)
Introduction
Total number of datasets in the system.
Recommendation
DHIS2 should contain datasets which are useful for data entry.
Data sets that have not been changed in last 100 days and are assigned to 1 or less orgunits
Level: Warning
Issue count: 79 (30%)
Introduction
Datasets should generally be assigned to multiple organisation units if they are used, or be modified recently (e.g. last 100 days) if they are under development. Unused datasets represent unnecessary clutter in the database and may confuse users and administrators. The exception is data sets which are associated with historical data, for example reporting forms from previous years which are no longer used, and datasets that is designed to be used in only on organisation unit (e.g. at national level).
Recommendation
Datasets which are not activly used or in development should be removed from the system to decrease system clutter and metadata size. Before removing the data sets, verify that the data set is not associated with historical data and kept for that reason.
Data sets with no data values in the last 3 periods (based on data set period type).
Level: Warning
Issue count: 227 (88%)
Introduction
Data sets with no recent data values associated with them are likely to fall into one of two categories: 1) they have been used previously and hold useful/relevant data, 2) they have not been used in any meaningful way (e.g. data values stem from testing during configuration or a small pilot) and the data is not useful/relevant.
Recommendation
If the data elements hold useful historical data, they should be kept. Consider renaming the data elements and/or data sets to make it clear they are not used for data collection any more. Data elements which are not actively used and have no valueable data associated
Dataset sections with non-sequential sort order
Level: Warning
Issue count: 67 (97%)
Introduction
Dataset sections are used to group certain related sections in a section data entry form. They can also be ordered. The order of the sections may become corrupted if sections are added or deleted.
Recommendation
It is possible to fix the sort order of data set sections by using
the fixSortOrder SQL function which is available in the
dhis2-utils Github repository (https://github.com/dhis2/dhis2-utils/tree/master/resources/sql).
Using this script you can fix the sort order for each affected data set
section.
Indicators
Total count of indicators
Level: Info
Issue count: 1284 (100%)
Introduction
Overview of the number of indicators in the system.
Recommendation
DHIS2 should contain useful indicators for users.
Indicators not in any groups
Level: Warning
Issue count: 302 (23%)
Introduction
All indicators should be in an indicator group. This allows users to find the indicators more easily in analysis apps and also contributes to having more complete indicators group sets. Maintenance operations can also be made more efficient by applying bulk settings (ex. sharing, filtering) to all indicators within an indicator group.
Recommendation
Indicators that are not in a indicator group should be added to a relevant indicator group. If the indicators are not needed, they should be deleted.
Indicators not used in favourites OR data sets
Level: Warning
Issue count: 71 (5%)
Introduction
All indicators that are calculated should be used to produce some type of analysis output (charts, maps, tables), alternatively to provide feedback during data entry by being part of a data set.
Recommendation
Indicators that are not routinely being reviewed in analysis, either in an output or data set, should be reviewed to determine if they still need to be calculated. If these are meant to be used for routine review, then associated outputs should be created using them. If these indicators are not going to be used for any type of information review, consideration should be made to either archive them or delete them.
Indicators not used in favourites
Level: Warning
Issue count: 184 (14%)
Introduction
Indicators should be used to produce some type of analysis output (charts, maps, tables). Note: indicators used in datasets to provide feedback during data entry are not counted as being used in analytical objects.
Recommendation
Indicators that are not routinely being reviewed in analysis should be reviewed to determine if they are useful and needed. If these are meant to be used for routine review, then associated outputs should be created using them. If these indicators are not going to be used for any type of information review, and are not used in data sets for feedback during data entry, consideration should be made to either delete them.
Duplicated indicator types
Level: Warning
Issue count: 2 (0%)
Introduction
Indicators can be assigned a factor which is multiplied which is multiplied by the indicators value. If you create a percentage based indicator, you can assign the indicator a factor of 100, which would be multiplied by the actual value of the indicator calculated by DHIS2. In general, having multiple indicator types with the same factor is not recommended. It is duplicative, and may lead to confusion.
Recommendation
Duplicated indicator types should consider to be removed from the system. Consider choosing on of the duplicated indicator types as the one to keep, and then update all indicators which share the same factor to this indicator type. The duplicated indicator types can then be removed from the system.
Option sets
Unused option sets
Level: Warning
Issue count: 19 (48%)
Introduction
Option sets should be used for some purpose either with attributes, data elements, or comments.
Recommendation
Consider deleting unused option sets, or alternatively, ensure that they have been properly assigned.
Empty option sets
Level: Warning
Issue count: 0 (0%)
Introduction
All option sets should generally include at least two items. Empty option sets serve no purpose.
Recommendation
Options should either be added to the option set, or the option set should be deleted.
Organisation units
Orgunits that are not in all compulsory orgunit group sets
Level: Severe
Issue count: 17 (0%)
Introduction
Any organisation unit groups which have been marked as compulsory should contain all organization units in the system. If certain organization units are omitted from the groups in the group set, this may cause irregularities in analytical outputs, such as data being omitted.
Recommendation
Add all organization units to exactly one group within a compulsory organization unit group.
Organisation units which have an opening date later than the closed date.
Level: Severe
Issue count: 0 (0%)
Introduction
If a closing date has been defined for an organisation unit, it should always be after the opening date (if one has been defined).
Recommendation
Alter either the opening or closing date of all affected organisation units so that the closing date is after the opening date.
Organisation units should not have trailing spaces
Level: Warning
Issue count: 25 (0%)
Introduction
Trailing spaces in organisation units are superfluous.
Recommendation
If the number of affected organisation units is small, the easiest remedy is to correct them directly from the user interface. Another possible option would be to replace all of the multiple spaces using SQL.
Point coordinates which are not contained by their parent
Level: Warning
Issue count: 70 (6%)
Introduction
Facilities are often represented as points in the DHIS2 hierarchy. Their parent organisation units geometry should contain all facilities which have been associated with them.
Recommendation
Often boundary files are simplified when they are uploaded into DHIS2. This process may result in facilities which are located close to the border of a given district to fall outside of the district when the boundary is simplified. This is considered to be more of a cosmetic problem for most DHIS2 installations, but could become an issue if any geospatial analysis is attempted using the boundaries and point coordinates.
In cases where the facility falls outside of its parent’s boundary you should confirm that the coordinates are correct. If the location is close to the boundary, you may want to reconsider how the boundary files have been simplified. Otherwise, if the location of the facility is completely incorrect, it should be rectified.
Organisation units should not have multiple spaces in their names
Level: Warning
Issue count: 26 (0%)
Introduction
Names of organisation units should not contain multiple spaces. They are superfluous and may complicate the location of organisation units when they are searched.
Recommendation
If the number of affected organisation units is small, the easiest remedy is to correct them directly from the user interface. Another possible option would be to replace all of the multiple spaces using SQL.
Organisation units close to Null Island
Level: Severe
Issue count: 0 (0%)
Introduction
A common problem when importing coordinates is the inclusion of coordinates situated around the point of Null Island. This is the point on the earths surface where the Prime Meridian and Equator intersect with a latitude of 0 and a longitude of zero. The point also happens to be situated currently in the middle of the ocean. This query identifies any points located within 100 km of the point having latitude and longitude equal to zero.
Recommendation
Update the coordinates of the affected organization unit to the correct location.
Organisation units with invalid geometry
Level: Critical
Issue count: 116 (7%)
Introduction
DHIS2 uses the PostGIS database extenstion to manage the geographical information associated with organsiation units. There are various reasons why geometries may be considered to be invalid including self-inclusions, self-intersections, and sliver polygons. Please see the PostGIS documentation for a more in-depth discussion on this topic.
Recommendation
Update the geometry of the affected organisation units to a valid
geometry. It may be possible to use the PostGIS function
ST_MakeValid to automatically fix the problem. However, in
other cases the geometry may need to be edited in a GIS tool, and then
updated again in DHIS2.
Organisation hierarchy should have a single root
Level: Critical
Issue count: 0 (0%)
Introduction
Every DHIS2 system should have a single root organisation unit. This means a single organisation unit from which all other branches of the hierarchy are descendants.
Recommendation
Once you have decided which organisation unit should be the real root
of the organisation unit hierarchy, you should update the parent
organisation unit. This can be done by using the DHIS2 API or my
updating the value directly in the organisationunit
table.
Organisation units with no coordinates
Level: Warning
Issue count: 1672 (51%)
Introduction
Ideally, all organisation units contained in the DHIS2 hierarchy should have a valid set of coordinates. Usually for all organisation units above the facility level, these coordinates should be a polygon which provides the boundary of the organisation unit. For facilities, these are usually represented as point coordinates.
There can obviously be exceptions to this rule. Mobile health facilities may not have a fixed location. Community health workers or wards below the facility level may also not have a defined or definable coordinate.
This check is intended to allow you to review all organisation units which do not have any coordinates and make a determination as to whether they should be updated.
Recommendation
Where appropriate, update the geometry of each organisation unit with a valid geometry. You may need to contact the appropriate local government office to obtain a copy of district boundaries, commonly referred to as “shape files”. Another possibility is to use freely available boundary files from GADM (https://gadm.org)
If facilities are missing coordinates, it may be possible to obtain these from the facility staff using their smart phone to get the coordinates. Images from Google Maps can also often be used to estimate the position of a facility, assuming that you have good enough resolution and local knowledge of where it is located.
Completely orphaned organisation units
Level: Critical
Issue count: 0 (0%)
Introduction
Orphaned organisation units are those which have neither parents nor any children. This means that they have no relationship to the main organisation unit hierarchy. These may be created by faulty metadata imports or direct manipulation of the database.
Recommendation
The orphaned organisation units should be assigned a parent or removed from the system. It is recommended to use the DHIS2 API for this task if possible. If this is not possible, then they may need to be removed through direct SQL on the DHIS2 database.
Organisation units which belong to multiple groups in a group set
Level: Severe
Issue count: 50 (1%)
Introduction
Organisation units should belong to exactly one group within each organisation unit group set of which they are a member. If the organisation unit belongs to multiple groups, this will lead to unpredictable results in analysis.
Recommendation
Using the maintenance app, assign the organisation units in the details list to exactly one group within each group set membership.
Periods
Distinct periods with the same start and end date
Level: Critical
Issue count: 0 (0%)
Introduction
Different periods should not have exactly the same start and end date.
Recommendation
All references to the duplicate periods should be removed from the system and reassigned. It is recommended to use the period with the lower periodid.
Periods which are more than three years in the future
Level: Warning
Issue count: 7 (0%)
Introduction
Periods in DHIS2 are automatically generated by the system. As new data is entered into the system, new periods are automatically created. In some cases, periods may mistakenly be created when data is sent to DHIS2 for periods which are in the far future. Different data entry clients may not properly validate for periods which are in the future, and thus any periods in the future should be reviewed. In some cases, data may be valid for future dates, e.g. targets which are set for the next fiscal year.
Recommendation
If any periods exist in the system in the future, you should review the raw data either directly in the datavalue table, or alternatively though the pivot tables to ensure that this data is correct.
In many cases, clients may mean to transmit data for January 2021, but due to data entry errors, January 2031 is selected. Thus, any data in the far future should be investigated to ensure it does not result from data entry errors.
Periods which are more than thirty years in the past
Level: Warning
Issue count: 1 (0%)
Introduction
Periods in DHIS2 are automatically generated by the system. As new data is entered into the system, new periods are automatically created. In some cases, periods may mistakenly be created when data is sent to DHIS2 for periods which are in the distant past. Different data entry clients may not properly validate for periods which are in the distant past, and thus these periods should be triaged to ensure that data has not been entered against them by mistake.
Recommendation
If any periods exist in the system in the distant past, you should review the raw data either directly in the datavalue table, or alternatively though the pivot tables to ensure that this data is correct.
In many cases, clients may mean to transmit data for January 2021, but due to data entry errors, January 2031 is selected. Thus, any data in the far future should be investigated to ensure it does not result from data entry errors.
Validation rules
Validation rule missing value stratgies which are NULL
Level: Severe
Issue count: 0 (0%)
Introduction
Validation rules are composed of a left and right side expression. In certain systems the missing value strategy may not be defined. This may lead to an exception during validation rule analysis. The affected validation rules should be corrected to with an appropriate missing value strategy.
Recommendation
Using the results of the the details SQL view, identify the affected validation rules and which side of the rule the missing value strategy has not been specified. Using the mainteance app, make the appropriate corrections and save the rule.