© 2024 IQVIA - All Rights Reserved

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Upgrading ClinSpark

New ClinSpark versions are released several times a year. Customers are encouraged to update to each new release. This ensures the customer receives the benefit of all new features and bug fixes, and also minimizes risk from upgrading by ensuring that upgrades are each a relatively small jump.

The ClinSpark documentation site will provide focused documentation identifying new features and changes. This supports training of staff and validation activities.

Here is an overview of the upgrade process:

Temporary VAL Instances

Customers need to perform training and validation activities on the new release. To support this, customers can request via a JIRA ticket a VAL instance pair of the new release. This VAL instance is a short lived instance. It is a clone of the PROD pair, with the upgrade applied. As such is it a full preview of what the users will see once they accept the upgrade into PROD.

This diagram shows how the VAL instance pair fits from a timeline perspective:

Note that the VAL instance will have some simple scrambling logic applied to the volunteer data to obscure PHI.

Requesting VAL Instances

Customers request to begin the upgrade process using JIRA tickets. In the ticket please include the following information:

  • The start date for when validation will begin

  • The target end date for when validation will be completed

  • Whether SSO is required to be configured in the VAL instance

  • Details for a lab test environment will be available for use in validation, if applicable

Please request the VAL pair only when there is an intent to devote resources to validation. Typically VAL instances should be required only for a few months.

Day of PROD Upgrade

Once validation has been completed by the customer, the customer can schedule a timeframe where the upgrade can be applied to PROD.

Upgrades typically involve some downtime. Typically this downtime is no longer than 15 minutes, but the expected downtime and windows size will be discussed and agreed upon with the customer during the scheduling via the JIRA ticket. It is a best practice to schedule an upgrade cycle on a day when there is minimal Data Collection activity, to minimize the risk of impact.

At the agreed upon time the upgrade itself proceeds as follows:


  • No labels