This is an entirely new section that is relevant to the sponsor and the investigator and therefore avoids duplication of expectations in the sponsor and investigator responsibilities sections. With extensive use of computerised systems in clinical trials, that the current addendum partly addressed, this new section provides a higher level of guidance that reflects the more detailed guidance that has been published in this area by Regulatory Authorities such as EMA, FDA and the MHRA’s Data Integrity Guidance.
- The beginning of the section again focuses on the quality of the information in the trial being sufficient to provide reliable results and that all processes and systems for the critical data in data life cycle should be implemented proportionately to risks to this and to the safety of participants.
- There is a much-expanded section on the maintenance of the blinding of treatment allocation and assessment of inadvertent unblinding, which could affect the reliability of the trial results, stating that it should be part of risk assessment. It states that processes must be in place to protect the blinding. I think this is an important addition because breaches of the blinding, both minor and extensive, have been observed to occur frequently in clinical trials.
- The section is based on the data life cycle and includes new and expanded text on data capturing, data verification, metadata, data corrections, data transfers and finalization of datasets prior to analysis. Some significant text that I noted and would like to draw to your attention:
i. Relevant metadata, including audit trails, has significant additions in relation to determining what metadata is available, stating that such data must be decipherable, and which data require review and retention. Audit trail review is particularly welcomed as this is an important aspect of the protection of data integrity.
ii. The data corrections section is expanded and there is new text stating that changes should be supported by source data around the time of original entry. This is useful in relation to changes made to participant diary data that may or may not be appropriate, depending on when the change is made. It has been seen where such data, including endpoint data, has been changed many months after it was originally recorded with nothing available to support making such changes.
iii. Requirement for validation of data transfers. This is an important addition as there have been trials where data has been lost during data transfer due to the lack of adequate transfer processes.
iv. The points relating to finalisation of datasets are valuable additions. It is expected that it must be clear what activities need to be completed. It must be demonstrated that they have been performed to confirm the data has satisfied the expected sufficient quality requirements for the analysis purpose. The use of the word “sufficient” in the text encourages proportionality, I believe, because there is not an expectation for an aim of perfection but a focus on addressing issues that could impact on safety (for example, missing safety data) or reliability of the trial results (lack of follow up data, missing endpoint data, etc.).
This section explains the importance of the system – whether it is specifically for the purposes of a clinical trial and who has the responsibility for it, as this sets the expectations for the system. Some of the expectations are expanded, e.g., requirement for documented procedures and back up. Some significant additional text that I noted and would like to draw to your attention is:
- That those developing systems should understand the GCP requirements. This will help to ensure that the system is compliant. I have seen systems where the functionality was insufficient, e.g., inadequate audit trail, lack of appropriate data change functionality, read-only access not available (for monitoring/audit), etc.
- Recommending that participants and healthcare professionals (i.e., end users) are involved in the system design.
- Expectations regarding user management and ensuring actions are attributable to an individual.
- Setting out of some security expectations.
- Expectations on Technical support. This is important as trials often have participants using electronic systems for the purpose of the trial and poor resolution of issues could potentially impact on drop-out rates or increase the amount of missing data.
Validation of computerised systems
Some significant text I noted and draw to your attention:
i. That validation should occur prior to use, that there is a change control process and the need to retain documentation.
ii. Mentioning that protocol-specific configuration data checks and calculations should be validated. This is a welcome addition as there are occurrences where dose changes calculated by eCRFs, described in this new text as critical functionality, have been erroneous or malfunctioned with some cases of mis-dosing of participants as a result.
iii. Ensuring that use of systems with outstanding issues should be justified.
iv. Ensuring that a system is only implemented if it is consistent with the approved protocol. Trials have been seen where updated systems are available for the investigator to use prior to approval by the regulatory authority, or that the site has been told to implement a protocol amendment, but the systems had not been updated. This has caused issues with eligibility in an eCRF (changed in an amendment) and the dose in the IRT system inconsistent with the approved protocol.