Longitudinal population monitoring using Entities in ODK central

Support
1

1. What is the issue? Please be detailed.

Can entities be used to monitor a population in a designated region over time ? Here are a few of the key elements of the problem :

  1. Initial baseline data collection of all locations (dwellings) and individuals. A few projects also like to keep track of families (households) and the relations in the family. Locations, individuals, and households are data entities that should persist across multiple data collection iterations. Individuals are associated with a location and sometimes to a household.

  2. Followup visits to a location may result in updates to the location, individuals, and households. Individuals may be born, die, or move. Locations can be abandoned. In addition, some events (like pregnancy) may be recorded during a visit. In some projects, internal movement in the study area is important to keep track of (individual A moves from location 1 to location 2).

  3. It is useful to have the current location and household of an individual readily available (in the individual entity record ?). Specifically, can the individual entity have a reference to a location entity and possibly a household entity ?

  4. Ideally, all individuals in a location could be listed when a field worker visits the location. Even more ideal would be to have a hierarchy of region/subregion/locations where only locations within a subregion could be accessible.

  5. For reference, one central purpose is to determine the total number of person days of "risk" in a region during a user-specified time interval. The longitudinal data about individuals and their changes through time contained in the various forms must be sufficient to make this calculation. Projects will layer research studies on top of this longitudinal core of data

2. What steps can we take to reproduce this issue?

Not relevant

3. What have you tried to fix the issue?

  1. Reviewed the documentation about entities, reviewed XLSForms
  2. Attempted to installed ODK central (failed) and posted problem to forum
  3. Searched forum posts about entities
2

Apologies for the radio silence here, hopefully an answer will still be helpful for someone.

This is a kind of workflow that we aspire to support and that can be supported at this time, but the current limitations may not make it very practical.

Currently, a single form submission can only create or update a single entity. This means you can't do something like have a form definition with questions about a household followed by a repeat for individuals associated with that household and create entities for each individual.

What you can do is have an existing list of households and associate individuals to those pre-populated households. For example, you could identify dwellings from satellite imagery and label them somehow. You could have a form to collect information about those dwellings and a second one to collect information about individuals. Here would be one possible workflow:

  • An enumerator uses the household form to navigate to a household based on its location (e.g. using a map showing selectable dwellings).
  • Once they reach the household, they continue filling the form with household-level information.
  • One of the things that filling out that form does is change the status of the household entity to mark it as "enumerated" or "needs additional visit", etc
  • After filling out household data, an enumerator would fill out one individual form per individual in the household. The first question in the form would be to select the household entity. Households that have already been enumerated would be filtered out based on the entity state. The default value could be based on the last saved one to speed up entering multiple people from the same household

One big limitation that even this workflow would encounter is that entities are currently only created and updated after a server round trip. This workflow would work best in a context with sporadic data connection so that the household status could be updated. It would require constant connectivity if there's information from the household entity that needs to be available when filling out data about individuals.

Yes, but this is not a concept that the platform knows about. That is, you can attach many entity lists to a single form and you can store entity ids as the value for entity properties. In your case, you could store a location entity id in the "location" property of a household. But the system doesn't know that these establish a link between the two entity types and do things like provide you nice menus to pick one from the other. It's up to you to use form building blocks to create appropriate selects and other question types to establish those connections.

You can define this in your form using region/subregion/etc properties on entities. What doesn't currently exist is a way to dynamically build a list of unique regions from household entities that each have regions defined. You'd have to do this through an external process (e.g. through the API) or have a prepopulated list of regions (probably an entity list).

If you have set points in time or number of points in time, you could express these as properties on the entity. For example, you could have "visit_date1", "visit_date2", "heart_rate1", "heart_rate2", etc that gets filled out by different submissions of an update form. Alternately, you could use entities just to coordinate work (keep track of what has been completed and what hasn't) and use the submissions for final analysis.

If you haven't already, I recommend taking a look through this entities tutorial to see some of these ideas applied more concretely.