12.7. Web site: admin functions¶
When viewing the HTML view of a task, some users will have some of these additional options, shown at the very bottom:
This allows you to apply a textual note to a task, which will be displayed alongside it in the future. (For example, you could use this feature to mark a task’s content as disputed, if you are prohibited by policy from deleting data.)
The note will be visible when viewing all predecessor/successor versions of the same record.
This allows you to edit the patient record for this task, and others created alongside it on the same client device (e.g. if someone has misspelled a name). The option is only available for finalized tasks.
This deletes the task’s data (leaving the empty task structure as a placeholder). Predecessor/successor versions are also erased. Other tasks for the same patient will not be affected.
Erasure is prohibited for non-finalized tasks (for one thing, the tablet might re-upload the record). Finalize the records from the tablet (or, if you absolutely must, force-finalize them from the server) first.
When might one want to erase a task? See Delete patient entirely.
This is similar to Erase task instance, leaving placeholder but the task is deleted entirely from the database, with no placeholder.
This would typically be used in the event of a technical problem (e.g. to remove duplicates following a network failure during upload).
These options, on the main menu, are only available to users who are marked as administrators for one or more groups.
This page shows all users registered with the CamCOPS server. For existing users, it shows:
the username (marked to show you in the list);
their internal user ID number;
flags, such as superuser or group administrator status, and if the user is locked out, lockout status with an unlock facility;
e-mail address, hyperlinked to e-mail them;
a link to view more details about the user;
a link to edit the user;
groups they belong to, with links to set permissions for the user within each group;
their current upload group, with a button to change their upload group;
links to set their authentication method, including
change password for another user;
change password for yourself;
change multi-factor authentication method for the user;
a link to delete the user.
There is also a link to add a user.
By default, autogenerated users (used by patients as part of task scheduling) are not shown. They have names that look like gibberish. However, you can show them if you wish; there’s a tickbox to enable this.
Who can edit which users?
Superusers can add, edit, and delete all users.
Group administrators can add users to their group, and edit/delete users who are in a group that they administer.
More specifically, you may edit any user if you are a superuser. Otherwise, you may edit a user if (1) they are not a superuser or group administrator, and (2) you are a group administrator for a group that they’re in.
What attributes can be set?
The following are user attributes:
password, and whether this must be changed at next login
which group the user will currently upload into
The following are attributes of the user—group association, i.e. apply separately to each group the user is in:
permission to upload from tablets and other client devices
permission to register tablet/client devices
permission to log in to the server’s web front end
permission to browse records from all patients when no patient filter is set (if disabled, no records appear in this circumstance)
permission to perform bulk research data dumps
permission to run reports
permission to add special notes to tasks
When adding a user, make sure you give them permission to log in, for at least one group, if you want them to be able to use the web front end! (You don’t have to do this, though – for example, some users may have permission only to upload from tablets, not use the server web interface.)
Setting MFA for a user
You may disable multi-factor authentication (MFA) for a user but not change the method by which they authenticate. If you do this, and MFA is mandatory on the server (see Multi-factor authentication settings), the user will need to set it up when they next use CamCOPS.
This simple page shows all e-mail addresses of your users, along with users whose e-mail addresses are missing.
You can e-mail an individual user by clicking their hyperlink (which will
launch your mail client via a
To e-mail all users, copy/paste the list shown into your e-mail client. (There
is no universally accepted standard for multi-recipient
mailto: URLs! See
This allows you to delete a patient (as identified by an ID number of your choosing) from a specified group. All tasks belonging to this patient are deleted. This operation is IRREVERSIBLE, so a number of confirmation steps are required.
When should records be deleted?
This can a complex question. To delete clinical records in the UK, one must know the age of the records (e.g. destruction after 30 years), but also factors such as whether the patient had a mental disorder within the meaning of the Mental Health Act 1983 2, or died whilst in the care of an NHS organization. See UK Department of Health, 2006, Records Management: NHS Code of Practice 3.
CamCOPS allows you to view records created before a certain date (e.g. created more than 30 years ago), by specifying a suitable end date in the search criteria, and for privileged users, this can be done across all patients.
The other criteria for deletion (e.g. mental disorder, death) are outside the scope of CamCOPS.
Here, you can force-finalize records for a device that has been lost or damaged while it has outstanding business with the CamCOPS server.
Client devices (tablets, or desktop clients) should finalize their own records. “Finalizing” means saying to the server “I have finished editing these; they’re all yours.” Tablets erase tasks locally when they finalize them (to minimize the amount of information stored on mobile devices), though they sometimes keep a copy of patient/subject identifiers to save typing later if the same patients will be re-assessed.
If a device is somehow disrupted – broken, CamCOPS uninstalled, device lost 1 – then you might need to tell the server that the client will no longer be editing these data. That’s what “forcibly finalizing” is.
After force-finalizing, the finalized versions will be treated as distinct from any remaining on the tablet, if the tablet is later rescued. That is, this process marks all records from a particular device (e.g. tablet, or desktop client) as final, so the device can no longer alter them. If you do this and the client re-uploads records, they will be created as fresh tasks, so only force-finalize devices that are no longer in use and to which you no longer have access.
The option will allow you to proceed even if the patient identification does not meet the necessary requirements; see also the facility to edit patient details, above.
These options are only available to users with the superuser flag set.
This option allows you to define groups, define ID policies for groups, and to configure which groups have intrinsic permission to see which other groups (if any). See Groups.
For existing groups, this page shows:
the group’s name;
its internal ID number;
groups whose data this group is allowed to see (in addition to its own data);
the upload ID policy;
the principal (single necessary) ID number required by the upload policy, if applicable;
the finalizing ID policy;
the principal (single necessary) ID number required by the finalizing policy, if applicable;
a list of group members;
buttons to edit and delete the group.
There is also a link to add a new group.
CamCOPS supports multiple simultaneous ID numbers. For example:
ID type number
CPFT RiO number
Smith group research ID
Jones group research ID
See patient/subject identification for more background. Here, you can view and edit ID number definitions.
For existing ID number definitions, this shows
the ID type number (e.g. 1, 2, 3…) (note: this is the internal CamCOPS number representing this type, not a specific patient’s ID);
a description (e.g. “NHS number”);
a short description (e.g. “NHS”);
a validation method, if applicable (e.g. CamCOPS knows how to check UK NHS numbers for validity using their checksum method);
for HL7 exports, the HL7 ID Type and HL7 Assigning Authority;
for FHIR exports, the URL (hyperlinked) used to define this ID number (Patient identifier) system;
buttons to edit and delete the ID number type.
There is also a link to add a new ID number definition.
There are a few additional options for HL7 (v2) and FHIR messaging:
For HL7 v2 messages, you can specify the Identifier Type here. This is ‘a code corresponding to the type of identifier. In some cases, this code may be used as a qualifier to the “Assigning Authority” component.’ See:
In the FHIR standard, all ID numbers are accompanied by a URL that defines the identifier “system”. You can set this for any ID number.
You should specify this for any “standard” identifier. For example, in the UK,
the standard URL for “NHS number” is
If you don’t specify one, CamCOPS will use a default value (a URL pointing back to the CamCOPS server).
A disaster; you should hope that the device was encrypted and be slightly relieved that CamCOPS data itself is.
UK Mental Health Act 1983: https://www.legislation.gov.uk/ukpga/1983/20/contents. UK Mental Health Act 2007: https://www.legislation.gov.uk/ukpga/2007/12/contents.
UK Department of Health, 2006, Records Management: NHS Code of Practice: https://www.gov.uk/government/publications/records-management-code-of-practice-for-health-and-social-care