Inspection Readiness

The regulatory authorities expect to be able to review relevant documentation about the chosen systems used in a clinical trial. But what is relevant, what should the sponsor or their representative (CRO) have on hand and what can be accepted as being held by the system supplier?

This document describes aspects to be considered when using a multi-tenanted cloud solution, such as Viedoc, for the collection of subject data in a clinical trial.

EMA GCP IWG Inspector Expectations

On the 9^th of March 2023 the EMA released their “Guideline on computerised systems and electronic data in clinical trials”, EMA/INS/GCP/112288/2023, and it came into effect on the 9^th of September 2023.

In this guideline the EMA state in Annex 2.1 “General Principles” (of computerised systems validation):

“The responsible party should ensure that systems used in clinical trials have been appropriately validated and demonstrated to meet the requirements defined in ICH E6 and in this guideline.

Systems should be validated independently of whether they are developed on request by the responsible party, are commercially or freely available, or are provided as a service.

The responsible party may rely on validation documentation provided by the vendor of a system if they have assessed the validation activities performed by the vendor and the associated documentation as adequate.”

They then go on and add:

“If the responsible party wants to use the vendor's validation documentation, the responsible party should ensure that it covers the responsible party's intended use as well as its defined needs and requirements. The responsible party should be thoroughly familiar with the vendor's quality system and validation activities, which can usually be obtained through an in-depth systematic examination (e.g. an audit). This examination should be performed by qualified staff with sufficient time spent on the activities and with cooperation from the vendor. It should go sufficiently deep into the actual activities, and a suitable number of relevant key requirements and corresponding test cases should be reviewed, and this review should be documented. The examination report should document that the vendor's validation process and documentation is satisfactory. Any shortcomings should be mitigated by the responsible party, e.g. by requesting or performing additional validation activities.

Some service providers may release new or updated versions of a system at short notice, leaving insufficient time for the responsible party to validate it or to review any validation documentation supplied by the service provider. In such a situation, it is particularly important for the responsible party to evaluate the vendor's process for validation prior to release for production, and to strengthen their own periodic review and change control processes. New functionalities should not be used by the responsible party until they have validated them or reviewed and assessed the vendor's documentation.

If the responsible party relies on the vendor's validation documentation, inspectors should be given access to the full documentation and reporting of the responsible party’s examination of the vendor. If this examination is documented in an audit report, this may require providing access to the report. The responsible party, or where applicable, the service provider performing the examination activities on their behalf, should have a detailed understanding of the validation documentation.

As described in Annex 1 on agreements, the validation documentation should be made available to the inspectors in a timely manner, irrespective of whether it is provided by the responsible party or the vendor of the system. Contractual arrangements should be made to ensure continued access to this documentation for the legally defined retention period even if the sponsor discontinues the use of the system or if the vendor discontinues to support the system or ceases its activities.”

This document describes how Viedoc helps you to comply with the EMA expectations listed above.

FDA Expectations

In June 2017 the FDA published their draft guidance “Use of Electronic Records and Electronic Signatures in Clinical Investigations Under 21 CFR Part 11 – Questions and Answers”. As a draft guidance this document has not yet been implemented and contains only nonbinding recommendations. But it gives a clear indication that FDA expectations are similar to those expressed by the EMA.

In the guidance the FDA write that:
“Sponsors and other regulated entities are responsible for meeting the regulatory requirements.”

“Sponsors and other regulated entities should obtain service agreements with the electronic service vendor. Before entering into an agreement, the sponsor or other regulated entity should evaluate and select electronic services based on the electronic service vendor’s ability to meet the part 11 requirements and data security safeguards…
Service agreements should include a clear description of these specified requirements and the roles and responsibilities of the electronic service vendor.”

“Sponsors and other regulated entities should have the following information available to FDA upon request at each of their regulated facilities that use the outsourced electronic services:

• Specified requirements of the outsourced electronic service
• A service agreement defining what is expected from the electronic service vendor”

“It is ultimately the responsibility of the sponsor or other regulated entity to ensure that the outsourced electronic service is validated as appropriate. Sponsors and other regulated entities should obtain documentation from the electronic service vendor that includes, but is not limited to, a description of standard operating procedures and results of testing and validation to establish that the outsourced electronic service functions in the manner intended.”

This document describes how Viedoc helps you to comply with the FDA expectations listed above.

PMDA Expectations

In March 2013 the PMDA released the EDC Management Sheet for completion when using EDC in clinical trials. In the first section “Precautions for Sheet Completion” they write the following concerning the basic concept of this document (translation by JPMA in June 2013):

“Regarding clinical trials, etc. using EDC, record the summary of the procedures for assuring the quality of data etc.
In using electronic record, since appropriate system selection, appropriate allocation of authority of entry and modification to users, appropriate use by the authorized users, etc. are important to prevent falsification or loss of data, specifically record the means and procedures for assuring the quality of data etc.”

