P2P/FHIR Core - Confirm device time is correct using GPS or network

[ekigamba]

We are using the lastUpdated time for P2P sync. This value is generated by the device. Because of the above we need to take the device date seriously. I think we should consider using GPS and network to get the latest date everytime the user logs-in so that the date is up-to-date. We should also force relogin/date-recheck when the date/time changes

LOE: 2 FTE days

[pld]

Sounds good, if the datetime changes, can't we do re-check w/o relogin?

[ekigamba]

We can definitely do a recheck without relogin.

The rough idea is that we block the UI while the device get's the latest GPS and we confirm that the date is correct. Incase the date is wrong, then we'd prevent interaction until the date is corrected.

I think we can build on a solution for this for the following cases:

• users changing the device date/time
• devices which have been off and do not have the correct date/time eg. Liberia

[pld]

Can we do the gps check in the background unless it's been past some threshold since last check and then we have it be a blocking step in p2p.

I wonder how easy it is to acquire a gps signal in the environment this will be used

[ekigamba]

We can do it in the background, however we ran a bigger risk if we allow the user to continue interacting with the app(not p2p) when the device date and time is wrong.

New records/updates will be saved with the wrong date/time and this can cause unintended effects during p2p sync, data reporting, scheduling and incorrect data.

Given that GPS signals might be hard to acquire, we can ask the guys in Liberia to test this out next time they are in the field. It was reported that the users in Liberia might leave the devices off and out-of-battery for a couple of days.

We can see if there's a better solution to this?

[pld]

That sounds good, we'll need to find a balance, but blocking or requiring some kind of admin override makes sense when the user has manually changed the date.

[HenryRae]

are there system default modals for the GPS / network date and time sync?

[ekigamba]

@HenryRae There are some system default modals that would be created but the user needs to be informed that the blocking process is ongoing. For us to enable GPS, the user might be requested for location permissions and to turn on GPS. After the permissions have been given and location enabled, the app waits until it receives an accurate location + time. The process while retrieving the time from network is a bit different because it will be a process controlled by the app and therefore no system modals.

[HenryRae]

So does this mean you don't need modal design from us? @ekigamba

[ekigamba]

@HenryRae For now, we will just need a page to block user ineraction and explain what is happening

[HenryRae]

Does something like this make sense? Nothing much user can do besides:

1. maybe minimising the app and trying to adjust time manually themselves
2. giving the app permissions to access their location or any other setting required to update time automatically (when the adjust time button is clicked)

what do you think? cc: @ekigamba @rowo

[ekigamba]

@HenryRae Yea, this is fine :+1:

[ekigamba]

STEPS

Whenever:

1. Device boots
2. The date/time changes

• We set a flag to confirm the date time
• When the app is openned, we should a screen explaining that we are confirming the date/time which could cause data corruption if wrong.
• The app confirms the date/time in the background and then requests the user to change the date/time. Clicking on the Change date/time button takes the user to the date/time settings page. The app starts a timer so that we can check the error margin without having to get the correct date/time again
• We confirm that the new date/time is within a certain error margin and allow the user to login and set the confirm the date time flag to false. If not, we provide the correct date/time and request the user to change it
• This check should be configurable

LOE: 2 FTE days

[pld]

• is this only after login? and if p2p is enabled?
• if the user background the app will the timer still work?
• if the user closes the app will the timer still work?

[ekigamba]

is this only after login? and if p2p is enabled?

This is before login. I believe that it should be a FHIR Core issue also. We previously had this on OpenSRP and it would force you to login via internet when the date/time changed. Currently, I believe it maintains data integrity in the app. I also believe it's going to be needed in Liberia where this brought up as a possible issue.

if the user background the app will the timer still work?

Possibly not. I assume this almost similar to closing the app

if the user closes the app will the timer still work?

No, the user will have to repeat the same process until the flag is reset. The time is stopped after the correct date/time is set. It's purpose is to prevent retrieving the date/time from the network/GPS again to confirm the user entered the correct date/time once back from the date/time settings page

