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 identical QR stickers at house; one will stay with the house at that location, the other can be carried by the family with them. The QR code is assigned/linked at a structure level and not a person level. There is not one QR code per person registered, 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?

• Need QR code because need to be able to assign to a structure even if a family is not home and leave something physically at the structure for the family to find. An ID would work for this if the ID is not reliant on family information to be generated and it can be pre-generated so that it printed and then assigned to a location when there. A QR code seems easier for a user to scan into the app and then stick on the house, than have to read and type in an ID which is more prone to errors.

MB:  We are in agreement on value of QR code.  Just saying there is no reason we need to 

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. QR code 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) .
2. If no QR code: Attempt to link to existing household first by searching list view. 
   1. Searchable features: all household names and 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

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

The program would like to conduct 'mop-up' from a central location, 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 families who present at the health facility catchment level
   1. Use QR code to lookup across synced data and link to their location
   2. Register as floating at HFC level
2. Global look-up
   1. with search functionality in list view
   2. with QR code
   3. NEED to CONFIRM EXTENT OF WORK IF THIS WERE ADAPTED FOR REVEAL - current state, what needs to be ported to Reveal, timelines, and level of effort. 
3. Server-side QR code reconciliation/matching ONLY NEED IF NO GLOBAL LOOK-UP
   1. Could lead to dual registration of family members/families
      1. Simple facility-level aggregate form so we do not register at the facility, and reconcile the totals against the registration #s, capture aggregate consent at this level
         1. If pre-registered, match back numbers
         2. If not pre-registered, use aggregate numbers as they are
      2. Anyone who shows up with a QR code gets linked

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). 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  → 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. 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

Option B - 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. 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. 

Option C - Implement 1,3

1. Could lead to dual registration of family members/families
   1. Simple facility-level aggregate form so we do not register at the facility, and reconcile the totals against the registration #s, capture aggregate consent at this level
      1. If pre-registered, match back numbers
      2. If not pre-registered, use aggregate numbers as they are
   2. Anyone who shows up with a QR code gets linked

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

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 and is not yet linked.  
         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. This is complex and may not be essential? Not MVP.
            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. Enter family  module
   2. Failure
      1. QR code does not match.  
         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

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

Out of scope

• Registering a family ad hoc (i.e. not at their household location) and then dropping a point for their location

Software to be Developed

Android

• Support Eligibility when tapping a structure
  • Open Structure eligibility form, once saved, execute logic based on the business_status to enter the register family form or back to the map view
    • The business status would determine the next step and it would be calculated in the bottom of the form
      • You would need to pass the business_status from the first form to the second so that we can appropriate close the task
• QR Management
  • Add this as an identifier to the family entity
  • Make it so that we can search based on this QR code family entity (index the database)
  • QR Codes should be entered or edited at the following points
    • Eligibility form - This QR code will be tracked against the location if they are eligible and not home or not fully home (locationQrReference)
    • Register Family - This QR code will be tracked against the family (familyQrReference)
    • Edit Family - This allows us to capture or update the QR code for the family at any time
  • Search by QR Code
    • Any time we read a QR code for search we need to search the following identifiers
      • Step 1: familyQrReference
      • Step 2: locationQrReference
        • If we match on this, enter the register family form passing in the location.id and this locationQrReference value so that it can be turned into the familyQrReference.
          • Delete the locationQrReference so that we can't find this again in this table and we would automatically redirect to the familyQrReference
• Create/Modify forms:
  • Eligibility Form when you click on a structure
  • Modify the Register Family form
  • Modify the Register Family Member form
  • Modify the Distribution form from MDA
  • Include ability to view and edit completed forms 
• Allow people to search by families and return a list of families
  • (We need Roger to help with this)
  • Outstanding Questions on this:
    • Problem: If the family isn't registered against a structure the search from the map view will return nothing, but the search from the task list view will return a result.
      • Does the task list view meet this need?
        • Do we need to support searching by families that don't have a task for this plan?
      • What's the difference between the "all clients view" from Eswatini and the task list view?
      • Do we need both?
