Assigning usernames - best practices, challenges?

Users
1

Hello Implementers!

As some sites in India scale, I've been thinking more about how best
to create usernames that have meaning to both the CommCare user and
the different web users. I've learned that user information needs to
be displayed differently for different people looking at the CCHQ
reports online. We're thinking carefully about the information we
convey in usernames and how we take advantage of the Groups feature.

I'm seeking tips from other CommCare implementers. Perhaps you can
share your use cases. Below I share what we've tried out at two sites
in India.

For the small 10 CHW pilots we ran, we create usernames containing
only the first name of the CHW. (i.e. suman) But now as these sites
scale, we learn that this is no longer feasible. The obvious reason is
because there are so many CHWs with the same name.

Avoiding duplication among users

Alternatively, we tried firstname.lastname. But not surprisingly,
there were several CHWs with the same first and last name. For those,
we distinguished by adding initials of the village name at the end. So
evidently, the usernames became firstname.lastname.villageinitials.
(The IDs are quite long and fall off the login screen).For this site,
we also used the Groups feature to divide the 70 CHWs by Primary
Health Center for top level insight.

I'm still not convinced this is the best option and sure there are
many more alternatives.

Meaningful information for Web users

One of the first questions I ask before implementation is about who
will be looking at the data on CCHQ. Each web users may be interested
in seeing information differently. The field-based project coordinator
most often knows their health workers well and can identify users on
CCHQ by the firstname.lastname. But perhaps a government official or
manager more removed from the field who also wants to monitor the data
doesn't find it meaningful to see performance data on a name-wise
basis and perhaps would prefer less detail?

An option could be to take advantage of the groups feature and create
'x' many groups as required by the different web user types.

More than 1 health worker type and multiple stakeholders

For a project that involves three different frontline health workers,
we created usernames with the following format:
firstname.position.communitycode. We need the ability to sort the CCHQ
reports by position (either ASHA, AWW or ANM) because they work under
different government departments. Right now, this would be possible
using the search box at the top of the CCHQ reports. Similarly, field
based supervisors will need to be able to sort data based on
communities, and they can also do this by using the search box.
Another web user needs to be able to organize data by subcenter. For
this use case, we decided to take advantage of the Groups feature.

Dealing with health worker turnover

What happens when a health worker gets replaced? (Though this rarely
happens). I guess its up to the NGO or government, and it becomes more
of a question of whether they want to track the cases or track CHW-
specific performance. If they want to track only the cases, then
perhaps a simple username like asha_05 could be used. Then the new
ASHA could pick up the work from that phone, using that ID. Does
anyone have thoughts on this?

Eager to hear if anyone has inputs.

Thanks,

Mohini

2

Hi Mohini,

Great topic to discuss, and I am also interested to see what others have to
say.

In our use of EpiSurveyor we run into similar issues. However, since
EpiSurveyor requires each CHW to have a unique email address, we were
pushed to come up with a reasonable naming convention early-on. In
particular, we chose to have separate Gmail accounts for each CHW, and were
forced to create unique 'usernames' for each CHW (ie. because
@gmail.com was often taken).

I actually think it would be better to display the CommCare User's First
Name and Last Name (AKA "display" name) in CCHQ reports and drop-downs
--- rather than the actual username. Advantages of displaying the first
and last name include:

  • More user friendly for people accessing CCHQ reports
  • Unlike the username, the first and last name can be changed over time.
    For example, we have started to append "()" to the Last
    Name     of some CommCare users

We are also starting to use the Groups feature to group users together in
meaningful ways for our "Web Users". Here are groupings we plan to use:

  • We plan to create one group for each health district and configure the
    group to include each CHW from that district. In our case, each 'district'
    group may contain up to 40 CHWs. This group will be used to
    monitor/supervise at the health district level
  • We plan to create one group for each NGO that helps to
    monitor/supervise CHW cases. In our case, one health district may have
    multiple NGOs involved with CHW monitoring/supervision and each NGO could
    be monitoring many CHWs. For this to work as desired, each NGO "Web User"
    account should only have access to one or more specific groups, since they
    should not be able to access case data from other CHWs.

