Support for having multiple places assigned to a user

[kennsippell]

CHT Core 4.9 supports having multiple places assigned to a single user
https://docs.communityhealthtoolkit.org/core/releases/4.9.0/#allow-multiple-places-to-be-assigned-to-users

In Kenya, we are planning to have a single CHA account with multiple CHUs associated with it. How can we support this scenario and make CHU management easy?

[ChinHairSaintClair]

Hi @kennsippell ,

Have you noticed any adverse replication impact with the "multi places assignment" feature?
Or should one be a little more aggressive with the purge script?
We've noticed that our online roles start running into timeouts when requesting around 28k records in the report view.
Does the purge script also reduce the amount of data being pulled through to the user management tool?

[kennsippell]

Hey @ChinHairSaintClair. I don't think anybody is using the multiplace assignment feature yet. We are still getting ready.

In general, that change didn't changed the CHT's client-side performance characteristics except to make it easier to have too many docs associated with a single account. When we use this feature, all the normal tricks to keep acceptable CHT performance will be even more relevant: purging (as you mention), but also replication depth since this feature is designed with supervisors in mind.

One clarification is that I think the feature is for offline-users only (maybe I'm wrong? I don't plan to use it for that users); but likely no impact for online users. Purging has no impact on the amount of data pulled through the user management tool, but this tool only deals with contacts and never looks at reports.

[ChinHairSaintClair]

Hi @kennsippell. That's fair enough, only got added in the latest release (4.9 at the time of writing).
We're pushing to upgrade and then intend to use this feature bit of an unorthodox way.
Operationally we need to track people that "out-migrate", and often the movements are outside the scope of our CHWs. Unfortunately at the same time, since they have intimate knowledge on the lay of the land, the CHWs are often best placed to indicate where exactly the person moved to. Bit of a predicament. Thus the halfway house concept is born.
The hope is to create a halfway house per NPO and assign each CHW to both their own area of operation, but then also to this item. It would enable each CHW across the system to move a patient out of a household, detailing in text where they have moved to physically, and then place them into this halfway house for further processing by the site managers.
The site managers , having elevated scope , will then be able, using the movement notes, to move the patient into an appropriate hierarchy item (should the item exist).
We'll then also be able to identify areas where the app needs to start operating in.
Interested to know what you think of this idea, or have any concerns.

In general, that change didn't changed the CHT's client-side performance characteristics except to make it easier to have too many docs associated with a single account.

Indeed that's the worry. We're trying to be a bit more attentive to performance by leaning into the purging script, but from reading forum threads it seems difficult to track the progress of the run.
Has there been any developments in that regard?

but also replication depth since this feature is designed with supervisors in mind.

Replication depth is a bit tricky for us, as it works from the top down, not the other way around.
We often need lower-level hierarchy details without much concern for the middle layer.
For example, our supervisors want to check if a CHW is servicing their areas as anticipated, but they don't care much about the team area the CHW area falls within.

One clarification is that I think the feature is for offline-users only

Online users are able to see all report data across the system (in the reports tab). However if you create an online user, that's placed within a specific PLACE in a hierarchy, they only pull that item's child hierarchy data. At least in our experience.
Given that, maybe it still has some effect?

Purging has no impact on the amount of data pulled through the user management tool, but this tool only deals with contacts and never looks at reports.

Thank you for the clarification, it's good to keep in mind.

[kennsippell]

Replication depth is a bit tricky for us, as it works from the top down, not the other way around.

In these cases, a combination of replication depth and needs_signoff may be useful.

However if you create an online user, that's placed within a specific PLACE in a hierarchy, they only pull that item's child hierarchy data.

I believe they see everything all the time. Would you confirm your expectation here? My knowledge may be out of date, but I just tested on 4.9 and I see everything.

[ChinHairSaintClair]

Thank you @kennsippell

In these cases, a combination of replication depth and needs_signoff may be useful.

