-
14th Apr 2014, 02:35 PM
#1
Suitability of targeted SDV of data collated into the dose escalation interim report
My questions is regarding how to interpret the MHRA recommendation (Grey guide section 12.6.2) that there should be a clear quality control (QC) process to confirm that the data collated into the dose escalation interim report are accurate to ensure a decision is based in robust data. Does a ‘clear QC process’ mean 100% source data verification (SDV) of all data (i.e. both critical and non-critical data) to be used for the dose escalation decision?
In our Phase I oncology trials, the documented QC process is detailed in the study-specific monitoring guidelines. All source data in the patient medical records is source data reviewed (SDR) by the Clinical Research Associate (as per the Transcelerate definition of SDR). In addition, the critical data for the dose escalation is 100 % SDV’ed. For non-critical data that supports the dose escalation data (such as Haematology/Biochemistry blood parameter values), a certain % is checked, based on the study team's risk assessment. I am trying to determine whether the QC process documented in our study-specific monitoring guidelines fulfils the MHRA criteria of a clear QC process of all data used in the dose escalation.
-
26th Nov 2014, 03:00 PM
#2
Moderator
The protocol requires PK and safety data for the DE decision; therefore we expect QC on that data. Monitoring covers transcription of data into the CRF, so this is covered for critical parameters. However Dose Escalation reports are usually written quickly (and outside the normal data management process), with tables transcribed directly from the source documents, therefore we expect QC at this step if this data is transcribed again. This would not be covered by monitoring if the report was prepared directly from the medical notes. If the data used to prepare the dose escalation report used specific programmes to generate listings, then this would need programming validation/QC checks also.
However it is acceptable to use a risk based process, but this would need to be clearly documented in a formal procedure and the risk assessment.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules