Improving connections from ODK to other systems (with health focus)

ODK has been recognized as a Global Good for Health by Digital Square at PATH. As part of the Global Goods community, we have created a public Health Interoperability Roadmap, which will sit alongside other ODK priorities (improving longitudinal data collection, making web forms more correct and performant, improving geospatial features, etc).

Unlike many of the other Global Goods, ODK is not specifically a health tool. However, it is frequently used at scale for health-related projects around the world (e.g., polio eradication, verbal autopsies).

Additionally, ODK enables a robust collection of health data in traditionally underrepresented environments (e.g. community-level, humanitarian settings) which can be of benefit to healthcare systems. In addition, non-health data can also play a crucial role in informing health systems. For example, social and environmental factors have a significant impact on health outcomes, and gathering and integrating data on these factors can provide important insights into healthcare needs and priorities.

We have outlined a living roadmap below with short and long term goals, which will continue to evolve as we learn. Through this work we will evaluate the functionality that will deliver the most value for ODK users. For the purposes of this discussion, let’s use the following definitions:

  • Interoperability: ability for systems to communicate through shared standards. For example, ODK Central is interoperable with Power BI.
  • Integration: connecting systems using some kind of middleware. For example, ODK Central can be integrated with RapidPro so an SMS is sent when a submission contains test_result=positive.

Living roadmap

Phase 1: Known improvements (by Jun 2023)

Phase 2: Understand user needs (by Sep 2023)

  • Talk to maintainers of other Global Goods about their users’ interoperability needs with ODK and more broadly [@LN and @Thalie in progress]
  • Understand opportunities and challenges for people who are responsible for integrations:
    • What functions do users see ODK as bringing to health systems?
    • Which systems are ODK users currently actively integrating with (eg automatically or manually uploading data to or downloading data from)?
    • Which systems would ODK users like to integrate with and why?
    • What makes those integrations valuable?
    • What are the barriers or concerns preventing those integrations?
    • What is the ideal integration workflow?
  • Understand opportunities and challenges for people responsible for interoperability:
    • What are the current challenges with interoperability?
    • Which systems would users like to be interoperable?
    • In what ways do entities change the desirability of interoperability (e.g. because users have sources of truth for entities outside of ODK)?
    • What are scenarios in which native interoperability would be desirable? Can e.g. OpenHIM be made simple enough to deploy that it replaces the need for native interoperability?

Tentative Phase 3: Improve documentation and examples around integration and interoperability (Sep 2023 and beyond)

The specifics would be determined by findings above. Some examples:

Tentative Phase 4: Implement functionality that lowers the barrier to integration or interoperability (Sep 2023 and beyond)

For example:

  • Add support for API keys in Central. Currently interoperability systems authenticate using Web User accounts. Introducing API keys would make the separation between automated and human-initiated actions clearer and provide a way to give access to systems that don’t support Central’s authentication mechanisms.
  • Allow Central Web Users to authenticate using a configured identity provider so users have fewer identities to manage when integrating between systems (single sign-on or SSO)
  • Make Central a webhook publisher (if we find a significant need for real-time integrations)

How you can help

Please let us know what you think about the approach we propose and whether there are additional user needs or challenges we should consider and why. I’ll keep this post updated according to your suggestions and comments.

If you have specific answers to some of the research questions outlined, please answer here as well!

People I think will be particularly interested:


This sounds great! I'm very excited to see ODK evolving in the way described by @LN.

Background: I'm using ODK in my role as software engineer at the Against Malaria Foundation (AMF), for a number of tasks. AMF fund bednets and organizes their distribution together with other partners and governments. A typical distribution reaches all households in a country/province, at a scale of millions of bednets. ODK is helpful for:

  • Collecting household-level data during the registration (e.g., size and GPS coordinates of beneficiary households)
  • Recording bednets that are distributed
  • Keeping track of logistics (e.g., capture waybills as nets move to their distribution points)
  • Monitoring during and after the distribution.

Our needs and challenges, particularly with regard to ODK and DHIS2:

  • Governments in partner countries often choose solutions other than ODK for political/non-technical reasons. In particular, DHIS2 is often preferred because it is already used in the country, perceived as more secure, or just better known. This is a pity, because ODK is simpler and more reliable, leading to better-quality data.
    • There's a potential to improve documentation around security, and to publish case studies of successful ODK use.
    • Better fine-grained access control would also help (easier way to set up enumerator and supervisor accounts; better controls regarding who can see what data; limit some form elements (like a select_one question) based on the enumerator's access rights, ...)
  • DHIS2 works better than ODK in multiphase projects, like when there is a separate registration of households, followed by bednet distribution.
    • ODK's upcoming entity-based workflows might help here
    • Access control seems crucial for that (e.g., only sync entities that a user can access; avoid syncing millions of records to a phone)
  • DHIS2 has built-in dashboards
    • Some sort of dashboard or reporting feature integrated closely with ODK would help.
    • PowerBI is used by some partners, but the cost and inability to share dashboards is often a blocker.
    • Several of our partners use scrappy home-brew dashboards
  • More thoughts on DHIS2 and ODK (already linked-to by @LN above)

One more thought related to integrations, which doesn't really fit elsewhere: There is currently no good ODK export for large, complex forms. If a form is complex (e.g., has repeat groups), XLSX is the only option that I know of; CSV does not contain fields in repeat groups. Yet if the form is large (100k or more submissions) XLSX is slow or fails completely.

In such cases, we use the API, but that's a bit cumbersome and not all partners have the expertise. Alternatively, we split forms into multiple sub-forms, which is also cumbersome. I would love to have a CSV export that supports repeat groups, or an easy way to export a subset of submissions in XLSX.


I know of "Mirth Connect", which is an open source middleware software used by many health care providers. If ODK users are already aware of it and would like to see ODK connector in there then it would be a valuable addition.