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

In April 2020 the EMA published a clarification on their expectations called “Notice to sponsors on validation and qualification of computerised systems used in clinical trials”, EMA/INS/GCP/467532/2019.

They also updated the answers to two related Q&A topics they have published on their website:

Q8. What are the pitfalls to be aware of regarding contractual arrangements with vendors for electronic systems in connection with clinical trials? Rev. April 2020

Q9. What is the level of validation/qualification needed to be performed by a sponsor when using an electronic system previously qualified by a provider? What documentation is required to be available for inspections? Rev. April 2020

In the notice to sponsors the EMA state:

“Data integrity, reliability and robustness will depend on the design and the validation status of the computerised systems used. Failure to document and therefore demonstrate the validated state of a computerised system is likely to pose a risk to data integrity, reliability and robustness, which depending on the criticality of the affected data may result in a recommendation from the GCP inspectors to the CHMP not to use the data within the context of an MAA.”

And furthermore:

“The sponsor is ultimately responsible for the validation of the computerised system and for providing adequate documented evidence on the validation process.
Sponsors shall be able to provide the GCP inspectors of the EU/EEA authorities with access to the requested documentation regarding the qualification and validation of computerised systems irrespective of who performed these activities.”

In the notice and the associated Q&A topic (Q9) the EMA outline two ways the sponsor can fulfil their responsibilities regarding the validation of computerised systems used for their clinical trial:

1. The sponsor may rely on qualification documentation provided by the vendor, if the qualification activities performed by the vendor have been assessed as adequate.
2. The sponsor may choose to perform their own full qualification of a system purchased from a vendor.

The conditions under which each of these will be judged to be acceptable are then outlined in more detail. For a more detailed discussion on regulatory expectations, see Appendix A.

When using Viedoc we recommend the first choice as detailed in this document.

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
• 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 Q&A topic 9 (see Appendix A for more information) regulator expectations are described:

“…that 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 trial results. … The risk assessment should be justified by the sponsor and documented.

The sponsor may rely on qualification documentation provided by the vendor if the qualification activities performed by the vendor have been assessed 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 Q&A topic 9 (see Appendix A for more information) but include the following:
  • the sponsor has a thorough knowledge about the vendor's quality system and qualification activities, which will usually be obtained through an in-depth assessment/audit;
  • an assessment/audit has been performed by qualified staff, with sufficient time spent on the activities and with cooperation from the vendor;
  • an assessment/audit has gone sufficiently deep into the activities and that a suitable number of examples for relevant activities have been looked at (and documented);
  • the assessment/audit report has documented the vendor's qualification documentation to be satisfactory or that shortcomings can be mitigated by the sponsor — e.g. that the sponsor is performing part of the qualification;
  • the sponsor, or where applicable the CRO performing these activities for the sponsor, has a detailed knowledge about the qualification documentation and can navigate in it and explain the activities as if they had performed the activities themselves;

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 setup 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 Release Checklist

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 Checklist

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:

https://www.viedoc.co.jp/site/assets/files/5378/pmext47-01_viedoc_4_74_pmda_edc_management_sheet_v2_0_-_ecf_english_translation_en2_02.xlsx

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

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! ​

Appendix A — Regulatory Expectations

In May 2018 the EMA GCP IWG published a Q&A topic called:

9. What is the level of validation/qualification needed to be performed by a sponsor when using an electronic system previously qualified by a provider? What documentation is required to be available for inspections?

They updated this topic in April 2020 when the “Notice to sponsors on validation and qualification of computerised systems used in clinical trials”, EMA/INS/GCP/467532/2019 was released. The full text for this topic can be read on the EMA website under:

Human Regulatory > Research and Development > Compliance > Q&A > GCP Matters

The topic informs the reader:

The system in question may be a system validated by the supplier, but installed at the sponsor, or a system provided as software-as-a-service (SaaS or cloud solution).

Different requirements will apply in cases where the sponsor is changing/adding functionalities to the system.

Viedoc is software-as-a-service, a multi-tenanted cloud solution where all installations are owned and maintained by Viedoc.

The Q&A topic then goes on to describe expectations with regards to sponsor responsibility:

…that 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 trial results. … The risk assessment should be justified by the sponsor and documented.

The sponsor is ultimately responsible for the validation of the clinical trial processes which is supported by electronic systems. The sponsor may rely on qualification documentation provided by the vendor if the qualification activities performed by the vendor have been assessed as adequate, but may also have to perform additional qualification/validation activities based on a documented risk assessment.

The sponsor should be able to rely on Viedoc standard qualification documentation as there are no sponsor or study specific software modifications made to the standard product. The configuration of Viedoc for use in a study is done using only validated functionality that has been validated before being released to the study.

The Q&A topic provides some examples of when the vendor’s documentation can and cannot be used, these are commented for Viedoc below:

The conditions for a sponsor to use the vendor's qualification documentation include, but are not limited to, the following:

• the sponsor has a thorough knowledge about the vendor's quality system and qualification activities, which will usually be obtained through an in-depth assessment/audit;
  Information about the Viedoc quality system and qualification activities can be downloaded from our website using the following link. Instructions about how to book an audit with us are also given:
  https://help.viedoc.net/l/2d18aa/en/
• an assessment/audit has been performed by qualified staff, with sufficient time spent on the activities and with cooperation from the vendor;
  When you audit us your audit should include sufficient focus on the validation of Viedoc standard functionality.
• an assessment/audit has gone sufficiently deep into the activities and that a suitable number of examples for relevant activities have been looked at (and documented);
  As above, this is input for your auditor to consider when planning the audit.
• the assessment/audit report has documented the vendor's qualification documentation to be satisfactory or that shortcomings can be mitigated by the sponsor – e.g. that the sponsor is performing part of the qualification;
  It should not be necessary for you to perform any additional qualification of the standard product – our validation activities are detailed and complete.
• the sponsor, or where applicable the CRO performing these activities for the sponsor, has a detailed knowledge about the qualification documentation and can navigate in it and explain the activities as if they had performed the activities themselves;
  See the Validation Summary available on the website by following the link above.
• when required during an inspection, the qualification documentation is made available to the inspectors in a timely manner irrespective of whether it is provided by the sponsor, CRO or the vendor.
  We are always happy to support customers being inspected, and can participate by webinar if desired by the inspectors.
• both the sponsor and the vendor establish full configuration management for qualification and production environments and that the sponsor can fully account for any differences between the vendor's validation environment and the sponsor's production environment and subsequently, justify any differences that are considered insignificant. If not, the qualification effort potentially does not justify the use of the system.
  There is no sponsor-specific production environment for Viedoc. We have full configuration management of the Viedoc production environment.
• the sponsor has performed an Installation Qualification/Performance Qualification where the system depends on trained users.

Installation qualification for your study is not necessary as there is no sponsor- or study-specific installation performed. We have performed and documented installation, operation and performance qualification for Viedoc before it is released to customers on the production servers.

It is a sponsor/CRO responsibility to validate the study configuration, and confirm that the study has been setup in accordance with the study protocol. This validation should be documented.