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
18.104.22.168.1. Charity payment records¶
View and add records of payments made to charity (payee and amount).
22.214.171.124.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.
126.96.36.199.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).
188.8.131.52.4. Contact requests¶
View contact requests here. (To generate a new contact request, see Submit contact requests.)
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.)
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
View letters generated by CRATE that the RDBM is authorized to see.
This also includes letters that the RDBM is required to send manually.
184.108.40.206.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
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).
220.127.116.11.1. Query audits¶
View the audit trail of research queries conducted via CRATE itself. The
underlying class is
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.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
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