BMS PV Integration

DP512 Migration Approach

Template Version Number: 1.01
Document Details
Project

BMS PV Integration

Status / Version

Initial Version

Reference Code
Disclaimer
If you are reading a copy of this document (i.e. print out of controlled electronic document or an
electronic copy of a wet ink signed paper document) you may be reading an uncontrolled
version. Before making updates, please ensure that you are using the latest version.
Document Approval / Review
Criteria

Name & Role

Signature

Author

Ritika Jain, Solution Architect

Electronic Signature in
LDMS

Date
Refer LDMS

Version Control
Version

Date

Description of Changes

Author

1.0

29-May-2014

Initial version

Referenced Documents
Name

Version

Location

Ritika Jain

Table of Contents
1

Scope of Migration...................................................................................................................... 4
1.1
General Assumptions........................................................................................................... 4
1.2
Out of Scope........................................................................................................................ 5
1.3
Abbreviations....................................................................................................................... 5
1.4
Computer Systems............................................................................................................... 6
1.4.1
BMS Systems............................................................................................................... 6
1.4.2
AstraZeneca Systems................................................................................................... 7
1.5
Vendors................................................................................................................................ 8
2 Migration Approach..................................................................................................................... 8
2.1
Identified Migration Components......................................................................................... 8
2.2
High Level Approach............................................................................................................ 9
2.3
High Level Process Workflow.............................................................................................11
2.4
Data Migration Environment Strategy................................................................................12
2.4.1
Environments Definition in AZ.....................................................................................12
2.4.2
AWARE Case Data Migration to SAPPHIRE Transactional........................................12
2.4.3
AWARE Document Migration to SAPPHIRE...............................................................12
2.4.4
Summary.................................................................................................................... 13
2.5
AWARE Case Data Migration into SAPPHIRE...................................................................13
2.5.1
AWARE Case Data Migration Strategies....................................................................13
2.5.2
AWARE Case Data Migration Validation Strategy.......................................................16
2.6
BMS Source Document Migration to SAM/SAPPHIRE......................................................16
2.6.1
BMS Source Document Migration Strategy................................................................16
2.7
Data migration numbers and estimates..............................................................................17
2.7.1
Number of cases......................................................................................................... 17
2.7.2
Volume of data to be migrated....................................................................................17
2.8
Identified Migration Tools................................................................................................... 18
2.9
Individual/groups responsible for migration and verification of identified components.......18
2.9.1
Case Data AWARE to Sapphire..................................................................................18
2.9.2
Source Documents DIMS to Sapphire........................................................................18
2.10
Migration windows and targeted turn-around time..........................................................18
2.10.1 Development to Test................................................................................................... 18
2.10.2 Test to Production....................................................................................................... 19
2.11
Cutover Plan................................................................................................................... 19
2.12
Migration resource contact points...................................................................................21
2.12.1 Solutions Architect:..................................................................................................... 21
2.12.2 Business Architect:...................................................................................................... 21
2.12.3 Source Data................................................................................................................ 21
2.12.4 Sapphire/Jasper Application Lead:..............................................................................21
2.12.5 Data Cleansing:.......................................................................................................... 21
2.12.6 Data Dictionary Migration............................................................................................ 21

1 Scope of Migration
AZ has acquired 7 diabetic products from BMS.

Onglyza (saxagliptin)

Kombiglyze XR (saxagliptin and metformin HCl extended release)

dapagliflozin (marketed as Forxiga outside the US)

Byetta (exenatide)

Bydureon (exenatide extended-release for injectable suspension)

Metrelept (metreleptin)

Symlin (pramlintide acetate)

BMS currently uses CARES for safety case handling and DIMS for source documents
management.BMS will be migrating safety data from CARES to AWARE. AWARE is Oracle Argus
(off the shelf product for patient safety case handling).
The scope of the Migration is:

1.1

Case data migration from AWARE to Sapphire

Source Document migration from DIMS to SAPPHIRE

BMS cases flow from SAPPHIRE to SMS

