Synchronizing Kobo data with DHIS2

User Support API
,
1

I am interested in tools and documentation about connecting Kobo with DHIS2.

Background: in my work (distributing bednets against malaria), DHIS2 is commonly used for storing and analysing data. We use it both for summary data (e.g., number of nets distributed per day in a given place) and individual-level data (e.g., GPS coordinates of a household that has received nets). People value the dashboards and analysis features of DHIS2. In addition, there are also political reasons for using it.

For data collection, however, Kobo is the better solution. It has simpler and more intuitive forms, better data validation, and requires fewer resources on the phones/tablets.

Existing information

Request for more information

Do you know other tools? Do you have success stories to share, or lessons learned?

1 Like
2

Hello @Sjlver,
interesting, thanks for sharing.
How will you solve the demand for data protection of personal-/household related data in this context?

3

@wroos the technical answer is that both ODK/Kobo and DHIS2 have mechanisms to limit who can access which part of the data (DHIS2 is a bit better). It is also possible to self-host either system (although that might well reduce security and reliability rather than increase it).

The political answer is more complicated… :frowning: but there is precedent (e.g., the Uganda vaccination project linked to above, and lots of successful uses of each system individually).

4

Yes.
A problem is that we cannot hide, i.e. limit visibility, of single data elements of a form on KoBo/ODK server level, for example GPS of household or member’s name. So, we decided to delete personal data elements before finalisation/submission. Furthermore, we remove (and separate) GPS elements from the dataset export for the main analysis.
Encryption and Briefcase export on local devices seemed not flexible enough for real-time monitoring, for data cleaning etc.

This are more “work-arounds” than comfortable data-protection solutions, like limited variable views, local encryption starting with the interview, temporary decryption view for specific users on server level, etc. (Fortunately, the kobo.humanitarianresponse.info server is in Irland; but the Kf server is in the USA.)

5

Here’s my summary of solutions, after a week has passed and I was able to do a bit more research.

  • Using OpenFn:

    • Well engineered, with lots of thoughts going into reliability and security (for example, syncs are idempotent and can be replayed. Credentials are stored safely. Security certification done).
    • Several success stories for connecting Kobo/ODK and DHIS2.
    • Basic principle: On submission, the Kobo servers send an HTTP POST request to OpenFn. OpenFn stores the message. It triggers a job that formats the data and inserts/updates it in DHIS2 using the DHIS2 API. Built-in connectors facilitate the task of parsing the Kobo message and formatting data for DHIS2.
    • I believe the process is a bit different for ODK (not 100% sure what it uses there, probably OData).
    • Costs: Users pay OpenFn for hosting and support (https://www.openfn.org/pricing).
    • Looks like the best solution overall for projects that can afford it.

  • Bao Systems’ KoboToolbox connector for DHIS2

    • Basic principle: This is JavaScript code that runs within DHIS2. It talks to Kobo’s API to fetch the form definition and data. The code then creates a matching DHIS2 configuration and inserts the data.
    • Limitations:
      • Does not support custom or existing data layouts in DHIS2
      • Requires Kobo’s API, does not support ODK or related systems.
      • Limited support for forms (e.g., no repeat groups)
      • Requires tweaks to DHIS2’s server setup to work around the browser’s same-origin policy.
      • No automated/real-time sync, since it runs in the user’s browser.
    • Would not recommend except for very simple integrations

  • Custom solutions:

    • Anecdotally, it seems common for people to build custom systems that connect to the OData feed from Kobo/ODK, process the data, and upload it to DHIS2’s API.
    • Examples are @Saad’s answer above, and other forum posts.
    • Benefits are that it’s potentially cheaper, does not rely on third parties.
    • Disadvantages: it’s hard to make this reliable, idempotent, secure…
    • Building blocks that could be used: Maybe OpenFn’s open-source tools, RuODK.

Another update of my thoughts: The DHIS2 Capture app is becoming better and has closed some of the gaps it had compared to Kobo/ODK. For example, adding a new tracked entity requires fewer clicks than it used to, and forms can be structured more intuitively. This means that the benefits of using a combination of Kobo/ODK and DHIS2 are smaller nowadays… the simplest solution might be to use DHIS2 Capture for those cases where the data needs to end up in DHIS2.

1 Like