Technical Considerations for

Clinical Study Migrations

December 7, 2017

2

About Perficient

Perficient is the leading digital transformation

consulting firm serving Global 2000 and enterprise

customers throughout North America.

With unparalleled information technology, management consulting,

and creative capabilities, Perficient and its Perficient Digital agency

deliver vision, execution, and value with outstanding digital

experience, business optimization, and industry solutions.

3

Perficient ProfileFounded in 1997

Public, NASDAQ: PRFT

2016 revenue $487 million

Major market locations:Allentown, Atlanta, Ann Arbor, Boston, Charlotte, Chicago,

Cincinnati, Columbus, Dallas, Denver, Detroit, Fairfax,

Houston, Indianapolis, Lafayette, Milwaukee, Minneapolis,

New York City, Northern California, Oxford (UK), Southern

California, St. Louis, Toronto

Global delivery centers in China and India

3,000+ colleagues

Dedicated solution practices

~95% repeat business rate

Alliance partnerships with major technology vendors

Multiple vendor/industry technology and growth awards

4

5

Today’s Presenters

5

Richard Gavan – Solutions Architect, Life

Sciences

- System administrator, database

administrator and software developer

specializing in Linux and Windows

platforms

- Focuses on Life Sciences projects,

including:

- Project 1

- Migrate large home-grown clinical

analysis and reporting application

- Solaris to Red Hat Linux

- Integrated with HPC platform

- Project 2

- Migrate seven OC studies from legacy

CRO environment to new hosted

platform

- Project 3

- Migrate three OC studies from legacy

CRO environment to new hosted

platform

6

• Migration Process Overview

• Moves and Merges

• Upgrades and Conversions

• Audit Trails

• Customizations

• Challenges and Opportunities

• Case Studies

Agenda

7

What is Study Migration?

Study migration involves moving a clinical study

from one database to another database.

Based on multiple client requests, Perficient has

developed a process, using Data Pump, to

export a study in it’s entirety from one Oracle

Clinical database and import it into another

Oracle Clinical database. This includes, but is

not limited to, the database objects, user

accounts, audit trails and journaling records as

well as the data.

8

Perficient and Study Migration

Reasons for migration, overview of the

Data Pump process, and technical

considerations were presented in our

webinar “An Introduction to Clinical Study

Migrations” in May, 2017.

https://youtu.be/lKrMcw3pWzI

Additional details were given in “Validation

and Business Considerations for Clinical

Study Migrations” in August, 2017.

https://youtu.be/H9YxOUWZlwA

9

Migration Process Overview

Planning

•Project

•Validation

Analysis

•Technical

•Business

•Validation

Development

• Data export/ import process

• Installation/ upgrade log (if needed)

•Testing scripts

Dry run/ informal testing

•Migration and installation

•Testing (IQ, MQ, post-migration cleanup)

Validation

• Execute migration/installation into a validation environment

•Formal documented testing (IQ, OQ/PQ, MQ)

Production/ Go Live

•Execute migration/ installation into prod database

•Formal documented testing (IQ)

Close out/ Hypercare

•Summary Reports

•Support

10

Migration Process Overview

Planning

•Project

•Validation

Analysis

•Technical

•Business

•Validation

Development

• Data export/ import process

• Installation/ upgrade log (if needed)

•Testing scripts

Dry run/ informal testing

•Migration and installation

•Testing (IQ, MQ, post migration cleanup)

Validation

• Execute migration/installation into a validation environment

•Formal documented testing (IQ, OQ/PQ, MQ)

Production/ Go Live

•Execute migration/ installation into prod database

•Formal documented testing (IQ)

Close out / Hypercare

•Summary Reports

•Support

11

Migration Process Overview

• Export

–Tables

• List of tables for your version of the application database

• Metadata inspection script to generate list of users implicated in audit trail

• Filters for extracting only a single study or subset of studies

–Sequence

• Tables use numeric sequences to track record identifiers

–Custom objects

• Derivation/validation procedures, extract macros, thesaurus DVGs may depend

on external objects such as stored procedures, tables and views

12

Migration Process Overview

• Upgrade and Convert

–Data application version upgrade

–Character set conversion

• Import

–Import tables

• Disable triggers, foreign key constraints

–Apply sequences

