-
-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Offline synchronization support #265
Comments
Hi @magp18 ! This is very well aligned with our goal of reaching the hardest to reach places.
In this scenario would the remote user ever have internet access, or always rely on the mobile health worker to replicate?
Many CHT functions rely on bidirectional replication so that changes made on the server end up getting back to the user. This means expected flows would fail in unpredictable ways. If the remote user has occasional (say, monthly?) internet access this may be acceptable, but to never have access would make this challenging. There are also some challenges about data security, because it's difficult to prove identity while offline, so if a random passerby requested the data how would the CHT know to block them? One option I have been thinking about is instead of using regular Couch/Pouch replication to achieve this, use an encrypted packet of data which can only be decrypted by the server. Then when the mobile health worker has a connection this is submitted to the server. The same can happen in reverse with the data being sent to the remote health worker being encrypted and downloaded on to the device. I think this is similar to your "alternative" approach above. I think this is a great topic, and could use some community discussion. Would you mind posting this to the community forum for additional visibility? |
Here my 2 cents comments (I am a colleague of @magp18 ) Regarding the security, could it be possible to use a server public key to encrypt the data on the APP
In addition a signature from the user "exporting the data" seems important, I would think of something like either a
in case of sync from the server, the data could be encrypted with the private SSL key of the server Regarding the data format, I don't really see security issue (mobile --> Server), for the otherway arround (server to app) it depends on the ACL/encryption in place on the app level:
br |
The person collecting all the data would have internet access as soon as he comes back to the main facility. The community health workers, assessing the patients in their devices would be fully offline if ever online.
Yes he (the person collecting data from all devices) would have access to internet periodically.
I think this is a very good point. Thanks for that suggestion, encrypting data might be a good solution. I will follow your advice and open it for discussion in the forum to see everyone's ideas. Thanks! |
I am not even sure if this would be at cht-android level or cht-core. I guess it would make more sense to have it in cht-core no? Otherwise I don't know how to get to the data and export it |
@magp18 Yeah it sort of needs to be in both, because android will handle the connection to the other device, and cht-core will provide the data. For now I think the forum is the right place to discuss what this would look like and to get more information about what the community needs. |
What feature do you want to improve?
Have a way of synchronize data offline with other devices. E.g. Health worker going to somewhere rural (being offline) would be able to synchronize data from other offline devices. He then could go to the main health facility, go online and synchronize with the main server.
Describe the improvement you'd like
Offline synchronization of data between two devices. Does not have to be bidirectional flow of data.
Describe alternatives you've considered
Download the data locally and the Health worker willing to collect the data would aggregate the data from every device in an USB key. He would then go to the main health facility and synchronize the collected data with the server.
Additional context
Mostly for full offline settings.
The text was updated successfully, but these errors were encountered: