A hitchhiker’s guide to data review in an ongoing (“live”) study – part 1: data review for pharmacovigilance purposes
Increasing complexity of study designs and demand for rapid data availability calls for regular data checks during the course of a clinical research project. However, especially in projects utilizing an electronic data capture (EDC) system, the data can change during the course of each day, e.g. due to data corrections, deletions or addition of novel data. Except for studies with very few patients, it is impossible (or rather impractical) to follow these changes in real time. So how can the demand for data review be satisfied without exploding the workload?
The most important issue to face is the nature or the goal of the respective review. Are you reviewing data for pharmacovigilance purposes? Or during data cleaning prior to an interim analysis? Or as part of your risk based monitoring or risk based quality management? Or rather for determining if the remuneration criteria of data entry are met?
All these aspects are frequently necessary during an ongoing project and are based on the review of given data status at a given time. However, the workarounds to obtain the respective data and their consequences can be very different. Sounds very theoretical? Indeed, thus let us illustrate some examples.
The following article series will present some aspects that we have faced over the last few years with the many different aspects of data review.
Part 1 – data review for pharmacovigilance purposes
In a way, this is the simplest and yet most demanding kind of data review, as time is a pressing matter in this context. The data are reviewed in different time frames according to the potential risks that arise from them.
For instance, serious adverse events (SAE) are usually reviewed within 24h to ensure that the information is as plausible and complete as possible, in order to take very rapid and important decisions (e.g. does this constitute a case that needs a rapid regulatory reporting). (see also Choosing the right safety reporting workflow for your study)
This constellation is not novel and has been practiced for many years in clinical research. The requirements and responsibilities are always very clear: the data comes by means of an electronic (eSAE) or paper-based SAE form and a pharmacovigilance-representative (or vendor) need to assess the data and initiate further actions as applicable. However, with increasing technical possibilities (especially eCRF technology), the sponsor all of a sudden gains awareness of many different data constellations, that require review to determine pharmacovigilance risks.
For instance – what about non-serious adverse events?
In a EU non-interventional setting as of 22.11.2017 all adverse drug reactions (ADRs, i.e. adverse events with a suspected causal relationship to a given drug) will need to be reported to the Eudravigilance Database every 90 days, irrespective of their seriousness (Directive 2001/83/EC).
This means, that you or your pharmacovigilance department might need to regularly review non-serious ADRs (or in some cases even all non-serious AEs in order to identify those cases that need to be reported). To this end, you will need regular reports (individual or aggregated) and will need to check if the data are valid, plausible and complete for reporting.
Thus, you will need to decide a priori what data shall be displayed, in what time frames data shall be reviewed and whether incremental and/or cumulative data representation of aggregated reports will yield the best usability.
Become aware of a hidden reports
In addition, you might also need to actively survey the study data beyond the AE data on a regular basis in order to monitor the sites’ compliance and identify potential missing case reports.
Again, especially in non-interventional settings with little monitoring but high surveillance demand in terms of reporting compliance, you might need to regularly check e.g. free text entries in the eCRF for hidden reports like “patient did not take medication due to rash after intake”. Just by reading this, you just have become aware of a hidden ADR – you now would need to check if a corresponding ADR is provided already, otherwise you will need to contact the site for further clarification.
Clearly define the consequences of your data review
Thus, findings from the respective data review have consequences, and these need to be clearly defined. Most commonly, findings from pharmacovigilance-related data review result in queries to the site to provide clarification and/or additional information, and in turn these data constitute a novel data status that needs to be checked in a respective time frame.
All of the above listed examples require many different eCRF and reporting functionalities. For instance, SAE information is usually forwarded in form of individual e-mail alerts for review. In contrast, non-serious events might be better monitored in an aggregated way e.g. by means of incremental and/or cumulative line listing. And yet again, the surveillance for “hidden” AE information might employ both approaches, i.e. real time alerts and aggregated listing review.
The important aspect here is that, especially with EDC projects, many steps need to be considered during the set-up of the study, which usually is prone to extensive time pressure.
We feel that for a smooth process and EDC set-up the following consideration check-list has proved helpful when applied early in the project:
checklis data review for pharmacovigilance
What are the regulatory and internal SOP requirements? Consult your pharmacovigilance (local and / or global) departments to identify their needs.
Based on these needs, identify early potential personnel and information processing bottle necks within your organization – their resolution will most likely result in budget impacts.
Include pharmacovigilance requirements (and preferably also pharmacovigilance decision makers form your organization) in the set-up phase of your study. This indeed sounds trivial but in our experience the sooner pharmacovigilance is involved, the faster and more smooth the set-up phase and later on the study runs. It is always easier to set up a system rather than to change a running system in order to include a new requirement.
Clearly define what are the data review requirements, i.e. what data is needed in what time lines.
Clearly define responsibilities – who will receive the information and who is responsible for its further processing. For instance- while it might be important to have many recipients for an SAE alert, one of these recipients should be clearly responsible for the further review and processing of this information. The same is also valid for aggregated reports – nominate the responsible party (within your organization or your vendor) who will review the data and follow-up on findings (e.g. by issuing queries, triggering a monitoring visit or escalating a case for further prioritized processing).
Clearly define the consequences of the review. When are queries issued to the sites and by what means. When is a query urgent enough to justify a phone call, when is a query in the eCRF sufficient. Keep in mind: these are budget-relevant decisions.
Define the necessity for documentation of the review. How to ensure that it is clear to an auditor or inspector who reviewed what and what the consequences were.