Onboarding Environment Lifecycle
Unless otherwise indicated, environments are offered in matched pairs.
Onboarding is the process leading up to a customer going live in Production (PROD). During this process, a series of short lived environments (also called ‘instances’) are created to support particular phases of onboarding. This guide describes these environments and clarifies their lifecycle.
Here is an overview of onboarding from an instance standpoint:
Environments as Pairs of Instances
ClinSpark environments are provisioned in pairs, unless otherwise stated. These pairs are referred to as ‘Main’ and ’Test'.
There will be a Sandbox pair, a Validation pair and a Production pair. Exceptions are Demo, Pre-PROD, Migration and Community Dev, which are all provisioned as single instances.
Environment | Pair | Longevity | Controlled / IQ’d |
|---|---|---|---|
Demo | No | Persistent | No |
Sandbox | Yes | Ephemeral | No |
Migration | No | Ephemeral | No |
Validation | Yes | Ephemeral | Yes |
Pre-PROD | No | Ephemeral | Yes |
Production | Yes | Persistent | Yes |
Community | No | Persistent | No |
Demo
A single environment that is first used by IQVIA to demonstrate ClinSpark to a prospective customer. Multiple versions of demo may exist, each with a different version of ClinSpark installed.
Customers are not typically given access to Demo environments.
Demo environments are not controlled environments and do not receive IQ documentation.
Sandbox
A pair of disposable instances is created for customers upon contract signing, and used for a wide variety of activities that includes training, informal testing, and continued feature exploration. Once in production, the sandbox pair will be destroyed. Sandboxes are not controlled do not receive IQ documentation. IQVIA may update and amend them without notice.
Sandboxes come complete with some base configuration out of the box and a sample of ’dummy’ volunteers.
Sandbox environments are destroyed once the customer is live. For continued feature exploration of the latest release, customers are expected use the Community Dev environment.
Appropriate Sandbox instance activities:
Training
Feature Exploration
Early Study Design
Informal Testing
Day-run Formal Testing
ClinSpark does not support a mechanism to copy study libraries from Sandbox and import them into other environments. While early study design activities may take place in Sandbox, efforts to establish master libraries and CRF Design elements intended for a PROD environment should take place in the Pre-PROD instances once available. If customers need to take basic CRF design elements from Sandbox into other environments, they should consider use the CDISC ODM XML study design file export/import feature.
Migration
This single disposable instance is created for customers whose source database will be migrated to ClinSpark.
It is used to present the output of volunteer database migration iterations for review and QC by customers. The migration instance is used for formal acceptance testing of the migration scripts. Migration contributes to all volunteer configuration, including most things under the Volunteers > Configure module.
The Database Migration process is described elsewhere in our documentation.
Customer / superadministrator changes to the Migration instance will not be preserved.
Any intended configuration updates such as medical history drop-downs, etc. must be made to the detailed in the Migration Specification where applicable and made in Pre-PROD.
The Migration instance is destroyed once the migration scripts are approved by the customer.
The Migration is not a controlled environments and do not receive IQ documentation.
Validation
Validation (‘VAL’) is offered as a pair of formal environments to support a customer’s platform validation activities.
The VAL instance pair is created by cloning the full and final configuration of the ClinSpark source instance (Pre-PROD). Having a pair of instances for VAL allows customer to execute the full study build, test and publish lifecycle, as it would be intended in production.
VAL is destroyed after validation is completed and the customer goes live. A fresh VAL pair is created the next time the customer needs to perform platform validation.
VAL environments are controlled environments and receive IQ documentation.
Pre-PROD
You may think of this as ’staging’. This is a single instance of ClinSpark.
During platform exploration in Sandbox you will reach decisions on your intended and required configuration to support the migration of participant data from your legacy solution and to support your business operations - how you conduct your trials. As you make these decisions, the configuration in Pre-PROD will need to be updated.
You will also be developing study design elements (forms etc.) in Sandbox that you intend to use in production. We recommend that your master library of forms be re-created in Pre-PROD. We provided some tips above on how to do that.
This is important as Pre-PROD will be cloned to make VAL and we recommend that the master library be included in that process.
Production
Production (‘PROD’) instances come as a pair.
The PROD ‘main’ instance is created by promoting Pre-PROD at the time of the participant database migration from the customer’s legacy system. The ’test’ partner to ‘main’ is created directly after.
PROD environments are controlled environments and receive IQ documentation.
Training
We typically see that customers will train staff and customer users (monitors, CRAs etc) in PROD Test. This environment does not contain any real participant information or any real trial data - only dummy data.
Once users are ’signed-off’ in Test, they can provided appropriate access to Main according to their role.
Community
Also known as ‘Community Dev’ - a shared environment IQVIA makes available to all customers, with the purpose to explore latest ClinSpark release functionality at any time. It is available for use during and after onboarding phases, and replaces the customer sandbox instance once the customer is live.
More details are on our Community page.