1.5. Groups

CamCOPS assigns each uploaded task to one group. Groups have the following functions:

  • Groups help to define access control: what information can a user see?

  • A group has a pair of ID policies: what information about a subject/patient is required to (a) upload to the server, and (b) finalize that upload, clearing the data off the tablet?

1.5.1. Access control

Users may belong to one or several groups. Users can see data from the groups they belong to. In addition, each group may also have permission to view other groups (and users also gain the permissions of their groups).

Users upload data to one group at a time (but can change which group that is).

To make all that concrete, here are some ways that groups can operate. Imagine a research-active hospital. Here are some of its users:

User

Description

Group(s) to which user belongs

Smith

Research associate

depression_crp_study

Jones

PhD student

depression_crp_study

Willis

Research associate

depression_ketamine_study

Fox

PhD student

depression_ketamine_study

Armstrong

Research associate

healthy_development_study

Bliss

PhD student

healthy_development_study

Cratchett

Principal investigator

depression_crp_study; depression_ketamine_study

Boxworth

Principal investigator; consultant

healthy_development_study; clinical

Amundsen

SHO

clinical

Richards

SpR

clinical

Dennis

consultant

clinical

Suppose also that we have the following group-to-group permissions:

Group

… can see other group(s)

clinical

depression_crp_study; depression_ketamine_study

Then users would have the following permissions:

User

Can see depression CRP study

Can see depression ketamine study

Can see healthy development study

Can see clinical

Smith

yes

no

no

no

Jones

yes

no

no

no

Willis

no

yes

no

no

Fox

no

yes

no

no

Armstrong

no

no

yes

no

Bliss

no

no

yes

no

Cratchett

yes

yes

no

no

Boxworth

yes

yes

yes

yes

Amundsen

yes

yes

no

yes

Richards

yes

yes

no

yes

Dennis

yes

yes

no

yes

This example embodies these specimen principles:

  • Researchers see only the patients consented into their study.

  • A researcher may be part of one or several studies.

  • Clinicians (members of the clinical group) can see all records, including research records, for patients consented into clinical research for the hospital (in this case: depression_crp_study, depression_ketamine_study).

  • There may be some studies that don’t involve patients, so clinicians don’t get some sort of superuser status (in this case: healthy_development_study is not visible to clinicians in general).

In this example you would also probably want to ensure that the hospital’s main clinical ID number was required for the clinical, depression_crp_study, and depression_ketamine_study groups (and it would probably be optional for the healthy_development_study group, since that might involve non-patient volunteers who aren’t registered with the hospital).

Note

CamCOPS superusers can see everything. This is an administrative role.

1.5.2. Identification policies

First, please see Patient Identification.

Since different situations may require different identification policies, CamCOPS lets you configure this by group. Here are some contrasting scenarios:

Scenario 1: unitary ID policy

Imagine an institution that has a single centralized ID system (e.g. a hospital that only uses UK NHS numbers). It requires that all data conform to the principle that you must always use an NHS number. It also requires that you specify forename, surname, date of birth, and sex. You could create an ID number type 1 that you call “NHS number”, or “NHS” for short. All CamCOPS groups that you create might use these policies:

Upload and finalize:

    forename AND surname AND sex AND dob AND idnum1

Scenario 2: multiple pseudonymous studies

Suppose a University CamCOPS site is hosting multiple independent studies. Its ID numbers might look like this:

ID number

Description

Short description

1

MRI of adolescent development study ID

MRIAD

2

MEG of hallucinations study ID

MEGHAL

3

Affective trajectory of painters study ID

MOODPAINT

Then a hypothetical mri_ad group might have these policies

Upload and finalize:

    sex AND idnum1

while the meg_hal group has these:

Upload and finalize:

    sex AND idnum2

… and so on. Each study requires its own study-specific ID but does not require subjects to be identified in other ways.

Scenario 3: mixture of requirements

Let’s use the hospital scenario above. We might have the following ID number types:

ID number

Description

Short description

