Page Comparison

...

Livashan Soobramoney pls help us to answer the questions below 

Updated 6.2325.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 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 ?Is it sufficient to 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 search for families, see search results, and then enter the family module to view members and forms?
   2. 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  
4. 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  
5. 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 
6. Have any decisions been made about what drug will be dispensed in this trial? 
   1. When will the data dictionary be updated?
   2. We are assuming that this program will only be dispensing a single dose of the drug 
   3. No adverse drug reaction reporting is included above - pls confirm this
   4. Has "eligibility" been defined yet?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.  
   5. Is it sufficient to be able to search for families, see search results, and then enter the family module to view members and forms?
   6. 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. 
7. 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?
   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  
8. 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 
9. Have any decisions been made about what drug will be dispensed in this trial? 
   1. When will the data dictionary be updated?
   2. We are assuming that this program will only be dispensing a single dose of the drug 
   3. No adverse drug reaction reporting is included above - pls confirm this
   4. Has "eligibility" been defined yet?
10. 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 
    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. 
11. 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.  
       2. QR code finds a match in the system to a registered family. User enters the family module directly. 
       3. Match not found - user must return to search  
    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 
       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.  

...