3 Considerations for Offline Data Collection

The world is getting more connected, but not for everywhere

Mobile connectivity is improving all over the world, and according to the GSMA, the number of people connected to mobile services surpassed 5 billion globally, with 3.7 billion in developing markets. As such, two out of three people in the world had a mobile subscription at the end of 2017.

But in many parts of the world, it’s still a struggle to get a decent 2G connection – people still travel to make calls or use the internet on their phone. How can we ensure our mobile data collection applications work for people in rural areas?

Use a tool that can collect data offline

Data still needs to be collected, even in areas without reliable internet. Therefore, one of our key principles is to build for offline first. Obviously, we are partial to CommCare, but a number of tools operate offline, handling workflows entirely on the fieldworkers’ phones. The only time internet is required is to sync this information to the server to ensure it can be analyzed.

Simply functioning offline is one thing, however. Thriving is another. Design the program with this in mind from the very beginning to help optimize your data flow from the user to the server – for example, evaluate each step, from collecting data to syncing the form, and consider who needs access via the web dashboard and when. You want to make sure that more complex workflows can continue offline, without utilizing features that rely on network connectivity.

Here are three key considerations when designing for offline data collection:

1) Assess the landscape

Before you start to design your app, it’s a good idea to take stock of the situation. Figure out what the local network can handle (and exactly how “local” it really is) by answering these simple questions:

• Which networks are available in the area in which you are deploying?
• Interview people who live in the area – which SIM/network do they use and prefer?
• Anecdotally, what can they achieve on the network? Just calls? SMS? Whatsapp?
• If they need an internet connection, how far must they travel? To the nearest health center?
• Is a new mobile tower being built or coming online soon? Or will the area you are working in remain mostly unconnected for the foreseeable future?

2) Start formulating a plan for network accessibility

At the end of the day, you will need to upload the data you collect to your server. Fortunately, there are a few different options to do so. Here are a few approaches that may work in different situations:

Coverage with multiple networks

In Malawi, there are two major networks and each covers a different area. One project we work with covers different districts, so some fieldworkers will have SIM cards for Airtel and others on the national network TNM. This requires each fieldworker to state their preference according to their location. It does make managing data top-ups more complex as the project deals with two network providers, but this added complexity pays off when most fieldworkers can connect easily to 2G or 3G network wherever they go.

Travel weekly to an area with better network coverage

Health centers typically have better network coverage than most of the locations fieldworkers will need to visit. So, if they have to check in once a week at a health center in town, you can build this into the data collection process as the time when they upload their data. Ensure that training emphasizes that they must bring their devices to this meeting, fully charged so they can all sync on this day.

Alternatively, if they regularly go to town for personal reasons, find out if they can bring their phones and ensure they sync then. If this becomes part of the program design, ensure it is communicated clearly and covered as part of a training manual or standard operating procedure.

Travel to download their data

Certain areas that your project covers will not have any internet connection, and workers could be stationed there for months at a time. In these situations, instead of syncing forms directly to the server fieldworkers may have to transfer forms to a host tablet. This host would then be returned to an area with Internet connectivity and sync all the forms to the CommCare HQ server.

This approach is like temporarily collecting data on paper again while retaining the accuracy and some of the speed benefits of mobile. However, if you lose or damage your stack of papers (i.e. phone), that data you spent so much time collecting is gone forever. This approach could be used for projects that only need to collect data and don’t require regular syncing.

3) Design the app with constraints in mind

If your field workers are not able to sync daily, their workflow should support this and not rely on any information being synced more regularly. This is where the application’s design becomes important, and should not use features that require frequent syncing.

Two case studies on referral design:

A common use case is a field worker who screens a patient, but if the patient needs further care, they must be referred to a properly equipped health facility to see a doctor. The following is how two different mobile data collection apps approached this workflow:

Project A – Referrals need a network connection because they are sent from one app to another via case sharing (from a community health worker in a village to a doctor at the health center)

Project B – Referrals were designed to work entirely offline using paper as the link, but still capture final referral outcomes digitally

What ends up happening with the limited connectivity of Project A is that the referrals aspect of the workflow couldn’t always happen. Referrals were made but never followed up on. In Project B, the referral and outcome could be recorded, though they were not handled entirely “online.” Let’s take a deeper look at the two approaches:

Project A diagram:

In low-to-no connectivity environments, each point with a red signal icon is a potential broken link in the system. For example, if the nurse tries to sync the data from her app to find a referral without a signal, the referral will not appear on her app. This means she cannot fill in the outcome or send it to the community health worker. This referral link is broken and will not have a properly recorded outcome.

Project B diagram:

Even though much of the referral workflow is handled by paper, the outcome is still captured electronically and therefore referrals and outcomes are not dependent on a network connection. The network is only needed to sync all the data captured with the server to ensure it isn’t lost.

Here are the strengths and weaknesses of each of these approaches:

Wrapping it up

Hopefully, the world continues to get more connected and offline becomes a distant memory. But until we all reach that point, there will still be rural beneficiaries whom you won’t be able to serve unless your mobile data collection app functions offline.

However, if you carefully consider the landscape, formulate a plan for these situations of limited network accessibility, and design your workflows accordingly, your project should still be able to collect its information and deliver its impact, even without regular access to the internet. Good luck!