NFR testing

Performance testing due to increased data volume

General Assumptions

Functional
Only closed cases will be migrated and BMS would provide a proof that all the cases are
already reported. Nothing that gets migrated would trigger a report
Sapphire would default all the cases to CLOSED
Only the latest version of the case would need to be migrated.
Only English language content will be migrated from AWARE
No field will be added to SE2B format.
Business will add relevant pages to PSI
Its not required to sync historic cases to JASPER
No drug codes will be migrated from BMS to SAPPHIRE
Both Sapphire and AWARE will use the same MedDRA versions
The original BMS case IDs must be preserved through the migration process to support
follow-ups.

Non-functional

1.2

Migration is considered to be a one-off activity

There is no anticipated increase in head count as to support BMS cases as BMS cases are
already being handled in SAPPHIRE
No change will be done to business rules
AZ will own all follow-ups post migration
BMS will inform AZ about the follow-ups received during migration window and AZ business
will take care of entering the same in SAPPHIRE
Inherent dependency on PS Consolidation project which would migrate source documents
from SAM to SAPPHIRE
Close dependency on CARES to AWARE migration project at BMS end.
Validation strategy needs to be further defined
Data validation checks if any will be defined by business prior to the data migration activity
SAPPHIREs capacity and performance needs to be reviewed as all documents attached to
cases in AWARE will be migrated to SAPPHIRE.
It is assumed that business would accept the delay in availability of BMS data in reporting
database incase ETL job to push data from transactional to RDM takes longer than the
migration window

Out of Scope

1.3

Data migration from AWARE to Jasper is considered out of scope for this project
Data migration from Empirica to AZ SMS is considered out of scope for this project
Data migration from Aris J to ClinicalWorks is considered out of scope for this project
Data migration from AWARE to PSI/SSI is considered out of scope for this project
No audit data will be migrated from AWARE to SAPPHIRE
Migration of paper based source documents is not in scope
Archival of BMS data and documents is not in scope of this project
No change will be done in RAVE and IMPACT interfaces
Any upgrade of existing systems is considered out of scope
AZDD upgrade is considered out of scope.
No additional data will be transferred from Sapphire to ClinicalWorks as a result of the
transfer from AWARE.

Abbreviations

Term

Definition

AE

Adverse Event

AZ

AstraZeneca

AstraZeneca (AZ)
Patient Safety
Toolset.

Sapphire, Jasper, SAM, GES ISS, AMASS, PSI, AZ Impact.

(note: this is not an exhaustive list)

AZ DD

AstraZeneca Drug Dictionary. It is a master data of all drugs

against which cases can be possibly reported.

ETL

Extract, Load, Transform. Commonly used in data warehousing to

denote the extraction and loading operations.

MC

Marketing Company

MedDRA

Medical Dictionary for Regulatory Activities. The terms of Med

DRA are used while capturing the case details and in subsequent
reporting.

OS

Operating System

PS

Patient Safety

PSI/SSI

AZ Product Safety Information / Study Specific Information

SAM

Safety Adverse Event Management System

VB

Visual Basic

VDME

Virtual Data Mining Environment

WDC

World class Data Centre

WHO

World Health Organization - a UN organization head quartered in

Geneva, Switzerland.

1.4

Computer Systems

Since this is a migration activity, in this section we provide a brief description about the systems
involved at BMS and AstraZeneca and which vendors are involved in these systems.
1.4.1
1.4.1.1

BMS Systems
CARES

CARES is the system used by BMS to capture (and report) adverse events (AEs).
Since the CARES system will be discontinued before the migration into Sapphire, analysis of this
system seems to be irrelevant.
1.4.1.2 AWARE
AWARE is Oracle Argus off the shelf product which will be used by BMS to capture AEs post the
migration from CARES to AWARE. ARGUS uses its underlying Oracle DB repository for storing
data.
Argus version to be used: 7.0.3.1
Oracle version 11.2.0.3

1.4.1.3

DIMS

BMS uses DIMS to manage all global source documents associated with cases and AEs.
1.4.1.4

ARIS J

BMS uses ARIS J for Japan AE reporting

1.4.2
1.4.2.1

AstraZeneca Systems
Sapphire

Sapphire is the AZ global safety database system to capture and report AEs. It is a custom built
solution for AstraZeneca by Cognizant. Sapphire system has the following main logical grouping:

Cases
Subject
Site
Drug & Dosage
Adverse Events

Fundamental concepts to note:

Cases are the nucleus in Sapphire. Cases can have versions; are reported from a location;
for a drug; and can have adverse events associated with them.
Subjects are humans on whom the drugs are administered. Cases are reported by subject.
Site is where the drug is administered. It has broadly reporter, site and country information.
Drugs contain information about formulation, dosage, label, etc.
Adverse events are any untoward occurrence on subject due to the administration of a
medical product. It need not necessarily have to have a causal relationship with the
treatment. This is critical information that needs to be captured, followed up and reported.

Sapphire has a transactional and a reporting database. Sapphire has more than a hundred
significant transaction tables besides a large number of master data tables. A nightly ETL pulls the
transaction data to a separate reporting database.
1.4.2.2 Jasper
Jasper is a new Marketing Company tool that was delivered in December 2010. It is a lightweight
web front-end to the Sapphire system, allowing MCs to enter key information about an AE, which
can be loaded to Sapphire for TCS central data entry to then enter full case information. It also
allows MCs to view and transmit reports to local regulatory bodies and Investigators and Ethics
Committees.
No data will be migrated to Jasper from AWARE.
1.4.2.3

SAM

Safety Adverse Event Management System (SAM) provides the ability to manage all global source
documents related to adverse events. Together with Sapphire, SAM forms an integral part of the
Patient Safety Tool Set of applications of AstraZeneca. SAM is physically hosted in the US. The
data entry sites in other places around the world use SAM by faxing, scanning or by emails (with
source documents as attachments to the emails).
SAM uses Documentum eContent Server 6.5SP2 and Oracle 10g R2. The user interface is written
in C# .Net3.5 and hosted in web server OS 2008-IIS7.5.

1.4.2.4 SMS
The AZ Signal Management System (SMS) is based on Lincoln web VDME and is fed by Sapphire.
No data will be migrated to SMS directly from AWARE.
There is an impact on SMS feed that goes out of SAPPHIRE into SMS due to technical limitation of
volume handling capacity.
Currently a file is sent from SAPPHIRE to SMS every 30 mins which contains 10 cases each.
There is a risk of congestion in SMS system due to heavy volume of cases being migrated into
SAPPHIRE as a part of this migration
There is a need to do detailed analysis on volume handling capacity of SMS or a need to design
alternative route of transfer in case of migration.
1.4.2.5 PSI/SSI
AZ Patient Safety Information / Study Specific Information (PSI / SSI) is a web-based storage area
that is created by the PS business to convey product and study specific information to TCS for entry
of cases into Sapphire.
AZ business will make relevant data in AWARE for marketed products and open studies available in
PSI/SSI for TCS to be able to enter cases in Sapphire for BMS after Go-Live. Business will add
pages to PSI

1.5

Vendors

Cognizant Sapphire, Jasper and SAM systems

o Cognizant supports all 3 systems and have developed Sapphire & Jasper
Quintiles AWARE Case Data
BMS Source documents

2 Migration Approach
This section describes the various components of data migration, starting with a high level overview,
and followed by the approach to data cleansing, data migration, drug dictionary coding and
document migration.

2.1

Identified Migration Components

The BMS AWARE system that holds the structured case data and unstructured case data
(electronic documents)

2.2

The BMS DIMS system that holds unstructured case data (source documents)
The AZ Sapphire system that holds the structured case data.
The AZ SPAPHIRE system that holds the unstructured case data (electronic documents)
depending on PS consolidation project

High Level Approach

