Abbott e-Submissions Program

1. Abbott e-SubmissionsProgram Documentum Migration Utility & Third Party Access Application 02/18/2005 v1.0

2. Agenda • Background • Migration Utility • Project Background • System Overview • Solution Screen Shots • Third Party Access (Extranet) • Project Background • System Assumptions • System Overview • Solution Screen Shots

3. Background • e-Submissions (e-Subs) Program • Manages process and procedures followed to submit documentation to the FDA • Uses Documentum to manage all submission documents • WebTop 5.1 (with customizations), AnnoDocs, CoreDossier • e-Subs 2004 Pain Points • Need the ability to efficiently “bulk load” documents into e-Subs • Need more control over documents that are shared externally

4. e-Submissions Migration Utility

5. Problem Statement • Need to move and/or copy documents and attributes: • into Documentum from an external file source • between Documentum Docbases • Need to enforce complex processes including: • Ensuring specific business rules are applied to the target data in Documentum. • Reducing complexity and support expense by having a common tool for each different data source that contains documents to be moved or copied into Documentum. • Simplifying user interfaces for initiation and tracking of migration efforts. • Minimizing time and management effort to set up large migration tasks. • Reducing effort involved in recovering from a failed migration.

6. Use Case – Statistical Datasets • Stats Group creates and manages datasets to support drug studies • Hundreds of datasets could be included in one submission • Currently a manual process to import each dataset into Documentum using the Webtop interface, and set property values one-by-one • After import, must then proceed to route each dataset on workflow for acceptance

7. Migration Utility – Vision • Accept input from multiple sources and formats (Data Staging) • Import data into Documentum in a batch approach • Allow for configurable business rules to be applied to the imported batch e-Subs Docbase Content & XML index file export Validate & import Staging Area Migration Utility

8. 1. Data Staging • Prior to importing into Documentum, stage the data from the various sources in a common area. • Staging area is a designated file share on the web server • Leverage XML to capture indexing information to be used for import into the target Documentum object: • Document type • Destination location • Attribute name and value mappings • Content pointer • Rendition pointer • Version tree structure • Audit trail values • Lifecycle state • Workflow template

9. Benefits of Staging • Allows for re-use of import processing code • Do not want to develop and maintain separate code modules for file-share import versus Docbase import, etc. • Content is just content in the staging area • Allows for consistent application of business rules • All content from the various sources is staged for import according to standard business rules Content & XML index file export validate & import Staging Area

10. 2. Batch Processing • Bundling a logical set of data and processing it as a batch results in a more efficient and manageable migration effort including: • Reduced set up time by allowing certain properties to be defined at a batch level rather than the document level. • Decreased preparation time by providing the ability to copy a document’s setup to other documents within the batch. • Improved monitoring by allowing large migration efforts to be broken down into phases to help meet various load and timing constraints. • Addressing failed imports by automatically isolating failed documents so they can easily be identified, corrected, and re-run.

11. 3. Configurable Business Rules • A set of business rules is associated with each e-Subs document type in the target Docbase. The business rules define what criteria must be met in order for migrated content to be imported as a particular document type. • XML schemas are used to define and enforce the business rules • The schemas validate things such as… • Lifecycle States • Lifecycle • Required • Lookup Values • Data Type • String Lengths • Special Characters

12. Phased Approach • Phase 1.0 • Enabled migration via Excel batch files • Export = none • Data Staging = manual • Validate and Import = Migration Utility Import module • Deployed September 2004 • Phase 2.0 • Enabled migration from a File Share source • Export and Data Staging = Migration Utility Interface • Validate and Import = Migration Utility Import module • Deployed January 2005 • Phase 3.0 • Under development now – target deploy June 2005 • Will enable Docbase to Docbase migration

13. Solution Screen Shots • File Share Source: • Create New batch • Upload Documents • Batch Details • Document Setup • Document Details • Available Batches • Error Processing

14. Available Batches • The available batches screen is the first screen presented upon login. It lists all the batches that have been created, and provides the option to create a new one.

15. Create New Batch • A user can set batch level properties and select local files and directories from the file system to include in the batch by clicking the add files button.

16. Upload Documents • After selecting one or more files, the user clicks the upload button to transfer the files from the local file system to the staging area.

17. Batch Details • Once a batch is created, the batch detail screen is displayed listing each document in the batch. Users may click on a document name to set up Documentum properties specific to that document type in the target Docbase.

18. Document Setup • The document setup screen is the first screen that is displayed when a user selects a document in order to specify its properties. The document setup screen is used to specify general properties for the target document in Documentum such as its document type and location within the Docbase. A user may click the next button to continue to add additional details for the document.

19. Document Details • This document details screen shows how a user is able to specify attribute values for the target document. The Justification for Change and Reason for Change attributes listed on this screen are examples of how suggested values can be pulled from Documentum and listed to help ensure data integrity.

20. Document Details (cont.) • This document details screen shows how a workflow template and workflow performers can be associated with a document. Upon import, the workflow will be initiated automatically.

21. Back to Batch Details • When a user returns to the batch detail screen, the properties are displayed along with the document name. Users may also click the copy doc setup button to copy properties from one document to any other documents in the batch.

