Specific page commentary
The course introduction objectives were good, however an additional objective which could be included is the importance of a ‘properly structured’ database. (Critical for a robust, valid and auditable system that maps easily to the data collection tool used, paper or electronic CRF)
Pg. 1 Course recognition: Suggest change "…research teams and others wanting to learn how to design and manage the data generated during clinical research; …”
Pg. 3 The objectives of good clinical data management…second bullet suggest change "sufficiently accurate to support…"
Pg. 6 The data management system is a computer system…
2nd paragraph, line 6 delete and Access
Add end of last paragraph:
MS Access can be programmed to meet most requirements, but this is a significant development task.
Paragraph 6: delete the reference to Epihandy (no longer supported)
Paragraph 7 …and funding agencies require
The DM plan
An essential component is a code-book/data dictionary which needs to be kept up-to-date through-out the life cycle of the clinical study. This will ensure accurate interpretation of the data variables collected during the study.
The reference to CDASH is very useful for those who are designing a case record form (CRF) and for guiding database development; this is becoming essential for data collected in clinical trials where the data will need to be submitted to a regulatory authority.
CRFs & protocol development
The CRF is a tool for collecting the necessary data as specified by the protocol; conversely, not every study activity is required by the protocol, and therefore does not need to be in the CRF. Developing the protocol and CRF in parallel is IDEAL but may not be possible practically. Wherever possible, however, include your data manager in protocol development, ideally before you submit it for review to ethics committees etc. This helps ensure everything stated in the protocol is do-able from a DM perspective. Remember also that variables need to be recorded in the correct form. E.g. don’t record things categorically if the study requires actual numeric values - if one wants to know someone’s age one should ask for their date of birth, rather than ticking a category which asks if an individual is above 18 or below.
Particular challenges for the site as regards DM
If the DM function is out-sourced to a vendor, there still needs to be a study staff member at site responsible for managing the vendor relationship (not necessarily the contract if this is held by the sponsor), data entry staff and data queries. There needs to be clearly defined roles and responsibilities - the tasks the site and vendor will take responsibility for and up to which level, including quality control. A suggestion is that, at study start, ensure you have access to the monitoring plan to explore the scope needed for site level quality assurance.
Differences between paper and electronic CRFs
The FDA has specific guidelines and recommendations pertaining to electronic data capture (EDC), these need to be taken into consideration with experienced staff in place before deciding to change from a paper based to an EDC.
The platform that the EDC system would be hosted on needs to be decided and considerations include:
· Where is the server that hosts the EDC, is this on a local server or a cloud?
· How secure is the logon system?
· What happens to your data after your study?
· How easily can you extract data from the system in order to perform analysis and for reporting?
· Assess to the EDC must be controlled with a user name and password, and only provided to those staff members that have been delegated tasks that require assess to the EDC.
Changing from a paper based CRF to EDC doesn’t mean the site has less work – it is simply task shifting, and in fact the site can take on more responsibility, particularly as regards quality control.
TIP: Structured notes on your electronic CRF will make it easier for data entry, for example snippets out of the SOP. You could use pop-ups. E.g. “you also have to do the height & weight”
Keep in mind the following when designing a database:
· Important not to over-codify in the database rather save the actual result and code later in your analysis software. E.g. if the response can be No, Yes, Unknown, save the data as N,Y,U and for coding before analysis 0,1,9.
· Consider what information you need in your analysis.
· Data 'people' often like to use numbers instead of text - it's the same amount of space to save Y/N as 1/2. However, in 10 year's time will you still know what the 1 & 2 stand for if this information is not recorded somewhere accessible?
“How much control does a team have when dealing with data queries from international vendors who have been outsourced to manage a particular aspect of a study i.e. they are not necessarily responsible for the study database, but a component?
In your plan specify that this section is being outsourced and handled by team x and make reference to their SOPs where necessary – remember to ensure these are consistent with GCP and, at a minimum, attain the objectives of the DM plan as a whole.
Is it better to code in the database or in the analysis program?
Overall remember… Specifics are better, easier is better, work towards minimizing error. Everyone enjoyed the quiz!