There are two approaches as mentioned below. The end to end migration time and
acceptable downtime would determine the final approach.
Phased : Case Data and documents are transferred from BMS but load happens in
two stagesWeek 1: Case and AE data from AWARE to SAPPHIRE
Week 2: Documents migration
Big Bang :Case Data and documents are transferred from BMS but load happens
in one go-Data and Documents all together

Before data migration

o All case versions in AWARE will be processed and moved out of the AWARE
Workflow prior to the migration.

o
o
o
o

Data migration window

o
o
o
o
o
o
o

BMS data will be copied into a secure HDD, in form of Database dump file for case
data and XML files for source documents, which would be transferred to AZ location
by mail or personally.
Files will be copied to AZ network location and subsequently move to Informatica
source file directory
Documents including metadata will be copied from HDD to SAPPHIRE document
Database<< Need to work with PS consolidation team on this>>
Integrity check to be done on data arrival

Upload BMS database dump in a database schema at AZ

ETL to read, transform and load data into SAPPHIRE database
A file containing all old AWARE case ids and the new Sapphire ids will be created
from the migrated Sapphire database to be used for source documents migration.
The transferred documents with meta data will be uploaded to the SAPPHIRE
Oracle DFS.
The new Sapphire case id will be retrieved from the file created and used for
documents upload
The Sapphire reporting database is updated using the standard nightly ETL which
would be run manually after migration.
Data validation checks will be defined by the business & applied at the appropriate
migration steps to ensure no data is lost and data is migrated accurately.

After migration window

o BMS will inform AZ Business about the follow-up cases received during migration
window
o AZ business will add those cases into Sapphire
o BMS will stop entering case data for these products into AWARE
o New case data for these products will be logged into SAPPHIRE
o Copy all source data to programme level Landing area for archival

2.3

High Level Process Workflow

2.4

Data Migration Environment Strategy

2.4.1

Environments Definition in AZ
Secured Network share to keep source data

Following Application, database and Informatica environments are needed:

Development/Sandbox - Non-validated/Informal, development of code, unit testing, IS

usage

System Test - Validated/Formal, full system testing, integration testing, IS usage

Pre-Production/Validation - Validated/Formal, User Acceptance Testing, User and Load

Testing, Same as production (scaled down), both IS & Business usage

Production - Validated/Formal, Operational for end Users, Business usage

Others - Training Validated/formal, user training, Disaster Recovery - Validated/formal, for

Disaster Recovery

2.4.2

AWARE Case Data Migration to SAPPHIRE Transactional

For Data Migration the following services/apps will be needed:

Secured Network share to keep source database dump
AWARE cleansed data (source) in form of database dump
Oracle database schema for loading BMS source database dump
BISS ETL (Informatica ETL for transformation)
Sapphire Transactional (target)
2.4.3

AWARE Document Migration to SAPPHIRE

For Document Migration the following services/apps will be needed:

AWARE source documents
Secured Network share to keep source data
Sapphire ID mapped to BMS ID
Upload Tool
Sapphire Oracle DFS

Following diagram depicts the same

2.4.4

Summary
The Data Migration (DM) and BAU work streams will work in separate environments for the
development and informal testing
Formal Testing will be carried out together from System Test Round 2.
This will mean sharing of the Sapphire formal environments.
Close collaboration will be needed between the work streams to co-ordinate the sharing of
the environments

2.5

AWARE Case Data Migration into SAPPHIRE

2.5.1

AWARE Case Data Migration Strategies

The migration strategy with the possible options is given below. Please note that many of these will
be revisited based on our learning during the migration process of development and system test
instances. The table below represents our current thinking.
2.5.1.1

Network

Data (cleansed/un-cleansed) will be extracted from BMS network and rest everything will done in
AZ network
2.5.1.2

Data Transmission method

There are three options here as shown below:

 Secure HDD
