Allow for multiple places to be assigned to users

[garethbowen]

Overview

Currently replication permissions are based on a user's facility_id. This is a single UUID that references a place in the hierarchy. The user is permitted to access all people and places underneath that place. The user also has access to all reports about the people and places they can access.

There are a few caveats to this, including

• depth: restricting how many levels below your facility you can access
• report depth: restricting how many levels you will access reports for
• privacy: whether the report contains restricted information
• sensitivity: whether the report is about the user

The hierarchy is also used to represent the geographical areas being served and is useful for reporting on a place's catchment.
The facility_id also dictates the default selected place when loading the Contacts tab, and registering new places starts here.

Problems

1. CHPs don't also manage all families in one geographical area. To work around this child areas are created (eg: Mary's area) to contain all the families a CHP is working with, but these are arbitrary and not useful for reporting purposes. To move a family from one area to another then requires updating their hierarchy which is difficult.
2. CHPs don't necessarily stick to their assigned geographical area. To work around this CHPs are given multiple logins, and multiple apps, so they can switch between areas. This performs really poorly.

Proposal

Instead of a user having a single facility_id allow configurations with multiple IDs. Keep the facility_id to reference the home place and add a new called something like "assigned_contacts". For backwards compatibility if you have no assigned contacts it defaults to the facility_id. The assigned_contacts behave the same as the facility_id but instead of querying the contacts_by_depth view with just one ID it'll use an array.

Each assigned contact will be able to be configured with a depth and report_depth component so they can be assigned contacts at different levels of the hierarchy. This means we can configure users who are assigned all places under their home place (as they are now) which means they will automatically be granted access to new children. Alternatively you can manually assign places to users where there is shared responsibility. One example is supervisors for an area will likely have access to view all CHPs in their area, but families may be assigned individually to CHPs and be reassigned as needed.

As well as replicating the assigned places, we will also allow read only access to all the parents, grandparents, etc of the assigned places so you can view but not edit the hierarchy. This means they can create valid children of places they can access.
When a user creates a new place we need to make sure it is assigned to them even if they're not assigned to the place's parent. This will require code to update the user's assigned places when a new place is created. This could be done in a sentinel transition but sentinel processes changes in order and can get behind which would be bad for assigned places. Instead, make a change to the replication code that updates the assignees when new places are replicated up. This will require a sentinel transition to update the user doc on place creation.

This allows for an admin to grant a CHP access to an arbitrary list of areas or families irrespective of their geographical location.

Discussion document

[kitsao]

Adding voice to this @garethbowen

CHPs don't necessarily stick to their assigned geographical area. To work around this CHPs are given multiple logins, and multiple apps, so they can switch between areas. This performs really poorly.

User story

"As a Community Health Assistant (CHA) supervising multiple Community Units (CUs), I want to be able to supervise my CUs without using multiple credentials (logging in and out to switch CUs or apps). This enables me to perform routine tasks such as death and muting reviews and to effectively offer intervention support to my CHVs. Currently, it is difficult to promptly do so because I am not an angel to know when a CHV is a particular CU needs my attention for me to switch to the CU."

Background

• This is from MoH Kenya eCHIS deployment where CHAs supervise at least one CUs.
• The current workaround that will not hold for long is that we have enabled logout on android for them to switch from a CU to another (multiple logins).
• Given the nature of the routine tasks around death and muting, it has become a big challenge to always login and out. In the meantime, we can talk about sms notifications to be informing the CHAs to logout in case a CHV submits a report requiring the CHAs approval, but the user experience shall remain to be poor.

Desired behavior

• Assign users multiple places and allow them to switch place profiles to effectively serve their supervisees.
• This makes it possible to use is single sign on to access a panel of all CUs so that the CHA can manouvre easily.
• It becomes even easier to manage CHAs and CUs e.g. when a new CHA is brought in or a CU is transferred/split.

cc @derickl @christinawere @PhilipNgari @ochanyo

[christinawere]

Hi @garethbowen @michaelkohn I will appreciate any updates on this. FYI @katanu @JenniferMuli

[garethbowen]

Hi @christinawere . Currently this work is not prioritised, it's just an idea. Is this blocking or impacting a project moving forward? Is there a timeline for when this is needed?

[christinawere]

Hi @garethbowen yes this is much needed for the CHV supervisors in eCHIS Kenya who have multiple community health units under them so that they don't have to log in and out for multiple accounts.

It's not blocking the CHAs to work, however from feedback right from co-création sessions with MoH to post deployment userfeedback from Migori County, it's not à good experience.

It would be great if this is considered or prioritised in your current sprint to increase acceptability and usability of the eCHIS application by supervisors countrywide in Kenya.

[garethbowen]

Prioritisation is @michaelkohn 's speciality, so I'll leave you in his capable hands!

[michaelkohn]

@christinawere I've added it to the agenda for our call with service designers tomorrow. I'd like to understand how many supervisors this affects in eCHIS and other projects, plus... there were conversations in the eCHIS 2.0 hierarchy deck around reorganizing the hierarchy so i'll be curious to understand how that would potentially impact this requirement. If you are not able to attend the call tomorrow, happy to connect in a separate session.

[latin-panda]

Related forum posts in case we need to reach out to these community members

• Most recent -> Seeking Technical Advice: One-to-Many Association
• Can one person belong to multiple places in the same hierarchy
• Can one person belong to multiple places in different hierarchy and be assigned to user with a role?

[Marina-Kenf]

MoH Mali is very keen to have this feature working an get unblock with their supervisor workflow.
I'm curious if there is already a plan on kicking off this work?

[christinawere]

@michaelkohn @n-orlowski @leah-ngaari @latin-panda Thank you for picking this up!. Glad to be part of this conversation early in the year. One-to-many associations for supervisors; was already explored to some extent, configured, and tested by Kitsao and the eCHIS KE PMs in October last year. Perhaps the conversation needs to continue further with @alexosugo too Find the details here Fyi @Marina-Kenf @katanu @JenniferMuli

[latin-panda]

See breadcrumbs video in the description of this PR.
See Aggregate Targets (disabled) video in the description of this other PR.