Good point! That should work from an app form/report perspective, we unfortunately also need to see the actual hierarchy items that were captured.
Another thing to note with the needs_signoff is that it won't affect reports retroactively, only newly captured reports after adding the property to the relevant app forms, if memory serves.

I believe they see everything all the time. ... My knowledge may be out of date, but I just tested on 4.9 and I see everything.

One can see all reports, but the hierarchy is scoped - see example scenario below:
The DHO role is set to online

As admin we can see two NPOs exist, with the DHO created under the "Another NPO" item

When logging in as the DHO, called "DHO Test", we can only see the items of the "Another NPO"

We can however still see all reports across the system

Would you confirm your expectation here?

I'd like the behavior to be consistent for both the reports and contact data.
If a user, regardless of online or offline, is scoped to a specific place - the pulled data should be too.

[kennsippell]

Thanks for confirming and explaining!

I'd like the behavior to be consistent for both the reports and contact data.
If a user, regardless of online or offline, is scoped to a specific place - the pulled data should be too.

Can you start that conversation on https://forum.communityhealthtoolkit.org/? I know this discussion has happened many times and I'm not sure about its latest status. I can't find a tracking ticket in cht-core anymore or I would forward you there.

[jkuester]

Just adding some links for the benefit of any future readers:

https://forum.communityhealthtoolkit.org/t/a-person-assigned-to-a-place-regardless-of-offline-online-should-have-their-data-scoped/3865

medic/cht-core#7496

[PhilipNgari]

@alexosugo Are we ok with the intended MoH-Ke work on CHAs? Any dependency on this convo?

[alexosugo]

@PhilipNgari We are ok as far as eCHIS-KE is concerned. Current dependency is the instance upgrades to v4.9+.

[kennsippell]

A group of us met today to discuss next steps for this ticket. @inromualdo @Benmuiruri @paulpascal @freddieptf

User Needs

• Making a supervisor user with n existing places and/or n new places
• Moving a place between two existing users
  • Can multiple supervisors supervise the same area? No, areas only need to be moved between places and never copied.
• Import a list of n users at a list of n places (either existing or new)
• Supervisors only supervise specific types of places. It should be restricted by type
  • In togo there are two types, in all other places there are one
• When changing a supervisor’s phone number or name, would be nice to change in one place. Currently it is duplicated on all primary contacts of all areas they manage.
• Supervisors can only share places in the same parent
  • For example, in Kenya CHA cannot manage CHUs across multiple subcounties. Others confirmed this was the case for all projects.

CHT Experience

CHT manges users and places separately. Which is closer to what we want now. Can we rely on the CHT experience in invest there?

• Uganda User Managers need to be restricted to a place and cannot use admin console.
• Ideal would be moving areas between places, never allowing multiple supervisors to manage the same place. Otherwise users need to make two changes: add in new place and remove in old place
• The csv import scenario isn’t supported
• CHT cannot restrict places by type.
• CHT search is very poor. UMT has good string search.

Experience Concepts

1. Experience to create users

• Manage users (create, delete, edit)
• Manage places
• Manage what places are linked to what (+/- boxes, list of all places with checkboxes, drag/drop places between users)

2. Group By CHA Name

• When typing a CHA, get a dropdown of all known existing supervisors in the same place. If you select it, then the new place is added to the existing user.
• New experience to move places between existing users.
• How does this work with two different types of places that can be linked? Maybe it won't.

Reviewing these options, we thought option 1 was better. Option 2 might be an easier lift, but likely cant be extended to meet the needs of users.

Decisions

• We think UMT can add value over CHT and we should pursue building an experience for this
• We should explore the first concept listed above in more detail with prototypes and mockups
• Fred, Ben, Kenn are going to make a UI mockup as next step. Starting in Feb.

Notes:

• Apps which have dedicated “Supervisor Areas” in their hierarchy. What should we do or recommend? Should we remove these now, or are they still useful? After discussing, Mali and Kenya would need to keep the "Supervision Area" concepts.