9.10. Research Database Manager functions¶

9.10.1. RDBM admin site¶

This Django admin site allows the RDBM to administer all relevant aspects of the CRATE web site.

The RDBM views are those ending in MgrAdmin within crate_anon.crateweb.core.admin.

9.10.1.1. Authentication and authorization¶

9.10.1.1.1. Users¶

You can add and edit users here. Most attributes are obvious but these deserve comment:

Staff status: Can the user log in to the admin sites? Usually given to the RDBM, researchers, and developers.
Superuser status: Grants the permissions of an RDBM. Use with care.
Enable developer functions: Grants the additional permissions of a developer (beyond those of the RDBM). Use with extreme care.
User is a clinician. Enables the “clinician” features, like lookup of research IDs from patient IDs (for “their” patients).
User is an NHS consultant. Approves the user to respond to research enquiries regarding CTIMPs 1.

There are also information flags, including:

Enough info for researcher status? Unless this shows a green tick, information is missing, preventing the staff member from being named as the lead researcher for a study. This requires just a title, first name, and last name. (Title is the bit that isn’t required to create a user, so most likely to be missing.)

9.10.1.3. Research¶

9.10.1.3.1. Query audits¶

View the audit trail of research queries conducted via CRATE itself. The underlying class is crate_anon.crateweb.research.models.QueryAudit.

Note that any queries the researchers perform directly (via a direct SQL connection to the database) will not be captured this way; enable auditing on your database engine directly (e.g. MySQL, SQL Server) for this.

9.10.2. Edit sitewide query library¶

Here, you can edit your site’s site queries.

9.10.3. Look up patient ID (PID) from research ID (RID)¶

You can use the RID, MRID, or TRID to look up patient identifiers (PID and MPID values). This function is primarily to assist clinicians who want to see their own patients’ records within the research database, if the clinicians don’t want to do it themselves.

9.10.4. Charity payment report¶

Reports on amounts due to charity and payments made, in respect of clinicians responding to e-mails about their patients. (Payments are attributed irrespective of the clinician’s yes/no response.)

9.10.5. Report patients to be excluded entirely from anonymised database¶

Shows NHS numbers (only) of patients to be excluded entirely (fetched from the consent-mode records), for feeding to the anonymisation system as required.

9.10.6. Test message queue by sending an e-mail to the RDBM¶

This tests the full CRATE message system, by sending an e-mail to the e-mail address defined by the RDBM_EMAIL setting in the CRATE web config file. The sequence is as follows:

CRATE front end → Celery → Celery broker (e.g. via AMQP to RabbitMQ)
(via CRATE backend) Celery → picks up message from broker → CRATE e-mail system → authenticates with e-mail server and sends message
E-mail system → recipient

Footnotes

1: CTIMP: Clinical Trial of an Investigative Medicinal Product. See the UK Clinical Trials Regulations (2004, etc.): https://www.legislation.gov.uk/uksi/2004/1031/contents/made

9.10. Research Database Manager functions¶

9.10.1. RDBM admin site¶

9.10.1.1. Authentication and authorization¶

9.10.1.1.1. Users¶

9.10.1.2. Consent¶

9.10.1.2.1. Charity payment records¶

9.10.1.2.2. Clinical team representatives¶

9.10.1.2.3. Consent modes¶

9.10.1.2.4. Contact requests¶

9.10.1.2.5. Emails¶

9.10.1.2.6. Leaflets¶

9.10.1.2.7. Letters¶

9.10.1.2.8. Patient responses¶

9.10.1.2.9. Studies¶