From: Overcoming challenges to data quality in the ASPREE clinical trial
Operational domain | Key requirements | Design solution |
---|---|---|
Visit booking | - Identification of participants to be booked and the visit required - Organisation of “due” participants by visit venue - Computation of visit venue booking time - Recording and tracking of venue room bookings - Recording tracking of participants bookings linked with room bookings | “2 step” solution implemented - Venue room booking information entered via a single web page - Participants’ booking information entered on a nested web page Bookings presented in both calendar and list format via the web application |
Conduct of calls | - Identification of participants to be contacted - Mechanism to record call attempts and messages - Mechanism to record if participants are unavailable for calls at certain timepoints | Online call tracking implemented - List of participants due and eligible to receive calls available via web application Simple online phone call data collection form |
Study medication tracking | - Tracking of dispensing and retrieval of study medication bottle - Mechanism to ensure that the correct medication is provided to each participant | Online drug log implemented - Study medication bottle dispensation date and retrieval date recorded - Pill count logged To avoid unnecessary queries caused by transcription errors, each participant’s unique study medication code prompted and validated on data entry |
Retention | - Conduct of scheduled contact at certain timepoints identified as increasing the risk of participant withdrawal (e.g. between dementia trigger and completion of additional cognitive assessment) - Mechanism required to shift participants at risk of withdrawal from the regular contact lists to a retention team list | Retention status implemented - Database “views” utilised to derive a status describing whether scheduled study contact was appropriate (e.g. not eligible for phone contact – dementia trigger follow up in progress) Status utilised to shift participants from regular contact lists to retention team lists |
Communication | - Mechanism for staff to notify PCPs/GPs of abnormal results - Mechanism for requesting clinical documents from third parties (e.g. hospitals, specialists and general practitioners) | Curated third party communication pipeline created and implemented - Standard document request and abnormal result notification letters auto-populated with relevant participant details via web application - Microsoft Visual Basic for Applications utilised to send standard letters via fax or email communications |
Staff decision support | - Mechanism to ensure that protocol specified follow up of endpoints was completed - Mechanism to ensure protocol specified follow up of abnormal results was completed - Mechanism to ensure that only eligible participants were randomised | Key operational “status” for each study participant or key step derived and displayed - Database views utilised to derive a status describing the operational “next step”’ (e.g. event coded – awaiting supporting documents; annual visit – overdue etc) Status displayed on relevant pages on the user interface Randomisation restrictions implemented - Automated checks compared entered data against eligibility criteria - Randomisation function disabled for ineligible participants |
Data entry | - Mechanism to alert staff to potentially incorrect data for review - Clear process for alerting staff to data queries for resolution | Checks and balances implemented to minimise transcription errors - Pre-programmed value ranges, process prompts and protocol compliance checks, checked at the point of data entry - Page submission restrictions implemented to check for logic between values on a page Staff action list implemented - Automated checks compared entered data against acceptable rangesa and produced “action items” - Staff specific list of action items displayed on “home” page of AWARD-Data web application |