Create a UserGroup feature (or Organizational Roles?)

Hi All,

I poked my head into a conversation thread about Cohort permissions, and the topic came up that we should have a built-in way of representing ad-hoc groups of users. (This is different from Role, which are about assigning system privileges.)

I feel like this feature would be important to have, but it’s never urgent enough for anyone to pick up ahead of time.

I’d like to volunteer to design and implement this feature. I would do this very slowly, since I don’t have much spare time these days.

Would this be useful? If so, please let me know here, and I’ll start a design doc to better capture the use case.

8 Likes"\"Organizational%20Roles\""

Thanks for the pointers Daniel!

I was thinking that instead of implementing “Organization Role” I would implement “User Group”:

  • a grouping of users (instead of persons or providers, and not tied to locations)
  • generic platform functionality (instead of modeling a specific part of the care system)
  • could be used as the basis for “share with …” functionality

Does anyone think this is useful, and if implemented they’d actually leverage it at some point?


Thanks @darius for offering to help on this topic :muscle:

Yes a new UserGroup entity is indeed needed. I would say that, among other things (such as those that you listed), this entity is what would be a proper implementation of organisational roles.

We discussed this very topic with @burke on a call recently and I commented that the OpenMRS wiki states well the distinction between app roles and organizational roles but does not provide an appropriate mechanism to model the latter. User groups would be the way to do that.

Thanks @mksd I’ll take your reply as volunteering to review a design doc. :slight_smile:

Please share if there are any notes from that call.

It’s certainly a feature that would be useful to the way we’re discussing leveraging cohorts to provide patient lists; whether or not that would see actual use in practice I’m unclear on. I’m happy to review a design document, though.

Hey @darius! I hope you and your family are doing well and staying safe. :slight_smile:

I like the potential of UserGroup to provide the creation of groups of users that can be used for more than permission assignment. Some random thoughts that come to mind (feel free to ignore these, just free-associating here):

  • What are the similarities/differences from cohort? Will we end up wanting all the same features as cohorts (e.g., static manually-managed lists of users and dynamic/calculated lists, start & stop dates for memberships)? If so, can we leverage the same code/approach to avoid doing the same thing twice or in different ways?
  • How does this relate to grouping providers? When I consider groups of users unrelated to permissions/access management, most of the examples are actually groups of providers.
  • How can we avoid promoting lists of everybody? Just like we added concept_class to classify concepts without having to create massive concept sets (like creating a concept set for all diagnoses), I wouldn’t want, for example, to end up with a user group for all providers.
  • Can we avoid making implementers & developers hate the UserGroup feature and find workarounds because it’s a pain to manage (like we managed to do with roles & privileges)? :slight_smile:

Would you mind sharing some of these examples?

Examples of groups of providers (not just users):

  • The doctors/nurses assigned to clinic A
  • Run a report for patients with encounters with any one of these people
  • The patient’s care team
  • The tumor review board
  • Team members on holiday in September

Some examples that could be (constrained to) users:

  • Quality metrics report broken down by each of these users
  • Who should be notified when a resistant infection is identified
  • People who should receive a copy of the report

Thanks! Most of those refer to an end-user use case, but a few don’t. Would you mind speculating at an end-user reason for these user/provider groups?

  • The doctors/nurses assigned to clinic A
  • The patient’s care team
  • The tumor review board
  • Team members on holiday in September

FYI I started sketching out some thoughts at OpenMRS UserGroup Proposal - Google Docs.

Right now my biggest gap is understanding real (potential) use cases.

  • The doctors/nurses assigned to clinic A

Am I supposed to work in clinic A or clinic B next week? Will Mary be working with me?

  • The patient’s care team

Who’s the patient’s primary care physician? Which cardiologist is treating this patient’s heart disease?

  • The tumor review board

Who is on the tumor board reviewing my patient’s case? Am I serving on tumor board next week?

  • Team members on holiday in September

Will Mary be starting holiday next week or the week after next? Does the clinic know I’m starting holiday next week?

I note that several of these are provider scheduling use cases that could be based on the same data structure as User Groups, but I would have assumed they’d be part of a dedicated system.

The most useful is defining the patient’s team members, but that could be limited to users of the system.

@ibacher @mksd @burke @dkayiwa @jdick

I sketched out some possible directions in this document: OpenMRS UserGroup Proposal - Google Docs

There are open questions, e.g. is this just a group of users? Or a set of users + provider?

Please give feedback, or point me to anyone else who might be interested. I’d like to figure out which direction is worth pursuing.

Since both users and providers point to person, wouldn’t it be simpler if this turns into a PersonGroup (list of persons)?

I would focus on users for now (instead of users + providers), since groups of providers remains an imagined need and, in most cases, providers will also be (or could be) users of the system.

Instead of hardcoding a single owner, what about allowing ADMIN, EDIT, and VIEW relationship to user and to user group? That would allow multiple owners (e.g., who could delete the group).

How would we handle publicly accessible (viewable) groups without having to grant view access to all users?

We may not need to add groups of groups now, but I could easily see it becoming a requirement if user groups are used widely, so – even if we don’t build it now – I’d like to at least consider how it would affect the API. More specifically, could it be introduced in a backwards-compatible way that doesn’t require all consumers to be refactored. For example, an API call like “Who are the users in this group?” could returns all users whether direct members or members of subgroups. And if “What groups is this user in?” only returned direct memberships, the responses wouldn’t change. But “Remove user from a group” might behave differently (e.g., after groups of groups was introduced, it might fail if the user belongs to a subgroup and isn’t a direct member of the group). That’s probably fine.

Groups of groups gets a little more complicated when you consider permissions (e.g. what happens if a user has VIEW access to a group but doesn’t have access to one of its subgroups? :confused: Maybe that’s more reasons to defer groups of groups for now.

1 Like

That’s definitely my preference.

I think you’re saying we need a more detailed way of controlling access. I will iterate on that.

I wonder if the MVP can be owner (or just creator) + is_publicly_visible, and Access Control Lists can be a followup.

I agree, and I should have said this more explicitly. I was thinking we’d distinguish between:

  • management functions, that operate at a single group level,
    • e.g. the management UI would use userGroup.getMemberships()
    • I don’t think it’s confusing to have Add/Remove work at this level. (Maybe I’m naive.)
  • usage functions, which operate on an expanded group
    • e.g. checking for group membership would do UGService.expandToUserIds(UserGroup)

That sounds reasonable. I’m pretty sure an early requirement will be the ability to share non-public lists with others (users or user groups) and collaborative management. Starting with just is_public could work and a couple of many-to-many relationships to hold permissions (admin, edit, view) for users & user groups could be v1.1.

As long as requesting a user’s groups only returns direct memberships (e.g., not parents of groups once hierarchies are introduced). When hierarchies are introduced, there could be separate method(s) to get all inherited groups and/or find out which direct group membership(s) connect a user to a specific group (i.e., to make it easier to figure out why a user is in a group through the hierarchy).

@darius do you feel closer to a design?