Pros
Easy setup
Security and privacy easily managed and trusted
Cons
Longer cutover period
Expensive and time taking process
Difficulty in handling, managing and rectifying extract issues and errors
Fileshare Sync
Pros
Shorter cutover
Efficient and faster process
Extract errors can be managed and rectified easily
Cons
More efforts in setup and configuration
Security and privacy need to be addressed
Cloud based (Box.com)
Pros
Shorter cutover
Efficient and faster process
Extract errors can be managed and rectified easily
Secured and agreed approach
Cons
More efforts in setup and configuration

2.5.1.3

Preparatory work

Define the steps of load- Load case data first and then source documents
Backup sapphire DB
Copy BMS data extract to AZ shared network
Create a temporary oracle schema to hold BMS database dump
The requirements for master data for entering a case in Sapphire must be well established.
This is to ensure that the migration of data from AWARE does not fail due to the lack of
required master data (i.e. it must satisfy foreign key requirements) elsewhere.
Perform integrity check

2.5.1.4

Extraction, Transformation and Load Case data to transactional DB

A combined approach to use ETL routines and PL/SQL custom routines will be used.
2.5.1.5

AZ Drug Dictionary Coding

There is no need to populate BMS Drug dictionary codes. Option to use Auto-encoder for re-coding
to AZDD will be considered
2.5.1.6

Population of reporting DB

There are two options which need to be considered based in the ability of existing ETL job to handle
the huge volume and amount of time taken by the job
Execute the existing ETL as and when data migration is completed.
Pros:
No additional effort needed to develop and test
Thoroughly tested code
Cons:
140k cases might take long and hence data may not be available in Reporting DB
immediately on start of business
Create a new high performing ETL/Oracle job to bulk load data
Pros:
High performing job means faster and data would be available in reporting DB
earlier
Cons:

Additional effort needed to develop and test

Highly skilled resources needed to performance tune the ETL
May require additional/improved infrastructure
New code means more risk

Currently, Sapphire uses BISS ETL services to pull data from Sapphire transactional database to
the reporting database.
The existing ETL job takes ~4-5 hours to push ~1500 cases to reporting DB.
Hence there is a need to analyze its capability to push 140 K cases and estimate the time it would
require.

2.5.1.7

Extraction and load source documents to Sapphire

<< Need to define this >>

2.5.1.8

Rollback

Restore DB from backup

2.5.2

AWARE Case Data Migration Validation Strategy

The test and validation need to be described in the TE582 Migration Test Approach document.

2.6

BMS Source Document Migration to SAM/SAPPHIRE

Need more analysis on this with PS consolidation project team

The metadata for checking in a document

SAM/Sapphire capacity and performance

This has a dependency on PS Consolidation project which is going to migrate SAM data into
SAPPHIRE
2.6.1

BMS Source Document Migration Strategy

2.6.1.1.1

Order of Migration

The fundamental ordering of task regarding data and doc migration is examined, since they are
closely linked.
Recommendation: Data migration of cases must precede the document migration. The
document extraction can start before case migration because document are only added and
not changed.
Rationale: Architectural integrity must be preserved. Existence of cases is neccessary
before documents can come into being.
The other strategy recommendations are:
2.6.1.1.2

Extraction of Documents from DIMS

BMS to extract documents and transfer to AZ via agreed transmission method.

2.6.1.1.3

Network Impact

Currently no impact has been identified on network as data transfer is supposed to happen
via secure HDD.

2.6.1.1.4

Metadata Creation

Option 1: Create document related metadata from the source system during the data
migration itself.

Option 2: Post migration, create the document related metadata from Sapphire.
Recommendation: Data migration should cover the extraction of identified metadata for
each of the case that has at least one document. It should be put in an agreed flat file
format and transferred to SAPPHIRE.

2.6.1.1.5

Upload to SAPPHIRE document management

<< Need to work with PS consolidation team on it >>

2.7
2.7.1

Data migration numbers and estimates

Number of cases
Currently 140K cases are identified for migration

2.7.2

Volume of data to be migrated

Case Data: 75 GB
Documents: 250 GB

2.8

Identified Migration Tools

2.9

