WHO DQA tool and Zeros not storing in DHIS2

Dear all,

We are looking at the WHO tool and there was a concern about the zeros which are not storing in the PostgreSQL database.

Please is there any solution for these zeros not storing?

Is there another way for the WHO tool to differentiate between an actual blank space and Zeros?

Thanks in advance for your contribution.

···

Regards,

Gerald

Hello Gerald,

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).

image

Once that is done for all the Data Elements, then the Form will be able to store Zero values.

Regards

···

Barnabas AKUMBA

Mobile: +2348036195778

Skype: barnabas.akumba

Dear Barnabas,

Thanks for your help.

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.

image

···

Regards,

Gerald

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.

Regards

image

···

Barnabas AKUMBA

Mobile: +2348036195778

Skype: barnabas.akumba

Thank you for the clarification.

image

···

Regards,

Gerald

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!

Best regards,

Jason

image

···

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

Dear Jason,

Thanks for the confirmation. Based on our discussions few minutes ago; the M&Es think this will help them to show the performances of their programs.

For example:

In a particular facility A; during the months Jan, Feb, Mar, Apr, May; the cases of measles are 5, 8, 9, 0, 10…

In our data collection, Apr will be seeing as no entry ( which means we can’t identify whether it is zero measle case or no entry was done.

image

···

Regards,

Gerald

Hi Jason,

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.

Regards,

Elmarie Claasen

Hisp logo

Project Manager

Health Information Systems Program

Tel: 041-367 1027

Cell: 082 374 2209

E-mail: elmarie@hisp.org

Skype: elmarie.claasen52

image

···

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!

Best regards,

Jason

On Thu, Nov 22, 2018 at 5:03 AM gerald thomas gerald17006@gmail.com wrote:

Dear Barnabas,

Thanks for your help.

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.

On Thu, Nov 22, 2018 at 9:50 AM Barnabas Akumba akumbabarns@gmail.com wrote:

Hello Gerald,

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.

Regards

On Thu, Nov 22, 2018 at 10:42 AM gerald thomas gerald17006@gmail.com wrote:

Dear all,

We are looking at the WHO tool and there was a concern about the zeros which are not storing in the PostgreSQL database.

Please is there any solution for these zeros not storing?

Is there another way for the WHO tool to differentiate between an actual blank space and Zeros?

Thanks in advance for your contribution.

Regards,

Gerald


Mailing list: https://launchpad.net/~dhis2-users
Post to : dhis2-users@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-users
More help : https://help.launchpad.net/ListHelp

Barnabas AKUMBA

Mobile: +2348036195778

Skype: barnabas.akumba

Regards,

Gerald


Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

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!

Best regards,

Jason

image

image

···

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049