22. Back to Available Batches • Once all the documents have been set up for a batch, a user may begin the verification and import process from the available batches screen. A user may click on a batch name to add or setup additional documents. A user may click the Verify link to verify that all documents in the batch have been set up to meet the defined business rules. After a batch has been successfully verified, a user may click the Import link to import the batch into Documentum. If an error occurs in the verification or import process, an error link will be displayed in the status column directing the user to a detailed error screen.

23. Validation Error Processing • The detailed verify error screen lists all documents that failed to meet a business requirement with a detailed description of the failure. From this screen, a user may click on any of the documents to remove it from the batch or correct any of its setup properties. After making corrections, the user can run the verification process again from the available batches screen.

24. Import Error Processing • The detailed import error screen lists all documents that failed to import into Documentum. From this screen, a user may click on any of the documents to remove it from the batch or correct any of its setup properties. Documents that imported successfully are automatically removed from the batch, making it easy for a user to run the import process again for only the documents that failed. After making corrections, the user can run the verification and import process again from the available batches screen.

25. Lessons Learned • Import processing is not difficult • Bulk of the challenge lies in… • Providing flexible architecture for business rule enforcement • Providing a robust user interface for users to easily define index information and to be confident of correct import • Batch details • Defining attribute mappings • Validation and Import Error processing • Allowing users to re-use defined document setups is high value

26. e-Submissions Third Party Access

27. Problem Statement • e-Submissions leverages third-party medical writers and medical investigators (CRO) • Current issues being faced when dealing with third party authors: • Lack of an audit trail of third party activity and actions • Confidential documents residing in third party email accounts and local hard drives • Third party authors not utilizing the latest e-Submission document templates • The need to email documents to third party authors • The need to send hard copies of documents • The need to scan-in hard copy signature pages

28. Extranet Application CRO Data Import Abbott Standards, Templates, Processes Third Party Access - Vision Abbott Standards, Templates, Processes Abbott Site 1 Abbott Site 2 Repository Publishing COE To Regulatory Agencies

29. Project Approach • 2004 • Perform analysis and user requirements gathering • Develop a prototype of the interface • Identify and explore technical architecture alternatives • Pilot a solution with subset of CRO’s by end of year • Compile a post-pilot summary report • 2005 • Implement a Validated system

30. System Requirements • 3rd Parties will not have access to the e-Sub System directly • This poses too much of a security risk • An Abbott owner will make documents available to the 3rd Parties • 3rd Parties will have the ability to author, review and approve documents • 3rd Party audit trails will be maintained • Same audit trails for external and internal users • 3rd Parties will see internal Abbott reviewer comments/annotations • The 3rd Party System will allow local export and printing • 3rd Party access will be via the web • 3rd Parties will access the application through a Citrix environment • The 3rd Party System will provide reasonable response time and performance

31. System Overview – Process Flow 1 – Abbott Author 3 – 3rd Party Author 2 – e-Sub System • Logs into the 3rd Party Extranet application • Accesses inbox • Selects workflow task and requests document for edit/acceptance/approval • Logs into the internal Abbott e-Submissions application • Initiates workflow to make document(s) available to external users • Notifies the external co-authors • Routes the workflow to the external users inbox 4 – Extranet Application 5 – 3rd Party Author 6 – Extranet Application • Serves up the document in Microsoft Word 2000 or Adobe Acrobat • Edits/accepts/approves the document • Finishes the workflow task • Routes the document(s) back to the e-Submissions system 7 – e-Sub System • Notifies the Abbott author, and delivers the workflow back to Abbott author, or ends the workflow

32. System Architecture Alternatives • e-Sub Direct • Allow 3rd party users to access the e-Sub System directly • Would publish the e-Sub application to a Citrix host in Abbott network DMZ • Would require heavy customizations to the e-Sub (Webtop) application to ensure the proper interface is shown to external users • Extranet Application • Build a new 3rd party extranet application, complete with a separate interface and repository from the e-Sub System • Would require some type of communication mechanism between e-Sub and the new extranet application • Data consistency could become an issue with this alternative • Extranet Interface with e-Sub Repository • Build a new 3rd party extranet interface, but have it connect directly to the e-Sub docbase • Would still require minimal changes to the e-Sub System to support new interface

33. System Architecture Decision • Extranet Interface with e-Sub Repository • Decision was made to follow this architecture, because it provides all the advantages of a secure streamlined interface for third party users, while minimizing data consistency issues. • Other advantages of this architecture • Less moving parts • Makes use of existing eSub architecture • Follows an approved Abbott network security model • Strikes the best balance in terms of validation requirements • Will require the least amount of validated changes to eSub • The Extranet Interface will be a new self-contained code base and can be validated on its own, separate from eSubs

34. Internal Citrix Internal Citrix DMZ Citrix System Overview – Pilot Architecture Abbott Firewall e-Submissions Extranet Application Abbott Author External 3rd Party User Web Server & Docbase

35. Solution Screen Shots • Extranet Interface Only • Login for external users • Processing Authoring Tasks • Processing Approval Tasks

36. Logging In • Login…login again…and login one more time…

37. Inbox

38. Authoring Task View

39. Delegate

40. Checkin

41. Approval Task View

42. Approve All

43. Reject All

44. Selective Approve/Reject

45. Questions