In summary, here is how I would like to see things work in our situation.
I'm interested to see what others think.

  1. Create CommCare User accounts with unique usernames of ".." and configure their actual First and
    Last names; appending "()" to the last name if needed to
    avoid non-unique "display" names
  2. Modify the CHW reports and DropDown to show the "display" name
    instead of the username
  3. Create both "geographic" and "monitoring/supervision" CommCare Groups
    and assign CommCare Users to the appropriate group(s)
  4. Support access control policies that allow CommCare WebUsers to only
    access configured Groups

Points 1&3 can be done already. Points 2&4 would require changes to CCHQ.

Regarding healthcare worker turnover, I woud like to handle this via an
administrative UI to re-assign cases from one CommCare User to a second
CommCare User. This would allow us to move all (or some) of the open cases
from one CHW to one or more CHWs. This would not only allow us to handle
CHW turnover, but also allow us to shift some cases between CHWs covering
the same communities. Functionality like this may already be in the works.
I would steer away from using the same CommCare User account for both a
previous and current CHW.

Hope this helps. I'm interested to hear what both fileld implementers and
CommCare developers think.

Ray

3

Hey Ray,

I think these are really good suggestions (as always), especially the
switch to listing CHWs by their display name rather than their username. I
think moving forward that's how we'll do it, so thanks for that. I think
that may help some of the problems that Mohini was talking about, but it
seems like there's still an open question as to how to name users that
every deployment will have to deal with.

Cheers,
Danny

··· 2012/2/23 Ray Brunsting

Hi Mohini,

Great topic to discuss, and I am also interested to see what others have
to say.

In our use of EpiSurveyor we run into similar issues. However, since
EpiSurveyor requires each CHW to have a unique email address, we were
pushed to come up with a reasonable naming convention early-on. In
particular, we chose to have separate Gmail accounts for each CHW, and were
forced to create unique 'usernames' for each CHW (ie. because @
gmail.com was often taken).

I actually think it would be better to display the CommCare User's First
Name and Last Name (AKA "display" name) in CCHQ reports and drop-downs
--- rather than the actual username. Advantages of displaying the first
and last name include:

  • More user friendly for people accessing CCHQ reports
  • Unlike the username, the first and last name can be changed over
    time. For example, we have started to append "()" to the
    Last Name of some CommCare users

We are also starting to use the Groups feature to group users together in
meaningful ways for our "Web Users". Here are groupings we plan to use:

  • We plan to create one group for each health district and configure
    the group to include each CHW from that district. In our case, each
    'district' group may contain up to 40 CHWs. This group will be used to
    monitor/supervise at the health district level
  • We plan to create one group for each NGO that helps to
    monitor/supervise CHW cases. In our case, one health district may have
    multiple NGOs involved with CHW monitoring/supervision and each NGO could
    be monitoring many CHWs. For this to work as desired, each NGO "Web User"
    account should only have access to one or more specific groups, since they
    should not be able to access case data from other CHWs.

In summary, here is how I would like to see things work in our situation.
I'm interested to see what others think.

  1. Create CommCare User accounts with unique usernames of ".." and configure their actual First and
    Last names; appending "()" to the last name if needed to
    avoid non-unique "display" names
  2. Modify the CHW reports and DropDown to show the "display" name
    instead of the username
  3. Create both "geographic" and "monitoring/supervision" CommCare
    Groups and assign CommCare Users to the appropriate group(s)
  4. Support access control policies that allow CommCare WebUsers to
    only access configured Groups

Points 1&3 can be done already. Points 2&4 would require changes to CCHQ.

Regarding healthcare worker turnover, I woud like to handle this via an
administrative UI to re-assign cases from one CommCare User to a second
CommCare User. This would allow us to move all (or some) of the open cases
from one CHW to one or more CHWs. This would not only allow us to handle
CHW turnover, but also allow us to shift some cases between CHWs covering
the same communities. Functionality like this may already be in the works.
I would steer away from using the same CommCare User account for both a
previous and current CHW.

