We are trying to determine whether DHIS2 supports the following setup natively, or if anyone has implemented something similar before.
We run mobile clinics in remote communities in Panama where there is no internet during the clinic day. Once we return to base camp, we regain internet access and sync devices back to the central server.
Right now, if a patient is registered on tablet A, that same tablet has to physically follow the patient through triage, provider, and pharmacy because tablets cannot reliably share Tracker data while offline.
What we are considering instead:
Bringing a small portable server to the clinic
Running a local DHIS2 instance on that server
Connecting all Android tablets to the same local Wi-Fi network (without internet)
Having all tablets connect to that local DHIS2 server during the clinic
Syncing the local clinic server back to the main server once internet becomes available again
So essentially:
Central DHIS2 Server ↔ Local Clinic DHIS2 Server ↔ Android Tablets on Local Wi-Fi
Our main question is:
Can the Android Capture application reliably work against a local network-connected DHIS2 instance in this type of setup?
We understand this would probably still require manual sync actions between stations and would not be true real-time synchronization.
More specifically:
Has anyone implemented something similar before?
Would Android Capture still keep data siloed locally per tablet?
Would manual sync between operations make this workflow practical?
How reliable is Tracker sync afterwards?
Any major issues with conflicts, duplicates, or local deployments?
We attached a simple diagram of the architecture we are considering.
Would really appreciate any advice or experiences from others working in low-connectivity settings.
Thank you for sharing this interesting use case. I have worked with the DHIS2 Android app in remote settings where the server was hosted in a different town and tablets relied on intermittent internet connectivity.
From my experience, offline data capture generally worked well as long as devices were able to sync once connectivity became available again. One issue we did encounter was around metadata changes. For example, if updates were made to forms or configurations on the server while Android devices still had older metadata, syncing could sometimes fail until the devices were updated with the latest changes.
I personally have not experienced duplicate records in those deployments, but metadata/version synchronization was definitely something we had to pay attention to.
I also do think @nancyesp may be able to provide additional insight here, especially given her experience with the Android Capture app.
Thank you for sharing your use case. This is a perfectly valid setup if it is properly managed. The Android Capture app can work against a DHIS2 instance located in a local network (without internet) in the same way it would work against an online instance.
As @Mayamiko mentioned, keeping everything on sync is challenging. Certain metadata changes can make the sync process fail, and this is specially relevant when the metadata changes have to propagate from the central instances to the offline instances, and then to the android devices. If the changes are properly planned, it shouldn’t be a problem
The android devices will have to sync data as soon as it is collected so that other devices can fetch it and use it. There is not such a parameter to upload the TEI right after the creation or edition (this has been discussed as an potential feature) so it will be important to educate the users to upload data very often.
I think this setup has been implemented in production out there. As far as I know, MSF used this setup in some of their projects. Maybe @acasrod can give more information about their experience in this kind of setup.
