Multi-structure household data collection
Starting this page for scoping - Derek Pollard to review. Initial scoping done as part of R3 scoping overview
Status
# | Step | Status |
---|---|---|
1 | Responsible prepares rough business analysis/reqs doc | COMPLETE: Pierre Dane |
2 | Get CHAI review | |
3 | Get Akros/VW Review | |
4 | Get Ona feedback | |
5 | Responsible - 1 iteration for feedback | |
6 | Ona sign off | |
7 | Ona tech spec scoping | |
8 | Ona LOE | |
9 | Ona scheduling |
Definitions
Household - a group of residential structures headed by one Head of Household
Requirements
- Structures can be registered without adding a new head of household and family
- These structures will be linked to a household by selecting an existing Head of Household from a drop down list, with an 'Other' option
- Infield operational dashboards will show c
- MVP needs
- Group structures into household - support indicator management off of this grouping
- Ultimate needs
- Enter some family module questions at household level to apply to all structures
- Enter some family module, structure-specific data at structure level
- Ability to move people across structures within a household (Derek P: I would suggest this is not needed?)
- Ability to do campaign data collection at structure or household level depending on how the campaign is built
Notes
E-mail with CHAI team from Derek P:
Multi-structured households:
I'm assuming that the main purpose here is for back end analysis for post season reporting and potentially informing monitoring indicators rather than being needed for in field visual guidance. This has implications on the level of technical build required to meet this feature.
- Sameen: Correct. Botswana would want to register the following info for household level: Head of Household Name, Cattle Post Name, Number of <5, Number of >= 5
- Erica: Yes, the purpose is to be able to calculate % households protected by IRS and % pop over/under 5 protected by IRS
The current requirements I'm writing up are assuming that during data collection, the field data collector would visit the structure in which the head of household lives first to record his details before moving onto the remaining structures within that household. (Erica: Yes, the culturally appropriate thing to do is check with the head of household first, so this flow makes sense.) At each additional structure they would just need to way to link the head of household, previously entered, to that structure - either through a drop down list of closest head of households or through searching all head of households in that operational area.
- Sameen: All head of households in an operational area would be far too many records to search through and at that point you are going to get repeat names, as the operational areas are entire villages. It could be done through a list of the closest head of households, but if they are visiting HOUSEHOLDS and not hopping around, presumably when they go to a 6-building household and register the head of household details, there should be an easier way of linking the next 5 buildings to the head of household you just registered rather than giving an expansive search.
- Derek P: We thought about a few options. 1. Agreed, the search would have to filter the existing dataset as you type but could have it's challenges if the spelling varied slightly when trying to filter. 2. A drop down list of the closest 3 or 5 head of households would likely provide the head of household needed to select. If an edge case occurred and that head of household was not on the list they could manually enter the name and this edge case would need to be cleaned post season. 3. Get the user to select all of the other 5 structures on the map when registering the head of household. This however requires a very good spatial understanding of what is on the map and what is on the ground and so I would expect a significant amount of error here and therefore we removed it as an option. 4. You only collect the the head of household structure and post season conduct a cleaning procedure to link non-head-of-household structures to the closest head of household structure. This requires spatial joins to be done by a GIS person and wouldn't need any Reveal development but would probably not be very accurate. I think option 2. would work best.
Now, if it was needed for in field visual guidance then it becomes more complicated as the mobile client would have to visually show the head of household structure with a visual link (maybe a line) connecting each structure that belongs to that head of household structure. I don't think that this is necessary as I can't think of a situation where this is necessary or that can't be obtained by speaking to the structure residents them selves and secondly it may clutter the map. What we could request is that as part of the spray status card (summary) when you select a structure, it displays the head of household name.
- Sameen: Yes we would just want the spray card to display the name.
- Derek P: Provided we go with option 1, 2 or 3 above.
Please confirm that the infield visual guidance is not necessary. If it is, please provide justification.
- Sameen: Confirmed
Views
Justification
Dependencies
Questions
Test Case
# | Step | Pass / Fail | Comment |
---|---|---|---|
1 | |||
2 | |||
3 | |||
4 | |||
5 | |||
6 | |||
7 | |||
8 | |||
Additional tester comments: |
This site is no longer maintained. Please visit docs.opensrp.io for current documentation.