Recently, a GCP inspector from MHRA posted an article on the MHRA Inspectorate blog. The post focuses on Computer System Validation (CSV) and is a combination of a case study seen at a single organization together with some common findings from GCP Inspectors in a number of recent inspections. According to the post CSV is an important part of the development and use of computer systems within clinical trials. It applies not just to eSystem vendors, but also to Clinical Trials Units (CTUs) or Clinical Research Organizations (CROs) offering randomization and Interactive Response Technology (IRT) services. Additionally, CSV is mandatory for analytical software developers and sponsor organizations developing their own software solutions. The post is intended to provide some guidance on the type of validation activities that should be considered when
a product that has been validated by a vendor,
a vendor’s product that has been validated for demonstrating its fitness for use,
a validated own product, or
a validated trial specific configuration/build
According to the blog common findings relating to the user aspect of validation include:
The product being released to the customer before the training material (i.e. user guide) has been developed and released,
Users being given access to the system with no training,
Users being given inappropriate (higher level) access such as the ability to make data changes,
User material not being reviewed or updated following the release of a new version with new functionality,
Users not being notified of system updates that included changes to functionality,
Internal processes and SOPs are not followed and as a result the formal review and approval of key documents such as validation plans, test scripts and reports are not completed.
Regarding contracts the post reminds to remember that the vendor may have produced the software, but he is not the one using it in the clinical trial, and ultimate responsibility is with the sponsor. If a system or piece of software is assumed to be validated and this causes data integrity or patient safety issues this remains the responsibility of the sponsor. Therefore, the contract with the vendor becomes essential as if tasks are not contracted there is a high probability that they won’t be done.
The following points should be considered in regard to contracts:
The eSystem vendors may have expert knowledge relating to IT systems and sometimes on data protection legislation if applicable, but not necessarily on GCP requirements (see also EMA Q&A on GCP),
The contract should require the vendor to work according to GCP (e.g. to retain sufficient documentation to reconstruct essential trial activities),
The contract should allow the sponsor access to (or ensure the retention of) essential non-trial specific documentation such as software/system validation documents, vendor SOPs, training records and issues log/resolutions in Helpdesk/IT Ticket system,
The contract should require the vendor to report serious breaches either to the sponsor or the relevant regulatory authorities,
The contract needs to be clear with regard to sub-contracting by the vendor specifically which tasks can and cannot be sub-contracted and how the sponsor will maintain oversight.