This document describes how Viedoc helps you to comply with the PMDA expectations.

Viedoc Inspection Readiness Packet

Sourcing a system for your clinical trial

At Viedoc our recommendation is that you rely on our validation of Viedoc, as this is one of the ideas behind the service we offer when you choose Viedoc for your study. By letting us do the work for you it will save you a lot of time, effort and heartbreak.

The Viedoc Inspection Readiness Packet (VIRP) provides you with information you need in order to fulfil regulatory expectations.

The following Viedoc documentation is available at all times

The regulatory authorities see the EDC system used for a clinical trial as an important computerised system with regards to both patient safety and data integrity. They expect the sponsor to have a complete understanding of the system. Their expectations are that the sponsor (or CRO, if delegated) fully understands the functionality of the EDC system being used and can demonstrate this understanding and explain how the system has been validated.

At Viedoc we publish our URS in an easy to understand format made up of Epics, Features and User Stories.

• Epics describe an overall module within Viedoc, such as Audit Trail, ePRO and Medical Coding
• Features describe a given functionality in more detail, such as Login/Logout, Queries and Email alert
• User Stories are the detailed, broken-down requirements used by the system developers when designing, implementing and validating Viedoc

To assist you in fulfilling inspector expectations we provide the following documentation for every release of Viedoc:

• User Requirements Specification describing the epics and features, and listing the user stories included in the release
• Traceability Matrix detailing the testing performed for every requirement in the URS
• Validation summary report describing the validation activities performed for this release, and their result
• Release Notes describing the additions to Viedoc in the release
• Release Certificate verifying that we have followed our documented procedures during the implementation and associated activities for the release
• EDC Management Sheet for submissions to the PMDA
• Clinical Trial Cloud System Checklist
• Viedoc Impact Assessment documenting at a feature level the risks and potential consequences arising from the release of new and updated features in the release
• Acknowledgement Form describing what you need to review, and containing room for your signature as evidence that you have completed your review
• Table of Contents of applicable SOPs used by Viedoc Technologies in the production of this release
• An introduction describing the contents of the Viedoc Inspection Readiness Packet (VIRP)

Documents you produce

We recommend you use a checklist of the required functions (such as randomization module, patient ePRO module, coding module) for your trial on our Epic level, and where necessary individual Features.

The actual details about how each of the modules is developed, configured and works in practice is usually not relevant — the study protocol seldom describes the system at this level of detail. As you are only using the system, and not developing it, there is no need to define this level of detail in your requirements. What you need to know is covered by the training and system documentation, so that your personnel know how to use the system in your clinical trial.

If you have defined the system to be used for your clinical trial using a checklist of expected Epics and Features as we recommend, then you only need to document that Viedoc has each of the Epics you have defined in your checklist. This is usually a one- or two-page document showing each required Epic and a tick box for Yes, No or Partly. If the answer is “No” or “Partly” for any module then a description should be included of the workaround for that module in the study (e.g. procedural instead of system, or an alternative system).

So, who is responsible for the URS for Viedoc? We are. We are responsible for specifying all requirements for the development of Viedoc, and for validating those requirements for each new release of Viedoc. We employ modern development methods and tools including an advanced requirement database where we store all requirements, test cases and the results from the execution of those test cases for full traceability. This database is updated with new requirements, test cases and test results for every new release of Viedoc, and every new version of Viedoc is fully validated (and this validation is documented) before it is released. This information is used to produce the User Requirements Specification and the Traceability Matrix that we include as part of our Inspection Readiness packet for each release.

The detailed requirements, test cases, test reports and test evidence are available from us if the inspectors should wish to view them, although we will need to take the inspectors through the information as Viedoc is a complicated system, and the full requirement specification and all associated validation documentation is complex. It is an advantage if the inspectors can visit us at our offices, or if we can take them through the documentation in a webinar. Allowing the inspectors free access to the requirements database will require specialist training and knowledge about system development that not all inspectors have.

Additional documents kept by you

If you choose to rely on our Inspection Readiness packet what are your responsibilities?

• You must document your decision to rely on our Inspection Readiness packet instead of producing your own URS, and the regulators recommend that this be done in the form of a risk-based assessment.

In ICH E6 (GCP) R2 it is written:

“The approach to validation should be based on a risk assessment that takes into consideration the intended use of the system and the potential of the system to affect human subject protection and reliability of clinical trial results.”

The EMA write in their guideline:

“The responsible party may rely on validation documentation provided by the vendor of a system if they have assessed the validation activities performed by the vendor and the associated documentation as adequate.”

In addition, the FDA write in their draft guidance:

