...

Status

The following tickets are detailed in this document:

...

• 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. 

  Jira Legacy
  server System JIRA serverId 3420e60a-4e6f-3f80-8335-059c22bb40aa key RVL-856

• 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. 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 identical QR stickers at house; one will stay with the house at that location, the other can be carried by the family with them.   MB: To clarify, are they leaving two identical QR codes at home to ensure one is not lost? They are not doing a The QR code is assigned/linked at a structure level and not a person level. There is not one QR code per person registered and not treated, rather one QR code per location.
2. QR codes need to have the operational area code written on them, at the time they are distributed.
   1. The intention of this is to allow us to simplify the lookup for the QR later in workflow 4. Humans will not read the QR code, but use it for less error prone id look up.

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?

...

1. If have QR code: Access family module from list view through a button  "Family lookup" 

   Jira Legacy
   server System JIRA serverId 3420e60a-4e6f-3f80-8335-059c22bb40aa key RVL-476

   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. Only this is we need to be able to add a family with a QR code already assigned and add a family that doesn't have a QR code assigned. Some families may show up for registration/treatment when you are not at their house and you haven't yet visited their house (and may never). And it makes sense to connect these workflows I think.lookup: See data dictionary logic for question flow. 
      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. After lookup (i) or entering registration without lookup (ii) Proceed to family module (workflow 1) . MB: I don't get what's happening here.  After looking up with QR code, if a match, OR if they don't have a QR code, you then jump into family module .
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. Okay, just searching list view is fine in the app. The user could "search" map view manually by looking and clicking if the family member has good spatial awareness of where they live looking at a map.  MB: We can try and support both and see what people do.  We'll have phone number so we can search on that.
   1. Searchable features: all household names . MB: Probably phone tooand phone number. 
      1. If find family, proceed to family module (Workflow 1)
      2. If no family found, register as new floating family without QR code

...

The program would like to conduct 'mop-up' from a central location. This , which 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. Health facility catchment area work.the health facility catchment level and use QR code to lookup across synced data
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. I suspected; I don't think option 1 is feasible with MVP.
   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 levelMB: 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). Right. Options 2 and 3 are trying to get around doing a global lookup by instead suggesting we just access the different OAs and sync data as people from that OA are treated. Which also requires connectivity which we are counting on, but doesn't require actually building the search in a global way.

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.  I modified this write-up to be less confusing, as I think I was mixing up the hamburger menu selection with syncing.

Option A - Implement 1, 2 ,3 → Global lookup

Working at the health facility level, where families from multiple (20+ OAs may show up for treatment), select hamburger menu option for that catchment.

Syncing assumptions

• Data would be synced globally to facilitate a search or QR look-up of any family

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. But we may be working in an environment where they are at a point that serves multiple OAs, so they need to switch back and forth (yes, need network). Having the OA written on the QR code paper means you can access that OA in the hamburger menu to find that person which at least means you don't have to sync all OAs in that facility and have to go a global search; instead each time someone presents, you sync for that OA and search within.  MB: We'll need to discuss this further.  We don't have the feature to pick from a list and then sync that OA.  Right now it syncs all OA's you are assigned too.  Implementing a global search (implies they have internet maybe work better).  Let's plan on discussing this further.
   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.
   If no QR code: stay at health facility level in hamburger menu with a full list view.   
   1. Conduct QR code look up. 
2. If no QR code
   1. 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 1B - Implement 1 → Local Lookup

Syncing assumptions

• Team of the user would be assigned to all OAs within the catchment, so all of the OAs should be synced to that device.
• This lookup with QR code will only work if the QR code is for a family/structure that was registered in the working catchment of the user.

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.
   3. Conduct QR code look up 
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. 

...

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). Right. Options 2 and 3 are trying to get around doing a global lookup by instead suggesting we just access the different OAs and sync data as people from that OA are treated. Which also requires connectivity which we are counting on, but doesn't require actually building the search in a global way.

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 

Jira Legacy
server System JIRA serverId 3420e60a-4e6f-3f80-8335-059c22bb40aa key RVL-828

Assumptions:

• Same syncing assumptions apply
• QR search can search across all synced data on the tablet. Matt, please confirm?
• 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:, scan QR code
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.  
         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. This is if we have been to that house and left a QR code there, and they visit you later not at there house, with their QR code, this applies. WE may not need to show location of the house, but linking back to a location if these criteria are met is important.
            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. Agree.
         2. "Yes" → enter family module
         "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.  What if the family provides a QR code that is not theirs? I.e. they accidentally swapped with their neighbor? Maybe an edge case but could happen.  MB: Edge case that I don't think is worth considering.  If this is the case, we can assign them a new QR code which we'll need to do anyways.Enter family  module
   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? We assume if they have a QR code, that someone has dropped a code with their house when they are not home. If a family has a QR code but that QR code (which is search at the OA level) fails to match, it could be that they are not in that OA or they have an incorrect code.  MB: Again this doesn't make sense.  If a family is assigned a QR code, we'll find them in the system.  It doesn't need a link to the OA.
         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. Can we capture their stock on a daily basis and compare this distribution form with the return form if comparing to usage is too complex?  MB: Again needs better scoping.  Let's just potentially start with capturing initial stock and then daily usage in some type of form.  I don't know if we need to calculate balances on the fly since this is used in campaigns.
  • 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

...