Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for having multiple places assigned to a user #185

Open
kennsippell opened this issue Jun 27, 2024 · 9 comments
Open

Support for having multiple places assigned to a user #185

kennsippell opened this issue Jun 27, 2024 · 9 comments

Comments

@kennsippell
Copy link
Member

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
Copy link

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
Copy link
Member Author

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
Copy link

ChinHairSaintClair commented Jul 24, 2024

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
Copy link
Member Author

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
Copy link

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
image

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

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

We can however still see all reports across the system
image

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
Copy link
Member Author

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
Copy link

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
Copy link

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

@alexosugo
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants