DHIS2 Offline Clinic Architecture Using Portable Local Server

Implementation - Implémentation
, ,
1

Hi everyone,

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.

Thanks!
Hannah
Floating Doctors

DHIS2 desired setup
DHIS2 desired setup1693×929 287 KB

2

Hi @hannahchek,

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.

3

Hello @hannahchek,

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.

4

Hi everyone,

Small update from our side after doing an initial proof of concept.

We were able to get a local DHIS2 instance running and connect tablets to it over a local Wi-Fi network.

What we tested so far:

Local DHIS2 instance running on a laptop
DHIS2 version tested locally: 2.41.8.2
Setup: Windows laptop with Ubuntu/WSL + Docker
Network: laptop hotspot / local Wi-Fi
Devices: Android tablets connected to the local Wi-Fi

We confirmed that the tablets could reach the local DHIS2 instance and that Tracker data could be created against the local server. Specifically, we tested creation/upload of:

Tracked entity
Tracker event

So at a basic proof-of-concept level, this worked:

Laptop/local server → local Wi-Fi → Android tablet → local DHIS2 Tracker data

This is encouraging, but we are now trying to understand whether this is a safe and scalable field architecture before investing in hardware or building this into our real clinic workflow.

Hardware question

Because many of our clinics have no power during the clinic day, we are trying to identify the most realistic low-budget hardware setup.

We initially considered a mini PC, but the power requirement is a challenge because it needs an external battery or power station. For a low-budget pilot, a refurbished business laptop may actually be more practical because it already includes:

battery
screen
keyboard
Wi-Fi
troubleshooting access
built-in backup power

Possible low-budget setup:

Local server: refurbished laptop with 16GB RAM and SSD
Router: small travel router
Router power: USB power bank
Backup: external SSD
Tablets: Android Capture connected to local DHIS2

More robust setup:

Local server: mini PC or dedicated laptop
Router: travel router
Power: portable power station
Backup: external SSD
Tablets: Android Capture connected to local DHIS2

For those with field experience: would you recommend starting with a laptop-based local server, or is a mini PC + battery setup worth the extra complexity?

Metadata and version control

Another major concern is metadata consistency.

Our assumption is that the central server should remain the source of truth for metadata. The local server would only be a temporary clinic instance.

The safer workflow seems to be:

1. Central DHIS2 remains the source of truth for metadata
2. Local server is prepared before clinic using central metadata
3. No metadata changes are made locally during clinic
4. Data is collected locally
5. After clinic, data is exported/imported back into the central server

We are concerned that if metadata changes happen on both central and local servers, this could create UID mismatches, option set problems, program stage changes, or import errors later.

Questions:

Should the local server always run the exact same DHIS2 version as the central server?
Should metadata changes be frozen during the field period?
Is there a recommended way to prepare a local server with the correct metadata, users, org units, programs, and Tracker configuration before clinic?

Preloading data from the central server

For the workflow to be useful, we would likely need to preload relevant data before going to clinic, such as:

patients from the communities being visited
active enrollments
recent events
program metadata
organisation units
users/user roles

The intended workflow would be:

Before clinic:
central server → export relevant community/patient subset → local server

During clinic:
tablets connect to local server and collect/update Tracker data

After clinic:
local server → export new/updated Tracker data → import back to central server

We are trying to understand the safest way to do this. Should this be done through the Tracker API, metadata/data package export, a database copy, or another recommended approach?

Our biggest concerns are:

TEI duplicates
enrollment conflicts
event UID conflicts
Tracker ownership issues
updates made on central while the local clinic server is also collecting data
safe import of local Tracker data back into production

At this stage, our thinking is:

central server remains the source of truth
local server is temporary
metadata is not edited locally
only the relevant community/program subset is loaded locally
all imports back to central are tested first with dryRun

Does this sound like a reasonable direction, or is this likely to create major Tracker sync/import problems?

Any advice on hardware, metadata alignment, preloading Tracker data, and safely importing local clinic data back into the central server would be very helpful.

Thanks again,

Hannah

Floating Doctors Panama

5

Hi @hannahchek

It’s nice to see how far you’ve gone and making that poster above closer to field implementation. To the best of my knowledge there’s always a pilot testing phase for any implementation; however, I do understand your concern about investing in hardware before making sure that it will :100: work as expected.

Please consider my response as suggestion open for discussion and not the final word here. :folded_hands:

I went through your nicely detailed post and it looks like you’ve done a thorough work and that the main thing remaining is ‘testing’ which is why (although it’s not suggested anywhere in the dhis2 docs-guidance) I would like to make a suggestion to run the entire ‘Local Clinic’ in a simulation.

For the PC, you can use Virtual Box with the same hardware features (16GB RAM, CPU Processors) and install a your setup “DHIS2 version tested locally: 2.41.8.2 — Setup: Windows laptop with Ubuntu/WSL + Docker”. (You can download a Windows OS for testing purposes for free it will have a short expiration date from the day you download the ISO).

For the Network, you can simulate it using the GNS3 which will allow you to “create” a WiFi network with specific speed and features for the Android tablets to connect to. For the tablets, you can also create VMs of Android tablets then use these VMs within the GNS3 network simulation.

This will allow you to test everything virtually; however, you might need at least one high performing physical laptop to run the simulation without hurdles.

I agree with you that this is the most part that needs to be tested to ensure that no data is lost, no conflicts occur, and that the workflow happens as expected.

If I understood correctly, you plan to replicate this setup for multiple clincs which means you will have multiple local servers connecting with one cloud instance? Which is why, I will need to raise a question here and I will ask the team as well:

We already know that tablets connecting to a server will download their own pre-reserved unique IDs; however, if we have multiple local instances connected to one main cloud instance, how do we know that each local instance will provide the tablets connecting to it a unique set of IDs that none of the other local instances gave out?

image
image1003×700 88.1 KB

Yes, there is a big warning about this in the Metadata Synchronization - DHIS2 Documentation documentation. The local instance is meant to synchronize metadata from a central system and not create metadata on its own. Which is a big indication that users on the local instances must not be able to make metadata changes. Only give this permission to users who have access to the central instance and are aware not to make changes to the local instance.

I definitely think that this is the recommended approach to quote the docs, “The metadata schema changes between versions of DHIS2 which could make different metadata versions incompatible.”

Since you have many tablets working offline and then syncing. I think this make absolute sense. Making changes during data entry could cause issues with syncing.

Yes, before you start connecting tablets to the local instance, you will need to prepare the metadata at the cloud instance and then sync to the local instance.

I’m not sure I understand the question exactly, but if I understood correctly that you’re asking about the safest way to setup the metadata sync between instances, I think your best bet is to follow the same order as in the docs, Metadata Synchronization - DHIS2 Documentation … 1) Configure metadata versioning on central instance 2) Connect local instance to central instance 3) Configure automatic metadata synchronization on local instance. Only after you have the local instance syncing from the central instance, you’ll start connecting the tablets to the local instance.

I feel that most of my response is already a confirmation to what you already know, and yet, I think the best you could do is actually start by testing in a simulation to see everything tested in real time.