Storing of zeros in the DHIS2 is configured during the Data Element Creation stage. There is an option where you need to enable the Data Element to store zero values (see attached screen shot).
Once that is done for all the Data Elements, then the Form will be able to store Zero values.
The issue now is that we had been ignoring it all this time. Now, we want to consider it again which means we will have to enable them as a batch by API method but I am inquiring if the previous missing zeros will appear.
Hello Gerald,
The Zeros were not stored so there won’t be any way of recovering them. The only option would be for you to update the Data Entry with the Zeros again after you must have enabled the “Store Zero values” option.
Hi Gerald,
No, they will not appear unless people re-enter the data. When this setting is used, what happens on the client side, is that even if people enter a zero, it will never get transmitted to the server. In most cases, having zeros simply leads to massive numbers of zeros stored in the database, which are not important when things get aggregated. Users are often not consistent about entering zeros, and trying to divine what the user’s intent was, can be exceedingly difficult. This is the reason that the “Complete” button was implemented. With proper training and messaging, this can be used to indicate that the report it complete, and that everything which is blank, should be able to be assumed to be zero. Often people want to try and use a zero to indicate that a particular service is offered, but that there were simply no clients for that reporting period. The problem of course is whether the data entry staff understand this. I am not sure what the need for zeroes actually is in your case, but you may want to consider to use the completion information instead, if possible. We have seen numerous cases were more than 60% of the values stored in a DHIS2 database are zeros. This leads to slower performance of analytics, as well as inflation of backup sizes, so I hope if you do change this, to think carefully about whether you really, really need all those zeros!
These explanations are helpful. As Gerald mentions it is tricky though if you want to use the WHO DQ app to find missing values which then flags all nulls as missing whether the complete button on the dataset has been pressed or not. So in this scenario we have 2 options – capturing zeros which is not advised as you point out as it does not affect the aggregated values and bloat the database. The 2nd option is that the WHO app could be bit more sophisticated to check for the complete flag before flagging a value as missing which in my view is 1st prize.
In SA we currently implement a solution where we save zero values in order to monitor completeness but then delete them at the end of the reporting financial year because then completeness monitoring is no longer a priority for that period.
No, they will not appear unless people re-enter the data. When this setting is used, what happens on the client side, is that even if people enter a zero, it will never get transmitted to the server. In most cases, having zeros simply leads to massive numbers of zeros stored in the database, which are not important when things get aggregated. Users are often not consistent about entering zeros, and trying to divine what the user’s intent was, can be exceedingly difficult. This is the reason that the “Complete” button was implemented. With proper training and messaging, this can be used to indicate that the report it complete, and that everything which is blank, should be able to be assumed to be zero. Often people want to try and use a zero to indicate that a particular service is offered, but that there were simply no clients for that reporting period. The problem of course is whether the data entry staff understand this. I am not sure what the need for zeroes actually is in your case, but you may want to consider to use the completion information instead, if possible. We have seen numerous cases were more than 60% of the values stored in a DHIS2 database are zeros. This leads to slower performance of analytics, as well as inflation of backup sizes, so I hope if you do change this, to think carefully about whether you really, really need all those zeros!
The issue now is that we had been ignoring it all this time. Now, we want to consider it again which means we will have to enable them as a batch by API method but I am inquiring if the previous missing zeros will appear.
Storing of zeros in the DHIS2 is configured during the Data Element Creation stage. There is an option where you need to enable the Data Element to store zero values (see attached screen shot).
Once that is done for all the Data Elements, then the Form will be able to store Zero values.
Hi Elmarie,
Yes, I think that makes sense, but the bigger issue is that data entry staff may be spending many cumulative man hours entering a whole bunch of zeros into a form to make it appear that it is complete. This time could perhaps be better spent on ensuring that the quality of the data (which is not zero) is of good quality.
I think absolutely that the WHO app needs to take completeness into account in situations where the data element is not zero significant. It should also take into account the other situation, when zeros really are important, which should be very few cases I think But this app should not drive DHIS2 implementations to enter zeros which really could be better inferred with the use of the “Complete” button. I think your solution of removing the zeros for historical periods makes a lot of sense as well.
We have also seen situations where when zeros are used to assess “completeness”, that some data entry staff will zero out the entire form early in the data entry cycle, to make it appear that data has been entered, only to later go back and fill in the data once it becomes available. In these cases, looking at the audit log (and even auditing the completeness action itself) may provide better insight into what is going on.
As you can tell, I am not a big fan of zeros in the database. For the most part in DHIS2, zeros are imputed when needed to meaningfully aggregate the data. Otherwise, it would be really impossible to do any analysis in DHIS2!