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

1. Accept input from multiple sources and formats
   (Data Staging)
2. Import data into Documentum in a batch approach
3. Allow for configurable business rules to be
   applied to the imported batch

e-Subs Docbase
Content XML index file
Validate import
export
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
validate import
export
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 documents 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
Third Party Access - Vision
Abbott Standards, Templates, Processes
Abbott Site 1
Abbott Site 2
Publishing COE
Repository
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 CROs 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 internal Abbott e-Submissions
  application
• Initiates workflow to make document(s) available
  to external users

• Logs into the 3rd Party Extranet application
• Accesses inbox
• Selects workflow task and requests document for
  edit/acceptance/approval

• 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
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

1. Loginlogin againand 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