Multi-structure household data collection

Starting this page for scoping - Derek Pollard to review. Initial scoping done as part of R3 scoping overview



Responsible Person:
Other parties to review/input:
FYI:
Targeted release date: 
Jira Status: RVL-161 - Getting issue details... STATUS

Status

#
Step
Status
1Responsible prepares rough business analysis/reqs docCOMPLETE: Pierre Dane
2Get CHAI review
3Get Akros/VW Review
4Get Ona feedback
5Responsible - 1 iteration for feedback


6Ona sign off
7Ona tech spec scoping
8Ona LOE 
9Ona 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: