What's the best way to break up forms for registering households and their members?

Support
,
1

Hola comunidad
actualmente estoy trabajando en un estudio de la situación nutricional en colombia. el formulario como tal son 6 formularios independientes donde en cada uno de ellos debo identificar siempre el hogar (ubicación). El formulario 1 tiene un registro de personas del hogar (en un repeat) y una seleccion de personas del hogar para saber quien aplica a los otros formularios.
un ejemplo sería

formulario 1 : identificación del hogar, registro de las personas del hogar ( esto es un repeat) y selección de personas (repeat) para los otros formularios.

formulario 2 ( antropometria) : identificación del hogar, toma de medidas de las personas seleccionadas en el formulario 1
formulario 3 ( mujer ) : identificación del hogar, encuesta solo para mujeres seleccionadas en el formulario 1
formulario 4 ( sedentarismo ) : identificacion del hogar, personas seleccionadas del formulario 1
formulario 5 ( alimentación ): identificacion del hogar, personas seleccionadas del formulario 1
formulario 6 ( muestras de sangre): identificacion del hogar, personas seleccionadas del formulario 1

Este es el flujo de información. Entiendo que podría hacerse por medio de entidades para conectar todos los flujos y que no se haga en todos los formuilarios la identificacion del hogar.

Como deberia funcionar mejor?
La entidad sería por hogar o por persona?
La entidad sería desde un repeat? es posible?

Agradezco su ayuda para saber como sería la mejor forma

Hello community,

I am currently working on a study of the nutritional situation in Colombia. The study involves six independent forms, where I need to identify the household (location) in each one. Form 1 includes a record of household members (in a repeat) and a selection of household members to determine who qualifies for the other forms.

An example would be:

Form 1: Identification of the household, record of household members (this is a repeat), and selection of individuals (repeat) for the other forms.
Form 2 (Anthropometry): Identification of the household, measurement of the individuals selected in Form 1.
Form 3 (Women): Identification of the household, survey only for women selected in Form 1.
Form 4 (Sedentary Lifestyle): Identification of the household, selected individuals from Form 1.
Form 5 (Nutrition): Identification of the household, selected individuals from Form 1.
Form 6 (Blood Samples): Identification of the household, selected individuals from Form 1.
This is the flow of information. I understand that this could be done through entities to connect all the flows, so that household identification does not need to be done in every form.

How should it function better?
Should the entity be per household or per person?
Would the entity be from a repeat? Is that possible?

I appreciate your help in determining the best approach.

2

Hi Carlos,
From your explanation I understand that there are 6forms, 1 is a registration and identification. The rest (forms 2 to 6) are follow ups.
Based on my experience and ease on logistics and analysis side it is better to have only two forms. That is the registration and identification form (form1) and a follow up form (containing forms 2 to 6) whereby each form title is treated as a group. Once the registration is done, you can create entities with household ids and particulars. Some of the core variables to store are household id, number of eligibles and eligibles to which form(now eligibles to which group of questions?). Each eligible should also have the unique id suffixed on the household id.

Once enumerator pulls a follow up form, then they can be instructed to key in household id which in turn pull the members eligibles (acting as the number of repeat counts for the larger group). The inner groups/sections (now form 2 to form 6) will be hidden/displayed by relevant expresion based on the current eligible household member profile.

My suggested approach simple and straight forward and here I presume that you dont intend to carry out a second follow up.

3

Hello Stephen. The initial idea is exactly your approach, but it is not possible because an enumerator, a nutritionist, and a bacteriologist interact with ODK almost simultaneously. What’s interesting about your proposal is how to achieve extracting variables such as age, sex, and order for the other forms using entities from Form 1?

4

Hey @Carlos_Andres_Sanabr ! :smile:

I shall be sharing a few approaches for the same based on my experience:

