Odd Dates

[QISPSK]

There are 47 events in DHIS2 listed as being sent in 2010. Panharith reached out to these providers and they mentioned that a lack of internet access may have changed the phone date to 01-01-2010 which was then reported when they submitted MCS app surveys. Not sure if this is a DHIS2 or a MCS app bug.

It appears that the issue may have been going on for a while now (according to the "Time Sent" DE), and seems to appear all at once for some providers (Mok Vuthy) and just from time to time for others (Lun Rotha (Sum Sina)).

Any idea why this may be happening?

[ifoche]

Hi @QISPSK,

The app uses the Android time to decide what in DHIS will be considered as the Event Date, this is, the date used for the analytics and for everything else. That time must be taken from the android phone, and not from the server, because server side all the events that arrive at the same time will have the same "last modification time". I mean, the server only knows about the events when they arrive, but the time we want to capture is the time the survey is created and not the time the survey is sent. Otherwise if we lost connectivity for a week, all that data would have the same event date.

The problem when we relay on the Android time is that we must be sure phones are always properly configured. Usually this is automatically done by Android if you activate the option for taking the time from the network.

So I think this is not really a MCS bug, nor a DHIS bug, but a problem without an easy solution apart from being sure the phones have time properly configured and fix any error in this sense server side.

Of course, we could always think on a new development like comparing the date of an event with the previous one stored locally and show a pop-up alerting in case the new event have an event date older than the previous ones...to give the user the oportunity of configure the time himself by hand before creating the survey. What do you think?

@rodmelia any further thoughts on this?

[QISPSK]

@ifoche That makes sense, very odd though. I think adding functionality to the app would likely further complicate things in that case. Instead, we should be able to manually update the dates in DHIS2 from our side.

In the case that this does happen, particularly where this happens multiple times, we can have a supporting officer remove the network acquired time and manually set the time on the phone which should prevent the issue (on that phone) going forward.

Thanks!

[rodmelia]

@ifoche @QISPSK I don't think we should think about new features to deal with this - this is a key piece of the functionality of the app: to record the actual time of when the test was conducted, which can ONLY be accomplish by using the date/ time of the phone, as we allow offline data collection. A phone connected to a 3G network having the wrong date/ time is almost impossible nowadays.

As part of data quality, you can create a program indicator/ or SQL looking for events for which the difference between the test date and the uploaded date is greater than 1w. My understanding is that normally you expect transmission the same day. Anything transmitted 1w after testing should be flagged as a suspicious record, and then you can investigate. This is all server-side, nothing to do with the app.