Hope this helps. I'm interested to hear what both fileld implementers and
CommCare developers think.

Ray

4

Hi Danny,

Great that you'll start using the display name across the CCHQ UI! I'm
sure that will make help a lot.

I believe showing the display name will also help address the original
question about how to avoid "duplication [of usernames] among users",
since the usernames will no longer be required to also convey "Meaningful
information for Web users". So, a username convention of
.. could be used to ensure uniqueness.
(I think of all my contacts who have email addresses that make no sense to
me....but I don't care because their display name is always used after I
add their contact information into my contact list).

Also, you could choose to use community-specific usernames (eg. .) and adjust the display names to represent the
'current' CHW over time. This may help address the turnover issue
mentioned by Mohini. However, I don't personally like this approach and
think it would is better to transfer case ownership during CHW turnover.

Thanks, Ray

··· On Tuesday, February 28, 2012 8:14:41 AM UTC-5, Daniel Roberts wrote: > > Hey Ray, > > I think these are really good suggestions (as always), especially the > switch to listing CHWs by their display name rather than their username. I > think moving forward that's how we'll do it, so thanks for that. I think > that may help some of the problems that Mohini was talking about, but it > seems like there's still an open question as to how to name users that > every deployment will have to deal with. > > Cheers, > Danny > > 2012/2/23 Ray Brunsting > >> Hi Mohini, >> >> Great topic to discuss, and I am also interested to see what others have >> to say. >> >> In our use of EpiSurveyor we run into similar issues. However, since >> EpiSurveyor requires each CHW to have a unique email address, we were >> pushed to come up with a reasonable naming convention early-on. In >> particular, we chose to have separate Gmail accounts for each CHW, and were >> forced to create unique 'usernames' for each CHW (ie. because @ >> gmail.com was often taken). >> >> I actually think it would be better to display the CommCare User's *First >> Name* and *Last Name* (AKA "display" name) in CCHQ reports and >> drop-downs --- rather than the actual username. Advantages of displaying >> the first and last name include: >> >> - More user friendly for people accessing CCHQ reports >> - Unlike the username, the first and last name can be changed over >> time. For example, we have started to append "()" to the >> *Last Name* of some CommCare users >> >> We are also starting to use the Groups feature to group users together in >> meaningful ways for our "Web Users". Here are groupings we plan to use: >> >> - We plan to create one group for each health district and configure >> the group to include each CHW from that district. In our case, each >> 'district' group may contain up to 40 CHWs. This group will be used to >> monitor/supervise at the health district level >> - We plan to create one group for each NGO that helps to >> monitor/supervise CHW cases. In our case, one health district may have >> multiple NGOs involved with CHW monitoring/supervision and each NGO could >> be monitoring many CHWs. For this to work as desired, each NGO "Web User" >> account should only have access to one or more specific groups, since they >> should not be able to access case data from other CHWs. >> >> In summary, here is how I would like to see things work in our situation. >> I'm interested to see what others think. >> >> 1. Create CommCare User accounts with unique usernames of "> name>.." and configure their actual First and >> Last names; appending "()" to the last name if needed to >> avoid non-unique "display" names >> 2. Modify the CHW reports and DropDown to show the "display" name >> instead of the username >> 3. Create both "geographic" and "monitoring/supervision" CommCare >> Groups and assign CommCare Users to the appropriate group(s) >> 4. Support access control policies that allow CommCare WebUsers to >> only access configured Groups >> >> Points 1&3 can be done already. Points 2&4 would require changes to CCHQ. >> >> Regarding healthcare worker turnover, I woud like to handle this via an >> administrative UI to re-assign cases from one CommCare User to a second >> CommCare User. This would allow us to move all (or some) of the open cases >> from one CHW to one or more CHWs. This would not only allow us to handle >> CHW turnover, but also allow us to shift some cases between CHWs covering >> the same communities. Functionality like this may already be in the works. >> I would steer away from using the same CommCare User account for both a >> previous and current CHW. >> >> Hope this helps. I'm interested to hear what both fileld implementers >> and CommCare developers think. >> >> Ray >> >