“A risk-based approach to validation … should be taken for outsourced electronic services.”

• You must be able to show that you understand the Viedoc quality system and qualification activities. Regulator expectations are described in more detail in the EMA “Guideline on computerised systems and electronic data in clinical trials” but include the following:
• • The responsible party should be thoroughly familiar with the vendor's quality system and validation activities, which can usually be obtained through an in-depth systematic examination (e.g. an audit).
  • This examination should be performed by qualified staff with sufficient time spent on the activities and with cooperation from the vendor.
  • It should go sufficiently deep into the actual activities, and a suitable number of relevant key requirements and corresponding test cases should be reviewed, and this review should be documented.
  • The examination report should document that the vendor's validation process and documentation is satisfactory. Any shortcomings should be mitigated by the responsible party, e.g. by requesting or performing additional validation activities.
  • The responsible party, or where applicable, the service provider performing the examination activities on their behalf, should have a detailed understanding of the validation documentation.

Do not write your own URS

Many companies use a User Requirement Specification (URS) to specify the contents they expect to see in a system to be used in their clinical trial, but this can be both unnecessary and create a large amount of additional work.

Viedoc is not developed per customer — there are no customer-specific versions of Viedoc, and no customer-specific development or validation is performed. As you are not defining the system to be developed, there is no need for you to document your requirements in the form of a URS.

The URS is used to specify the system to be developed. As a direct corollary to the URS is the expectation that all requirements in the URS be validated — if you have written a URS as part of your procedure to source a system then you must validate that the system actually fulfils all of the requirements in the URS. You are responsible for performing the validation yourself. If you rely on the system supplier to validate the system in accordance with your URS then you must be able to demonstrate that the supplier has a test case for each of the requirements in your URS, and you must be able to show inspectors both the test cases and the results from executing those test cases. If multiple releases of the system are used during the trial, then this testing must be repeated for each new release.

Two Validations to Perform

Your responsibility — Study configuration

Viedoc is adapted to individual studies by configuring standard (validated) functionality. This is done to adapt the system to the study protocol for your study. This configuration can be performed by your personnel or you can outsource the study configuration to us or to a third party.

Irrespective of who performs the study configuration, the responsibility for validating that the study is set up in compliance with the study protocol remains yours, and cannot be delegated to Viedoc personnel.

You should define a set of test cases that demonstrate that the study has been set up correctly, and you should document the result of executing those test cases. This should be based on a risk assessment covering such aspects as how complicated the study is and whether it is like earlier studies that you have validated.

If you make changes to the study configuration during the trial (for example following a protocol amendment) then you must evaluate the extent of validation required as a result of these changes and perform the validation following the above steps.

When using Viedoc this is the limit of your responsibility for validation of Viedoc as no customer-specific development is performed per sponsor or per study.

What about edit checks then? Are these not examples of customer-specific programming that is performed per study? In Viedoc all edit checks are “sandboxed”, that is they only have access to the data in your study and they can only read that data, not change it. You can define derived values that are calculated from existing study data, but you cannot change that original data. It is not possible for edit checks to alter any study data, nor to alter Viedoc program code. The use of edit checks does not require revalidation of basic Viedoc functionality nor does it constitute a danger to data integrity in your study. The only validation requirement is that if the edit checks are complex, then they will need to be validated for compliance with your study protocol, i.e. that they really do check what you want them to.

Viedoc Responsibility — New releases of Viedoc and the EDC Management Sheet

New versions of Viedoc are released approximately 7-8 times a year (usually once every 6 weeks). Each new version has been fully validated before release. These releases are installed on all production servers at the same time, meaning all customers and all studies are updated at the same time.

To ensure that ongoing studies are not affected every new release of Viedoc fulfils these two requirements:

1. The new release must be 100% backwards compatible
2. Any new functionality in the release shall be disabled for ongoing studies by default

By fulfilling these two requirements we ensure that the release does not affect ongoing studies, in fact ongoing studies do not even notice that a new release has been made.

100% Backwards Compatible

The reason for this requirement is straightforward — a new release should never require a change in the study configuration of ongoing studies or require the revalidation of the setup of those trials. By being 100% backwards compatible we ensure that your study will look and work the same for all users. We consider a successful new release of Viedoc to be one that is not noticed by the users of ongoing studies!

New functionality disabled

This is to ensure that new functions that the user has not been trained in do not suddenly appear, causing confusion and the possibility of errors.

The study administrator must enable any new functions before they become visible in an ongoing study, giving the study personnel time to ensure that all affected users have been trained in advance. Note that if new functionality is enabled in a study then the configuration of that functionality must be validated against the study protocol at that time, and this validation documented.

Minor updates (such as the correction of spelling or grammatical mistakes in system texts or the addition of new filtering possibilities in exports) do not need to be disabled by default but are released directly as they are easy to understand and are of use to all studies.