[pld]

k, the other factor with Liberia is that many users will never have access to the internet, so we wouldn't want this to block them from being able to use the app.

[ekigamba]

Yea, we'll be using a combination GPS and cell network

[pld]

Is cell network required? I'm not sure if they'll have access to that when it's in use, but I don't think so. @AnnieMungai do you know?

[ekigamba]

Sorry, we will use either that is available, since this is to be used across FHIR Core, we can implement both since cell network will be faster inside buildings/structures. Liberia version might quickly switch to GPS if cell network is not available

[AnnieMungai]

@pld @ekigamba confirming that network connection is not available. The phones do not have sim cards, and the network connection is not reliable.

[ekigamba]

Sources of date/time in selection order

• Cell Network
• https://worldtimeapi.org/ API
• GPS

The https://worldtimeapi.org/ API will be useful since it is fast, will work even during development and devices inside health facilities with neither SIM cards and poor GPS reception due to buildings.

[pld]

@AnnieMungai do you have a sense of how long it takes to get a gps fix in the areas healthcare workers are working? is this something we do in VTS?

[AnnieMungai]

@pld we are currently not collecting GPS data on VTS. It is not easy to get a GPS fix in CHW areas of operation. It was abandoned as it proved to be difficult to obtain- there is a lot of forest cover and heavy clouds.

[pld]

OK, so @ekigamba what alternatives do we have in a situation where there's no cell network, no internet, and no GPS availability?

[ekigamba]

OK, so @ekigamba what alternatives do we have in a situation where there's no cell network, no internet, and no GPS availability?

We can have an override code that enables the supervisor to ignore this page for the specific case(boot or system date-time change). We can also request the user to confirm that the date is correct after a boot but not force the check through internet, GPS or cell network.

This is the workflow:

• User logs in while online, we get the current date-time from the login response header and confirm it's almost similar to the device's. If not, we prevent login, open the date-time-incorrect-page and request the user to fix the date-time first.
• When the device boots, we can either request the user to confirm or force the date-time check. If we force the check, we can provide an admin/supervisor override code
• When the device date is changed from the settings, we force the date-time check with a possible admin/supervisor override code

During the date-time check, we can use either internet, GPS or network. I believe this issue affects FHIR Core because we have a number of FHIR Resource fields that are automatically populated with the device's date/date-time and will also spiral to make reporting inaccurate

[AnnieMungai]

@ekigamba @pld Currently, on VTS the device is connected to the internet before deployment (for the initial sync). The time/date is set to update automatically when the phone is being set up (it is part of the deployment checklist). If need be, and when the device is in the field with no internet connectivity, the device time can be updated manually if the time is off (this is only an edge case and is generally discouraged). cc @dubdabasoduba

[ekigamba]

@HenryRae

1. Can you provide the icon used in the design above?
2. Change the design above to suggest the date and time to the user

[HenryRae]

sorry, didn't get you right on the second request @ekigamba

[ekigamba]

sorry, didn't get you right on the second request @ekigamba

@HenryRae We already know the correct date and time and therefore need to suggest this to the user

[HenryRae]

if we do, we can't automatically adjust it? Do we just show the correct time to the user and request them to confirm it or update to the new time?

[ekigamba]

@HenryRae We cannot. We need to show the correct time and request the user update it to the correct date and time.

[HenryRae]

@ekigamba wondering how date and time will be updated with the lock apps used on FHIR apps like eCBIS. cc: @dubdabasoduba LINK to design draft

[dubdabasoduba]

@ekigamba wondering how date and time will be updated with the lock apps used on FHIR apps like eCBIS. cc: @dubdabasoduba LINK to design draft

@HenryRae most locking apps provide a way to unblock some settings. eCBIS has a setting to unblock the date. I think the date also affected something on VTS so they already figured out how to unblock just that.