Page Comparison

...

Summary

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

Here is an overview of the upgrade process:

...

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

Here is an overview of the upgrade process:

...

can support validation and training activities.

To help our customers enter into a well-coordinated and controlled upgrade cycle, we’ve outlined many of the common activities, expectations and responsibilities between customer and IQVIA teams and detailed article.

Example Customer Validation & Upgrade Process Flow

We suggest our customers review and consider this in their own upgrade plans and raise questions to our support team where applicable.

Temporary VAL Instances

We anticipate our customers' need to perform training and validation activities on a new release. To support this, customers can request via a service desk (JIRA) ticket a IQVIA provides a temporary VAL instance pair of the new release for this purpose.

This VAL instance is expected to be a short lived instance. It will be a clone of the PROD environment pair, with the upgraded version (build) applied. As such, is it expected to be a full preview of what the users will actually see once they accept the upgrade into PROD.

More information about the creation of VAL environments is here: Creating VAL Environments

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

...

Note that the The VAL instance will have some simple scrambling logic applied to the volunteer data to obscure PHI. More information about that process is noted here: Obfuscating Volunteer PII

Requesting VAL Instances

Customers request to begin the upgrade VAL process through the service desk. In the ticket, please include the following information:

• The version number and build to deploy to VAL instances

• The start date dates for when validation activities will begin

• The target end date for when validation will be completed

• Whether and end

• Indicate if 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 instance pair only when there is an intent to devote resources to validation activities. Typically, VAL instances should be required only for a few weeks/months.

...

More details covering the creation of VAL environments can be reviewed here: Creating VAL Environments

PROD Upgrade

Once validation has been completed by the customer, the customer can schedule a timeframe where the upgrade can be applied to PROD Main/Test instance pairan upgrade to PROD environment pair can be scheduled and coordinated. All PROD upgrades are coordinated through the service desk with the assistance of an IQVIA PM.

Customers request to begin the PROD upgrade process by submitting a service desk ticket. In the ticket please include the following information:

• The version number and build to deploy to PROD (this usually matches the VAL version/build)

• The expected date & time Time slots indicating dates/times on when the upgrade would be suitable to occur. If providing multiple, indicate a preferred time slot. Ideally, multiple time slots (including timezone) would be provided for consideration, so IQVIA PM can coordinate with available engineering resources. Example: Monday, July 1st, 9am - 10am CST; 2pm-4pm CST

Upgrades typically Please ensure adequate warning is provided of the intended upgrade; minimum three weeks notice is preferred.

Upgrades can involve some downtime. Usually this downtime is no longer than 15 minutes, but the , usually a matter of minutes. The expected downtime and window size upgrade timelines will be discussed and agreed upon with the customer during the scheduling via the service desk 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. This would be a suitable ‘quiet’ time in the clinic.

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

...

Hotfix Releases

When necessary, hotfix release builds are created and provided for customers. Hotfixes are often very small in scope of change and do not introduce new features. They intend to address issues having a significant impact on user experience, clinical data, security, or otherwise addressing regulatory non-compliance.

Hotfix builds are not automatically pushed to customer environments. Customers are expected to review release contents and consider acceptance into environments similar to standard upgrades. All upgrades, including hotfix releases, will always require planning and coordination between customer and IQVIA teams to ensure a successful deployment.