The EDC Management Sheet

The different versions of systems used during the study and a synopsis of the differences between the versions should be stored as part of the study record in the sponsor (e)TMF.

The PMDA EDC Management Sheet is used for documenting the EDC system used for a clinical trial. We recommend that you keep some similar record even for trials performed outside of Japan. Here is an example of the EDC Management Sheet.

At present we publish an updated version on our Japanese website for every new release of Viedoc.

Clinical Trial Cloud System Checklist

In April 2024 the JPMA released their Clinical Trial Cloud System Checklist. This checklist aims at helping sponsors and CROs in their oversight of cloud services providers.

We have completed the checklist from a Viedoc point of view and included it in VIRP for your records.

End of Study — Decommissioning

When using a multi-tenanted cloud solution such as Viedoc for your trial the nature of “decommissioning” changes. Instead of the system itself being decommissioned at the end of the trial it is the trial that becomes “decommissioned”. By that we mean:

• The data are cleaned (all data are reviewed, queries are written and closed)
• The study is locked, and no further changes can be made
• All study data and metadata are downloaded from Viedoc for archiving in the sponsor and the investigator (e)TMFs
• The study is deleted from Viedoc (including all data and metadata)

When downloading study data and metadata for archiving a risk-based approach should be documented and followed. We recommend the archiving of multiple formats of the data, including but not necessarily limited to:

• Static files, such as PDF screen shots showing the investigator view at the time of data entry
• Static files, such as the user and role report showing all study users and their role in the study
• Dynamic files, such as SAS data sets allowing advanced data analysis
• Dynamic files, such as Microsoft Excel data sets allowing the data and metadata (audit trail, query history, medical coding, review status, user and role report etc.) to be sorted and filtered for analysis
• Dynamic files, such as randomisation lists, allocation lists and kit history lists
• Dynamic files, such as the CDISC ODM data archiving format which also includes the study configuration

All the above formats can be exported from Viedoc.

The procedures adopted for decommissioning at the end of the study should be documented in a study SOP.

Pitfalls to be avoided

We have developed the methodology described above to ensure that you can implement your study in Viedoc in full compliance with inspector expectations. Most studies implement multiple systems (10 or more) per study, more and more of those are multi-tenanted cloud solutions (as Viedoc is). What are the pitfalls you should look out for in the other systems in your study?

Customer-specific software

The software of some systems is adapted for every new customer and study, for example some systems are configured by writing new software and not by using standard, validated functionality as Viedoc is.

Although the result may look the same to the user, the ramifications for the sponsor/CRO are enormous — a customer-specific version of the system also requires a customer-specific validation of that system, with documented requirements (a URS), test cases and test results. This is the responsibility of the sponsor as the software has been customised at their request.

Not only is this required before the study is released the first time, it must be repeated for every new release of the software and every change to the study configuration. Admittedly not many systems release new versions as often as Viedoc, but on the other hand the typical clinical trial will run for 1-2 years and during this time it is not inconceivable that a number of new releases and a number of protocol amendments will be made, each time requiring a full validation of the system by the sponsor/CRO.

New functionality in a release

If new functionality is not disabled by default as in Viedoc but simply appears in a new release, then this will require both validation of the configuration of this new functionality against the study protocol and training of all users before the new functionality can be taken into use.

In order to suit the study this means it must nearly always be possible for the sponsor/CRO to affect the date and time of the release, to ensure that all validation and training activities have been performed before the release.

This rapidly becomes untenable in large multi-tenanted systems, leading to noncompliance.

Lack of backward compatibility in a release

If the behaviour of a system changes after a release, then the study configuration must be validated against the study protocol again.

In order to suit the study this means it must nearly always be possible for the sponsor/CRO to affect the date and time of the release, to ensure that all validation and any necessary training activities have been performed before the release.

This rapidly becomes untenable in large multi-tenanted systems, leading to noncompliance.

Edit checks

In systems where the edit checks are not “sandboxed” then there is a real risk that complex edit checks may affect the system software itself or the integrity of the study data.

In order to ensure that this has not happened the entire system must be revalidated when such edit checks have been written, and every time the edit checks are revised, resulting in a large additional burden on the sponsor/CRO.

Conclusions

At Viedoc our recommendation is that you rely on our documentation instead of writing your own URS and performing your own validation. ​

By letting us do the work for you it will save you a lot of time, effort and heartbreak. ​

When using Viedoc you only need to validate that your study configuration is in compliance with your study protocol. Remember that in Viedoc there is no customer-specific development implemented per sponsor or per study! ​

To assist you in fulfilling inspector expectations we provide the Viedoc Inspection Readiness Packet for every release of Viedoc - use it in good health! ​