A tool for Cognizant to import the data from database dump to intermediate staging area
and into the Sapphire transactional database. For example, an ETL tool like Informatica
PowerCenter.
A tool to import the DIMS exported case documents in bulk into the AZ document repository
and link the documents with the appropriate case (structured data) in Sapphire.
.

Individual/groups responsible for migration and verification of identified

components

2.9.1 Case Data AWARE to Sapphire

Action
Export AWARE data
Transform & load the data into Sapphire via
an intermediate staging area.

Responsibility (* Primary)
BMS (led by Kamlesh)
Quintiles
Cognizant

2.9.2 Source Documents DIMS to Sapphire

Action
Responsibility (* Primary)
Export DIMS documents
BMS (led by Kamlesh)
Load source documents in SAM/SAPPHIRE Cognizant

2.10 Migration windows and targeted turn-around time

Targeted turn-around time must allow enough time for the data migration to be aborted and all
changes to be backed out. Therefore the targeted turn-around time would be approximately half of
the migration window (around 2 days). Database backups, Disaster Recovery planning/testing and
other potential data migration efforts (such as Japan) must also be factored into the planning of an
optimum time for the migration to occur.
2.10.1 Development to Test
It is recommended that a test of migrating all of the BMS data (structured and unstructured) will be
performed prior to the final production migration in the Sapphire and SAM pre-prod environments.
The Sapphire Test (pre-prod) area contains a similar volume of cases to Sapphire production and
so is the appropriate environment to perform performance/load testing of the Sapphire system &
reporting performance, with the BMS data incorporated, in order to detect problems prior to the final
production migration.
Component

Days

Time (CT)

Expected

Notes

AWARE to
Sapphire

TBD

Duration
TBD

AWARE to
SAM/SAPPHIRE

TBD

TBD

Time (CT)

2.10.2 Test to Production

Component Days
A

AWARE to
Sapphire

TBD

Expected
Duration
TBD

AWARE to
SAM/SAPPHIRE

TBD

TBD

This includes import of AWARE

flat files, transformation of data,
Sapphire database backups and
load of data into Sapphire and
the ETL to the datamart.
This includes import of AWARE
unstructured content (case
documents) extracts, SAM
database & content repository
backups and bulk import of
unstructured content extracts into
SAM /SAPPHIRE and integrating
them with cases

Notes
This would be a replay of the
process that was used to migrate
the data into the test (pre-prod)
environment, now using the
Sapphire production
environment.
This would be a replay of the
process that was used to migrate
the data into the test (pre-prod)
environment, now using the
SAM/SAPPHIRE production
environment.

2.11 Cutover Plan

One of the following three approaches can be used to define cutover plan

 Immediate cutover
As soon as AZ is live, BMS stops entering cases for these products.
Sapphire is used to enter all new and a follow-up case from the moment system is back.
Pros:
Low cost
Operational ease
Cons:
High risk
Phased cutover
Cases related to 1-2 drugs are entered in Sapphire post first phase migration; BMS
continues to receive cases related to other drugs till final phase migration happens.
Sapphire is used to enter all cases after second phase migration
Pros:
Medium risk
Better user confidence
Cons:
More cost
Operational complexity

Recommendation:
Phased cutover is recommended to optimize risk and cost

2.12 Migration resource contact points

For more information or answers to question about the ADM migration approach please contact the
following people:
2.12.1 Solutions Architect:
o
o
o

Name: Ritika Jain

Phone: +44 7769290018
e-mail: ritika.jain@cognizant.com

2.12.2 Business Architect:

o Name: Alastair.Fowkes
o Phone: +44 1625 512414
o e-mail: Alastair.Fowkes@astrazeneca.com
2.12.3 Source Data
o Name: Kamlesh Shah
o Phone:
o e-mail: Kamlesh.Shah@bms.com
o
o
o

Name: Raghunandan satyanarayan

Phone:
e-mail: raghunandan.satyanarayan@bms.com

2.12.4 Sapphire/Jasper Application Lead:

2.12.5 Data Cleansing:
<<TBD>>
2.12.6 Data Dictionary Migration
<<TBD>>