Embed Size (px)
Citation preview
PREVIOUS NEXT PREVIOUS NEXT
Merging Multiple Drug Safety and Pharmacovigilance Databases into One Global Oracle Argus Safety System
Facilitating Globalization with Automated Configuration Loading
May 30, 2012
Rodney Lemery, MPH, PhD Vice President, Safety and Pharmacovigilance
BioPharm Systems, Inc.
PREVIOUS NEXT
Agenda
• Summary of Situation • Project Overview
• Review of Database Architecture
• Technical Overview
• Description of Methods Used • Origin of Methodology
• Techniques Used
• Results of Methods
• Lessons Learned
• What This Means for You
PREVIOUS NEXT
Summary of Situation
Project Overview • A leading U.S.-based pharmaceutical company founded in the early 1980s
issued a RFP asking for assistance in the globalization of their current Argus Safety system
• The company would be migrating three separate non-Argus safety applications into their central Argus database
• To accommodate this migration, configuration of the data not currently present in the global repository needs to be entered and present before any meaningful mapping discussions could be final and executed
PREVIOUS NEXT
Review
Review of Architecture
• We are a diverse audience and thus a refresher of basic Argus application and database architecture is important
PREVIOUS NEXT
Review
Review of Architecture
• Oracle databases organize data into objects called TABLES
You can think of these as individual tabs present in a single MS Excel workbook
Similarly, the tables contain columns and all of your clinical data is stored in the resulting rows
COLUMNS
ROWS
PREVIOUS NEXT
Review
Review of Architecture
• Oracle has done a wonderful job ensuring that information from one table, required in another, is not repeated but rather referred to between the tables
a.k.a. Referential Integrity
• In the example below, the Acarbose record is available in 10 mg concentration, while the Acetaminophen is 100 mg
• Note that the LM_PRODUCTS table does NOT contain the actual unit of measure but rather refers to the LM_DOSE_UNITS table for the decoded value
LM_PRODUCTS LM_DOSE_UNITS
PREVIOUS NEXT
Review
Review of Architecture
• The data in certain columns on tables can have special “rules” associated to them
• These “rules” are referred to as “constraints”
• For example, the LM_PRODUCTS table contains a rule stipulating that the PRODUCT_ID field cannot be NULL (missing) and must be unique for every row
LM_PRODUCTS
PREVIOUS NEXT
Review
Review of Architecture
• Certain rules are created on tables to identify column(s) as primary to the table (Primary Keys)
• Other rules can be created to ensure that a reference to another table is appropriately used (Foreign Keys)
LM_PRODUCTS
Primary Key Foreign Key
PREVIOUS NEXT
Review
Review of Architecture
• In an Oracle database, other rules can be used to automatically perform certain functions when things happen to the underlying table (a.k.a. TRIGGERS)
LM_PRODUCTS
• Ex. On table INSERT, UPDATE or DELETE; populate the audit tables
PREVIOUS NEXT
Summary of Situation
Technical Overview • Company’s acquisition of a global generics company resulted in the need
to incorporate international configuration and case data into their existing drug safety system
1857 Products Including product family, ingredients, data sheets, etc.
1995 Ingredients 5442 Licenses 147 New regulatory report rules and associated reporting destinations
PREVIOUS NEXT
Methods Used
Origin of Methods • Argus installations contain an
Oracle DUMP (DMP) file that contains a number of database tables pre-populated with the “standard” data that ships with the initial Argus application
• BioPharm reviewed the associated LOG files to identify tables that were manipulated by the vendor
PREVIOUS NEXT
Methods Used
Origin of Methods • Unfortunately, the desired list maintenance (LM) tables (such as
products, licenses, etc.) were not present in the DMP file
• However, BioPharm does see the use of a DMP file as vendor precedence for the use of data manipulation language (DML) in configuration tables of the Argus database
• Also, in our past Argus migration work, the required extract, transformation and loading tools included DML use in the Argus backend
PREVIOUS NEXT
Methods Used
Technique Overview
PREVIOUS NEXT
Methods Used
PREVIOUS NEXT
Methods Used
Techniques Used
• Given that we interface with mostly safety business users and the fact that this configuration methodology and work is technical in nature, we have devised a configuration requirements specifications (CRS) document to fully document the required elements of configuration
• This MS Excel document is populated with the required elements necessary in full configuration table population
PREVIOUS NEXT
Methods Used
Techniques Used
• We identified the mandatory field data in the required tables and reflected those fields in the CRS document
• Meetings were then facilitated to discuss the information in the CRS and reach consensus to its content
PREVIOUS NEXT
Methods Used
Techniques Used • Since all of the Argus native constraints were kept active in the database, we
needed to reflect that constraint logic in the Excel file to ensure minimum negative database impact
• Sometimes, constraints were enforced by the Argus application and NOT the database
PREVIOUS NEXT
Methods Used
PREVIOUS NEXT
Methods Used
Techniques Used • For mass loading of data,
BioPharm used the SQL*Ldr application available from Oracle as part of an advanced SQL*Net installation
• This application requires the creation of a control (CTL) file that describes what file should be uploaded into what table
• This file also contains descriptions of the columns expected in the source data file and maps it to the corresponding Argus table
PREVIOUS NEXT
Methods Used
Techniques Used • The corresponding CRS tab was then saved into a corresponding CSV file
referred to in the control file above
PREVIOUS NEXT
Methods Used
Techniques Used • Many of the populated tables, such as LM_PRODUCTS, required a number
of decoded fields from the database (such as concentration units, formulation, etc.) prior to insertion (foreign key lookups)
• While we could have placed those required IDs in the CRS directly, the volume of information would have been very challenging to manage
• We opted instead to use SQL*Ldr to load the more complex data into temporary staging tables where a helper PL/SQL Package was used to “code” the required information by executing a series of lookup functions to return the required ID fields that are required to adhere to referential integrity
PREVIOUS NEXT
Methods Used
PREVIOUS NEXT
Methods Used
Techniques Used • SQL*Ldr can be executed through the standard MS Command-line
interface on any windows machine
• The execution command requires the control file
PREVIOUS NEXT
Methods Used
PREVIOUS NEXT
Methods Used
Assumptions and Risks to Remember with this Methodology
• The BioPharm methods explained here do NOT disable the native constraints and triggers used by the Argus database
• All information loaded into the tables must comply with these native table constraints
• There is a possibility that certain Argus application level triggers or constraints are being bypassed in this methodology beyond those already identified within these slides
PREVIOUS NEXT
Methods Used
PREVIOUS NEXT
Methods Used
OQ/PQ Testing • Once the CRS is final, BioPharm suggests documenting the user
requirements in a separate document referred to as a User Requirements Specification (URS)
• This document should contain all of the high-level requirements for the globalization of the system including any major aspects of the system that the users are concerned over given the risks of using a database level loading of configuration
PREVIOUS NEXT
Results
Impact on Globalization • Saved ~39 days in
configuration work
• Empowered the company to reuse the scripting in future globalization efforts
Configuration Type Configuration
Item Count
Estimated Manual
Time
Actual Load Time
Saved Time
Products 1789 7.5 0.008 7.492
Ingredients 1927 2 0.008 1.992
Licenses 4242 26.5 0.008 26.492
Datasheets 1178 1.2 0.008 1.192
Reporting Rules 156 1 0.008 0.992
E2B Receivers 70 0.6 0.008 0.592
E2B Senders 68 0.6 0.008 0.592
Manufacturers 57 0.1 0.008 0.092
TOTALS 9487 39.5 0.063 39.436
Table 1: Estimated Time Savings From Configuration Development Scripts (all time in days)
PREVIOUS NEXT
Lessons Learned
Improvements for Next time • MS Excel constraint and lookup columns were not always hidden from
user view when reviewing this complex document and should have been
• As many decisions on the data in the CRS were driven by Argus business use, importance should be placed on how the application is to be used before configuration data is uploaded
• All end-users should actively participate in these decision discussions as the data will impact their entry, management and analysis of safety information
• Automation of the CSV files from the MS Excel sheets
PREVIOUS NEXT
Ways to Engage…
• For those ready • Proof of concept
• For those not quite ready • Schedule early engagement calls to provide guidance on similar projects
• For those in the midst of a globalization • Refine your approach with guidance calls to review your approach and
evaluate if BioPharm’s methods might be useful to your organization
What This Means for You
PREVIOUS NEXT
Questions & Answers / Contact Information
Rodney Lemery, MPH, PhD Vice President, Safety and Pharmacovigilance +1 650 292 5310 (U.S.) [email protected] Rod Roderick Vice President of Business Development +1 877 654 0033 (U.S.) [email protected] Rudolf Coetzee Director of Business Development, EMEA +44 (0) 1865 910200 (U.K.) [email protected] For more information about our offerings, you can reach any team member above or
e-mail [email protected].
