Page Comparison

...

Livashan Soobramoney pls help us to answer the questions below 

Updated 6.23.20

...

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?The requirements above mentions a family
   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
?
6. Is it sufficient to be able to search for families, see search results, and then enter the family module to view members and forms?
7. 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  
8. 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, is that correct?
   1. Has it been confirmed that mop up days are a part of this new pilot?
   2. Our recommended way forward: if these mop up days are happening at the health center level (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  
9. 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
   2. Android - it references something about PZQ received - those returned and distributed → this is not data we are collecting 
Have any decisions been made about what drug will be dispensed in this trial? 
10. When will the data dictionary be updated?
11. We are assuming that this program will only be dispensing a single dose of the drug 
12. No adverse drug reaction reporting is included above - pls confirm this
Has "eligibility" been defined yet?
1. 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
13. 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.
14. 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).
15. 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.
16. 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 
17. 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

...