Onboarding Environment Lifecycle
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 Summary
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 Longevity
Some environments are disposable or ‘ephemeral’ and are destroyed once their purpose has been fulfilled.
Change Control
Certain environments are under change control. When created they will be ‘qualified’ (Installation Qualification / IQ) and subsequent changes documented in ‘Environment Change Records’ (ECRs).
Environment | Pair | Longevity | Change Control |
|---|---|---|---|
Sandbox | Yes | Ephemeral | No |
Migration | No | Ephemeral | No |
Pre-Production ('Pre-PROD’) | No | Ephemeral | Yes |
Validation (‘VAL') | Yes | Ephemeral | Yes |
Production ('PROD') | Yes | Persistent | Yes |
Demo | No | Persistent | No |
Community | No | Persistent | No |
Configuration Management
There is currently no way to export or ‘promote’ environment configuration automatically ‘up the environment life cycle’, so this needs to be done by hand.
However, this is mitigated as this manual configuration only needs to be done once - from Sandbox to Pre-PROD.
VAL is a clone of Pre-PROD and once validation is complete, Pre-PROD is promoted to PROD, hopefully with only minor adjustments arising from validation.
System configuration is reportable via means of an extensive PDF which allows users to capture the configuration state at any time. It can be used to understand and detect the differences in the configuration state of different environments.
Typical Onboarding Instances
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
Dry-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.
What is the Sandbox Test Environment for?
One of the main reasons for giving you a Test environment is to allow you to practice with and use (including development of test cases as required) the study export / import process which customers use as part of study UAT.
See the documentation here - Export from Production Environment / Import to Test Environment
This configuration (having both Main & Test) allows you to fully emulate and practice all your system and study management lifecycles as you would have to do in Production.
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.
Pre-Production
You may think of Pre-Production ('Pre-PROD') 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.
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.
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.
Additional Environments
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.
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.