• Run script to update all tables with latest sequence numbers

–Import custom objects

–Import Users

• Typically without passwords

13

Moves and Merges

• Move

–Target database is a newly created database with the target application installed,

but no data entered

–All global data is either already existing or new

–Keep new data to capture configuration/customization

• Merge

–Target database is an already-existing database with the target application

installed; some data has been entered and system is live

–Some global data may conflict with existing

–Conflict resolution

• Create copy of target database for development, attempt to import

• Review log for errors, compare conflicting rows

• Update import script to account for whether to keep existing or incoming record

14

Upgrades and Conversions

• Upgrade

–Target database application version does not

match the source database

–Data must be upgraded prior to final import

–Need to create staging database where data

will be imported and upgraded first prior to final

import

• Character Set Conversion

–Target database character set does not match

the source character set

–Data must be converted prior to final import

–Either update in the source system or in staging

database

15

Clinical Audit Trail

• Need to ensure necessary identifying information for users implicated in audit trail for

study being migrated

–Users may no longer be active

–Accounts don’t necessarily need to be migrated

–But the contact info does (e.g., Oracle_accounts table)

• Some applications do not have a straightforward mapping of users to the studies

they’ve touched

• Need to inspect existing audit trails to compile list of users

–Query username column of journaling tables

–Query created_by, modified_by, etc. fields of standard tables

16

Conflict Analysis

• Attempt to import into copy of target

database, similar to standard process

• However, import probably won’t succeed

• Inspect import errors to determine which

tables had a conflict

• Refresh target database copy, import

conflicting tables into a different schema

• Use SQL operations to identify just those

rows that had a conflict

• Determine whether to keep existing data

or replace with new

• Update import scripts accordingly

17

Customizations

• Customizations of the existing system need to be accounted for. This can include:

–Customized defaults and settings

–Custom data

• Thesaurus DVGs

–Custom programming

• External procedures, packages

–Custom images

• CRF Logos

–Customer user roles and permissions

• Migrate each object appropriately

–Customized defaults and settings included in standard tables

–Custom data, custom programming objects migrated via SQL or Data Pump

–Images transferred

–Custom database roles created, permissions migrated

18

Challenges

• Heavy customization can significantly increase effort

–Especially if existing customizations are not well documented

–Try to identify all of them during analysis; otherwise, testing effort may be delayed by

issues discovered

• Downtime

–Target database will need to be offline during the final import

–Not a problem if importing into new database

• Export/import iterations

–Typically, development of migration scripts involve at least two exports from the

source system

–Risk for delays if a new export cannot be readily obtained

–Even worse when there’s poor communication

19

Opportunities

• Database Cleanup

–Migration affords an opportunity to retire

unneeded dependencies and objects

–Avoid migrating perceived dependencies if they

are not required in the new system

–Cleans the database and makes the migration

easier

–Testing will be occurring anyway, this may be a

good time for some cleanup

• Multiple goals in the same project can reduce

total effort

–E.g., study migration with upgrade, character set

conversion, and merge

–Accomplish goal of moving the study, upgrading

the application, upgrading the hardware, etc.

20

Case Study

We were hired by a large CRO to migrate 7 studies into a new hosted OC/RDC/TMS database for

its client that had purchased the drug rights from a major pharmaceutical company. Due to study

timelines, it was determined that the first 6 studies would be migrated initially. The 7th study would

be migrated at a later date but would need to be imported into the same database. The source

database was version 5.0, but the CRO wished the database to be upgraded to 5.1 as part of the

migration.

• Challenges

–Application bugs

• Project involved upgrading to OC 5.1; encountered a number of bugs

• Effort increased due to having to discern application vs. migration defect during development and testing

• At least one bug was data-specific

–Did not have access to source system

• Had to coordinate with legacy vendor and timelines depended on their availability

–7th study needed to be merged into the same database

• Conflict analysis increased complexity and effort

QuestionsType your question into the chat box

22

For more information about Perficient’s capabilities or to

set up a free clinical study migration brainstorming

session to explore options most relevant to your

situation, please email Jessica.Knowles@perficient.com.

Next Steps

• Perficient.com/SocialMedia

• Facebook.com/Perficient

• Twitter.com/Perficient_LS

• Blogs.perficient.com/LifeSciences