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.2. Consent¶
9.10.1.2.1. Charity payment records¶
View and add records of payments made to charity (payee and amount).
9.10.1.2.2. Clinical team representatives¶
For each known clinical team, you can mark one CRATE user as the clinical team representative. (They should have clinical authority to see identifiable records for any patient open to that team.) This person will then become one possible person for CRATE to e-mail about contact requests from researchers.
9.10.1.2.3. Consent modes¶
View and add consent modes in CRATE’s own database.
The consent mode includes two flags:
Consent mode (red, yellow, green, unknown/NULL).
Exclude patient from Research Database entirely?
Ancillary information includes:
Does the patient prefer e-mail contact?
Was the consent mode changed by a clinician’s override?
Who signed/authorized the change?
Note that the recording of consent modes is a little complex; in its Cambridge/CPFT configuration, CRATE looks up consent modes in a recent copy of the primary clinical records system (but failing that, CRATE’s own database can be used – which is what this view inspects/edits).
9.10.1.2.4. Contact requests¶
View contact requests here. (To generate a new contact request, see Submit contact requests.)
9.10.1.2.5. Emails¶
View e-mails sent by CRATE that the RDBM is authorized to see. (That’s not all e-mails; certainly not those to clinicians about patients on behalf of researchers.)
9.10.1.2.6. Leaflets¶
View and upload PDFs for the master leaflets used by CRATE.
If this view is blank, your site is not yet properly configured and you
need to run crate_django_manage populate
once from the command line.
The underlying class is
crate_anon.crateweb.consent.models.Leaflet
.
9.10.1.2.7. Letters¶
View letters generated by CRATE that the RDBM is authorized to see.
This also includes letters that the RDBM is required to send manually.
9.10.1.2.8. Patient responses¶
View/edit patient responses (where the patient has written back to the RDBM, after receiving information from their clinician).
The underlying class is
crate_anon.crateweb.consent.models.PatientResponse
. This object is
created when a clinician decides to send information to a patient; see
crate_anon.crateweb.consent.models.ClinicianResponse.finalize_b()
.
9.10.1.2.9. Studies¶
Add and edit research studies here. In addition to basic registration information, this includes:
the lead researcher (which CRATE user?);
a textual summary (used to send to clinicians/patients);
flags affecting the legal position or manner in which CRATE handles requests (e.g. under-16s, CTIMP, researcher prefers to approach patients directly?);
the study details PDF (sent to patients/clinicians);
an optional additional (subject form template) PDF for clinicians to complete about eligible patients, where applicable;
other researchers (eligible to submit requests to contact patients).
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