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

Community
1

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

Screenshot 2023-04-26 at 1.42.55 PM
Screenshot 2023-04-26 at 1.42.55 PM2472×1136 242 KB

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:

11 Likes
2

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.

7 Likes
3

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.

4

There are a few steps I would recommend for FHIR interoperability with a first focus on getting data out ODK and into the FHIR ecosystem of tools:

  • For drop down values/controlled data entry fields you can export the data fields as FHIR ValueSets. How you can do this is described in an IHE/FHIR profile called SVCM.
  • For a data capture form, you can describe what is being captured as a FHIR Questionnaire. Drop down data fields are bound to Valueasets. A row of captured data is a QuestionnaireResponse. There is something called Structured Data Capture (in particular structure map based extraction) that then let's you say how to transform these questionnaires into the appropriate FHIR resources (patient, observation, etc) With this approach you don't need to get wrapped up in the intricacies of the FHIR data model to add value. rather you can quickly make use of the FHIR standards and ecosystem of tools (Structure Maps) for ETL.

Note that this would make the phase 2 (or 3) project about getting a patient resource a more tractable problem - I am assuming here that each ODK implementation has variations of the data that comprises a patient.

For getting data into ODK, there is an IHE profile of FHIR called mCSD that tells you how to represent health facility, geographic data and location data. That standard is being or has already been adopted by multiple communities/products such as OpenHIE, WHO Geolocated Facility Dataset, DHIS2. You could of course export geographic data from ODK from the same spec.

Anyways, those were some quick thoughts. Happy to discuss more.

Cheers,
-carl

2 Likes
5

Happy new year everyone,

@litlfred even if I see where you are going (leveraging existing FHIR Questionnaire Response mapping to other FHIR resources) I would not convert odk XFORM to fhir questionnaire response because FHIR questionnaire miss some question type support, it would only be problems (maybe in few years when FHIR questionnaire would be more mature)

I am fully with @LN regarding mapping of entities but I would foresee more than the patient . Maybe a mapping entity-FHIR process would make more sense rather than 'just' the Patient mapping; or we might think of some "ODK FHIR ready entities" that comes with a mapping already defined by the community (ODK is neither an hospital management system nor a electronic medical record therefore an important simplification of FHIR resource sounds reasonable to me)

br

1 Like