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:
...
High Level Overview
Demo instance is for Foundry Health to demo ClinSpark in ‘branded’ environment to a potential customer.
Sandbox instance pair is created for customers upon contract signing, and used for a wide variety of activities that includes training, informal testing, and continued feature exploration.
Migration environment is used to present the output of volunteer database migration iterations for review by customers. Migration contributes to all volunteer configuration, including most things under the Volunteers > Configure module.
VAL instance pair is created to support formal validation activities. The VAL instance pair is created by combining the general configuration of the source instance selected by the customer (Sandbox or prePROD instance) with the output of the migration program.
PROD instance pair is created by combining the general configuration predefined by the customer for this instance or coming from VAL with the output of the migration program.
Community Dev is a shared environment Foundry Health 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, but typically, customers explore ClinSpark in their own Demo and Sandbox instances first. More details are on our Community page.
Demo Environment
A Demo environment is first used by Foundry Health to demonstrate ClinSpark to a prospective customer. After the demo, it may also be provided to a customer prior to contact signing to explore ClinSpark functionality for a short period of time.
The demo environment configuration and data may be comprised of other ‘demo’ environments used by Foundry Health.
Demo environments do not receive IQ documentation.
Sandbox Pair
Once a customer signs a contract, the Sandbox pair is created. Depending customer preference, Sandbox can either be a brand new ‘empty’ instance pair or a clone of Demo instance in order to preserve data and configurations already familiar from the Demo instance.
Sandbox environments exist to explore and experiment in. Environments like this reduce the risk of adversely affecting a larger group of people or sensitive data in more controlled environments. In Sandbox, things may change freely without much disruption.
Sandbox environments are destroyed once PROD goes live. For continued feature exploration, customers are expected use the Community Dev environment.
Sandbox environments do not receive IQ documentation.
Appropriate Sandbox instance activities:
Training
Feature Exploration
Early Study Design
Informal Testing
Note: ClinSpark does not support a mechanism to take 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/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 passes from Sandbox to VAL and PROD, if Sandbox is defined as the source instance
Administration > Roles
Administration > Sites (Note that archived sites are not passed)
Administration > General Settings (except when this is integration-specific such as with SSO)
Administration > System Settings
Administration > Medical Dictionaries
Devices
Labs, Panels, Lab Tests
Barcode Label Configurations
Migration
A dedicated Migration instance is created for customers whose source database will be migrated to ClinSpark. This instance exists solely for the purpose of presenting the output of the the migration logic for review by the customer. It is a single instance, and only the main instance is provided to support this activity.
The Database Migration process is described elsewhere in our documentation.
Changes to the Migration instance will not be preserved. Any updates to the Migration configuration such as medical history dropdowns, etc. must be made to the Migration Specification our source database and be implemented by way of the migration process itself.
The Migration instance is destroyed once the migration outputs are signed off on by the customers.
The Migration environment does not receive IQ documentation.
Appropriate Migration instance activities:
Evaluation of the output of the migration program
What is passed from Migration to VAL and PROD
All Volunteers
Archived studies, created to support historical study participation
These Volunteer > Configure elements:
...
VAL (Validation) Pair
VAL is a formal environment provided to support a customer’s validation activities. This environment will be produced with the general configuration from the source instance selected by the customer PLUS the migration output. Note that this is effectively a dry run of the same mechanism used to create PROD.
Volunteer PHI is obfuscated in the VAL environment.
If required, informal versions of VAL can be created to support early activities such as test creation or QA prior to the creation of the final VAL instances.
VAL is destroyed after validation is completed and PROD goes live.
VAL environments receive IQ documentation.
PROD (Production) Pair
These are customer production instances. After “go-live” these instances remain as is until upgrading.
PROD environments receive IQ documentation.
PROD “go-live” steps
Customer: provide FH with final source DB dump/files and any other related files.
FH: extract configuration from the source ClinSpark instance agreed upon by the customer
FH: run the migration program to produce the new ClinSpark instance
FH: populate, configure, review the final PROD Main instance
FH: provide formal IQ documentation
Customer: perform final QC check