...

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

Justification

Notes

Questions

...

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

...