• Allow people to add families outside of structures
  • (We need Roger to help with this)
  • We definitely need them to be able to add a family if a search result in a list returns nothing or a QR search returns nothing.
  • Question
    • Do we need to allow them to add families from the map view without associating a structure?
    • How do we allow a user to add a family from the task list view (assuming that's the primary search view for families)?
• If they decide to support taking roll
  • Create a Take Roll Form - this form includes a button to read the QR code
  • Add a Take Roll Activity to the Plan.action section
  • Code the process for generating a take roll action when the family is registered
• Edge Cases/Outstanding Questions
  • What happens if we distribute a QR code to the location and to the family and we then need to merge them?
  • Linking Families to locations
    • (Supported) When we register a family in the field, we link the family to the location
    • (Supported) When we leave a QR code at a location that's eligible, but not home, we have the ability to link the family to that location when we read the QR code because the QR code that was distributed to the location (see QR code search Step 2)
    • (EDGE CASE) When we register a family from the task list view, we have no way of knowing the location they should be registered against.
      • The family should be linked to the jurisdiction from the plan.
      • Out of scope
        • We are looking at a floating family in the family module
        • We see that they are not linked to a structure through a visual indicator
        • We could have the ability to click the option menu to kick off a workflow that allows them to link the family to a structure
          • Click option menu
          • Open map view of the entire operational area
          • User click a location
            • We query to see if a family is already registered
              • If registered, we don't allow it and recommend that they archive that family first
              • If not registered, we highlight the location
          • User clicks save
          • We add the "residence" to the family
  • We need a status update on what we will deliver for Workflow 4. It is not included in this spec so far. Isabel will follow-up on this

Web

• New plan type of: NTD MDA in community
  • This plan type has the following tasks: 
    • Register Family (BOTH linked to location and also floating) - does not autogenerate
    • Register Family member - does not autogenerate 
    • Drug Distribution - autogenerates against any eligible, registered child
• Follow the IRS model for plan, where we see a map of all eligible operational areas and point and click which we prioritize. 

Justification

Notes

Questions

Livashan Soobramoney pls help us to answer the questions below 

Isabel Shaw Im concerned we are working off the wrong Doc. Please use https://docs.google.com/spreadsheets/d/1irNlenvTf3TzcdSOdKAp2kdYjwO0O1Hl4vvNsJ9saDU/edit?usp=sharing

Updated 6.25.20

1. Will health workers be visiting a combination of homes already registered and identified in Reveal and "unspecified structures" during this campaign, or only "unspecified structures?"
   1. The answer to this question directly impacts how we build our issue QR code workflow 
   2. LS response on call: we will only be incorporating enumerated structures without families registered 
2.  Our assumption is that QR codes will only be issued to any families registered at their homes - is this correct?
   1. LS response on call: that is correct 
3. The drug administered has not yet been confirmed with Ona, but our expectations are that it will be a single dose per the requirements 
   1. LS response on call: that is correct 
4. Will the scale and location of the pilot be the same?
   1. The scope sites one district 
   2. The designated district was Gwembe
      1. For the pilot we are targeting one District and that District is Gwembe
5. The requirements above mentions a family list view in addition to a task list view - is there any reason that the user would need to look through a list of floating families?
1. What would that use case be that required the person to look through a list of people instead of searching for a person/family? Once the family identified is searched, they will be able to see all the data on them. We're trying to understand why these families would require a different workflow than the families associated with structures. Currently, our list view is not a client list it is a task list - door-to-door Reveal campaigns has always focused on tasks opposed to client registers.  
   1. In the event that the entire family is not present at the health facility, we need to create a mechanism to view the partially ''completed'' family to complete drug distribution 
2. Is it sufficient to be able to search for families, see search results, and then enter the family module to view members and forms?
   1. No, we need a separate list view for the floating families 
1. The distinction between two list views (lists of floating families versus lists of tasks) could be a bit confusing to end users, so we'd prefer to maintain a single view unless there are other business requirements here we're missing. It is also important to note that we do not know how many floating families there will be. This could mean that there is an empty screen for the start and possibly a good deal of the campaign. 
   1. Please see comments above
6. Has any additional conversation been had on workflow 4 (searching clients across OAs) that is not documented above? Our understanding is that a final decision had not been reached on an implementation path
   1. Has it been confirmed that mop up days are a part of this new pilot?
      1. Plan A: Families convene at Health Facility
      2. Plan B: Potentiallly CDD team to revisit areas with partiality low coverage
   2. Our recommended way forward: if these mop-up days are happening at the health center level as stated above (I believe this is level 3 in Zambia), we can fit all of that client data on a device and no global search is needed. I believe in Zambia right now, we can actually fit data from 3 health centers on to a single device. If that is sufficient, we can just create credentials at that level and allow the user to search through all clients already synced to phone. 
   3. If that is not sufficient, we need to have a conversation here ASAP, as global search introduces an immense amount of complexity in terms of client management  
      1. The workaround is acceptable. We are willing to make a concession here to move dev along.
7. Our assumption is that the reporting requirements for both the web AND Android apps have not been updated for this implementation - is this correct? 
   1. Web - It references % of people screened, and % of case-triggered FIsTest Case
      1. This data is not found within our data dictionary. 
   2. Android - it references something about "PZQ received - those returned and distributed" → this is not data we are collecting
      1. This is data we are collecting (Drug Allocation to CDD team Form & Drug Return from CDD Team Form).
8. Have any decisions been made about what drug will be dispensed in this trial? 
   1. When will the data dictionary be updated? 
      1. 01/07/2020
   2. No adverse drug reaction reporting is included above - pls confirm this
      1. At this time, this has not been included in the pilot.
   3. Has "eligibility" been defined yet?
      1. Household: Eligible if child exists.
      2. Child: All persons under the age of 18 will be registered, however, only children between the ages of 5 & 15 will receive PZQ.
9. The requirements above make references to a separate family lookup with a form that requires the user to answer whether or not the family has a QR code. We don't believe either of these things are necessary and would prefer to keep things simpler for the sake of the end user. Pls confirm below is acceptable: 
   1. If a user wants to find a family - either floating or associated with a structure - they either hit the search bar to search by name / phone number or hit the QR code icon. Both will allow them to search every client in the system 
      1. This is fine
   2. It is not necessary to ask if they have a QR code in the system. This adds friction without any value. The user should just always ask for a QR code in every encounter with families. And, based on the answer, search in the tool in the appropriate manner. 
      1. It was added as a form of a reminder but we are fine the approach 
10. Pls confirm the expectations of the functionality under the "Use QR code to link family to location" section above 
    1. Our understanding: a family arrives at a health center with a QR code. The user searches via QR code.
       1. QR code finds a match to a structure in the system. The family is then registered against that structure. If you were to scan that QR code again, it would then bring you directly to the family module view.  
          1. Correct
       2. QR code finds a match in the system to a registered family. User enters the family module directly. 
          1. Correct
       3. Match not found - user must return to search  
          1. User should be redirected to feature to register floating families.
    2. Out of scope: 
       1. Showing the structure on the map as part of that workflow - given this, the confirmation questions above will also not be needed 
          1. Correct
       2. Linking a floating family already registered to a structure. If an error was made and a family was registered as a floating family despite living in a structure within the OA, the user will not be able to link them with that structure later on. That structure will either have to be left unvisited or the user can mark it as ineligible. 
          1. Correct