Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Technical Considerations for Clinical Study Migrations

185 Aufrufe

Veröffentlicht am

There are a variety of essential technical considerations that should be evaluated when migrating clinical studies from one database to another.

Does the incoming data need to be “merged” into an existing database? What if the source application has been customized? What obstacles can be expected? Where does regulatory compliance come into the picture?

In this SlideShare, Richard Gavan, a solutions architect in our life sciences practice, discusses several case studies that provide insight into the:

Steps followed during a study migration process, from a technical perspective

Technical considerations for migrating into an empty database or a database that already contains data – and how to decide between the two

Actions needed to preserve the integrity of clinical audit trails

Difficulties and opportunities presented by existing customizations

Pitfalls and challenges that may be encountered

Lessons learned

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Technical Considerations for Clinical Study Migrations

  1. 1. Technical Considerations for Clinical Study Migrations December 7, 2017
  2. 2. 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. 3. 3 Perficient Profile Founded 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. 4. 4
  5. 5. 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. 6. 6 • Migration Process Overview • Moves and Merges • Upgrades and Conversions • Audit Trails • Customizations • Challenges and Opportunities • Case Studies Agenda
  7. 7. 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. 8. 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. 9. 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. 10. 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. 11. 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. 12. 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. 13. 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. 14. 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. 15. 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. 16. 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. 17. 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. 18. 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. 19. 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. 20. 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
  21. 21. Questions Type your question into the chat box
  22. 22. 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