Status

The following tickets are detailed in this document:

RVL-858 - Getting issue details... STATUS

RVL-856 - Getting issue details... STATUS

RVL-506 - Getting issue details... STATUS

RVL-476 - Getting issue details... STATUS

Requirements

• Ability to look-up households per list view lookup 
• Need some kind of searchable unique identifier to uniquely identify people to avoid counting them twice. (QR code)
• Need a way to link family that doesn’t have locations.
• Search needs to search floating families

Assumptions

• You will never treat a child without a caregiver to consent.
• You will never treat a child without linking them to a family entity. All workflows rely on registering a family/family head.
  
  • On-ground protocols will determine and train on what defines a family entity.
• We will not be able to unlink and relink to "fix" where linkages were made incorrectly in the MVP with QR codes.

Workflow

There are two main templates that will inform these workflows. The Web UI reporting and plan template contains the details of the plan and activity as well as requirements for web based dashboards. The Data collection data dictionary defines the forms and data needed for register family, register child and drug distribution workflow, as well as two aggregate forms.

Plan: NTD MDA in community  RVL-858 - Getting issue details... STATUS

• This should follow the IRS model for plan, where we see a map of all eligible operational areas and point and click which we prioritize. 

Location types: Residential structure

Activities/Tasks available:

• Register Family (linked to location by also floating, detailed in workflow 3) - does not autogenerate
• Register Child - does not autogenerate 
• Drug Distribution - autogenerates against any eligible, registered child. We need to define eligibility criteria and generate tasks based on these criteria and NOT for all person-entities.  RVL-856 - Getting issue details... STATUS
• Drug Allocation (team-level task not linked to location)
• Drug Return (team-level task not linked to location)

Workflow 0 - Confirm household eligibility and presence

1. Visit home, tap on house from map view, following questions appear before kicking off family registration
   1. Confirm house is residential, someone is home to give info, and consent is given, is main house? 
   2. If no to any of above, follow skip logic and do not enter family module and family registration 

Workflow 1a, 1b, 1c - WHEN AT HOUSE: Register/Edit Family, Register/Edit Child, Distribute Drugs (all within Family Module)

1. After answering yes to all of Workflow 0
   1. Access family module, register family
   2. Register each child, including children that are not present 
      1. Treat each eligible, present, child.  Children not treated will be registered but left untreated.

Workflow 2 - Leave QR code when not everyone home  RVL-475 - Getting issue details... STATUS

1. In 'Add family' workflow (1), after answering 'no' to 'is everyone home' and 'yes' to 'is main house'
   1. User is taken to a QR scanning view. 
   2. "Scan the QR code for this structure and leave stickers at house"
      1. User scans QR code
      2. User leaves two QR stickers at house.  MB: To clarify, are they leaving two identical QR codes at home to ensure one is not lost? They are not doing a QR code per person registered and not treated.
2. QR codes need to have the operational area code written on them.

Why is this needed?  From the QR code perspective, we just need the unique ID.  Are humans going to read the QR code for some specific reason?

Workflow 3 - FLOATING FAMILY, NOT AT HOUSE: Linking to Location and entering Family Module

Find someone who belongs to unregistered household  RVL-476 - Getting issue details... STATUS  or does not belong to that community

• This could happen in the village at a location that is not the household location

1. If have QR code: Access family module from list view through a button  "Family lookup"  RVL-476 - Getting issue details... STATUS
   1. "Does this family/child have a QR code"   MB: This would just be a QR code lookup.  We don't need to have that question.
      1.  If yes, open QR code scanner to link (Details in QR linking below)
      2. If no, "Are you sure this family/child does not belong to an already registered house?"
      3. Proceed to family module (workflow 1) . MB: I don't get what's happening here.  
2. If no QR code: Attempt to link to existing household first by searching map and list view . MB: This means being able to get to a HH via the map.
   1. Searchable features: all household names
      1. If find family, proceed to family module (Workflow 1)
      2. If no family found, register as new floating family without QR code

Workflow 4 - FLOATING FAMILY NOT WITHIN VILLAGE (Point-distribution?)

The program would like to conduct 'mop-up' from a central location. This means that families may show up with their QR code or with no QR code at a health facility. This requires the following features

1. Register new floating families to a location level higher than operational area level.  We can assign to the ward or district above.  We have a location hierarchy in OpenSRP we can use here.
2. Global look-up with search functionality in list view
3. Global look-up with QR code

Option 1 - Implement 1,2,3 (likely beyond MVP, significant effort)

Working at the health facility level, select hamburger menu option for that catchment.

