With the move to electronic ways of working and integration of more electronic systems within a clinical trial, the MHRA Good Clinical Practice (GCP) inspectorate has noticed that not all eSystems have been designed with the correct functionality in mind. This is because some of these systems are a mechanism to report protocol-required clinical data to the sponsor and are therefore acting as an electronic case report form (eCRF), yet do not have the same functional requirements for an eCRF to meet International Council for Harmonisation (ICH) GCP expectations and ensure data integrity.
There has been increasing use of interactive response technology (IRT) systems collecting trial data such as height, weight, stratification factors and other protocol-specified data which is then integrated into either the main eCRF, for example, to be visible in an editable field, or into a table in the clinical database which may not be viewable in the eCRF. Depending on the process used, a number of issues can arise due to this integration where the data integrity aspects and investigator’s control of the data have not been adequately assessed.
For example, where clinical data entered into the IRT is transferred to the database or a non-editable field which is visible in the eCRF, there is no mechanism to amend or query the data should inaccuracies be identified, nor a mechanism to demonstrate via an adequate audit trail when data was entered, modified and by whom, with a reason for why the data was changed. A number of these scenarios have been described below along with some of the issues we have seen arising on inspection.
Definition of a Case Report Form (CRF)
To start with, let’s remind ourselves of the definition of eCRF:
ICH GCP E6 R2 (2016), 1.11: A printed, optical, or electronic document designed to record all of the protocol required information to be reported to the Sponsor on each trial subject.
The requirements and functionality of an eCRF must comply with the following to ensure that the data is robust and that any changes can be verified:
UK statutory Instrument 2004/1031 (including numerous amendments), Schedule 1, Part 2 (9): All clinical information shall be recorded, handled and stored in such a way that it can be accurately reported, interpreted and verified, while the confidentiality of records of the trial subjects remains protected.
If the trial is being conducted in accordance with ICH GCP E6 R2 (2016) the following requirements also apply to the eCRF: 5.5.3, 4.1.5, 4.9.3, 8.1, 8.2.2, 8.2.7, 8.3.2, 8.3.14, 8.3.15 and 8.3.24.
The eCRF is therefore a mechanism for the investigator to enter data into an electronic system to transfer to the sponsor. It is a form of electronic data capture (EDC).
The database is comprised of database tables which store all the clinical data. Data can be entered into these database tables via the front end (for example, eCRF or data entry screens for data management when using paper CRFs) or via direct data transfers from other electronic systems (such as laboratory data). There can be data tables which have no data entry screen and are not viewable as well as tables which are viewable but may or may not be editable. Each of these scenarios are explored below.
Clinical data entered into IRT which is then INTEGRATED into the clinical database (such as direct transfer to a table within the database)
When IRT data is integrated directly into the clinical database and not the eCRF, findings have been identified on inspection where the investigator has not maintained control of their data which was entered into IRT, not been provided with a copy of the data entered, nor the associated meta data. We have also identified that such data has included source data for which no other records were available. Without the full audit trail, it was not possible to verify what data was entered, when, by whom, and whether the data had changed at all. As per ICH GCP, this data belongs to the investigator and therefore should be available to, and under the control of the investigator (and not under the direct control of the sponsor). Where source data is entered directly into the CRF, or systems acting as the CRF, this should be defined in the trial protocol.
Sponsors have taken this approach to prevent the site from entering the data twice (for example, into IRT for stratification and randomisation and also the eCRF for the clinical database) negating the need for monitors/data management to reconcile the data between 2 datasets. However, we have observed findings where the monitor has not reviewed the data entered into IRT against source data in circumstances when it has not been also entered in the eCRF (and reconciled later by data management). Monitoring plans had not considered the verification of this data entered into IRT.
There should be a mechanism available for the site to correct the data entry if required within the IRT system, to ensure that the data submitted to the sponsor is accurate. Equally, there should be a mechanism in place to query the data should this be inaccurate, and, as such, edit checks, source data verification and queries raised during data reconciliation activities may be useful in this regard.
However, often such IRT systems do not have this functionality built in and it is therefore not possible to confirm if the data had been reviewed during monitoring and verified as accurate.
Clinical data entered into IRT and then INTEGRATED into the clinical database and visible in the eCRF screen
Within this example, the data is manually entered into the IRT and then the information is integrated into the database and is visible on a form field within the eCRF. Consideration in this example is required as to whether the data in the eCRF can be amended by the site or not. Findings have been given on inspection where the data integrated into the eCRF can be amended and this has resulted in discrepancies between data entered in IRT and eCRF. This is usually following source data verification (SDV) of the eCRF value, resulting in a change to eCRF data (which had been integrated from IRT, yet the IRT entry has not been changed and shows a different value, see also the example below). This scenario is of concern where the IRT system contains source data and a discrepancy is identified between the 2 systems.
Clinical Data entered into IRT AND into the database via the eCRF
When the same data point is entered separately into the eCRF and IRT (such as height and weight) then it should be defined and documented which data set will be used for the analysis of the data and there should be mechanisms in place to ensure the accuracy of the dataset. For example, if it is decided that the eCRF height and weight will be used for the analysis then it is important that there is functionality within the eCRF to demonstrate the robustness of the data via audit trail and queries. It would be expected that the data is reconciled between the 2 systems and any inconsistencies identified and resolved (in the same way discrepancies between the clinical and pharmacovigilance safety database are managed).
The data entered into IRT may be critical data based on your risk assessment. For example, if height and weight were being used to calculate the dose for a subject then this would be a critical data point requiring review. If these fields in the eCRF can be edited and changed, but the IRT system cannot, then it is important to ensure monitoring plans include the requirement to review this data in both systems.
The impact of not changing the information in IRT should also be assessed. Are there algorithms built into IRT which base the assigned dose on the weight entered into the system? If so, then it is vital to ensure the correct information is entered into IRT, and if it was incorrect then there should be a mechanism for reviewing the impact on patient safety as well as data integrity (and a deviation raised where applicable).
Other eSystems
The above requirements also apply to other EDC systems such as ePRO, systems used to derive data directly from electronic health records and any devices used to collect clinical data to report to the sponsor. The functional specifications of such systems should be akin to eCRF systems with data management and monitoring processes in place to ensure the accuracy and integrity of the trial data.
Changes to the investigator's data
When using paper CRFs, there was a clear distinction between the CRF and the sponsor’s clinical database and the investigator always retained a copy of their CRF and an audit trail of any changes to their document. The sponsor would enter this data in their own database and would have to raise manual queries to the investigator for a response. They were not able to make any changes to the investigator’s CRF data.
With the increasing use of electronic systems and enhanced functionality of eCRF systems, we are not seeing the same clear distinction of what is the investigator’s CRF data. For example, serious adverse events (SAEs) are now being reported to the sponsor via the eCRF to reduce duplication of data. However, we have seen that on the SAE eCRF pages, there are fields for sponsor staff to add the SAE receipt date and expectedness assessment.
We have also seen the addition of protocol deviation forms into the eCRF for monitors to enter the information and the study management team to assess and document their review. This is not acceptable as this is an entry into the investigator’s eCRF (for example, form page). It would be more appropriate to have a separate database for this. It should be noted that workflow systems within the eCRF software itself, such as coding or queries, which allow sponsor staff to enter information, are acceptable as these are not trial specific data entry screens (which are CRF forms).
Change to the data entered into an eCRF by the sponsor or their delegated representative is strongly discouraged. This is because the CRF is the investigator's CRF and should remain in the control of the investigator. Similarly, data previously collected in paper diaries would be returned to the investigator for review and retention and then data transcribed for the sponsor, this equally applies when the format of data collection is electronic via an eDiary.
The investigator is responsible for delegating activities to trial personnel, which also includes entry of data into the CRF, which should be documented on the delegation log (as per ICH GCP E6 R2 4.1.5, 8.3.24). Therefore, the investigator should authorise the access of any person assigned editing rights in the eCRF and maintain oversight of this where the sponsor controls it, as well as authorisation of any entries and changes to the data by having visibility and oversight of such changes (ICH GCP 4.9.3).
There should be no need for any pre-authorised ‘self-evident corrections’ to be made by sponsor data management as occurs for paper CRFs and a sponsor database because any changes to an eCRF should be routed back to the investigator as a query and the paper-based system did not involve the sponsor staff amending the CRF itself, just their database copy of it. It is not necessary for the sponsor staff to have edit access to the eCRF forms.
The investigator should approve the data entered and any changes in the same way this is required for the CRF. We often see that data change requests for IRT and ePRO systems bypass the investigator and require sponsor approval only. Additionally, the rules concerning data changes have been agreed between the sponsor and the eSystem vendor and the investigator has not been made aware of these. This is not acceptable and would raise questions on the reliability of the data (particularly when the system contains source data). There should be robust data integrity control measures in place to ensure that the sponsor does not change the data without investigator approval.
We have seen instances where the data entered into these systems are used to make key safety decisions which are normally the responsibility of the investigator (for example, eligibility or dose adjustments). It is paramount that there are mechanisms in place to ensure the accuracy of the data entered and controls to any changes made.
Case Study
A data integrity critical finding was identified for a trial where the clinical database (which contained transcribed data from paper CRFs from site) was changed into an eCRF, without a sufficient risk assessment for data integrity or sufficient measures to ensure the investigator maintained control of their data. The change in system functionality should have been assessed against the requirements in ICH GCP and been part of the change control validation process, which it was not. Site staff were simply provided with access to the clinical database in the same way the sponsor data management staff were, and this resulted in a number of problems.
Due to both the sponsor’s clinical trials unit (CTU) and investigator site staff entering/editing data in the same database, the investigator did not retain control of their data. There were no controls in place to ensure the investigator’s entered data could not be amended by sponsor staff. This raised concerns about data reliability since there were examples of data being changed within the database by sponsor staff.
This was compounded by inadequate database functionality. For example, a ‘reason for change’ could not be applied to a single data field (only the entire form) in the database at any time during the trial and there was no requirement for the principal investigator (PI) to sign off and approve their CRF data. These requirements would be expected for an eCRF which the system morphed into.
When the database changed to allow site access, the paper CRFs at site became the equivalent of source worksheets, with data being transcribed directly into the sponsor’s database. The query process did not support this change and it became difficult to reconstruct what changes were made to the database, if they were supported by source data and approved by the investigator. For example, sponsor CTU staff were amending paper CRFs and later the eCRF (including making self-evident corrections) without PI authorisation. The changes were emailed to the PI with instructions to amend their copy of the paper CRF to reflect the change, rather than having a clear data clarification/query process. There were occasions where an acknowledgement or approval of the change was not provided by the PI. Therefore, the sponsor staff made changes to data without PI approval. Furthermore, there was no verification or quality control (QC) of data entry documented so it was not possible to determine the accuracy of data transcription from paper records.
This caused significant implications to the management of the data and resolution of queries that were not addressed by the CTU. Upon review of the source and paper CRFs at the investigator site, numerous issues were identified, such as:
- data added to paper CRFs as source without confirmation of when added
- changes to paper CRF not always signed/dated
- changes made to the CTU copy of paper CRFs were not reflected in paper copy at site as site staff had not followed instructions in the email
- inconsistencies between the paper worksheets (now source) and data entered directly into the database
The sponsor database evolved into an eCRF without required controls to ensure data integrity and the investigator’s control of their data (including source data). An impact assessment on the integrity of trial data was required for all trials conducted at the CTU as a result of the critical finding.
Summary
The different systems used to collect clinical trial data should be mapped out and the data flow should be defined, in particular the identification and location of source and transcribed data.
The functionalities of such systems should permit data changes and authorisations by the investigator with a clear audit trail to verify the integrity of the trial data and to explain why the data was amended.
The impact of inaccurate data reported through such systems should be assessed for impact on patient safety and data integrity. For example, incorrect weight entered into an IRT system may impact dosing, which has a patient safety impact.
Incorrect stratification data entered into the IRT system can have an impact on the data analysis, and as such there should be mechanisms in place to verify the accuracy of the data and report any inaccuracies so that they can be corrected either within the system itself or for the analysis.
Going back to the definition of a CRF, regardless of what you call your system, if it is recording protocol-required information and providing this to the sponsor, then it is also a CRF and needs to have the required functionality of an eCRF.
Don’t miss the next post, sign up to be notified by email when a new post comes out