1

Hospital number

H

2

NHS number

NHS

3

Research Healthy Development Study number

ResHealthyDev

The hospital might want all studies involving patients to have fully identifiable information, so the clinical, depression_crp_study, and depression_ketamine_study groups might all have the following ID policies:

Upload:

    forename AND surname AND dob AND sex AND (idnum1 OR idnum2)

Finalize:

    forename AND surname AND dob AND sex AND idnum1 AND idnum2

The difference between uploading and finalizing allows clinicians some leeway by allowing them to fetch NHS numbers later.

In contrast, the healthy_development_study might involve volunteers who might not have a hospital number, and don’t need to know their NHS number, but can provide it if they wish and consent to have their research records cross-linked to their hospital or other NHS records. That group might have these policies:

Upload:

    sex AND idnum3

Finalize:

    sex AND idnum3

Other variations

Some clinical research studies might want to enforce their study-specific number in addition to the hospital’s common clinical identifier (such as an NHS number).

These requirements are why CamCOPS allows an ID policy to be set for each group. A global setting wouldn’t be enough.

If still further isolation is required, additional CamCOPS instances (databases) can be created.

1.5.3. Group administrators

For a large-scale system, it can be be desirable to delegate user management to group administrators (“groupadmins”), such that groupadmins can manage their own users WITHOUT being able to see all records on the system.

For example, Alice may be a superuser, but Bob, Carol, Dave, and Edna all run separate studies. Alice doesn’t want to have to manage the dozens of end users, so she makes Bob a groupadmin for his study, Carol a groupadmin for hers, and so on. Then Alice only has to worry about setting up the groups and the groupadmins in the first place (and perhaps rescuing groupadmins who forget their password).

This is a bit tricky conceptually. CamCOPS implements it as follows:

  • Only superusers can set groupadmin status, and create/delete groups.

  • We want groupadmins to be able to add users. If they try to add a user that already exists, we don’t want a duplicate user added (so the fact of a user’s previous existence may become known to groupadmins). When they add a user, they must make that user a member of at least one group

  • We can’t let groupadmins delete users arbitrarily. We allow groupadmins to delete a user if all the users’ groups were administered by this groupadmin. (Phrased a different way: a groupadmin can’t delete a user who belongs to any groups that don’t “belong” to the groupadmin.)

  • The groupadmin can grant/revoke access for their groups only.

  • As a result, some permissions are group-specific 1:

    • login (users can login if the “login” permission is set for any group)

    • upload (users can upload to a group only if they have “upload” permission for that group)

    • register devices (similar to “upload”)

    • view all patients when unfiltered (if you’re in more than one group, this per-group setting would be applied to patients’ records belonging to each group according to your permissions for that group)

    • may dump data (applies to data for that group only) 2

    • may run reports (also per-group) 2

    • may add notes (also per-group)

  • A certain amount of crosstalk is hard to avoid, e.g. for these flags:

    • must change password (this flag is associated with a user, not a group; it wouldn’t make sense to say that you have to change your password for group A but not for group B, so the outcome is that any groupadmin can make any of “their” users change their password).

  • Groupadmins can perform user editing functions (such as altering permissions or resetting passwords) for users that they oversee.

  • Groupadmins may not edit permissions for (or delete) other groupadmins or for superusers, unless they are themselves a superuser.

  • Note that this leaves one other main area where the superuser may have to step in. Suppose Bob administers group B. Richard is in group C, and Bob wants to add him to group B. Bob won’t be able to see or edit Richard, so the superuser will have to intervene. (If Bob were adding a completely new user, Sandra, that’d be different – Bob could create Sandra’s user and assign her to group B simultaneously.)


Footnotes

1

Implemented in the UserGroupMembership class.

2(1,2)

Specifically, note that there is no “second-hand” authority to dump/report. For example, if group G1 can “see” G2, and user U has authority to report on (or dump data from) G1, that authority does not extend to G2 – even though U could browse tasks from G2 via the second-hand authority for that.