Approach 1 (fully automated approach):
Create 7 different forms, split the first form into two parts, so you will have:

  • Form 1: Identification of the household, details other than members about the household.
  • Form 1.1: Record of household members, and selection of individuals for the other forms, filled differently for each household member, is linked to the form 1 using household ID.
  • Form 2 (Anthropometry)
  • Form 3 (Women)
  • Form 4 (Sedentary Lifestyle)
  • Form 5 (Nutrition)
  • Form 6 (Blood Samples)

This will eliminate the repeat group, thus you will be able to use "entities" for entire data collection. The only thing to be cautious about in this approach is that the data collectors should carefully mention the household ID (generated in form 1) into the form 1.1. You will have to define the format and structure of the household ID.

Approach 2 (partially automated approach):
In this approach, there are no changes to the forms, instead you will have to develop a python (or maybe a power query m-code script) which will fetch and analyze the data from the form 1 and produce the entity list. The newly produced entity data can be appended to the entity list (the one being used by other follow-up forms, from form 2 to 6) manually or via script.

Approach 3 (the one I used two years ago as back then i had no experience with media files, entities, scripts, etc :sweat_smile: ):
Manual data collection, don't auto-fill the entries from form 1 to other other forms, let data collectors do the thing manually. There can be many errors in such a approach, which you as a project manager will have to handle, thanks to the review system and enketo in ODK Central!

Note:

  1. I recommend not merging the forms.
  2. I suggest having a day gap between filling the form 1 and other forms.
  3. Make sure to ask the data collectors to refresh their devices daily, normally they get refreshed on their own, but sometimes - who knows, no harm in refreshing once a day, preferably in morning. Though, if using the approach 1, then look into offline-entities as well, in that case the devices must be refreshed to synchronize the data over the server if the same device isn't conducting the follow-ups (form 2 to 6).

Great day ahead! :smile:

3 Likes
5

I’m definitely going with the proposed approach 1. Eternally grateful. MinimalPotato.

2 Likes
6

I love this thorough answer, @MinimalPotato! And I agree with you @Stephen_K_ojwang that in some cases it can be advantageous to combine forms. Entities with parent/child relationships is not something we support ideally yet so there are certainly tradeoffs. In the future, we intend to make it possible to update multiple Entities with one submission, including multiple ones of the same type within a repeat. That will make these kinds of relationships easier to establish and manage over time.

I think the tradeoffs are fewer now with offline Entities, though. With offline Entities, the household Entity created by Form 1 in @MinimalPotato's first approach will be available immediately in any forms that use the household Entity List. This gives you more options for minimizing or eliminating the need for data cleaning around the relationship between households and their members. This is also the approach I would tend to use. You would end up with two Entity Lists: households and household_members (or similar names). Each household_members Entity would have a link to the households Entity it is part of.

In Form 1.1 and other follow-up forms, you could still have your data collectors enter in a household id in a text field but then you could use that household id to look up information about the household, even if it was just created. This also lets you show information like the creation date and show a helpful error message if the household id entered doesn't match any existing registered household. You can also show all members that have been added to the household so far.

Instead of having data collectors enter the household id in a text field in Form 1.1 and others, you could instead start your follow-up forms by showing either all households or all households recently registered (e.g. in the last 3 days) in a select (from map, with autocomplete appearance, etc). Even though you can only create a single Entity with a form submission, you can attach any number of Entity Lists to a form.

Offline Entities require Central v2024.3.0 which was released last week. It also requires Collect v2023.3.0+ which has been in the Play Store for a little over a month.

You may also be interested in reading some previous threads about Entities with parent-child relationships like this one with @Baptiste_Monnier (@Baptiste_Monnier I just remembered this exchange we'd had! Hopefully offline Entities help you too).

2 Likes
7

"Thank you, I really appreciate the advice. One last thing, if I eliminate the repetition in the registry of people, how could I control the position without repeating it by household?"

8

You may want to say a bit more about what you need position for to get the best answer.

You could have a property for your members called number or something like that. When a household member gets added, you can compute the maximum number given so far and add 1 to it to get the next one. Here's a thread you'll likely find useful: Generate sequential ID based on pulled data - #8 by LN