1. Workflow looks identical to Workflow 3, except
   1. List view will show all families (floating and not) in the catchment . MB: This has significant sync implications.  We can only list a few thousand clients so a full list of all clients is probably not feasible.  A global search is feasible (no map view).  This will require a connection.  It also probably represents some additional LOE. 
   2. Searches will then happen at this level . MB: Will require connectivity.  We can't probably sync all data to the device unless we are limited to several thousand households.
   3. There will be no map view

Option 2 - Implement 1, 2 

Working at the health facility level, select hamburger menu option for that catchment.

1. If have QR code paper
   1. Contains written operational area on QR code
      1. Switch to that OA on hamburger menu, proceed with Workflow 3 .  MB: What's the purpose of this?  If we have the OA in the hamburger menu then we will have already synced all data for that area. We can look up the household directly from the QR code.
   2. Does not contain written operational area on QR code .  MB: Again I don't understand purpose of this
      1. Family must be registered as a floating family.
2. If no QR code: stay at health facility level in hamburger menu with a full list view.   
3. Attempt to link to existing household by searching list view (global look-up)
   1. Searchable features: all household names
      1. If find family, proceed to rest of Workflow 1
      2. If no family found, register as new floating family without QR code

Option 3 - Implement 1

Working at the health facility level, select hamburger menu option for that catchment.

1. If have QR code paper
   1. Contains written operational area on QR code
      1. Switch to that OR on hamburger menu, proceed with Workflow 3
   2. Does not contain written operational area on QR code
      1. Family must be registered as a floating family.
2. If no QR code: stay at health facility level in hamburger menu with a full list view.
   1. Family must be registered as a floating family. 

MB: Finding this section a bit confusing.

If QR code, we just need to look up.  The main question is lookup will only work against locally synced data.  If QR code is out of the area you have synced we will have to implemented a global lookup (requiring connectivity).

If not QR code, just register a family and assign them to either the highest level catchment or sub area if they can identify it.  I don't think we should try and link them to structures though.  

Use QR code to link family to location  RVL-828 - Getting issue details... STATUS

Assumptions:

We will not be able to unlink and relink to "fix" where linkages were made incorrectly in the MVP.

1. In looking up family, when triggered to open QR scanner:
2. Potential results from scan
   
   1. Success
      1. QR code matches this village and is not yet linked .  MB:  This means that the QR would be linked to a family assigned to the village level but not a household.  I
         1. Confirmed match, show view of household location on map . MB:  I don't know if this is worth the added complexity.  I'm assuming this means we are trying to link a family to an unclaimed structure on a map?  What does this give us if we are providing the service when we see them?  This only should be attempted if you are visiting the household at their house.
            1. "Confirm link?"
            2. If yes, make link and proceed with workflow
            3. If no, warning message "This QR code links with the house shown on the map; are you sure you do not want to link?"
               1. Do not link → back to question in form asking "Does this family have a QR code"?
      2. QR code matches and has already been linked
         1. "This code is already linked with this structure. Proceed?"   MB: we don't need this.  It should just load the family view if a matching ID is found.
            1. "Yes" → enter family module
            2. "No, go back" → back to question in form asking "Does this family have a QR code"?  MB: I don't get this.  This is after scanning a QR code so the family will have one.  
   2. Failure
      1. QR code does not match this village .  MB: I don't understand this.  Do you mean that the family may be a QR code that may not be properly registered?  If a family has a QR code don't we assume they've been registered?
         1. "Okay"→ back to question in form asking "Does this family have a QR code"?

Other forms

• Drug distribution tracking to distributor team . MB: This needs better scoping?  IS this meant to be a stock form?  We can do a form to capture stock levels. We don't want to go down path of doing any type of calulations based on usage / resupply, etc.  That would be out of scope. 
  • We expect this to happen once or a few times
  • This should be a form that is not linked to task model OR is an "on demand" form
    • Want to see on application indicator for #drugs received against #drugs distribution, this should sum if there are multiple submissions on the form . MB: this sounds like stock management. Don't think this should be in scope at this phase
    • Need to keep form blank for the next round of edits
• Drug return form
  • We expect this to happen potentially multiple times
    • Should play into the same indicator

Reporting

The mobile client indicators are defined in the Data collection data dictionary

The web indicators are defined in the Web UI reporting and plan template

Mock-Ups

Views/UI

• Add list of floating families view (likely from list view)
• QR code
  • Scanning screen (think this already exists in OpenSRP)
  • Visualize matched house screen (show on the map view, the location of the house that matches with the QR code
  • Follow-on/confirmation questions
• View to family-look up → icon from list view?
  • to look up families with QR code
  • to add floating families

Justification

Notes

Questions

Test Case