Best practices for user management at scale?

Implementation
1

Intro

I was on a call with a partner and they wanted to know what are the best practices for user management at scale? I realized that the question might be a fun research project for myself, a Medic teammate, and that I could post both the questions and answers publicly here on the forum. Anybody who has related questions, or solutions they’ve implemented, should feel welcome to add their own comments!

In this context a “user” is a community health worker (CHW) and have an area that the families they care for are under, a login and password and a role.

Questions

  • How does the CHT recommend retiring users and replacing them with new ones?
  • How do you manage the lists of information, such as surname, telephone number, village etc., before the users exist in the CHT?
  • What are some of the best practices that medium to large deployments of the CHT use to manage their users?
4 Likes
2

I’ve had a number of conversations about this over the past few weeks and I wanted to report back to the community about what I’ve found.

How does the CHT recommend retiring users and replacing them with new ones?

I found a number of real world practices that I wanted to spell out the pros and cons of. Let’s start with

New contact & new user, associate with existing place

This is best practice. The steps are:

  1. Create a new contact for the new CHW.
  2. Make this contact the new primary contact for the old CHW’s place - do not create a new place!
  3. Change the name the CHW’s place as needed
  4. Create a new user associated to the new contact.

If you want to deactivate the old CHW

  1. Have the old CHW do one last sync to ensure all data is pushed up from their device
  2. Change the password for the old CHW’s user on the server
  3. Wipe the user’s device to clear any private health information

Pros

  • No data loss from one CHW to another
  • Humans and computers alike looking at the CHT, CouchDB and Posgtress can tell both who was giving the care, and when the switch happened between caregivers.
  • Households associated with the old CHWs place do not need to be re-parented.
  • All reports from the old CHW are accessible to the new CHW.
  • Any replication and applicable replication depth rules apply exactly the same as before - no more or less data will be synchronized
  • Very secure - old CHW can not log in

Cons

  • Old CHW Contacts linger around, which may pollute workflows. There is no native “disabled” flag for a contact.

Edit existing contact, user and place

This is straightforward and a single step: just change the name on the 3 records. To make it a secure option, you need to change the CHW password and re-login. This practice is not recommended, but offers a lot of real world benefits.

Pros

  • Very few steps to set up
  • No extra CHW user and contact left to linger

Cons

  • Humans and computers alike looking at the CHT, CouchDB and Posgtress can NOT tell both who was giving the care, and when the switch happened between caregivers.
  • If the old CHW returns and you want to keep both CHWs active, you’re stuck creating a new contact and user.

Handing the mobile phone from one CHW to another

This is by far the simplest practice - effectively no steps are needed in the CHT. It comes with many draw backs and is not recommended. To make it a secure option, you need to change the CHW password and re-login. The pros and cons are similar to prior option.

Pros

  • No setup, leave changing the password
  • No extra CHW user and contact left to linger

Cons

  • Humans and computers alike looking at the CHT, CouchDB and Posgtress can NOT tell both who was giving the care, and when the switch happened between caregivers.
  • If the old CHW returns and you want to keep both CHWs active, you’re stuck creating a new contact and user AND getting a new device.

How do you manage the lists of information, such as surname, telephone number, village etc., before the users exist in the CHT?

Operational security is paramount when it comes to lists of usernames and passwords. The ideal practice could be to create a spreadhsheet with full name, telephone number etc. Included is a username but NOT a password. When users are created in bulk via the command line, have magic links sent to the user via an SMS gateway. This avoids the problem of passwords being stored in clear text in the spreadsheet or on a printed version.

An alternate, and also secure approach, is to bulk create the users as described above, not use magic links, and use random passwords that you do not save. At a later time, manually change each user’s password as you’re provision their mobile device. This also prevents a list of passwords from being stored in clear text.

Unfortunately, we know of many deployments that bulk create all users with near identical passwords that are then printed out or shared via email. This is poor security practice and should be avoided if possible.

What are some of the best practices that medium to large deployments of the CHT use to manage their users?

Beyond what is stated above, I did not get additional input from folks I talked to about this. I would love to hear what others here on the forum have to say! As well, we’re covering this on the next Round-up call.

3 Likes