dhis2-devs team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

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


On Thu, Nov 22, 2018 at 6:05 AM Elmarie Claasen <elmarie@xxxxxxxx> wrote:

> 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*
>
> [image: Hisp logo]
>
> Project Manager
>
> Health Information Systems Program
>
> Tel:      041-367 1027
>
> Cell:     082 374 2209
>
> E-mail: elmarie@xxxxxxxx
>
> Skype:  elmarie.claasen52
>
>
>
> *From:* Dhis2-users <dhis2-users-bounces+elmarie=
> hisp.org@xxxxxxxxxxxxxxxxxxx> *On Behalf Of *Jason Pickering
> *Sent:* Thursday, November 22, 2018 12:34 PM
> *To:* gerald thomas <gerald17006@xxxxxxxxx>
> *Cc:* dhis2-users@xxxxxxxxxxxxxxxxxxx; dhis2-devs <
> dhis2-devs@xxxxxxxxxxxxxxxxxxx>
> *Subject:* Re: [Dhis2-users] [Dhis2-devs] WHO DQA tool and Zeros not
> storing in DHIS2
>
>
>
> 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@xxxxxxxxx>
> 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@xxxxxxxxx>
> 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).
>
> [image: image.png]
>
> 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@xxxxxxxxx>
> 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@xxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>
>
>
>
> --
>
> Jason P. Pickering
> email: jason.p.pickering@xxxxxxxxx
> tel:+46764147049 <+46764147049>
>
> *This message and any attachments are subject to a disclaimer published at
> http://www.hisp.org/policies.html#comms_disclaimer
> <http://www.hisp.org/policies.html#comms_disclaimer>.  Please read the
> disclaimer before opening any attachment or taking any other action in
> terms of this electronic transmission.  If you cannot access the
> disclaimer, kindly send an email to disclaimer@xxxxxxxx
> <disclaimer@xxxxxxxx> and a copy will be provided to you. By replying to
> this e-mail or opening any attachment you agree to be bound by the
> provisions of the disclaimer.*
>


-- 
Jason P. Pickering
email: jason.p.pickering@xxxxxxxxx
tel:+46764147049