dhis2-devs-core team mailing list archive

[Markus Bekken <markus.bekken@xxxxxxxxx>]

Hi all!
In the Palestine context we are discussing a lot around offline support these days. We had one thread going on the subject, and after some more discussions we are ready to start a new one :) Ultimately we want the Palestine app to be a configured version of the Tracker Capture app. Therefore every change we make needs to be platform enhancements and enhancements to the exiting Tracker Capture app. The discussion below is initiated with the Palestine tracker in mind, please help us providing your thoughts on the offline support from your point of view. 

To some of you this is old news, but the level of offline support needed in Palestine seems to exceed the current general support in the web apps. The Palestine/RMNCH tracker is a Point of Care solution, and if it stops working even for a short while it will be a big practical problem for the health worker. It is expected that we from time to time will experience offline-situations, at least in rural parts of Palestine. They might last for hours or even days. To avoid falling back to paper in these situations, we need to be able to continue to register data on program stages even when offline, and the health workers needs to be able to log off and change shifts even in offline mode. The data should be stored in a secure way. Then, when online after an offline period, the offline data should be sent to the server in some way. See breakdown below.

Offline data registering
To be able to register data for program stages even when offline, we can think of three main needs: 
-A local copy of tracked entities and program enrollments native to the clinic in question.
-Ability to store new program stages locally for the existing program enrollments.
-Ability to create new tracked entity instances and program enrollments while offline.

Offline re-authentication
To enable the health worker to log off and change shifts(someone else logs in), we can think of the following concept:
-A local list of users is kept. The list can for example contain every user connected to the clinic, or it can contain every user that has logged into the system before. The register would conceptually contain the username and a one-way-hash of the password.
-When attempting login in offline-setting, the username and password is only compared to the local register.
-When attempting login in online-setting, the username and password is authenticated with the server as normal. Then the potential unsent offline-content is sent to the server(possibly only for the user that logs in).

Offline secure data storage
This is not a requirement very specific to the Palestine tracker, but one might argue that the strengthened offline support drives the need for a more secure storage(i.e. no storage in clear text). This area we have not yet dug too much into yet. An encryption mechanism can be a bit tricky; if we use a symmetric key encryption, we would have to keep the key stored locally somehow.

Sending offline data when re-connected to server
To send data when reconnected, we have to come up with a mechanism that allows for the data accumulated in offline mode to be sent. Along broad lines we can imagine that we either queue the requests that was not sent to the server, or that we do syncing of the local data with the server - inspecting the local changes to find the records not yet reflected in the server. Perhaps the group has some views on the rough feasibility and complexity on the approaches. It will probably also have an impact on the possibilities for a merge/conflict resolution mechanism. For Palestine we can hopefully keep the merge quite simple.

Looking forward to hear your thoughts on the various offline topics. Let us see if we can fit a phone meeting with the extended core and mobile teams once we have had a mail iteration or two.

Thanks and regards,
Markus

p.s. Sorry to the mobile team if you received this mail twice. The first sendout didn't go to the core group correctly.