OpenText Documentum for LifeSciences...LegalNotice...

OpenText™ Documentum® forLife SciencesVersion 4.3

Administration Guide

Legal Notice

This documentation has been created for software version 4.3.It is also valid for subsequent software versions as long as no new document version is published.

Open Text Corporation

275 Frank Tompa Drive, Waterloo, Ontario, Canada, N2L 0A1

Tel: +1-519-888-7111Toll Free Canada/USA: 1-800-499-6544 International: +800-4996-5440Fax: +1-519-888-0677For more information, visit https://www.opentext.com

Copyright 2017 Open Text. All Rights Reserved.

Trademarks owned by Open Text.

Adobe and Adobe PDF Library are trademarks or registered trademarks of Adobe Systems Inc. inthe U.S. and other countries.

Disclaimer

No Warranties and Limitation of Liability

Every effort has been made to ensure the accuracy of the features and techniques presented in thispublication. However, Open Text Corporation and its affiliates accept no responsibility and offer nowarranty whether expressed or implied, for the accuracy of this publication.

https://www.opentext.com/

Table of Contents

Preface ................................................................................................................................ 13

Chapter 1 Life Sciences Solution Fundamentals ......................................................... 15Overview ......................................................................................................... 15Document Domains .......................................................................................... 16Roles ............................................................................................................... 18Administrators ............................................................................................. 20Document Approvers ................................................................................... 20Document Auditors ...................................................................................... 21Document Authors ....................................................................................... 22Document Contributors (LSTMF) .................................................................. 23Document Coordinators................................................................................ 24Document Quality Organization Approvers (LSQM) ...................................... 25Document Readers ....................................................................................... 25Document Reviewers .................................................................................... 26Managers (Product, Project, Trial, Study, Regulatory) ...................................... 27Controlled Printers (LSQM) .......................................................................... 28Global External Participants (LSTMF) ............................................................ 28Inspectors (LSTMF) ...................................................................................... 29Investigators (LSTMF) .................................................................................. 29Quality Check (LSTMF) ................................................................................ 29Solution-Specific User Roles .......................................................................... 29User Roles in Documentum eTMF ............................................................. 29Cross-functional User Groups ............................................................... 31Reporting Groups................................................................................. 32External Trial Participant Roles .............................................................. 32External Trial Participant Groups........................................................... 33

User Roles in Documentum Q&M.............................................................. 34Cross-functional User Groups ............................................................... 36Reporting Groups................................................................................. 37

User Roles in Documentum R&D............................................................... 37Cross-functional User Groups ............................................................... 41Reporting Groups................................................................................. 41

User Roles in Documentum SSV ................................................................ 41Correspondence User Groups................................................................ 43Cross-functional User Groups ............................................................... 44Reporting Groups................................................................................. 44

Control Categories............................................................................................ 45

Chapter 2 Customizing D2-Based Solutions ................................................................ 47Extending D2-Based Life Sciences Solutions ....................................................... 47Creating a Custom Application ..................................................................... 47Modifying or Extending a Base Configuration ................................................ 48Extending the Base Solution Contexts ............................................................ 48

Upgrading the Customized Solution .................................................................. 50Reconciling Extended Base Configurations with Solution Upgrades................. 50

3

Table of Contents

Merging D2 Configuration XML Files ............................................................ 51Best Practices for Team Development with D2 .................................................... 52Extending Roles ............................................................................................... 52Creating Custom Roles ................................................................................. 52Configuring the Property Pages ..................................................................... 52Configuring Workflows ................................................................................ 53Configuring Roles (LSQM) ............................................................................ 53

Chapter 3 Life Sciences Data Model ............................................................................ 55Data Model Overview....................................................................................... 55Add or Modify Attributes in Existing Solution Types .......................................... 57Create New Types that Extend from Existing Solution Types ............................... 58

Chapter 4 Reference Models ........................................................................................ 59Standard Solution Implementation of the DIA EDM Reference Model.................. 59Standard Solution Implementation of the DIA TMF Reference Model .................. 66Standard Solution Implementation of Quality and ManufacturingDocument Models ............................................................................................ 68Implementation of the DIA EDM Reference Model for the RegulatoryDomain (LSRD) ................................................................................................ 69Extending the Standard Reference Model Implementation (LSTMF) .................... 71Extending Dictionaries.................................................................................. 71File Plans and File Plan Templates ................................................................. 72

Implementing a Custom Reference Model (LSTMF) ............................................ 72

Chapter 5 Document Creation Profile .......................................................................... 73Management Creation Profiles .......................................................................... 73Document Creation Profiles .............................................................................. 74Control Category Definition .............................................................................. 76Default Values Template ................................................................................... 76Customizing Creation Profiles ........................................................................... 78Creating a New Creation Profile .................................................................... 78Changing Creation Profile Properties ............................................................. 79Changing Creation Properties for an Artifact within an ExistingCreation Profile ............................................................................................ 79Adding Artifacts to an Existing Creation Profile ............................................. 79Removing Artifacts from an Existing Creation Profile ..................................... 80Removing or Disabling an Existing Creation Profile ........................................ 80

File Naming and Versioning .............................................................................. 81O2 Configuration for PDF and Native Annotations ............................................. 81C2 View Configurations for PDF........................................................................ 82PDF Rendition Overview .................................................................................. 83Electronic Signatures ........................................................................................ 83Page Sizes and Overlays.................................................................................... 84Signature Page ............................................................................................. 84Overlays ...................................................................................................... 84

Chapter 6 Registration Forms ...................................................................................... 87Overview and Form Types ................................................................................ 87Creating Custom Registration Form Types ......................................................... 89

4

Table of Contents

Chapter 7 Attribute Inheritance and Cascading Attribute Rules .................................. 91Auto-Inherited Attribute Rules .......................................................................... 91Configuring Auto-Inherited Attribute Rules ....................................................... 92Configuring Cascading Attribute Rules.............................................................. 98Extended Attribute Expressions....................................................................... 104Context User Support in CDF Methods ............................................................ 109Special Naming Conventions........................................................................... 115Artifact-based Autonaming and Attribute Lists (LSTMF) .................................. 115Configuring the Existing Dictionary for Artifact-based Autonaming .............. 116

Preconfigured Cascading Attributes Rules ....................................................... 117Using a Custom Attribute Inheritance Rule to Reapply D2Configurations to Selected Objects ................................................................... 122Extensions to Cascading Attributes and Auto-Inheritance Rules toSupport Auditing ........................................................................................... 125Extensions to the CDF ApplyInheritedAttributes Method ............................. 126

Chapter 8 Workflows ................................................................................................. 129Workflow Roles .............................................................................................. 129Workflow Diagrams........................................................................................ 129For Collaborative Editing (Categories 1 - 3) .................................................. 130Submit for Review and Approval (Category 1) ............................................. 130Submit for Approval (Category 1)................................................................ 131Periodic Review (Category 1) ...................................................................... 132Withdraw Document (Category 1) ............................................................... 133Send to TBR Distribution (Category 1) ......................................................... 133Recall Document ........................................................................................ 134Submit for Review and Approval (Change Request) ..................................... 135Submit for Approval (Change Request)........................................................ 136Submit for Review and Approval (Category 2) ............................................. 136Submit for Review-Format Approval (Category 2) ........................................ 137Submit for Approval (Category 2)................................................................ 138Expiry Review (Category 2)......................................................................... 139Submit for Review (Category 3) ................................................................... 139Submit for Delegated Approval (Category 3) ................................................ 140Content Template Approval ........................................................................ 140Review Ingested Document......................................................................... 141

Configuring Workflows .................................................................................. 141Assigning Workflows to Artifacts .................................................................... 142Modifying the Task Outcome Labels ................................................................ 142Configuring Workflow Messages ..................................................................... 143Workflow and Non-Workflow Attributes ......................................................... 143

Chapter 9 Lifecycles .................................................................................................. 145Document Lifecycle ........................................................................................ 145Document Lifecycle Models ............................................................................ 148LSQM Document Lifecycle Models .............................................................. 149Control Category 0 Documents Lifecycle.................................................. 149Control Category 1 Documents Lifecycle.................................................. 149Control Category 2 Documents Lifecycle.................................................. 150Control Category 3 Documents Lifecycle.................................................. 151

LSTMF Document Lifecycle Models............................................................. 152Control Category 2 Documents Lifecycle.................................................. 152

5

Table of Contents

Control Category 3 Documents Lifecycle.................................................. 153LSRD/LSSSV Document Lifecycle Models .................................................... 154Control Category 2 Documents Lifecycle.................................................. 154Control Category 3 Documents Lifecycle.................................................. 155

Using Uniqueness Checks to Validate Transition............................................... 156Normal States and Pseudo States ..................................................................... 157Creating or Modifying a New Lifecycle Configuration ...................................... 157Custom Business Logic Using Lifecycle Actions................................................ 158

Chapter 10 Security ..................................................................................................... 159Controlled Document Foundation Security Model ............................................ 159Permissions.................................................................................................... 159Permissions in Documentum eTMF ............................................................. 160Permissions in Documentum Q&M.............................................................. 161Permissions in Documentum R&D and Documentum SSV ............................ 163

Assignment of Control Categories ................................................................... 164Role-Based Access Control .............................................................................. 166Ownership of Category 1-3 Documents............................................................ 167Folder Security ............................................................................................... 168TMF Dynamic Role-Based Access Control (LSTMF) .......................................... 168External User Registration........................................................................... 169

Granular Security for Submissions (LSSSV) ...................................................... 170Security Settings in the Regulatory Application Registration Form................. 171Security Settings in the Submission Registration Form .................................. 172Security Settings in the Regulatory Activity Package ..................................... 173Security Settings on Submission Folders....................................................... 174Security Settings on Submission Subfolders.................................................. 174Security Settings on Submission Documents................................................. 175

Chapter 11 Workspaces and Welcome Pages ............................................................. 177Workspaces .................................................................................................... 177Workspace Views and Tasks ........................................................................ 177Workspace Groups ..................................................................................... 181Workspace Views for Workspace Roles ........................................................ 189

Display Labels................................................................................................ 194Welcome Pages............................................................................................... 194

Chapter 12 Reports ...................................................................................................... 197Overview ....................................................................................................... 197Report Widgets .............................................................................................. 198Report Generation Process .............................................................................. 199Configuring External Widgets for myInsight Reports ........................................ 199Accessing the Reports ..................................................................................... 200

Chapter 13 Change Request ........................................................................................ 201Disabling Change Request for Category 1 Documents....................................... 201Configuring the Change Request Properties ..................................................... 202Configuring Release Pending as the Final State for Category 1Documents..................................................................................................... 202Binding Rules for Change Requests ................................................................. 203

6

Table of Contents

Configuring the CURRENT Binding Rule for a Change Request ........................ 204

Chapter 14 Controlled Print ......................................................................................... 207Cover Page Configuration ............................................................................... 207Overlay Configuration .................................................................................... 207Creating the Print Profile................................................................................. 210Creating the Overlay PDF Template................................................................. 210Mapping the Contexts to the Controlled Print Profiles....................................... 212Setting Up the Printers .................................................................................... 212Print Reasons ................................................................................................. 212Configuring Auto-Recall ................................................................................. 213

Chapter 15 Virtual Document Templates ..................................................................... 215Installing the Clinical Study Report VDoc Template .......................................... 215D2 Configuration for the VDoc Template ......................................................... 216VDoc Template Approval................................................................................ 217Creating a Custom VDoc Template .................................................................. 218Creating an Instance of a Clinical Study Report Assembly ................................. 220Review and Approval of VDocs....................................................................... 221Versioning of Virtual Documents ..................................................................... 222

Chapter 16 Configuration Tasks .................................................................................. 225Configuring Credential Enforcement ............................................................... 225D2 Mailing Configurations .............................................................................. 227Types of Mailing Configurations.................................................................. 227Configuring Mailing Configurations ............................................................ 229List of Task Variables .................................................................................. 229Message Configuration ............................................................................... 231Disabling Email Notifications ...................................................................... 233

Auditing Events ............................................................................................. 233Configuring Audit Events ........................................................................... 234

Configuring Automated Delegation ................................................................. 235Media Files .................................................................................................... 235Search Configuration Changes......................................................................... 235Configuring Search Criteria............................................................................. 236Configuring XML DocViewer to Display PDFs in Excel Format ......................... 236Hard Delete (LSTMF)...................................................................................... 237Bulk Import-Export (LSTMF)........................................................................... 239Lifecycle Model for Document Packages ...................................................... 240Configuring the Bulk Import-Export Spreadsheet ......................................... 240

Configuring Roles and Permissions for External Participants (LSTMF) ............... 242Defining External Trial Participant Roles ...................................................... 243Defining Permissions for External Participant Roles ...................................... 246Adding an External Participant Role Example .............................................. 247

Configuring Quality Check (LSTMF) ............................................................... 250Distributed Server Method Processing ............................................................. 251Enabling Distributed and Multi-threaded Processing .................................... 252Disabling Parallel Processing for CFD Methods ............................................ 254

7

Table of Contents

Creating a dm_method Object ..................................................................... 254Enabling the Trace Level of the D2 Core Method........................................... 255

Enabling the “Convert to virtual document” Menu Option................................ 255Updating the PDF DocInfo Parameter in D2 Dictionary..................................... 256

Chapter 17 Regulatory Submissions ........................................................................... 259Submission Overview ..................................................................................... 259Electronic Common Technical Document Submission ....................................... 261Regional XML Files for Other Agencies ........................................................ 261Additional XSL Style Sheets ........................................................................ 261

Submission History XML Files ........................................................................ 262Submission Import Progress Monitoring and Error Handling ............................ 262Supporting New eCTD XML Formats .............................................................. 263XML Schema Configuration Object Settings ................................................. 266

Processing Standard XML Files ....................................................................... 273Transforming Non-Standard XML Files............................................................ 276Previewing and Processing eCTD Module 1 Regional XML Files ....................... 279XML Metadata Extraction ............................................................................... 281Example 1: US Submission to the FDA ......................................................... 285Example 2: EU Submission to Multiple EU Countries ................................... 286Mapping XML Values to Documentum Attributes ........................................ 289Worked Example: Extending SSV to Support the US Regional 2.3eCTD Format (DTD Version 3.3) .................................................................. 290

Non-eCTD Electronic Submission .................................................................... 303Submission Filestore ....................................................................................... 303Updating the D2 URL in D2 Dictionary............................................................ 304Configuring the SSV Viewer Widget URLs ....................................................... 305Updating the XML Viewer D2 External Widgets ............................................... 313Processing of PDFs and Inter-Document Hyperlinks......................................... 314Study Tagging Files ........................................................................................ 315Previewing of Media Files ............................................................................... 316Adding Custom Format Icons ..................................................................... 317

Chapter 18 Migration and Integrity Check Utilities ..................................................... 319D2 Configuration Migration Tool..................................................................... 319Installing the D2 Configuration Migration Tool............................................. 320Configuring the D2 Configuration Migration Tool ........................................ 321

TMF Admin Integrity Checking and Repair Tool .............................................. 322Installing the TMF Admin Tool.................................................................... 323Examining Access Control Groups............................................................... 323Checking and Repairing the TMF Security Settings for External Users ............ 323Refreshing TMF Access Control Groups for Registered ExternalUsers ......................................................................................................... 326Purging and Deleting Specific Groups.......................................................... 327

Chapter 19 Life Sciences Software Development Kit ................................................... 329Overview ....................................................................................................... 329Web Services Integration ................................................................................. 329Java Client Library...................................................................................... 330

Supported Functionality in the SDK................................................................. 330

8

Table of Contents

Chapter 20 Configuration Settings to Improve Performance ....................................... 333D2 4.7 Performance Best Practices .................................................................... 333Deactivating the myInsight Agent Job .............................................................. 333Disabling RSA Security Providers for myInsight Reports .................................. 333Internet Explorer Browser Settings (LSSSV) ...................................................... 334Improving Performance of Server Methods ...................................................... 334Database Settings ........................................................................................... 335SQL Server ................................................................................................. 335Oracle ........................................................................................................ 336

Content Server Settings ................................................................................... 336Scheduled Jobs ........................................................................................... 336Server.ini File Settings................................................................................. 337JBOSS Access Log ....................................................................................... 337Java Server Method Settings ........................................................................ 337

D2 Web Server Settings ................................................................................... 337JMS Configuration ...................................................................................... 338D2 Caching ................................................................................................ 338

D2 Client Configurations ................................................................................ 338Optimizing the D2 GUI Performance ........................................................... 339Life Sciences Document Preview Widget Configuration ................................ 339

Appendix A Configuration Planning Checklist .............................................................. 341

Appendix B Troubleshooting ........................................................................................ 345Log Files ........................................................................................................ 345D2 Log Files ............................................................................................... 345Life Sciences Log Files................................................................................. 345Underlying Products Log Files .................................................................... 347Content Transformation Services ............................................................. 348xPlore ................................................................................................... 348Content Server ....................................................................................... 348Java Method Server................................................................................. 349

Third-Party Log Files .................................................................................. 349myInsight .............................................................................................. 349

Enabling Logging, Debugging, and Tracing...................................................... 349Configuring Logging for D2 ........................................................................ 349Configuring Logging for Controlled Print .................................................... 350Configuring Debugging for Custom External Widgets .................................. 350Configuring Logging for Underlying Products ............................................. 351Content Server ....................................................................................... 351Content Transformation Services ............................................................. 352xPlore .................................................................................................... 353Thumbnail Server ................................................................................... 354Java Method Server................................................................................. 354Life Sciences SDK ................................................................................... 355

Configuring Logging for Third-Party Products ............................................. 355myInsight .............................................................................................. 355ARender ................................................................................................ 355

Connection Issues........................................................................................... 355D2 Performance Issues .................................................................................... 356Submission Viewer Timeout Issue (LSSSV)....................................................... 357Exporting Large Folders Issue ......................................................................... 357

9

Table of Contents

Appendix C DIA EDM and TMF Reference Model Dictionaries ...................................... 359

Appendix D Visual Representation of Attribute Cascading in Life Sciences ................ 365

Appendix E D2 Configurations ..................................................................................... 371

10

Table of Contents

List of Figures

Figure 1. Product and Project Registration Form Attributes ................................................. 366Figure 2. Cascading of Attributes in the Clinical Domain .................................................... 366Figure 3. Cascading of Attributes in the Non-clinical Domain.............................................. 367Figure 4. Cascading of Attributes in the Regulatory Domain ............................................... 368Figure 5. Cascading of Attributes in the Safety and Quality Domain .................................... 369

11

Table of Contents

List of Tables

Table 1. Document domains .............................................................................................. 16Table 2. Top-level domain roles.......................................................................................... 19Table 3. Objects Types for which Users can Create Documents ............................................. 56Table 4. EDM reference model Quality domain dictionaries ................................................. 60Table 5. DIA EDM reference model taxonomies .................................................................. 63Table 6. TMF dictionaries .................................................................................................. 66Table 7. Taxonomy ............................................................................................................ 69Table 8. Dictionary ............................................................................................................ 69Table 9. Taxonomy ............................................................................................................ 69Table 10. Management Creation Profiles .............................................................................. 73Table 11. Required default values ........................................................................................ 77Table 12. Registration form types......................................................................................... 88Table 13. Comparisons between D2 inheritance and Auto Inherited Attribute Rules ............... 91Table 14. Extended attribute expressions ............................................................................ 104Table 15. Context User Support in CDF Methods ................................................................ 110Table 16. Workspace views and tasks ................................................................................. 177Table 17. Workspace Views for eTMF Workspace Roles....................................................... 190Table 18. Workspace View for Q&MWorkspace Roles ........................................................ 191Table 19. Workspace View for R&DWorkspace Roles ......................................................... 192Table 20. Workspace View for SSV Workspace Roles ........................................................... 193Table 21. Object Types for Configuring D2 Mailing ............................................................. 227Table 22. List of Task Variables .......................................................................................... 230Table 23. Configuring the Hard Delete feature .................................................................... 237Table 24. Lifecycle model for document packages ............................................................... 240Table 25. Configuration planning checklist ......................................................................... 341Table 26. Clinical domain dictionaries ................................................................................ 359Table 27. Non-Clinical domain dictionaries ........................................................................ 360Table 28. Quality domain dictionaries ................................................................................ 361Table 29. Regulatory-Admin domain dictionaries ............................................................... 362Table 30. TMF dictionaries ................................................................................................ 362

12

Preface

This guide contains information about administering, configuring, and extending the solutions thatare part of the OpenText™ Documentum for Life Sciences solution suite. The Life Sciences solutionsuite includes the following solutions:

• Documentum Electronic Trial Master File (known as Documentum eTMF)

• Documentum Quality and Manufacturing (known as Documentum Q&M)

• Documentum Research and Development (known as Documentum R&D)

• Documentum Submission Storage and Viewing (known as Documentum SSV)

Intended AudienceThis guide is intended for anyone responsible for configuring, extending, or administering anyproducts in the Documentum for Life Sciences solution suite. OpenText recommends completion ofthe following training prior to using this guide:

• Technical Fundamentals of Documentum

• Composer Fundamentals

• D2 Configuration

• Life Sciences Fundamentals

• Life Sciences Trial Master File (eTMF)

Information about these training courses is available on the EMC website.

Revision History

Revision Date Description

July 2017 Made a correction in Binding Rules for ChangeRequests, page 203.

13

Preface

Revision Date Description

May 2017 Made a correction in the description inDocument Coordinators, page 24.

March 2017 Initial publication.

14

Chapter 1Life Sciences Solution Fundamentals

This section provides an overview of the Documentum for Life Sciences solution.

OverviewThe Documentum for Life Sciences solution suite (Life Sciences solution suite) helps organizationsmeet compliance requirements, increase productivity, and securely collaborate across the extendedenterprise. The Life Sciences solution suite includes:

• Documentum Electronic Trial Master File (Documentum eTMF or LSTMF)

• Documentum Quality and Manufacturing (Documentum Q&M or LSQM)

• Documentum Research and Development (Documentum R&D or LSRD)

• Documentum Submission Storage and Viewing (Documentum SSV or LSSSV)

The Life Sciences solution suite is built on Documentum D2 and the Documentum platform.

Individual solutions rely on reusable components provided by two base layers:

• Unified Solution Layer (also referred to as Controlled Document Foundation)

• Life Sciences Foundation

In this architecture, the lower layers have no dependencies on the higher layers. For example, the LifeSciences Foundation components do not depend on any types, configurations, Java classes, and soforth defined in the Q&M, eTMF, or R&D solution layers. The Unified Solution Layer componentsdo not depend on any components in the Life Sciences Foundation or specific solution layers.Conversely, dependencies on lower layer components are encouraged.

D2 configurations are assigned to one of the following applications corresponding to the layeredarchitecture:

• Documentum Q&M solution

• Documentum eTMF solution

• Documentum R&D solution

• Documentum SSV solution

15

Life Sciences Solution Fundamentals

Document DomainsDocumentum Life Sciences solutions provide extensive inventory to manage documents relevantfor each functional area within Life Sciences organizations. Documents stored and managed byDocumentum Life Sciences solutions are categorized according to the functional area in whichthey are used. This top-level categorization is called the document domain. Every document isautomatically assigned a domain when it is created. The domain assignment at document creationor import time is accomplished using a D2 Default Values template configuration associated withthe creation profile of the document.

The standard domains provided with each solution mirror those defined by the DIA ElectronicDocument Model (EDM) reference model. The DIA EDM reference model is patterned after theElectronic Common Technical Document (eCTD) standard. The DIA website provides moreinformation about the DIA EDM reference model.

In Documentum R&D, domains and inventory are based on DIA EDM Reference Model withextensions where appropriate. The DIA EDM reference model defines the following domains:

• Clinical

• Labeling

• Non-Clinical

• Quality

• Regulatory/Administrative

These same domains are defined in the solution with additional inventory to manage Safety-PVG,Promotional Materials, and Medical Device documents.

Documentum Q&M provides an inventory mapped to the DIA EDM QM Reference Model withextensions where appropriate. In addition to standard documents, the solution includes domains tomanage Design History File and Device Master Record components.

The following document domains are provided in the respective Document Life Sciences solutions:

Table 1. Document domains

Solution Domain Name Description

Documentum eTMF Clinical TMF Includes documents that are included within aTrial Master File and corresponds to the DIA TMFreference model.

Clinical Corresponds to the DIA EDM reference modelClinical domain.

Non-clinical Corresponds to the DIA EDM reference modelNon-Clinical domain.

Quality Corresponds to the DIA EDM reference modelQuality domain.

Safety Include documents that provide safety informationfor a drug.

Documentum R&D

16


Solution Domain Name Description

Labeling Include documents that provide labeling informationfor a drug.

PromotionalMaterials (AdPromo)

Include documents that provide marketing and salesinformation for a drug.

Medical Devices Include documents for a medical device within theClinical, Non-clinical, and Regulatory domains.

Regulatory/Administrative

Corresponds to the DIA EDM reference modelRegulatory/Administrative domain.

General Includes uncontrolled documents such as letters,memos, and notes.

RegulatorySubmissions

Includes documents that form a part of the electronicand paper submissions to a health authority for aregulatory application. Corresponds to the DIA EDMreference model Regulatory/Administrative domain.

Documentum SSV

RegulatoryCorrespondence

Includes any form of correspondence exchangedbetween the pharmaceutical companies and theregulatory agencies for a particular submission.

GoodManufacturingPractices (GMP)

Includes controlled documents relating toorganizational directives, policies, standardoperating procedures (SOPs), production ofmarketed products in a GMP environment includingmethods, specifications, and master batch records,certificates, records, and drawings related to adrug manufacturing or packaging facility. Includesdocuments relevant to the packaging and labelingof drug product. Includes documents used inthe validation of products, substances, materials,systems, and equipment. Includes guides, manuals,reference documents, and training materials.Includes project deliverables such as requirements,planning, design, risk assessments, and reports.

Documentum Q&M

GMP MedicalDevices

Includes medical devices deliverables such as Bill OfMaterial, Labeling, DMR Specifications, Drawings,DMR, Production Document, Customer Documents,Service Documents, Software Release, Protocols,Reports, Requirements, Reviews, Plans, Checklists,DHF Specifications, Matrix, Risk Documentation andDHF.

New document domains can be created to extend the solution to support additional kinds ofdocuments. Creating a new domain requires adding an additional Documentum object type and a setof D2 configurations to support the creation of documents of that type.

Note: Documentum Q&M documents all belong to the domain, GMP. However, this domain isfurther subdivided into categories as noted in parentheses in Table 1, page 16.

17


RolesA role is a type of group that contains users or other groups that are assigned a specific role. Rolesprovide a means of defining groups that have a particular function within a system. For example,pharmaceutical companies manage their huge set of documentation by the assignment of roles suchas authors, reviewers, approvers, managers, and so on. Each role can have one or more peopledesignated to perform the activity.

Predefined roles (user and workspace roles) are installed with the Life Sciences solutions.Administrators must add users or groups to the applicable predefined roles and ensure each user hasan assigned D2 workspace and appropriate access to documents and functions. For more informationabout workspace roles, see Workspace Groups, page 181.

A set of roles are provided for each of the following domains:

• Clinical

• Non-Clinical

• Quality

• Regulatory/Administration

• Safety

• Labeling

• Promotional Materials (Ad Promo)

• Correspondence

• GMP

• Medical Devices

In addition, the Documentum Q&M (GMP) solution roles are assigned by Applicable Sites. ApplicableSites are defined in a dictionary and can be determined by physical manufacturing location and/orbusiness groups. The Configuring Roles (LSQM), page 53 section provides the steps to configuresite-based roles.

All roles are installed for all solutions. However, some roles are typically used only in a particularsolution. The naming convention used for the group name for each role in the Documentum R&Dsolution is cd_<domain>_doc_<role>. For example, the group name for the Author role in the Clinicaldomain is cd_clinical__doc_author.

The naming convention used for the group name for each role in the Documentum Q&M solution iscd_<applicable_site>_<role>. For example, the group name for the Document Coordinator role for theBoston site is cd_boston_coordinators.

Some roles have default members. For example Document Coordinators are members of theDocument Authors role. A top-level role for each domain is also installed. All domain roles are mademembers of the top-level domain role as shown in the following table.

18


Table 2. Top-level domain roles

Role Group Name Contains

cd_ad_promo Users of Promotional Materials documents. Users in this role canaccess the Promotional Materials domain documents and at least haveREAD permission on the documents.

cd_clinical Users of Clinical documents. Users are able to access the Clinicaldomain documents and at least have READ permission on the same.

cd_corres Users of Correspondence documents. Users in this role are able toaccess the correspondence domain documents and at least haveREAD permission on the documents.

cd_gmp_all_users Users of GMP documents.

cd_labeling Users of Labeling documents. Users in this role are able to accessthe Labeling domain documents and at least have READ permissionon the documents.

cd_md_users Users of Medical Devices documents. Users in this role can accessthe Medical Devices domain documents and at least have READpermission on the documents.

cd_md_clinical Users of Clinical documents for medical devices. Users are ableto access the Clinical domain documents and at least have READpermission on the same.

cd_md_regulatory Users of Regulatory documents for medical devices. Users in this roleare able to access the Regulatory domain documents and at least haveREAD permission on the documents.

cd_md_regulatory_users Users of Regulatory documents for medical devices. This is asubgroup within the cd_md_regulatory group. Users in this role areable to access the Regulatory domain documents and at least haveREAD permission on the documents.

cd_md_submission_users Users of Submission documents for medical devices This is asubgroup within the cd_md_regulatory group. Users in this role areable to access the Regulatory Submission documents and at least haveREAD permission on the documents.

cd_non_clinical Users of Non-clinical documents. Users are able to access theNon-clinical domain documents and at least have READ permissionon the documents.

cd_quality Users of Quality documents. Users in this role are able to access theQuality domain documents and at least have READ permission onthe documents.

cd_regulatory User of Regulatory documents. Users in this role are able to access theRegulatory domain documents and at least have READ permissionon the documents.

cd_safety Users of Safety documents. Users in this role are able to access theSafety domain documents and at least have READ permission onthe documents.

19


The predefined roles are described in the following sections.

Administrators

Administrators have the ability to modify most D2 dictionaries and taxonomies as well as otherconfiguration objects, including Auto Inheritance Config and Delete Config objects.

Group name cd_admingroup

Contains members <none>

Is a member of <none>

Document Approvers

Document Approvers are responsible for approving controlled documents. They perform the ForApproval task in a controlled document workflow.

Group name cd_ad_promo_doc_approvers

cd_ad_promo_template_approvers

cd_clinical_doc_approvers

cd_clinical_template_approvers

cd_corres_doc_approvers

cd_corres_template_approvers

cd_general_doc_approvers

cd_general_template_approvers

cd_global_approvers

cd_gmp_approvers

cd_gmp_template_approvers

cd_labeling_doc_approvers

cd_labeling_template_approvers

cd_md_clinical_doc_approvers

cd_md_doc_approvers

cd_md_non_clinical_doc_approvers

cd_md_regulatory_doc_approvers

20


cd_med_device_template_approvers

cd_non_clinical_doc_approvers

cd_non_clinical_tem_approvers

cd_quality_doc_approvers

cd_quality_template_approvers

cd_regulatory_doc_approvers

cd_regulatory_template_approvers

cd_safety_doc_approvers

cd_safety_template_approvers

Contains members cd_admingroup

Is a member of cd_<domain> (Documentum R&D, Documentum eTMF,Documentum SSV)

cd_gmp_all_users (Documentum Q&M)

Document Auditors

Document Auditors inspect the state of documents in their respective domain for audit-readiness.Document Auditors have read-only access to Effective/Final/Released, Superseded, and Expireddocuments and no access to documents in other states.

Group name cd_ad_promo_doc_auditors

cd_clinical_doc_auditors

cd_corres_doc_auditors

cd_general_doc_auditors

cd_global_auditors

cd_gmp_auditors

cd_labeling_doc_auditors

cd_md_clinical_doc_auditors

cd_md_doc_auditors

cd_md_non_clinical_doc_auditors

cd_md_regulatory_doc_auditors

21


cd_non_clinical_doc_auditors

cd_quality_doc_auditors

cd_regulatory_doc_auditors

cd_safety_doc_auditors




Document Authors

Document Authors create documents and submit them for collaborative editing, review, andapproval. They can self-approve documents that do not require formal review and approval.

Group name cd_ad_promo_doc_authors

cd_ad_promo_template_authors

cd_clinical_doc_authors

cd_clinical_doc_authors_tmf

cd_clinical_template_authors

cd_corres_doc_authors

cd_corres_template_authors

cd_general_doc_authors

cd_general_template_authors

cd_global_authors

cd_gmp_authors

cd_gmp_template_authors

cd_labeling_doc_authors

cd_labeling_template_authors

cd_md_clinical_doc_authors

cd_md_doc_authors

cd_md_non_clinical_doc_authors

22


cd_md_regulatory_doc_authors

cd_med_device_template_authors

cd_non_clinical_doc_authors

cd_non_clinical_template_authors

cd_quality_doc_authors

cd_quality_template_authors

cd_regulatory_doc_authors

cd_regulatory_template_authors

cd_safety_doc_authors

cd_safety_template_authors

Contains members cd_<domain>_doc_coordinators

cd_admingroup

cd_regulatory_managers

cd_regulatory_publisher


cd_general_doc_authors (Documentum R&D,Documentum eTMF)


Note: The cd_general_doc_authors role is not a member of any Document Coordinators role becausethere is no corresponding Document Coordinators role for the General domain.

All domain Authors roles except the cd_general_doc_authors role, are members of thecd_general_doc_authors role. This enables authors in all roles the ability to create Generaldocuments. Documentum Q&M does not use the cd_general_doc_authors role.

Document Contributors (LSTMF)

Document Contributors upload files that originated outside of the Documentum repository to a TrialMaster File (TMF) within a Documentum repository.

23


Group name cd_clinical_doc_contributors

tmf_contributors

tmf_external_contributors

Contains members tmf_external_contributors

tmf_external_reviewers

tmf_investigators

tmf_inspectors

Is a member of cd_clinical

Document Coordinators

Document Coordinators manage the release of controlled documents. They can also create documentsand submit them for collaborative editing, review, and approval. Document Coordinators monitorthe progress of document workflow tasks. They can change workflow task performers.

Group name cd_ad_promo_doc_coordinators

cd_clinical_doc_coordinators

cd_corres_doc_coordinators

cd_general_doc_coordinators

cd_global_coordinators

cd_gmp_coordinators

cd_labeling_doc_coordinators

cd_md_clinical_doc_coordinators

cd_md_doc_coordinators

cd_md_non_clinical_doc_coordinators

cd_md_regulatory_doc_coordinators

cd_non_clinical_doc_coordinators

cd_quality_doc_coordinators

cd_regulatory_doc_coordinators

24


cd_safety_doc_coordinators


cd_non_clinical_study_managers

cd_product_managers



cd_<domain>_authors (Documentum R&D, DocumentumeTMF)


Document Quality Organization Approvers (LSQM)

Quality Organization (QO) Approvers perform the second-level of approval for controlled documentsthat require two-levels of approval.

Group name cd_global_qo_approvers

cd_gmp_qo_approvers


Is a member of cd_gmp_all_users (Documentum Q&M)

Document Readers

Document Readers have read-only access to Effective versions of documents. They browse for,search, and read documents.

Group name cd_ad_promo_doc_readers

cd_clinical_doc_readers

cd_corres_doc_readers

cd_general_doc_readers

cd_global_readers

cd_gmp_readers

cd_labeling_doc_readers

25


cd_md_clinical_doc_readers

cd_md_doc_readers

cd_md_non_clinical_doc_readers

cd_md_regulatory_doc_readers

cd_non_clinical_doc_readers

cd_quality_doc_readers

cd_regulatory_doc_readers

cd_safety_doc_readers






Document Reviewers

Document Reviewers review documents and edit documents using annotations. They are responsiblefor technical reviews during the authoring and review cycle. Reviewers complete workflow tasks andcan browse and search for documents.

Group name cd_ad_promo_doc_reviewers

cd_clinical_doc_reviewers

cd_corres_doc_reviewers

cd_format_reviewers

cd_general_doc_reviewers

cd_global_reviewers

cd_gmp_reviewers

cd_labeling_doc_reviewers

cd_md_clinical_doc_reviewers

cd_md_doc_reviewers

26


cd_md_non_clinical_doc_reviewers

cd_md_regulatory_doc_reviewers

cd_non_clinical_doc_reviewers

cd_quality_doc_reviewers

cd_regulatory_doc_reviewers

cd_safety_doc_reviewers






Managers (Product, Project, Trial, Study, Regulatory)

Managers manage the documentation for their respective domains. They create and manage theregistration forms that users use to import and create documents. They also monitor documentprogress. Product Managers are responsible for all documents across the regulatory applications,non-clinical studies, clinical trials, and quality projects associated with particular products. Theycreate and manage Product Registration Forms.

Group name cd_ad_promo_managers

cd_clinical_trial_managers

cd_clinical_trial_managers_tmf

cd_corres_managers

cd_labeling_managers

cd_md_managers


cd_product_managers

cd_quality_project_managers

cd_regulatory_activity_managers


27


cd_safety_project_managers


cd_product_registration_group

cd_project_registration_group

Is a member of cd_<domain>

cd_<domain>_doc_coordinators

Note: Because the cd_product_managers role spans multiple domains, this role is a member of thefollowing roles:• cd_clinical_doc_coordinators

• cd_non_clinical_doc_coordinators

• cd_quality_doc_coordinators

• cd_regulatory_doc_coordinators

Controlled Printers (LSQM)

The Controlled Printers group is responsible for printing controlled documents. Users in thisgroup will be able to use the Print, Reprint, Recall, and Print Reporting features of the ControlledPrint widget.

Group name cd_controlled_print

cd_controlled_print_recall


cd_gmp_coordinators

Is a member of <none>

Global External Participants (LSTMF)

The Global External Participants group includes external participants in a clinical study who at leasthave READ access to the document.

Group name tmf_global_external_participants


Is a member of cd_<domain> (Documentum eTMF)

28


Inspectors (LSTMF)

Document Inspectors are the users who can inspect the TMF documents uploaded to a placeholderto which they have access.

Group name tmf_inspectors



Investigators (LSTMF)

TMF Investigators are the users who can import the TMF document for a placeholder of a particularsite, country, or trial but cannot make it Effective/Approved/Final.

Group name tmf_investigators



Quality Check (LSTMF)

TMF Quality Check are the users who performs a quality check on an indexed TMF document for aplaceholder of a particular product, site, country, or trial before making it Final.

Group name cd_clinical_qc_tmf

Contains members cd_clinical_qc_technical

cd_clinical_qc_business


Solution-Specific User Roles

This section lists the defined user roles for each Life Sciences solution.

User Roles in Documentum eTMF

Documentum eTMF provides defined user roles that enable or restrict user access to documents andinformation in the system. The following table describes the user roles:

29


User Role Groups Description

Managers cd_product_managers


Create and manage registration forms foreach domain. For example, the ClinicalTrial Managers create clinical trial, country,and site registration forms. Clinical TrialManagers also set up and maintain the fileplan for a trial.

Contributors cd_clinical_doc_contributors

tmf_contributors

Import and index Trial Master File (TMF)documents. TMF Contributors are able toperform inspection, review, and import ofTMF documents for placeholders to whichthey have access.

Authors cd_clinical_doc_authors



Create documents and submit them forcollaborative editing and review. Authorscan also import documents like theContributors. Authors can self-approvemost TMF documents. Template Authorscreate and manage clinical templatedocuments.

Users in the cd_clinical_doc_authors_tmfgroup can import Clinical files to therepository but do not author newdocuments. For example external TMFInvestigators and external Authors belongin this role.

DocumentCoordinators

cd_clinical_doc_coordinators Manage the publication of controlleddocuments.

Authors can act as Document Coordinatorson most TMF documents.

Reviewers cd_clinical_doc_reviewers

cd_format_reviewers

Review documents using annotations andedit documents.

Approvers cd_clinical_doc_approvers


Responsible for approving controlleddocuments. Template approvers approveclinical template documents.

Auditors cd_clinical_doc_auditors Have read-only access to audit logs as wellas Effective/Approved/Final, Superseded,and Expired documents.

Readers cd_clinical_doc_readers Have read-only access to Effective/Approved/Final versions and areconsidered general consumers.

30



Investigator* tmf_investigators Clinical investigators who administer thedrug or therapy to subjects (patients orvolunteers) and record clinical data oneach subject. Investigators typically act ascontributors to the TMF.

Inspector* tmf_inspectors Health authority or regulatory agencyrepresentatives who may audit a clinicaltrial. Inspectors are typically givenread-access to Effective/Approved/Finaldocuments in the TMF.

Quality Check cd_clinical_qc_technical

cd_clinical_qc_business

Inspects the indexed documents for qualitybefore making them Final.

ExternalContributor*

tmf_external_contributors Produces documents or imports eTMFdocuments. For example, a member of aContract Research Organization.

External Reviewer* tmf_external_reviewers Peer reviews or participates in collaboratingon documents. For example, an expert inthe relevant field of medicine.

Administrator cd_admingroup Accesses administrative functions but doesnot have access to controlled documents.

*These roles are external participants. They can receive access to documents associated with a countryor site. The use of the term external does not require the user to be a contractor or otherwise externalto the system. It means that they do not have global access to all documents in the system and onlyhave access to what managers specifically grant to them. Managers can grant the access for a limitedtime. External Trial Participant Roles, page 32 provides more information.

Cross-functional User Groups

The following table describes the cross-functional user groups:

Groups Description

cd_admingroup Administrator:• Access to administrative functions

• Require Administrative client capability

• Do not have access to controlled documents

cd_product_managers Product managers who create ProductRegistration Forms.

cd_general_doc_authors Users in the role can create general documents(letters, memos, notes). By default, allother authors groups are members of thecd_general_doc_authors role.

31


Reporting Groups

Documentum eTMF provides an optional reporting feature for monitoring active clinical trials basedon AMPLEXOR myInsight for Documentum (myInsight). The reports can be customized usingmyInsight.

In Documentum D2, users view dashboards containing report information. The following tabledescribes the reporting groups used by the Report Generator:

Groups Description

report_user Report Users can generate reports and viewhistorical data in the form of saved reports.

report_builder Report Builders can manage report definitionsand presentations.

report_administrator Report Administrators can define categories andscheduling of reports.

External Trial Participant Roles

Documentum eTMF enables you to add a named user to participate as a particular role withinthe eTMF system. These users, known as external participants, can receive access to countries orsites. External participants only have access to the documents associated with the entity granted.Administrators specify document access levels when configuring the user roles. External trialparticipants require a Documentum user account (dm_user) for system access.

Note: The use of the term external does not require the user to be a contractor or otherwise external tothe system. It means that they do not have global access to all documents in the system and only haveaccess to what managers specifically grant to them.

Managers can register external participants for countries and sites to grant access for the specifiedentities. They register the external participants by adding them to the relevant site or countryregistration forms. By default, users who have Write access to the registration form can add externaltrial participants. The Access Control tab of a registration form defines the users who can update theform. For example, a clinical trial manager or a local site administrator delegated to act in this rolecan add external participants to registration forms. These participants receive the access specified inthe registration form.

The following table describes the default external participant roles:

Role Description

Investigator A clinical investigator responsible foradministering the drug or therapy to subjects(patients or volunteers) and recording clinicaldata on each subject.

Inspector A representative of the health authority orregulatory agency responsible for ensuring thatgood clinical practice is followed during theconduct of the trial.

32


Role Description

External Contributor A producer of specific documents or a personwho can typically import eTMF documents.For example, a member of a Contract ResearchOrganization.

External Reviewer A peer reviewer or participant of specificdocuments. For example, an expert in therelevant field of medicine.

External Trial Participant Groups

The system creates user groups for providing document access to external trial participants. Thefollowing table describes the external trial participant user groups:

Groups Description

tmf_global_external_participants Provides access rights common to all externalparticipants. This group is a Trial Master File(tmf) group.

tmf_contributors Provides read-only and browse access to thetop-level Clinical cabinet and product folders.All clinical trial participants belong to this groupindirectly.

tmf_external_contributors Assigns a workspace to the ExternalContributors.

tmf_external_reviewers Assigns a workspace to the External Reviewers.

tmf_inspectors Assigns a workspace to the Inspectors.

tmf_investigators Assigns a workspace to the Investigators.

pg_<product-code>

(Product group)

Provides Read access to the product-levelfolders.

tg_<trial-ID>

(Trial group)

Provides Read access to the top-level TMF folderfor the trial.

cg_<trial-ID>_<country-code>

(Country group)

Provides Read access to the top-level countryfolder for the trial.

sg_<site-ID>

(Site group)

Provides Read access to the top-level site folderfor the trial.

Each external trial participant user group is further divided into subgroups for roles with thefollowing suffixes:

• Investigator: _inv

• Inspector: _insp

33


• External Contributor: _contrib

• External Reviewer: _rev

For example, for Product XYZ, Trial 1234, Country IRL, and Site dublin, the system creates thefollowing groups and subgroups:

• pg_XYZ

— pg_XYZ_inv

— pg_XYZ_insp

— pg_XYZ_contrib

— pg_XYZ_rev

• tg_1234

— tg_1234_inv

— tg_1234_insp

— tg_1234_contrib

— tg_1234_rev

• cg_1234_IRL

— cg_1234_IRL_inv

— cg_1234_IRL_insp

— cg_1234_IRL_contrib

— tcg_1234_IRL_rev

• sg_dublin

— sg_dublin_inv

— sg_dublin_insp

— sg_dublin_contrib

— sg_dublin_rev

Note: You should not directly add users to these groups. The system automatically populates thesegroups when you selectManage External Participants.

User Roles in Documentum Q&M

Documentum Q&M provides defined user roles that enable or restrict user access to documents andinformation in the system. The following table describes the user roles:


Administrators cd_admingroup Access administrative functions but do nothave access to controlled documents.

34



Approvers cd_<applicable site>_approvers

cd_gmp_template_approvers

cd_med_device_template_approvers

Approve controlled documents (ControlCategory 1 and 2). Some documentsrequire electronic signatures. Templateapprovers approve template documents.

Auditors cd_<applicable site>_auditors Have read-only access to audit logs,Effective/Approved/Final, Superseded,and Expired documents. They can viewdocument content, history, and properties.

They must have a minimum extendedprivilege of View Audit.

Authors cd_<applicable site>_authors

cd_gmp_template_authors

cd_med_device_template_authors

Create documents and submit them forcollaborative editing, review, and approval.• Control Categories 1 and 2: Authorscannot be an Approver.

• Control Category 3: Authors canapprove documents and act asDocument Coordinators.

Template authors create and managetemplate documents.


cd_<applicable site>_coordinators Manage the release of controlleddocuments.• Control Category 1: Schedules releasedates. Verifies that all members of theTo Be Read (TBR) Distribution List havesigned off on a document or rejected thetask in the Send to TBR distributionworkflow before the document becomesEffective/Approved/Final.

• Control Categories 1 and 2:Releases documents to anEffective/Approved/Final state andcontrols the long-term management ofthe document. Can submit a documentto a workflow.

• Control Category 3: Authors can act asDocument Coordinators.

QualityOrganizationApprovers

cd_<applicable site>_qo_approvers

Responsible for final approval of ControlCategory 1 documents.

35



Readers cd_<applicable site>_readers General consumers with read-only accessto Effective/Approved/Final versions.

(Optional) Recipients on the To be Read(TBR) Distribution List receive notificationwhen a Control Category 1 documentis scheduled to become Effective. Theyconfirm that they have read the document.

When a Reader requests a printablePDF, the system adds them to the TBRDistribution List. Typically, PDFs aresecure and do not allow local printing,editing, or annotation.

Reviewers cd_<applicable site>_reviewers Review documents using annotations andedit documents. They are responsible fortechnical review during the authoring andreview cycle.

Device Managers cd_md_managers

cd_md_regulatory_mgrs

cd_md_submission_mgrs

Create and manage Medical DeviceRegistration Forms, Medical DeviceRegulatory Application RegistrationForms, and Medical Device SubmissionRegistration Forms.



Groups Description




cd_c2_printers Users in this group have access to the right-clickprint menu used for uncontrolled copies withC2 watermarks/overlays.

cd_controlled_print Users in this group can use the Print, Reprint,and Print Reporting features of the ControlledPrint widget.

cd_controlled_print_recall User in this group can use the Recall and PrintReporting features of the Controlled Printwidget.

36


Reporting Groups

Documentum Q&M provides an optional reporting feature for monitoring active clinical trials basedon myInsight. See Reporting Groups, page 32 for the reporting groups used by the Report Generator.

User Roles in Documentum R&D

Documentum R&D provides defined user roles that enable or restrict user access to documents andinformation in the system. The following table describes the user roles:


Approvers cd_ad_promo_doc_approvers




cd_md_doc_approvers







cd_<domain>_template_approvers

Approve controlled documents. Somedocuments require electronic signatures.Template approvers approve templatedocuments.

Auditors cd_ad_promo_doc_auditors



cd_md_clinical_doc_auditors

cd_md_doc_auditors


Have read-only access to audit logs,Approved, and Superseded documents.They can view document content, history,and properties.

They must have a minimum extendedprivilege of View Audit.

37



cd_md_regulatory_doc_auditors





Authors cd_ad_promo_doc_authors





cd_md_doc_authors







cd_<domain>_template_authors

Create documents and submit them forcollaborative editing, review, and approval.• Control Categories 2: Authors cannot bean Approver.

• Control Category 3: Authors canapprove documents and act asDocument Coordinators.

Template authors create and managetemplate documents for that domain.


cd_ad_promo_doc_coordinators

cd_clinical_doc_coordinator





Manage the release of controlleddocuments.• Control Category 2: Approvers can actas Document Coordinators.


38




cd_non_clinical_doc_coordinator

cd_quality_doc_coordinator

cd_regulatory_doc_coordinator

cd_safety_doc_coordinator

Product Managers cd_product_managers Create and manage Product RegistrationForms. Responsible for all documentsacross the studies, clinical trials, andprojects associated with particularproducts.

Device Managers cd_md_managers Create and manage Medical DeviceRegistration Forms. Responsible for alldocuments across the medical deviceclinical trials and regulatory documentsassociated with particular medical device.

Regulatory,Clinical Trial,Non-clinicalStudy, QualityProject, Labeling,Safety Project,PromotionalMaterialsManagers

cd_ad_promo_managers



cd_md_clinical_trial_mgrs








Create and manage registration forms foreach domain. For example, Quality ProjectManagers create Project RegistrationForms.

Responsible for related documents.

39



Readers cd_ad_promo_doc_readers




cd_md_doc_readers







General consumers with read-only accessto Approved versions.

Reviewers cd_ad_promo_doc_reviewers


cd_format_reviewers



cd_md_doc_reviewers







Review documents using annotations andedit documents. They are responsible fortechnical review during the authoring andreview cycle.

40



SubmissionArchivist

cd_submission_archivists Imports submissions.

Note: Although this role is presentin LSRD, it does not play any vitalfunction as it is only required for importingsubmission against a regulatory applicationregistration form, which is available inLSSSV only.

Administrators cd_admingroup Access administrative functions but do nothave access to controlled documents.



Groups Description




cd_product_managers Product managers who create and manageProduct Registration Forms.



Regulatory Managers who can register productsand projects.

cd_general_doc_authors Users in the role can create general documents(letters, memos, notes). By default, allother authors groups are members of thecd_general_doc_authors role.

Reporting Groups

Documentum R&D provides an optional reporting feature for monitoring active clinical trials basedon myInsight. See Reporting Groups, page 32 for the reporting groups used by the Report Generator.

User Roles in Documentum SSV

Documentum SSV provides defined user roles that enable or restrict user access to documents andinformation in the system. The following table describes the user roles:

41


User Role Group Description

RegulatoryManager

cd_regulatory_managers Create and manage regulatory applicationregistration forms.

Create product and project registrationforms.

Handles regulatory documents.

Imports correspondence documents andmanages the lifecycle transitions of thesedocuments.

RegulatoryActivity Managers


Users who can act as Managers of allapplications/submissions by default.

RegulatoryActivity Monitors

cd_regulatory_activity_monitors

Users who can act as Readers of allapplications/submissions by default.

RegulatoryAuthors

cd_regulatory_doc_authors Creates correspondence documents andmanages the lifecycle transitions of thesedocuments.

Creates and monitors documentworkflows.

SubmissionArchivist

cd_submission_archivists Imports submissions for a regulatoryapplication registration form.Submission archivists containscd_regulatory_doc_readers.

Reader cd_regulatory_doc_readers Have read-only access to submissionand correspondence documents based ontheir permissions set by the regulatoryapplication registration forms.

Auditor cd_regulatory_doc_auditors Have read-only access to audit logs,Approved, and Superseded documents.

Reviewer cd_format_reviewers


Review documents using annotations andedit documents.

Approver cd_regulatory_doc_approvers Approve controlled documents.

DocumentCoordinator


Manage the release of controlleddocuments.

Device Managers cd_md_managers



Create and manage Medical DeviceRegistration Forms, Medical DeviceRegulatory Application RegistrationForms, and Medical Device SubmissionRegistration Forms.

42


Correspondence User Groups

Use the correspondence user groups for correspondence documents. The following table describesthe correspondence user groups:

Groups Description

cd_corres Users of Correspondence documents. Users inthis role are able to access the Correspondencedomain documents and have at least READpermission on the documents.

cd_corres_doc_approvers Correspondence document approvers approvecontrolled documents. Some documents requireelectronic signatures.

cd_corres_doc_auditors Correspondence document auditors haveread-only access to audit logs, Approved,and Superseded documents. They can viewdocument content, history, and properties.

cd_corres_doc_authors Correspondence document authors create andedit Correspondence documents in the Draftstate.

• Control Categories 2: Authors cannot be anApprover.

• Control Category 3: Authors canapprove documents and act as DocumentCoordinators.

cd_corres_doc_coordinators Correspondence document coordinatorsmanage the release of controlled documents.

• Control Category 2: Approvers can act asDocument Coordinators.


cd_corres_doc_readers Correspondence document readers haveread-only access to Approved versions.


cd_format_reviewers

Correspondence document reviewers reviewdocuments using annotations and editdocuments. They are responsible for technicalreview during the authoring and review cycle.

cd_corres_managers Correspondence project managers createand manage registration forms for theCorrespondence domain.

43


Groups Description

cd_corres_template_authors Correspondence template document authorscreate and manage template Correspondencedocuments.

cd_corres_template_approvers Correspondence template document approversapprove template documents.



Groups Description




cd_regulatory Users of regulatory and administrativedocuments.

cd_product_managers Product managers who create and manageProduct Registration Forms.

cd_quality_project_managers Quality and manufacturing project managerswho create Project Registration forms



Regulatory Managers who can register productsand projects.

Reporting Groups

Documentum SSV provides an optional reporting feature for monitoring active clinical trials basedon myInsight. See Reporting Groups, page 32 for the reporting groups used by the Report Generator.

44


Control CategoriesThe term control category refers to the level of regulation that should be applied to a document. Thecontrol category for each artifact is defined in the creation profile through the assigned DefaultValues template and lifecycle.

The control category for a document is stored in the Category attribute. It is an integer value of either1, 2, 3, or 4. The value of the Category attribute determines the lifecycles and workflows that areapplied to a document. Documentum Life Sciences solutions provide four control categories.

The common security features for all control categories:• Allow joint and collaborative authoring in Documentum D2.

• Restrict access to content based on user role and lifecycle state.

• Allow complete withdrawal of the document with optional retention of historic copies.

The following table describes the security of the document control categories:

Control Categories Security Description

Category 1 Controlled documents that require formalreview and approval along with signoff by theQuality Organization (QO). These documentsbecome Effective/Approved/Final and may besent on TBR and periodic review workflows.

The workflow process includes:• Independent two person review and approvalbefore release.

• Approval with electronic signatures forspecific document types.

• Additional approval by the QualityOrganization department before release.

• Controlled release by DocumentCoordinators.

• Controlled release that can be deferred until aspecified effective date.

• Effective/Approved/Final versions thatautomatically rescind on expiration.

• Effective/Approved/Final versions that can besuspended and reinstated on demand.

• Effective/Approved/Final versions that can besuperseded when the next version becomeseffective.

• Expiration notifications.

45


Control Categories Security Description

Category 2 Controlled documents that require formalreview and approval. They do not requiresignoff by the Quality Organization.

The workflow process includes:• Independent two person review and approvalbefore release.

• Approval with electronic signatures forspecific document types.

• Documents that become effectiveimmediately.

• Effective/Approved/Final versions that can besuspended and reinstated on demand.

• Effective/Approved/Final versions that can besuperseded when the next version becomeseffective.

Category 3 Controlled documents that can be self-approvedby Authors. Independent review and approvalis not required. This category is typicallyassigned to documents that are created and/orapproved outside of the system.

The workflow process:• Enables self-approval by Authors.

• Makes the previously Effective/Approved/Final version superseded when the nextversion becomes Effective/Approved/Final.

• Allows the Effective/Approved/Final versionto be suspended and reinstated on demand.

Category 4 Non-controlled general documents that donot require formal review or approval. Thesedocuments are not allowed in regulatorysubmissions. Authors manage access to thesedocuments.

46

Chapter 2Customizing D2-Based Solutions

The Life Sciences solutions are configured in D2 Config. The configurations are based on life scienceindustry best practices and stored in a set of Documentum D2 applications. Topics in this chapterdescribe configurable features and tasks for experienced Documentum and Documentum D2administrators to perform to meet their business requirements. To generate a document listing thedefault configurations, select Specifications > Generate specifications from D2 Config.

Some administrative functions are available in the D2 Client.

The Documentum D2 Administration Guide provides more information. The Appendix E, D2Configurations section provides the list of D2 configurations that must not be renamed or removed.

Extending D2-Based Life Sciences SolutionsYou can use all of the configuration capabilities of Documentum Content Server and D2 when youdeploy the Documentum Life Sciences solution. It is important to note that future upgrades can becomplicated by extensive changes to the D2 configurations of the base Life Sciences solution.

This section describes procedures and best practices for extending D2-based Life Sciences solutionsin a manner that will enable you to upgrade to a new version of a solution in the future and thenreapply your specific extensions and modifications.

Extending the Life Sciences solution involves the following key activities:

1. Creating a custom application

2. Modifying the base configuration

3. Extending the base solution context

Creating a Custom Application

All configuration items that are either part of the base solution but modified by the customer or newlyadded by the customer must be assigned a custom application. The first step when extending anexisting solution is to define the custom application:1. In D2-Config, select Tools > Applications.

2. Click New.

47

Customizing D2-Based Solutions

In the example below, the new application is named, KB Pharma. All of the configurations that areeither modified or added by the customer will be assigned this application. Existing applicationsdefined by the base solution should be left in the Applications list for base solution configurations aswell.

Assignment of a custom application enables you to easily identify your custom configurations andpackage them for deployment and backup.

Modifying or Extending a Base Configuration

For each customization, you must decide whether:

• To change the base solution configuration or,

• Use the base configuration as a template for creating a new configuration.

You can use the Create from option to create the new configuration from the base template.

In general, it is recommended to create a new configuration from the existing one rather than directlymodifying the base solution configuration. However, this is not always practical because you have tochange all existing references to the base configuration to instead refer to your custom configuration.This can significantly increase the number of configuration items that you must change.

If there are many references to a configuration item, directly modifying it is better than copying it.Dictionaries are a good example of configurations that you should modify directly. Dictionaries andtaxonomies are referenced heavily in property pages, auto-naming, auto-linking, and so on. It is easyto reconcile differences between two versions of a dictionary.

Extending the Base Solution Contexts

To ensure that any new custom configurations are used at runtime, extend the base solution contextsto which your new configurations apply.

1. Use Create from to create a new context with the same parameters as the existing context.

2. Assign your custom application name to the extended context.

48


3. In the matrix, position the extended context to the left of the context it extends so that yourcustom context takes precedence.

4. Assign your custom configurations to the relevant extended contexts in the configuration matrixas shown in the following image:

49


Upgrading the Customized SolutionWhen upgrading to a new version of the solution and if you have changed an existing solutionconfiguration, you must perform a comparison of your modified configuration with the new versionof the solution configuration and merge the two configurations. Merging can either be done throughthe D2-Config tool after importing the new version or within the configuration export XML files priorto importing them. However, this is an activity that requires a developer or consultant with extensiveknowledge of D2, the base Documentum Life Sciences solution, and the customer modifications.

Reconciling Extended Base Configurations withSolution Upgrades

D2-Config provides the Create from capability for creating a new configuration from an existingconfiguration. In D2, Create from is enhanced so that a reference to the original base configurationitem is maintained in the parents_config attribute of the new custom configuration.

When a new version of the base configuration is imported during a solution upgrade, D2-Configreports warnings for any custom configurations in the new version that differs from the previousversion. In this way, D2 identifies which of your custom configurations needs to be reconciled withthe new base solution configuration.

For example, assume you customize the Procedure Properties configuration by using Create from tofirst create a copy of this property page and then modify the copy. You name the custom propertypage KB Procedure Properties. D2-Config will report the following warning when importing the newversion of the solution configurations:

Reconciling the changes between the new version of the base configuration (in this example,Procedure Properties) and the extension (in this example, KB Procedure Properties) is a manualprocess that involves either:

• Using a diff and merge tool on the two versions of the XML file and then importing the updatedXML file, or

• Using D2-Config to extend the upgraded version of the configuration and reapplying yourchanges.

50


Merging D2 Configuration XML Files

The format of D2 configuration files exported to the file system is enhanced in D2 to better supportteam development of D2-based applications and comparison between two versions of a configurationfile. D2 supports the following features related to exported configuration files:

• Granular files: The structure of the exported configurations is completely granular. There is aone-to-one correspondence between a configuration item and an XML file.

• Consistent ordering of XML attributes and elements: The XML elements and attributes withinthe XML files are ordered consistently and in a more readable format to facilitate comparisonbetween multiple versions of the file.

• Un-encoded filenames: Filenames in D2 configuration export packages are not hex-encoded. Thefilename reflects the name of the configuration item.

These improvements to the D2 configuration export packages greatly improve the team developmentexperience on D2 and are required for enabling and simplifying the comparison between two versionsof a configuration export package. Comparing export packages is a necessary step in the process ofupgrading a solution and migrating customer extensions to the upgraded version.

The following image shows the comparison of two versions of a creation profile using a diff andmerge tool:

Notice that the changes are highlighted. In this case, the version of the file on the left allows forcreation of two additional document types. There are also some changes in the properties of thecreation profile highlighted. After you have verified the changes, you can merge the changes usingthe tool.

Note: Between D2 4.5 and 4.6 release, the D2 config XML has undergone some changes. For instance,in D2 4.5, the display config is named as d2_attribute_mappings.xml but in 4.6 it is just .xml.

Note: In some sections, there is a separation between the configuration definition and its settings.This can be seen as a “contents” folder under the main folder. While there may be no changes in thedefinition file, there may be changes in the content file. It is recommended that you check both files.

51


Best Practices for Team Development with D2You should manage the source files for all of your custom components in a source code controlsystem that allows the versioning of files, including D2 configuration files. Multiple developerscan modify configurations in a shared Documentum repository or they can modify them in theirown local repository that is not shared. In either case, each developer should export their modifiedconfigurations, unzip the exported configuration package, and check the individual XML files intoa source code control system. Within the source code control system maintain the same directoryhierarchy in which D2 exports files.

Building D2 configurations can be performed by retrieving the latest configuration directory fromyour source code control system and rezipping them. A standard archive tool like Winzip can beused to rezip the files.

Extending RolesIf you require custom roles to be created in the Life Sciences solution, you can do so by extending thepredefined roles that are installed with the application. Extending the roles involves making propertypage changes and workflow configuration changes through D2-Config.

Creating Custom Roles1. Log in to Documentum Administrator.

2. Create a new custom role.

3. Assign the users and groups to the new role.

4. Add the custom role to the existing role. For example, to create a new role for authors,create a new_authors custom role. Then, add this role as a member of the existingcd_<domain>_doc_authors role.

The Documentum Administrator User Guide provides the steps of creating custom roles.

Configuring the Property Pages

The Property pages in the Life Sciences solution query and display the default roles. You must modifythese queries so that the custom roles are used. For example, in the Quality Documents propertypage, the Process Info tab displays the users in different roles. If you want to display a custom rolefor authors, you must change the query by replacing cd_quality_doc_authors with the custom role.

1. Log in to D2-Config.

2. Select Go to > Property page.

3. Under Property pages, select the property page for the respective domain.

4. Under Structure, expand the Process Info folder.

52


5. Expand the role folder for which a custom role is created.

6. On the right pane, in the DQL Query field, replace the old role in the query with the new role.

7. Click Save.

Configuring Workflows

When a workflow is started, the system specifies the performers for each state of the workflow. Bydefault, users who are members of the default roles are assigned as performers to the workflow.However, if the default roles are extended with custom roles, the query that assigns the performersmust be modified.


2. Select Go to >Workflow.

3. UnderWorkflow List, select a workflow.

4. Under Participant’s Structure, select the default role.

5. In the DQL query for the role, change the default role to the custom role.

6. Click Save.

Configuring Roles (LSQM)

By default, Documentum Q&M provides a list of site-based roles as defined in the ApplicableSites dictionary. Follow these steps to configure your own sites and user roles according to yourenvironment and requirements.


2. In the filter on the main toolbar, select All elements.

3. Select Data > Dictionary.

4. Under Dictionaries, select GMP Applicable Sites.

5. On the Languages tab, you can add or remove the required sites.

6. On the Alias tab, under each roles, define the respective user group for the respective site. Forexample, for the Boston site, under authors, type cd_boston_authors.

7. Click Save.All Documentum Q&M groups are cd_<site>_<role>. Custom roles should follow the same paradigmas the queries in the system are built to look for that structure. Note that this also applies for customR&D, SSV, and eTMF roles where it is cd_<domain>_doc_<role>. The queries are built expecting that

53


structure as well, although they typically take the group_name (for example, cd_clinical, cd_quality,and so on).

54

Chapter 3Life Sciences Data Model

This section provides an overview of the object data model used in the Life Sciences solutions.

Data Model OverviewThe Life Sciences data model serves two functions:

• It defines attributes that support all of the features provided by the Life Sciences solutionssuch as controlled document management, TMF planning and tracking, regulatory applicationmanagement, and so on.

• It implements, as a Documentum object model, the taxonomy and metadata described in the DIAReference Model for GMP Quality Systems Artifacts 1.0 for LSQM, DIA EDM reference model 1.3for the inventory in LSRD, and the DIA TMF reference model 2.0 and 3.0 for LSTMF. Users in theappropriate roles can create any document artifact defined in these standard reference models.

The following diagram depicts the Life Sciences object type hierarchy:

55

Life Sciences Data Model

Two base types, cd_controlled_document and cd_common_ref_model, define metadata that pertainsto all subtypes. Users do not directly create instances of these two types.

Types with the _info suffix represent registration forms. Registration forms are created and managedby the Business Administrators in each respective domain, that is, Product Managers, Clinical TrialManagers, Non-Clinical Study Managers, Project Managers, and Regulatory Managers.

Users in each respective domain in the appropriate roles can create instances of the types listedin the following table.

Table 3. Objects Types for which Users can Create Documents

Type Domain Created By Solution(s)

cd_app_reg_labeling_doc


Labeling Authors Documentum R&D

cd_change_request Change Request GMP Coordinators/Authors

Documentum Q&M

cd_clinical Clinical Clinical Authors Documentum R&D

cd_clinical_tmf_doc Clinical TMF Clinical Authors andContributors

Documentum eTMF

cd_core_reg_labeling_doc


Labeling Authors Documentum R&D

cd_general General Authors from alldomains

Documentum R&D

56


Type Domain Created By Solution(s)

cd_non_clinical Non-Clinical Non-Clinical Authors Documentum R&D

cd_quality Quality Quality Authors Documentum R&D

cd_quality_gmp [1] GMP All GMP Authors Documentum Q&M

cd_reg_admin Regulatory/Administrative

Regulatory/AdministrativeAuthors

Documentum R&D

cd_reg_ad_promo Regulatory/Administrative

Ad Promo Authors Documentum R&D

cd_reg_correspondence

RegulatoryCorrespondence

CorrespondenceAuthors

Documentum SSV

cd_safety Safety Safety Authors Documentum R&D

[1] — Users can create documents for the subtypes under this object type, that is,cd_quality_gmp_effective and cd_quality_gmp_approved.

You can extend the data model in the following ways:

• Add or modify attributes in existing solution types

• Create new types that extend from the existing solution types

Add or Modify Attributes in Existing SolutionTypesIf an attribute that represents metadata required for your organization’s documents is not available inthe standard data model, you can alter the existing types by following these recommendations:

• Use your own naming convention for custom attributes so that you can easily identifythem. For example, if KB Pharmaceuticals requires additional attributes on thecd_quality_manufacturing_sop documents for equipment type, physical location, and processstep, name these attributes as kb_equipment_type, kb_physical_location, and kb_process_steprespectively.

• Do not add or move a standard attribute to a higher level in the type hierarchy. If an existingattribute is required on additional object types, add a new attribute to those object types instead.Moving a standard attribute from a lower-level object type to a higher-level type can causeinstallation errors during future upgrades of the base solution.

• You can increase the length of string attributes if needed. When upgrading, the longer length isretained. However, you cannot change an attribute from repeating to single or from single torepeating.

• After adding new attributes, you must extend the relevant property page configurations and anyother D2 configurations in which you want to use the new attributes. For example, you maychoose to define new auto-naming or auto-linking configurations that use the new attributes.

57


Create New Types that Extend from ExistingSolution TypesIf there is no standard object type that represents your documents, you can create a new objecttype that extends from an existing solution type.

• Use your organization’s naming convention for the type name. Do not use the cd_ prefixes.

• After adding new types, you must add D2 configurations that enable users to create and manageinstances of the new type. Typically, the following D2 configurations are needed to support anew object type:

— Dictionary used in a creation profile

— Default Values template used in a creation profile

— Property page

— Creation profile

— Auto-naming

— Auto-linking

— Access Control List (ACL)/security

• You may also need to create content templates for the new object type.

Caution: Extending the object model with additional levels can affect the performance of thesystem.

58

Chapter 4Reference Models

A document management reference model defines the following:

• The kinds of documents that are managed by the document management system

• The metadata that is used to describe each kind of document

• An organizational structure for documents

The DIA EDM and TMF reference models are industry standard models developed by a consortiumof Life Sciences industry and vendor experts. The DIA EDM and TMF reference models provide anexcellent starting point for implementing a Life Sciences document management system because theyare based on industry experience and best practices. The Documentum Life Sciences solutions includea complete implementation of the DIA EDM reference model. The eTMF solution includes a completeimplementation of the TMF reference model as well. After installing a solution, you can immediatelycreate and manage any of the documents (referred to as artifacts) defined by the reference models.

The reference models are implemented using D2 configurations. Dictionaries, property pages, autolink, and auto naming configurations for all documents in the DIA EDM Regulatory/Administrative,Quality, Non-Clinical, Clinical, and so on domains are provided in all solutions. The eTMF solutionprovides D2 configurations for creating and managing all document artifacts defined in the DIATMF reference model. The Documentum Q&M solution provides D2 configurations for creatingand managing document artifacts related to the quality and manufacture of the marketed product.The configurations have been derived from industry best practice and are closely aligned with theDIA reference model that is currently in development for Q&M documents. The DocumentumR&D solution provides D2 configurations for creating and managing document artifacts relatedto the research and development of a product.

You can use the standard solution implementation of these models out-of-the-box. You can alsoextend the standard implementation to support additional kinds of documents and metadata. Oryou can use the standard solution implementation as a pattern for implementing a completelydifferent model.

Standard Solution Implementation of the DIAEDM Reference ModelThe DIA EDM reference model is defined in an Excel spreadsheet that is available on the DIA website.The spreadsheet contains tabs for each of the four document domains: Regulatory/Administrative,Quality, Non-Clinical, and Clinical. Each tab lists the document artifacts for that domain and the

59

Reference Models

metadata for the documents. The documents are categorized according to group and subgroup. Thefollowing image is a small snippet of the DIA EDM reference model spreadsheet:

The Artifact Name column lists the individual document artifacts for the given domain. In thesnippet, artifacts for the Quality domain are shown. The Group and Sub-Group columns show howeach artifact should be categorized. The columns to the right of Artifact Name, list the metadatafor documents in the given domain. An “M” in the cell indicates the attribute is mandatory forthe associated artifact.

This model is implemented in the Life Sciences solution using D2 dictionaries and taxonomies. D2property pages enforce mandatory attributes as defined in the model.

For the purpose of explanation, the Quality Domain dictionaries are used as an example. Thecomplete set of D2 dictionaries that list the groups, subgroups, and artifacts defined in the DIAEDM and TMF model are described in Appendix C. The Quality Domain dictionaries used in theimplementation of the DIA EDM reference model are listed in the table below. Notice that thesedictionaries map to the columns of the DIA EDM reference model spreadsheet.

Table 4. EDM reference model Quality domain dictionaries

Dictionary Name Description

Quality Groups List of values in the Group column on theQuality domain tab of the DIA EDM referencemodel spreadsheet. These values are the logicalgroupings or CTD modules in the Qualitydomain.

60

Reference Models


Quality Subgroups List of values in the Sub-Group column on theQuality domain tab of the DIA EDM referencemodel spreadsheet. Within the Quality domain,categories of documents within a group, usuallybased on CTD module subsets.

Quality Artifact Names Complete list of Quality artifacts defined inthe Artifact Name column on the Qualitydomain tab of the DIA EDM reference modelspreadsheet.

Quality Adventitious Agents Artifact Names List of artifacts in the Adventitious Agentsgroup on the Quality tab of the DIA EDMreference model spreadsheet.

Quality Drug Product Artifact Names List of artifacts in the Drug Product group onthe Quality tab of the DIA EDM reference modelspreadsheet.

Quality Drug Substance Artifacts Names List of artifacts in the Drug Substance group onthe Quality tab of the DIA EDM reference modelspreadsheet.

Quality Information Artifact Names List of artifacts in the Quality Information groupon the Quality tab of the DIA EDM referencemodel spreadsheet.

Quality Literature Reference Artifact Names List of artifacts in the Literature Referencesgroup on the Quality tab of the DIA EDMreference model spreadsheet.

Quality Medical Device Artifact Names List of artifacts in the Medical Device group onthe Quality tab of the DIA EDM reference modelspreadsheet.

Quality Overall Summary List of artifacts in the Quality Overall Summarygroup on the Quality tab of the DIA EDMreference model spreadsheet.

Quality Overall Summary Drug Product ArtifactNames

List of artifacts in the Quality OverallSummary group/Drug Product subgroup on theQuality tab of the DIA EDM reference modelspreadsheet.

Quality Overall Summary Drug SubstanceArtifact Names

List of artifacts in the Quality Overall Summarygroup/Drug Substance subgroup on the Qualitytab of the DIA EDM referencemodel spreadsheet

Quality Regional Information Artifact Names List of artifacts in the Quality RegionalInformation group on the Quality tab of the DIAEDM reference model spreadsheet.

These dictionaries are used in D2 creation profile configurations to enable users to create specificdocument artifacts. In the following creation profile image, the Quality Drug Product Artifact Namesdictionary is used in a creation profile to enable users to create Quality – Drug Product documents:

61

Reference Models

D2 taxonomy configurations use these dictionaries and those in Appendix C DIA EDM and TMFreference model Dictionaries to define the Group/Subgroup/Artifact organizational structure definedby the DIA EDM reference model. The following screenshot shows the Quality Classificationby Group dictionary in D2-Config:

The following table lists the complete set of taxonomies in the Documentum Life Sciences solutionsthat are used to implement the DIA EDM reference model.

62

Reference Models

Table 5. DIA EDM reference model taxonomies

Taxonomy Name Description Dictionaries

Clinical Classification byArtifact

Organization of Clinicaldocuments according toartifact/subgroup/group asdefined by the DIA EDMReference model.

Clinical Groups

Clinical Subgroups

Clinical Artifact Names

Clinical Classification byGroup Organization of Clinicaldocuments according togroup/subgroup/artifact asdefined by the DIA EDMReference model.

Clinical Groups

Clinical Subgroups

Clinical Artifact Names

Non-Clinical Classification byArtifact

Organization of Non-Clinicaldocuments according toartifact/subgroup/group asdefined by the DIA EDMReference model.

Non-Clinical Groups

Non-Clinical Subgroups

Non-Clinical Artifact Names

Non-Clinical Classification byGroup

Organization of Non-Clinicaldocuments according togroup/subgroup/artifact asdefined by the DIA EDMReference model.

Non-Clinical Groups

Non-Clinical Subgroups

Non-Clinical Artifact Names

Quality Classification byArtifact

Organization of Qualitydocuments according toartifact/subgroup/group asdefined by the DIA EDMReference model.

Quality Groups

Quality Subgroups

Quality Artifact Names

Quality Classification by Group Organization of Qualitydocuments according togroup/subgroup/artifact asdefined by the DIA EDMReference model.

Quality Groups

Quality Subgroups

Quality Artifact Names

Promotional MaterialsClassification by eCTD Section

Organization ofPromotional Materialsdocuments according togroup/subgroup/artifact/eCTDsection as defined by the DIAEDM Reference model.

Promotional Materials Groups

Promotional MaterialsSubgroups

Promotional Materials ArtifactNames

eCTD Section

63

Reference Models


Promotional MaterialsClassification by Group

Organization of PromotionalMaterials documents accordingto artifact as defined by the DIAEDM Reference model.

Promotional Materials ArtifactNames

2–Collaboration

2–SelfApprove

2–Approve

2–Approve-Review

2–Formatter

3–Review

3–Approve

Approvesig

Regulatory LabelingClassification by Artifact

Organization of RegulatoryLabeling documents accordingto group/subgroup/artifactas defined by the DIA EDMReference model.

Regulatory Labeling Groups

Regulatory Labeling Subgroups

Regulatory Labeling ArtifactNames

Regulatory LabelingClassification by Group

Organization of RegulatoryLabeling documents accordingto group/subgroup/artifactas defined by the DIA EDMReference model.

Regulatory Labeling Groups

Regulatory Labeling Subgroups

Regulatory Labeling ArtifactNames

2–Collaboration

2–SelfApprove

2–Approve

2–Approve-Review

2–Formatter

3–Review

3–Approve

Approvesig

64

Reference Models


Regulatory CorrespondenceClassification by Group

Organization of RegulatoryCorrespondencedocuments according togroup/subgroup/artifact asdefined by the DIA EDMReference model.

Regulatory CorrespondenceGroups

Regulatory CorrespondenceArtifact Names

2–Collaboration

2–SelfApprove

2–Approve

2–Approve-Review

2–Formatter

3–Review

3–Approve

Approvesig

Safety Classification by Artifact Organization of RegulatorySafety documents accordingto group/subgroup/artifactas defined by the DIA EDMReference model.

Safety Groups

Safety Artifact Names

Safety Classification by Group Organization of RegulatorySafety documents accordingto group/subgroup/artifactas defined by the DIA EDMReference model.

Safety Groups

Safety Artifact Names

2–Collaboration

2–SelfApprove

2–Approve

2–Approve-Review

2–Formatter

3–Review

3–Approve

Approvesig

The above taxonomies are used in D2 property page configurations to provide Taxonomy-basedvalue assistance. If an artifact is selected, the list of valid subgroups and groups is filtered using theappropriate taxonomy as shown in the following screenshot:

65

Reference Models

Standard Solution Implementation of the DIATMF Reference ModelThe DIA TMF reference model is a standard that describes the documents that might be included ina Trial Master File. Some of the artifacts defined in the Clinical domain of the DIA EDM referencemodel overlap with those defined in the DIA TMF reference model. This information is definedfor the Documentum eTMF solution in the D2 configuration in the form of a single dictionaryconfiguration for each DIA TMF reference model, instead of multiple dictionaries and taxonomies.Defining the artifact names and its corresponding information including category, workflowmappings, and so on, in a single dictionary configuration makes it easy for administrators to managechanges to existing artifacts and add new artifacts whenever required.

Note: You must not modify the reference model in the spreadsheets (file plan template) as it willalways be overwritten by the value in the object.

The following table lists the dictionaries that map to the columns of the DIA TMF reference model.

Table 6. TMF dictionaries


TMF Models Name and version of the TMF reference modelthat is supported as listed in the DIA TMFreference model spreadsheet.

TMF Unique Artifact Names 2.0 List of values in the Unique Artifacts name, TMFZone, TMF Section, and TMF Artifact Numbercolumns of the DIA TMF Reference Model 2.0spreadsheet. Additional columns that reducethe dependency on other dictionaries andcreation profiles include Category, Is Crossover,Object Type, Initial Version, and WorkflowMappings and so on.

TMF Unique Artifact Names 3.0 List of values in the Unique Artifacts name, TMFZone, TMF Section, and TMF Artifact Numbercolumns of the DIA TMF Reference Model 3.0spreadsheet. Additional columns that reduce

66

Reference Models

Dictionary Name Descriptionthe dependency on other dictionaries andcreation profiles include Category, Is Crossover,Object Type, Initial Version, and WorkflowMappings and so on.

All the information about the artifact is consolidated into a single dictionary per reference model. Aseparate TMF Models dictionary identifies the available models and the associated dictionary for themodel as an alias as shown in the following image:

Each value mapped to the Dictionary alias for the associated key in the TMF Models dictionary has adictionary. For example, the DIA TMF 2.0 key is associated to the TMF Unique Artifact Names 2.0dictionary. In the TMF Unique Artifact Names 2.0 dictionary, information about an artifact is storedas an alias (as columns) as shown in the following image:

When you create placeholders and TMF documents, the creation logic uses the respective dictionary,which is determined by the reference model of the trial, and populates the relevant artifactinformation in the property pages. A default value template, TMF Placeholder Defaults, is definedto apply the default values for all the placeholders and documents that are created. Anything thatchanges from artifact to artifact is defined as an alias in the dictionary and a lookup expression isused in the default values template to determine the values from the dictionary.

67

Reference Models

Standard Solution Implementation of Qualityand Manufacturing Document ModelsLife Sciences solutions enable the creation and management of other document types besides thestandard DIA reference model artifacts that have been established for R&D and eTMF. The followingD2 dictionaries and taxonomies are used for documents in the Quality and Manufacturing documentmodels:

• GMP Categories

• GMP Groups

• GMP Subgroups

• GMP Artifacts

The following screenshot shows the GMP Artifacts taxonomy in D2-Config:

The following table lists the taxonomy properties for the D2 dictionaries in D2-Config.

68

Reference Models

Table 7. Taxonomy

Taxonomy Name Description Used Dictionaries

GMP Artifact Hierarchy and classification forall Q&M documents.

GMP Categories, GMP Groups,GMP Subgroups, GMPArtifacts

Implementation of the DIA EDM ReferenceModel for the Regulatory Domain (LSRD)In the previous implementation of the DIA EDM reference model for the Regulatory domain,Regulatory/Administrative inventory-related data was scattered across multiple sources likedictionaries and taxonomies, such as Group, Subgroups, and so on. Although this design providedbetter organization of the data, a side effect was that in case there were any changes to the existingdata model, any additions to the model at various stages including Group, Subgroup, or Artifactlevel, or any workflow mapping changes to an existing artifact, it required a better understanding ofall those configuration objects. Updates had to be made to more than one configuration resulting in acumbersome process of making any changes to the data model.

The Regulatory domain had the following dictionaries and taxonomies in the previous design:

Table 8. Dictionary


Regulatory-Admin Artifact List of the types of documents in theRegulatory/Administrative domain.

Regulatory-Admin Groups List of logical groupings or CTD modules in theRegulatory/Administration domain.

Regulatory-Admin Subgroups Within the Regulatory/Administrative domain,list of categories of documents within a group,usually based on CTD module subsets.

Table 9. Taxonomy

Taxonomy Name Description

Regulatory-Admin Classification by Groups List of artifacts based on its group and subgroupmappings and the workflow mappings for eachartifact.

Apart from the above configurations, the category of each artifact is configured in the creation profile,Regulatory Documents by EDM Artifact Name. For each artifact, there is a default values templateconfigured in which the category is set to either 2 or 3 based on the artifact. Therefore, if there wasany change in the artifact’s category, the creation profile also had to be updated.

To simplify making changes to the data model, a new implementation of the reference model is usedwith the objective to reduce the number of configuration elements and capture the data in a single

69

Reference Models

dictionary rather than scattering it into multiple configurations. The new implementation includesthe following changes:

• All the above dictionaries and taxonomies have been replaced with a single dictionary,Regulatory-Admin Artifact. This dictionary holds a key with a syntax <artifact_name>|<region>.There is an alias created for each value that varies for each artifact, for example, Group, Subgroup,Region, and so on.

• The creation profile, Regulatory Documents by EDM Artifact Name, is configured with a singledocument type, New Document. Users must select document properties including artifact_namein the properties screen. The data in the properties screen is sourced from the single dictionary,Regulatory-Admin Artifact. All the artifacts within the Regulatory domain are Category 2.Therefore, a single default values template Regulatory-Administrative Cat 2 Default Values isconfigured in the creation profile.

• The dictionary/taxonomy mappings from the property page configuration have been replacedwith DQL queries to populate data from the new dictionary where ever it is required.

With this single dictionary implementation, any changes to the data model and workflow mappingscan be done by modifying the Regulatory-Admin Artifact dictionary instead of managing multipleconfigurations.

70

Reference Models

Extending the Standard Reference ModelImplementation (LSTMF)Documentum eTMF maintains its reference model in several configuration components withinthe system:

• Dictionaries: Contain information about sets of acceptable values in the reference model.

• File plan and file plan templates: Configured to activate artifacts within studies. Each artifact tobe activatedmust be contained within the file plan for the study. The file plan template enables youto add new artifacts in the new study file plans, and be imported when study plans are reloaded.

Each of these components must be configured with the new artifacts that are to appear in the system.

Extending Dictionaries

In Documentum eTMF, you must extend the following dictionaries:

• TMF Models if you want to add a new reference model.

• TMF Unique Artifact Names <version> if you want to add a new artifact.

To extend a dictionary by adding a new artifact, follow these steps:

1. Log in to D2-Config as Administrator.



4. Under Dictionaries, select the dictionary that you want to extend, for example, TMF UniqueArtifact Names 2.0.

5. Under Properties, on the Alias tab, click Add alias.

6. In the Key column, type the name of the new artifact.

7. In the corresponding columns, type the values for the new artifact and then click Save.

8. Click Update repository.You can also modify dictionaries by exporting the values as an Excel spreadsheet, making thechanges, and then importing them back. After importing the spreadsheet, click the Update repositorybutton to ensure the changes are available.

71

Reference Models

File Plans and File Plan Templates

A file plan is a Microsoft Excel spreadsheet specifying the expected artifacts in each filing area.The file plan specifies whether artifacts are required (must-have), recommended (should-have), oroptional (could-have) documents. In Documentum eTMF, the File Plan Sample spreadsheet is used asthe base when file plan templates are created.

Each new artifact needs to be placed in the file plan to be activated. If the artifact is to be includedin every study, you can place it in the master template. Alternately, it can be placed in a specifictemplate or file plan as any artifact within the system. The Documentum Electronic Trail Master FileUser Guide provides more information about file plans.

Implementing a Custom Reference Model(LSTMF)To implement a custom reference model in Documentum eTMF, follow these steps:

1. In the TMF Models dictionary, add a new key for the custom reference model. Follow the stepsprovided in Extending Dictionaries, page 71 to add a new artifact.

2. Select the existing dictionary, for example, TMF Unique Artifact Names 2.0, and click Create from.

3. In the Name field, type a name for the custom dictionary and then click Save.

4. Click Export to export the dictionary into an Excel spreadsheet.

5. Open the Excel sheet, delete the existing content and add the new artifact values.

6. After you finish updating the dictionary Excel sheet, in D2-Config, click Import.

7. Select the updated dictionary Excel sheet and click Open.

8. Click Save and then click Update repository.

9. Restart the Java Method Server.

72

Chapter 5Document Creation Profile

The Life Sciences solutions provide several D2 creation profiles to enable users to create and importdocuments and registration forms. There are one or more creation profiles for each DocumentumR&D, Documentum eTMF, and Documentum SSV domain. There is no manager role in DocumentumQ&M as registration forms are not currently used in this solution.

Management Creation ProfilesManagement creation profiles enable users in a manager role to create registration forms andother management related documents, such as content templates and Trail Master File (TMF) bulkimport/export packages, in the manager’s domain.

Table 10. Management Creation Profiles

Creation Profile Available to Role

Clinical Trial Management Artifacts cd_clinical_trial_managers

Clinical Template Management Artifacts cd_clinical_template_authors

Non-Clinical Study Management Artifacts cd_non_clinical_study_managers

Non-Clinical Template Management Artifacts cd_non_clinical_template_authors

Product Management Artifacts cd_product_managers

Quality Project Management Artifacts cd_quality_project_managers

Quality Template Management Artifacts cd_quality_template_authors

Regulatory-Admin Management Artifacts cd_regulatory_managers

Regulatory Correspondence TemplateManagement Artifacts


Regulatory Template Management Artifacts cd_regulatory_template_authors

Safety Template Management Artifacts cd_safety_template_authors

TMF Clinical Trial Management Artifacts cd_clinical_trial_managers

TMF Clinical Template Management Artifacts cd_clinical_tem_authors_tmf

GMP Template Management Artifacts cd_gmp_template_authors

Med Device Template Management Artifacts cd_med_device_template_authors

73

Document Creation Profile

Document Creation ProfilesMultiple document creation profiles, for each document domain, enable end users to create or importdocuments for the applicable domain. The DIA EDM reference model categorizes documentsaccording to the taxonomy, domain/group/subgroup/artifact.

For the creation profiles relevant to the DIA EDM reference model domains: Regulatory/Admin,Quality, Non-Clinical, and Clinical, there is a creation profile for each DIA EDM group within theapplicable domain.

Note: For the Regulatory/Admin domain, only one artifact available in the creation profile that is,New Document. Group, Subgroup, and Artifact information is captured on the Edit properties screen.

Within each creation profile, the individual document types map to artifacts.

74


Each creation profile has an associated D2 dictionary that defines the document types (that is,artifacts) for the relevant domain and group. For Quality and Manufacturing domains, the individualdocument types within each creation profile map to groups rather than artifacts.

75


Control Category DefinitionThe control category for each artifact is defined within the creation profile through the assignedDefault Values template and lifecycle.

The Default Values template and lifecycle must always refer to the same control category number.In the example, the Directive artifact in the Q&M Governance and Procedures domain will becreated as a Control Category 1 document. The assigned Default Values template ensures that thecategory attribute is assigned the value 1. The document then matches contexts with the condition,category=’1’. This ensures the correct Control Category 1 configurations are applied to thedocument at runtime.

Default Values TemplateA pertinent Default Values template is assigned to each document type within the creation profiles.The following screenshot is an example of a Default Values template, which is assigned to ControlCategory 2 Quality Drug Product artifacts:

76


The Life Sciences solutions depend on correct default values to function correctly. The following tablelists attributes that must have default values when a document is created.

Table 11. Required default values

Attribute Default Value Runtime Use

authors User creating document Used in security configurationto ensure that the user thatcreated the document continuesto have WRITE access to theDraft document.

category Control Category 1,2,3, or 4 Determines the lifecycle andworkflows available for thedocument.

domain Document domain (forexample, Quality, Clinical,Non-Clinical, Regulatory)

Used along with artifact_nameto look up applicable contenttemplates.

77


Attribute Default Value Runtime Use

group_name Group prefix correspondingto domain (for example,cd_quality, cd_clinical,cd_non_clinical, and so on)

Used in value assistancequeries for role attributes onthe document and for potentialworkflow performers. This isnot relevant to DocumentumQ&M.

primary_group Required for artifacts withinDIA EDM reference modelgroup-specific creation profiles.The value is the applicable DIAEDM reference model group.

Ensures that theprimary_group is defaultedduring creation based onthe user’s selected creationprofile. This is not relevant toDocumentum Q&M.

Customizing Creation ProfilesYou can customize creation profiles in the following ways:

• Create a new creation profile.

• Change creation profile properties.

• Change creation properties for an artifact within an existing creation profile.

• Add additional artifacts to an existing creation profile.

• Remove artifacts from an existing creation profile.

• Remove or disable an existing creation profile.

Prior to adding additional artifacts to a new or existing creation profile, you must create any of thefollowing configurations that will be referenced in the creation profile:

• Object types

• Dictionaries or added dictionary values

• Property pages

• Inheritance configurations

• Default values templates

• Lifecycles

Creating a New Creation Profile

1. In D2-Config, click Creation > Creation profile.

2. Click New.

78


3. Under Properties, enter the profile details, such as name, description, list of applications, anddictionary properties.

4. Click Save.

Changing Creation Profile Properties


2. Under Profiles, select the creation profile you want to update.

3. Under Properties, change the relevant properties.

4. Click Save.

Changing Creation Properties for an Artifact within anExisting Creation Profile


2. Under Profiles, select the creation profile you want to update.

3. Add your custom application name to the Applications list.

4. In the Dictionary table, update the rows for a particular artifact.

5. Click Save.

Adding Artifacts to an Existing Creation Profile


2. Select the creation profile you want to modify and make a note of the dictionary that is used todefine the documents that can be created. For example, the Quality Drug Product Artifact Namesdictionary is used as an example:

3. Edit the dictionary. Add the names and labels of your new artifacts to this dictionary.

4. Reopen the creation profile.


79


6. In the table, create a new row for each new artifact and select the following values in theirrespective columns for each new row:

a. First column: Select a dictionary item from those you added in step 3.

b. Type column: Select the object type for the new document that will be created when a userselects this item in the creation profile. If you created your own custom type, you canspecify the custom type.

c. 02 config column: Leave blank.

d. Property pages column: Select the property page configuration that should be displayedduring creation or import for this item.

e. Version column: Typically, you should select 0.1. This value ensures that the first effectiveversion of the document is version 1.0, while all draft or pre-effective versions are 0.x.

f. Inheritance column: Select an appropriate D2 inheritance configuration. If you created yourown inheritance definition, select the custom inheritance definition.

g. Default Values Template column: Select a Default Values template that corresponds to thespecific artifact, its domain, and/or its group and the desired control category.

h. Lifecycle column: Select the lifecycle corresponding to the desired control category for thedocument. This must correspond to the Default Values template. If you created your ownlifecycle definition, select the custom lifecycle definition.

i. Workflow column: Leave blank.

7. Click Save.

Removing Artifacts from an Existing Creation Profile



3. Remove the unwanted rows from the table at the bottom of the page.

4. Click Save.

Removing or Disabling an Existing Creation Profile


2. Under Profiles, select the creation profile that you want to disable.

3. Under Properties, in the Users group field, set the value to admingroup. This ensures that nobusiness users will have access to the creation profile.

4. Click Save.

80


File Naming and VersioningThe document name is automatically assigned based on the naming schema: <artifact name>- <document ID>. For Documentum Q&M, the naming schema is <group name prefix>- <document ID>.

Where the artifact name is 230 characters and the document ID is a 9 digit incremental number.

The naming rules ensure that documents are named consistently. For example, when the artifactname is Cover Letter and the document ID is 000000001, the name displayed in the D2 Clientworkspace is: Cover Letter - 000000001

Caution: The system generates the document_id from a 9-digit counter, which allows 100million unique document IDs. In D2-Config, the size of the counter can be increased by editingthe _Document_ID auto naming configuration. However, the document_id attribute in thecd_controlled_doc object type is a ten character string. When the digits are increased above10, the cd_controlled_doc object type must also be changed.

If the counter value on the _Document_ID auto naming configuration is reset after creatingdocuments, subsequent document IDs might not be unique. Consequently, you should not resetthis counter value in a production repository.

If two autonaming configurations have the same prefix, the system does not validate theconfigurations for existing documents. This can result in duplicate document names in the system.For example:• QUA - Quality

• QUA - Qualitative Use Assessment

You can avoid this by defining a different prefix for the document in the respective Prefixes dictionaryin D2-Config.

Document versions are minor (v 0.1) until they are made effective. Documents in anEffective/Approved/Final state have major version numbers (v 1.0).

O2 Configuration for PDF and NativeAnnotationsIf you use PDF annotations in your documents, you must avoid using O2 trigger events other thanthe Checkout/Checkin and Save Properties events. This is because O2 events update the contentand, if PDF annotations exist on the document, these updates cause the annotations to be deletedprior to the author being able to view them. In addition, when a user updates the properties of adocument, the updated properties will not be in sync with the content of the object until the userchecks out the document and checks it back in.

By default, the Life Sciences solution supports only the Checkout/Checkin and Save PropertiesO2 trigger events. Other O2 trigger events will only work with native annotations and not PDFannotations. For example, updating the last periodic review date on an Approved document or

81


updating the Product Code that then cascades down to the documents. The Documentum D2Installation Guide provides information about O2 configurations.

C2 View Configurations for PDFThe Life Sciences solutions use C2 View configurations to dynamically generate PDFs that the endusers can view. The following table describes the C2 View configurations for the Life Sciencessolution:

Option Description

Form Details

Default Configuration Select to make this configuration the defaultview configuration. If more than one defaultconfiguration is applicable for the end user ina context within the configuration matrix, D2uses the top-most configuration in the C2 ViewConfiguration page.

Compatibility Select the oldest compatible version of the PDFviewing software.

Protection Details

Encryption Level Determines the type of encryption (40 or 128 bit).

User password The password required for opening the PDF.

Password to modify preference The password required for modifying the PDF.

Permissions Check the checkboxes to allow the user to print,modify content, copy, or modify annotations.

Initial View Details

Page Layout Defines the layout of the document, for example,multiple pages, single page, and so on.

Display Determines which panels to display on initialview, for example, bookmarks or just the PDFpage, and so on.

Displayed page on running Select the page to display on initial view.

The following table lists the C2 View configurations used by the Life Sciences solutions:

C2 View Configuration Name Solution

Audit Report C2 View All

Category 1 C2 View for Effective LSQM

Category 1 C2 View for Non Effective LSQM

Category 1 C2 View for Effective GMP Forms LSQM

82


C2 View Configuration Name Solution

Category 2 C2 View for Approved Non QM LSRD, LSTMF, LSSSV

Category 2 C2 View for Non Effective All

Category 2 C2 View for Effective All

Category 2 C2 View for Non QM LSRD, LSTMF, LSSSV

Category 3 C2 View for Approved LSRD, LSTMF, LSQM

Category 3 C2 View for Approved Non QM LSRD, LSTMF, LSSSV

Category 3 C2 View for Non Effective All

Category 3 C2 View for Non QM LSRD, LSTMF, LSSSV

Category 3 C2 View for Submission Documents LSSSV

Change Request C2 View LSQM

TBR Audit Report C2 View LSQM

Templates C2 View All

Note: When exporting Audit Report C2 View and TBR Audit Report C2 View, the Audit table willbe appended in front of the document followed by rest of the document content. There is no wayto show only the Audit Report through C2 View configurations.

PDF Rendition OverviewThe Life Sciences solution uses C2 Rendition configurations, which is similar to the C2 Viewconfigurations as described in C2 View Configurations for PDF, page 82, to provide PDF renditions ofa document to publishing tools. This allows the system to generate a PDF rendition with a signaturepage that can be retrieved using lower-level API calls directly against Documentum, that is, usingDFC/DFS and not through D2. The PDF rendition generated from the rendering engine (ADTS orAdlib PDF Enterprise) can be used by the publishing tool for all Non-Effective (Approved or Final)versions. However, after the document becomes Effective (Approved or Final) and a signature page isrequired, the PDF rendition in the repository is updated to include the signature page. The followingsections describe the flow of documents through the system with regard to PDF renditions.

Electronic SignaturesElectronic signatures are captured during the workflow process when approving documents byforcing the user to enter a username and password and storing that information in the audit trail.

83


The C2 configuration then reads the audit trail to create the signature page that is dynamically orstatically applied to the PDF rendition.

Page Sizes and OverlaysNot all parts of the world use the same page size. Most documents in the US are created using USLetter page size (279 mm x 215.mm). Documents within the European regions typically use an A4size (297 mm x 210 mm). Unfortunately, C2 does not automatically scale signature pages or overlays.

Signature Page

Signature pages are currently handled through C2 configurations that attach the signature page tothe PDF rendition. This process uses XSL FO to produce one or more PDF pages containing a tableof signature information. C2 does not provide a mechanism for determining the page size of thegenerated signature page. To make it easier for clients to configure the page size for the signaturepage, parameters for the page height and width can be configured in D2-Config on the C2 RenditionConfiguration Merge section:

It is recommended to set the page size to the largest page size used if multiple page sizes are requiredfor a client. When choosing to physically print the document, the “fit to page” option should beselected.

Overlays

Overlays are applied through C2 Export, C2 Print, and C2 View configurations through the layersetting in the Stamping configuration. To ensure that the correct layer is used with regard to pagesize, the overlay must contain a page for each page size and orientation. For example, to support bothportrait and landscape orientations in both A4 and US Letter page sizes, four pages are required inthe overlay:

• US Letter Portrait

• US Letter Landscape

• A4 Portrait

• A4 Landscape

84


Other page sizes can be supported by simply adding another page with the appropriate settings. Ifthe header or footer is changed in the document, such as property changes, header/footer locationchanges, or changes to the size of the header or footer, the C2 overlay may also need to be altered.

Note: This only applies to overlays generated through C2. It does not apply to overlays generated bythe Controlled Print feature.

Note: Only portrait-based templates are included out of the box. If landscape pages are required,these pages must be added to the authoring template as well as to any existing overlays so that theproperly sized or positioned overlays can be applied.

85


86

Chapter 6Registration Forms

This section provides an overview of registration forms.

Overview and Form TypesWhen document Authors create a new document, they associate it with an existing registration form.The registration form specifies the product codes, trial IDs, project names, default role assignments,and other property values that can be selected in the new document’s properties dialog box. EachR&D and eTMF document type that can be directly created by users has a corresponding registrationform subtype. This does not apply to Q&M documents or Change Requests.

Registration forms can be associated with a document in one of two ways:

• The user selects the registration form before importing or creating a document.

• The user selects the ID (for example, product_code, clinical_trial_id, project_name, and so on) ofthe registration form in the properties dialog for the new document during creation or import.

Documents can inherit from multiple registration forms. Chapter 7, Attribute Inheritance andCascading Attribute Rules provides more information about how to configure documents to inheritproperties from registration forms.

Most registration forms are contentless documents with the exception of the TMF Clinical TrialRegistration Form. In this case, the content of the registration form is the TMF File Plan spreadsheet.Registration forms have their own lifecycle and security configurations. Registration forms serve thefollowing purposes:

• Define the product code names, trial ID numbers, project names, and so on, that can be selected indocument properties dialog boxes (on the Classification tab) when a new document is created orimported.

• Provide default metadata that can be inherited by the relevant documents. This simplifies thedocument creation process for the Authors and reduces the amount of metadata to be filled-inby the end-user.

• Define default role assignments (for example, Reviewers, Approvers, Coordinators, and so on)to apply to the relevant documents.

• Enable the overall status of a product, trial, or project to be indicated by the appropriate Managers.

• Enable an entire product, trial, or project to be locked down if necessary, in order to preventadditional documents from being made “Effective” (perhaps temporarily).

87

Registration Forms

Registration forms are set up by the high-level Management team, that is, Product Managers,Regulatory Managers, Clinical/Non-Clinical Trial Managers, Project Managers in the R&D Qualityarea, and Corporate Administrators. Only these users can create and modify the forms. In general,these forms provide an overarching governance mechanism that can be used at the Managementlevel, over and above the role-based access controls applied at the individual document level. Thefollowing table shows the available registration forms, the registration form object type, and the typeof object that inherits properties from this kind of registration form.

Table 12. Registration form types

Registration Form Name Registration From Type Target Object Type(s) Inheritfrom Registration Form

Country Registration Form(eTMF solution only)

cd_clinical_country_info cd_clinical_tmf_doc

Site Registration Form (eTMFsolution only)

cd_clinical_site_info cd_clinical_tmf_doc

Clinical Trial Registration Form cd_clinical_trial_info cd_clinical

cd_clinical_tmf_doc

Non-Clinical StudyRegistration Form

cd_non_clinical_study_info cd_non_clinical

Medical Device Clinical TrialRegistration Form

cd_clinical_trial_info cd_clinical

Medical Device RegistrationForm

cd_product_info cd_clinical

cd_non_clinical

cd_reg_admin

Medical DeviceRegulatory-AdminRegistration Form

cd_reg_admin_info cd_reg_admin

Medical Device SubmissionRegistration Form

cd_reg_submission_info cd_reg_admin

Product Registration Forms cd_product_info cd_clinical_tmf_doc

cd_clinical

cd_non_clinical

cd_quality

cd_reg_admin

Project Registration Forms cd_quality_project_info cd_quality

Regulatory ApplicationRegistration Forms

cd_reg_admin_info cd_reg_admin

88

Registration Forms

Registration Form Name Registration From Type Target Object Type(s) Inheritfrom Registration Form

Regulatory Activity PackageRegistration Form

cd_reg_admin_activity_info cd_reg_admin

Submission Registration Form cd_reg_submission_info cd_reg_admin

In most cases, each registration form object type extends the relevant target object type (that is, thedocument object type to which the form pertains) for the following reasons:

• Optimizes query performance since there are usually fewer instances of registration forms thandocuments, so the queries used to populate the product, trial, or project codes work efficiently.

• Facilitates D2 configuration, enabling D2 contexts to be used to restrict certain configurationelements to registration forms (for example, attachment of property screens, lifecycles, andsecurity models).

• Provides the ability to add attributes specific to the registration form but not the target documents.

It is possible to extend the configuration to support other types of registration forms if necessary.

Creating Custom Registration Form TypesYou can create a custom registration form type for a new type of document or to support an additionallevel of inheritance to existing document types using the following steps:

1. Create a new object type for the registration form type. By convention, the object typename should have the _info suffix and as a best practice, the object type name should beprefixed according to your organization’s naming convention. For example, if you are adding aregistration form for marketing materials for KB Pharmaceuticals, name the target object typekb_marketing and the registration form subtype kb_marketing_info. The object type should alsohave an attribute that can be used as an identifier. This will be the key attribute when associatinga document with the registration form.

2. Add the registration form name to a D2 dictionary. This dictionary value is used in a creationprofile to enable users to create instances of the registration form. For example, create adictionary, Marketing Management Artifacts, with a key value and language label value:Marketing Registration Form. Alternatively, if you are adding the registration form to an existingcreation profile, modify the existing dictionary that is associated with the existing creation profile.

3. Create a property page configuration for the registration form.

4. Create an inheritance configuration to be used during creation of the new registration formif needed. This step refers to inheriting configurations from an existing registration form toyour new registration form. For example, the Marketing Registration Form might inheritfrom a selected Product Registration Form. You can also use a standard solution inheritanceconfiguration rather than create a custom one.

5. Create a D2 inheritance configuration that defines the attributes that will be inherited from thenew registration form to target documents.

6. Create a Default Values template to be used during creation. Ensure that all of the mandatorydefault properties described in the Default Values Template, page 76 are defined.

89

Registration Forms

7. Create a lifecycle configuration for the new registration form type if desired. You can also usean existing registration form lifecycle if it applies.

8. Create a creation profile that enables creation of the new registration form type. Alternatively,add the new registration form to an existing creation profile. Customizing Creation Profiles,page 78 provides more information.

90

Chapter 7Attribute Inheritance and CascadingAttribute Rules

This section explains how attribute inheritance and cascading rules work in the Life Science solution.

Auto-Inherited Attribute RulesThe Life Sciences solutions use standard D2 inheritance configurations but they also introducea flexible mechanism called Auto-Inherited Attribute Rules. The following table summarizes thedifferences between these two mechanisms.

Table 13. Comparisons between D2 inheritance and Auto Inherited Attribute Rules

D2 Inheritance Auto-Inherited Attribute Rules

Configured in D2-Config. Configured in D2-Client by creatingan Auto-Inherited Attribute Rules(cd_auto_inherit_config) object and setting itsproperties.

cd_auto_inherit_config does not delete emptyfolders or update versions other than the currentone. When configuring auto-inheritance andcascading attribute rules, run the following DQLto set the immutable flag on the type. This isapplicable for all the types for which the rulesare being configured. A sample DQL queryfor the "cd_non_clinical" object type with theattribute swy_study_category is as follows:

alter type cd_non_clinicalmodify swy_study_category(setignore_immutable=-1) publish;

91

Attribute Inheritance and Cascading Attribute Rules

D2 Inheritance Auto-Inherited Attribute Rules

Requires the user to preselect the sourcedocument before initiating a new or importoperation.

Inheritance is based on the product code, trialid, study id, project name, and so on, thatthe user selects in the Properties dialog boxduring creation or import. The source objectfor inheritance is identified through a querydefined within the Auto-Inherited AttributeRules object. Therefore, it is not necessary topreselect a source document.

Documents can only inherit from the selecteddocument.

Documents can inherit from more than onedocument. They inherit from all documents thatmatch a configured source query qualification.

Applied by the D2 runtime before displayingthe Properties dialog box during documentcreation or import.

Applied by the Life Sciences solution server-sidelogic after the document is created and theinitial lifecycle state actions executed. Therefore,the inherited attribute values will not be shownin the Properties dialog box during creation orimport. Consider configuring the property pagesuch that fields that will be inherited throughthis approach are not visible during creation.

Allows copying an attribute value from theselected document to a new document.

Provides for configurable inheritance rules.Documents can inherit attributes from multiplesources. You can merge or override attributes,can transfer attributes to different attributes,and can apply conditional inheritance rules,depending on the object type and/or propertiesof the target object.

Configuring Auto-Inherited Attribute Rules1. Log in to D2-Client as a user in the cd_admingroup role.

2. Click New > Content.

3. Select the System Administration creation profile.

4. In the System Administration list, select Auto Inherited Attributes Rule and click Next.

5. In the Name field, type a name for the configuration.

6. On the Rule applicability tab, configure the following fields.

Option Description

Enabled Check if this auto-inheritance configuration is enabled. Ifunchecked, it is ignored at runtime.

92


Option Description

Automatically applies to newobjects

Check if this auto-inheritance configuration should beapplied automatically whenever objects of the specified typesare created. If unchecked, the configuration is only applied ifit is explicitly called from a lifecycle action.

Order of precedence Specifies the order of precedence for this rule in relationto other rules that may be applicable. Rules are applied inincreasing order of precedence that is, a precedence valueof 0 denotes the highest precedence, 1 is the next highest;and so on. When two or more applicable rules have the samelevel of precedence, they are applied in alphabetical order ofobject_name.

The order in which the rules are applied and if a subsequentrule depends on a value being already set can be significant.For example, if two or more rules are configured to set defaultvalues, the first rule will override any subsequent rules.

Applies to object_types Defines the optional list of target object types that this rulecan apply to. Where defined, if the target object is not one ofthe specified object types (including subtypes), it is ignored.If undefined, the rule can apply to any target object.

Condition qualifier (optional) Specifies an optional DQL qualifier that must be satisfied forthe target object in order for the rule to apply. For example,the condition product_code is not null ensures the ruleonly applies to documents that have defined product_codevalues.

7. On the Inherit from tab, configure the following fields.

Option Description

Inherit from Specifies the source object(s) that are used to provide thevalues to be inherited. The object(s) are in terms of a DQLqualifier. This can refer to attribute values of the target objectusing the $value(...) notation within the qualifier, as instandard D2 configurations. For example,

cd_product_info where product_code =

‘$value(product_code)’

uses a cd_product_info source object with a product_codevalue matching that of the target object.

The $quotedvalue(...) notation can also be usedto safely refer to attributes that could potentially haveembedded quotes in them. For example, the precedingqualifier could also be written as follows:

cd_product_info where product_code =

$quotedvalue(product_code)

93


Option Description

If you use the $quotedvalue(...) form, the value isquoted automatically, with internal quotes doubled-upso that the DQL clause is syntactically-correct. If thespecified attribute is a repeating attribute, you can use theplural form $quotedvalues(...) to generate a seriesof comma-delimited, safely-quoted strings, which can bereferenced in a DQL “in” clause. For example,

cd_non_clinical_trial_info where any study_num

in ($quotedvalues(study_num))

If the resulting DQL qualifier identifies multiple sourceobjects, the inheritance rules are applied to each sourceobject in turn, in the order in which they are returned by thequalifier. Use an order by clause in the qualifier if necessary,to ensure the source objects are taken in the appropriate order.

To implement folder-based inheritance, a qualifier of thefollowing form can be used:

<folder_object_type> where r_object_id in

($quotedvalues(i_folder_id))

Where <folder_object_type> is the appropriate object type.This enables the target object to inherit attribute valuesfrom the parent folder(s) after it has been created andauto-filed in the repository. However, if the target objectis linked to multiple parent folders, the order in which theparent folders are retrieved is not deterministic, and thetarget object may inherit values from the wrong foldersas a result. To counter this, the source parameter can beset to the special value PARENT_FOLDERS, which appliesparent folder inheritance in strict order, so that the primaryfolder is used first, followed by any secondary folders. Thespecial value PRIMARY_PARENT_FOLDER can also be used toenforce folder inheritance from the primary folder link only.The PRIMARY_PARENT_FOLDER is the one listed as the firstfolder in the i_folder_id property.

8. On the Inherit to tab, configure the following fields.

94


Option Description

Inherit to Specifies the target object(s) on which the inheritance rulesare to be applied. The default setting is SELECTED. Thisenables attribute inheritance to be applied to one or moreobjects related to the selected object (the object specified bythe –id argument) as opposed to the selected object itself suchas its parent folders. For example, for Documentum eTMF,to propagate attributes from the currently-selected object toits parent folders along the folder path towards the cabinetlevel, set source to SELECTED and target to ALL_FOLDERSfor the tmf_folder object type .

For checked-out objects Specify how currently checked-out items should be handled.If you use the Bypass lock temporarily option, the existingcheck-out locks are reinstated after the update, enabling usersto continue to work on checked-out documents.

9. On the Attributes tab, configure the following fields.

Option Description

Attributes Specifies the list of attributes to be inherited from the sourceobject(s) to the target object. Each entry is of the form:

[<update-mode> ]<targetAttribute> [=

<sourceAttribute> | :<literal-value>]

where <update-mode> is:

default – apply the inheritance only if the current targetattribute value is undefined (for example, a blank string) orzero.

merge – merge the attributes of the source and target,avoiding duplicates. (This only applies to repeated attributes– if applied to single-valued attributes, the effect is the sameas default.)

replace – (default) discard the existing target attributevalue(s), if any, and replace it with the source attribute values.This is the only valid option if batch update mode is used.

Update Mode Specifies how the identified target objects are to be updated:

Serial (default) – target objects are processed in sequence, inthe defined order.

Parallel – target objects are processed in parallel using theconcurrent method handling framework.

Batch DQL – target objects are updated as a group using aDQL update query. This option is only valid if a single sourceobject is specified, the target objects are specified in terms ofa DQL qualifier, and the attributes list specifies only replaceoperations.

95


10. On the Folder updates tab, configure the following fields.

Option Description

Update Folders Specifies a set of folders that should be moved or renamedafter updating the attributes of the target object, in theform <source-folder-path>|<DQL-qualifier> =><new-folder-path>|<new-folder-name>. Attributeexpression functions prefixed by the “$” symbol can be usedto refer to attributes of the context object (the first sourceobject, by default). For example,

/Clinical/$arg(old_value)=$new_value

renames a product-level folder in the Clinical cabinet.

Attribute expression functions prefixed by “@” can alsobe used in the right-hand side of the expression to refer toattributes of the existing folder. For example,

dm_folder where folder('/Clinical Trial

Library/$arg(new_value)', descend) and

object_name like '$arg(old_value) -%' =>

@replace("@value(object_name)","$arg(old_value)

-","$arg(new_value) -")

renames all subfolders below /Clinical Trial Library/<new-value> beginning with “<old-value> -”, replacing <old-value>with <new-value> in the existing folder names.

If a folder path is specified in the right-hand side, the existingfolder is renamed if necessary and then moved into thespecified target folder, which is created automatically ifnecessary. For example,

/Clinical/$arg(old_value)/$value(product_code)=>

/Clinical/$arg(new_value)/$value(product_code)

moves an existing product-level folder to a new parent folder.The folder type can also be specified in curly braces in theright-hand path if necessary. For example,

/Clinical/$arg(old_value)/$value(product_code)=

/Clinical/{tmf_folder}$arg(new_value)/$value

(product_code)

creates a new folder of type tmf_folder below the Clinicalcabinet if necessary, instead of using the default folder type(dm_folder).

Renaming and moving existing folders in this way canremove the requirement to apply D2 auto-linking rules tothe individual subordinate objects. Multiple folders to berenamed can be specified; if the specified source folder doesnot exist, the setting is logged as a warning and disregarded.

11. On the Deletion tab, configure the following fields.

96


Option Description

Delete Empty Folders Select this option if you want to delete empty folders afterapplying D2 auto-linking or deleting objects, that is, wherea document is moved from its current folder to some otherlocation, and there are no other documents in the originalfolder.

Delete Target Objects Where Use this setting to selectively remove redundantobjects identified in terms of a DQL qualifier orBoolean attribute expression (that is, an attributeexpression returning a ’’true’’ or ’’false’’ value). Forexample, either the DQL qualifier r_object_type= ’cd_product_info’ or the attribute expression@eq(@value(r_object_type),cd_product_info) canbe used to delete Product Registration Forms.

If the update mode is set to Bulk DQL, a DQL qualifier mustbe specified here; otherwise, it is more efficient to use anattribute expression. Within the attribute expression, useexpressions to refer to attributes of the context object (the firstsource object, by default) and @value() expressions to referto attributes of the target object in each case. The wildcardsymbol * refers to all target objects. Note that the selectionis made before inherited attributes are applied, so the DQLqualifier or attribute expression should refer to the currentobject values, not the new values.

12. On the Post-processing tab, configure the following fields.

Option Description

Reapply D2 Auto-NamingWhere

Specifies a sub-set of the modified target objects that shouldbe auto-named after updating them, in terms of either aDQL Qualifier or a rule expression (i.e. an expression thatevaluates to either true or false, as appropriate). As forupdate_folders, “$” or “@” function prefixes can be usedwithin the rule expression to refer to attributes of the contextobject or modified target object, respectively. For example,

@endswith(@value(r_object_type),_info)

causes D2 auto-naming to apply to all modified target objectswith an object type ending in “_info”; that is , all registrationform object types, but not others.

The wildcard value * can be used to apply D2 auto-namingto all modified target objects. If null or undefined, D2auto-naming is not applied to any of the modified objects,unless –apply_d2_configs true is specified explicitly in themethod arguments.

Reapply D2 Auto-LinkingWhere

Specifies a sub-set of the modified target objects that shouldbe auto-linked after updating them.

97


Option Description

Reapply D2 Security Where Specifies a sub-set of the modified target objects that shouldhave D2 security configurations applied after updating them.

Apply Custom ProcessingWhere

Specifies a sub-set of the modified target objects that shouldhave custom processing applied after updating them.

Class Path of Custom Plug-in The post-processing plug-in class to invoke for eachqualifying object, if any. Specify the fully-qualified classpath. For example, com.documentum.cdf.plugins.MyPluginClass.

Additional plug-in arguments Specifies additional arguments for the custom plug-in.

13. On the Auditing tab, configure the following fields.

Option Description

Apply Auditing To Enables auditing to be applied to a subset of the impactedobjects based on a DQL qualifier; for example, specifyr_object_type = ‘target_type’ in the Apply Auditing To fieldto audit changes on objects of a specific type. Specify “*” toaudit changes on all impacted objects. Note that this canincur a lot of extra processing if many objects are affected.

Audited Event Name Specifies the event name to be recorded in the audit trail foreach impacted item. If null or undefined, auditing is disabled.

Audited Event Arguments Up to 5 arguments can be recorded in the audit trail foreach modified object. The argument values can containattribute expressions, prefixed either by “$” symbols to referto attributes of the source object, or by “@” symbols to referto attributes of the target (impacted) object in each case. Forexample, “@value(object_name)” records the name of thesource object in the audit trail (that which caused the objectto be updated) in each case.

14. Click Next.

The Documentum Controlled Document Foundation Developer API Javadocs provides more details.

Configuring Cascading Attribute RulesDuring document creation or import, a document inherits a set of attributes from a correspondingregistration form. For example, if you create a non-clinical document, the system requires you toassociate the document to a Non-clinical Study Registration Form. The individual document inheritsa set of product and study information from the registration form.

But what happens if the information on the registration form changes after you create the document?The Life Sciences solution Cascading Attributes functionality enables you to update existingdocuments for searching and reporting purposes. You also have the option to leave existingdocuments unchanged for compliance reasons.

98


For example, there may be cases where you want the related documents to take on the new attributevalue from the registration form, such as the addition of a generic name to a product registration.There may be other cases where you do not want the existing documents to take on the new value ofthe attribute, but only new documents, such as the changing of a Principal Investigator at a trial site.And there may still be other cases where you not only want the attribute to be saved on the existingdocuments, but you would like to have business logic invoked to properly represent the change tothe registration form.

See Appendix D, Visual Representation of Attribute Cascading in Life Sciences for a visualrepresentation of how the attributes are cascaded from the registration forms to the documents.

This section defines how to configure the Cascading Attribute rules. By default, the Life Sciencessolutions come with preconfigured cascading attribute rules. Preconfigured Cascading AttributesRules, page 117 provides more information.

To configure the Cascading Attributes rules:

If you modify the cascading attribute rule settings (the cd_auto_inherit_config objects in the/System/CDF/Auto Attribute Inheritance Config folder), restart the Documentum Java MethodServer service on each Content Server node in order to pick up the changes.

1. Log in to D2 Client as a member of cd_admingroup.

2. From the Repository browser, navigate to System/CDF/Auto Attribute Inheritance Config.

3. Right-click an auto inheritance configuration object in the folder, such as Change Product Code,and select Properties.

4. Select Enabled to enable this configuration rule or clear the check box to disable it.

5. On the Rule applicability tab, configure how to apply the rule to object types as described inthe following table:

Field Description


Select whether the system applies the rule automaticallywhen users create the specified object type. Clear thisoption if the rule applies explicitly as part of a lifecycletransition action. For example, in the Change ProductCode function.

Order of precedence Select the order of precedence for this rule when thereare other applicable rules. The system applies rules withthe highest order of precedence first. If two or moreapplicable rules have the same order of precedence,the system applies the rules in alphabetical order byobject_name.

The order in which the rules apply can be significant. Forexample, if two or more rules set default values, the firstrule overrides any subsequent rules.

99


Field Description

Applies to object types Select the object type or types that apply to this rule.For example, Change Product Code applies to thecd_product_info object type.

Condition qualifier (optional) Type an optional DQL qualifier to satisfy before applyingthe rule to the object type. For example, the conditionproduct_code is not null ensures that the ruleonly applies to objects with defined product-code values.

6. On the Inherit from tab, in the Inherit from field, type the source objects that provide theinherited values:• SELECTED: Inherit values from the currently selected object.

• PRIMARY_PARENT_FOLDER: Inherit values from the immediate primary parent folder ofthe selected object.

• PARENT_FOLDERS: Inherit values from each immediate parent folder of the selected object,starting with the primary folder, which is the first folder in the i_folder_id property.

• ALL_FOLDERS [<DQL-qualifier>]: Inherits values from all direct and indirect parentfolders, from the first parent folder to the cabinet level, that match the specified conditions,if any. For example, ALL_FOLDERS tmf_folder where product_code != ’ ’inherits values from all direct and indirect parent folders of type tmf_folder with non-blankproduct_code values.

• <DQL-qualifier>: Inherits values from the specified objects in terms of a DQL qualifier. Youcan use $-expressions within the DQL qualifier to refer to attribute values of the selectedobject, if necessary. For example, the Inherit Clinical Trial Registration Form Info ruleuses the DQL qualifier: cd_clinical_trial_info where clinical_trial_id =$quotedvalue(clinical_trial_id)

If you leave this field blank, the system uses SELECTED as the default.

7. On the Inherit to tab, configure target object inheritance as described in the following table:

Field Description

Inherit to Type the target objects that inherit the relevant attributevalues.

The selection options are the same as for the sourceobjects in the Inherit from field.

For checked-out objects Select how to handle checked-out items.

8. On the Attributes tab, configure attribute inheritance as described in the following table:

100


Field Description

Attributes Specify the list of attributes to inherit from the source tothe target objects. In each case, specify:

• default: where the attribute value should be set bydefault, if it does not currently have a value.

• replace: if the attribute value should always overwritethe current value.

• merge: With repeated attributes, it enables the currentvalues to combine with new inherited values, withoutduplicates. For example, to combine values fromtwo or more registration forms. For example, mergekeywords adds keywords from the source object orobjects that are not currently listed in the keywordsrepeated attribute.

If default, replace or merge is not specified, the systemuses replace.

It is also possible to inherit attributes from a differentattribute of the source object if necessary, by appending=<source-attribute>. For example, replacetitle=study_title copies the value of study_titlefrom the source object to the title attribute of the targetobject.

A literal value can also be specified using the :<value>notation. For example, replace log_entry:Createdby user $USER. You can use $-expressions in the valueto refer to attributes of the source object.

You can modify the predefined rules if necessary toinclude custom attributes, where you have added themto the standard object model. For example, the InheritClinical Trial Registration Form Info rule defines theattributes inherited from Clinical Trial RegistrationForms.

Update mode Select the update mode to use to process the target objects.

Serial update mode processes the target objects one at atime. Use this option if there is only one target object, or asmall number of target objects to update.

Parallel update mode processes the target objectsconcurrently. Use this option if there could potentiallybe many target objects to update and the attribute listcontains default or merge entries.

101


Field Description

Batch DQL update mode processes the target objects as agroup using a DQL update query. Use this option if therecould be many target objects to update and the attributelist contains only replace entries. You can only use thisupdate mode to replace (overwrite) attribute values.

The following example shows the Attributes field for the Inherit Clinical Trial RegistrationForm Info automatic inheritance configuration object:

9. On the Folder Updates tab, specify the list of folders to move or rename.To move a folder and its contents to another location, specify <current-folder-path> =><new-folder-path>

To rename a folder, specify <current-folder-path> => <new-folder-name>.In both cases, you can use $-expressions to refer to attributes of the source object, and you canuse @-expressions to refer to attributes of the target folder. You can also use a DQL qualifier tospecify the source folder if necessary.The following example shows the Folder updates field for the Change Product Code automaticinheritance configuration object:

In the example, $arg(old_value) and $arg(new_value) refer to the old and new productcode values, respectively.

10. On the Deletion tab, configure how to delete objects as described in the following table:

102


Field Description

Delete empty folders Select whether to delete the empty folders that remainafter moving documents and folders to new locations.

Delete target objects where Type a DQL qualifier or a Boolean attribute expression toremove redundant objects.

11. On the Post-processing tab, you can selectively apply Documentum D2 autonaming, autolinking,security, and custom post-processing to the modified objects. Type a DQL qualifier, Booleanattribute expression, or the wildcard symbol * in the applicable fields.For example, in the Change Product Code rule, the system appliesDocumentum D2 autonamingto the relevant Product Registration Form and its associated Clinical Trial RegistrationForms using the following DQL qualifier: r_object_type in (’cd_product_info’,’cd_clinical_trial_info’)

You can apply Documentum D2 autonaming, autolinking, and security selectively to the affectedobjects using this technique. The system applies the DQL qualifier to identify the target objectsbefore applying the inherited attributes, but applies the Documentum D2 configurations after theobjects update. (If there are multiple target objects to update, they process in parallel, regardlessof the Update Mode setting.)It is also possible to apply custom processing to selected target objects using the Apply custompost-processing where field. For example, to apply custom autonaming to the affectedobjects, you can write a Java plug-in and install it in the Java Method Server lib directory. TheDocumentum Controlled Document Foundation Developer API provides details.

12. On the Auditing tab, configure the following fields.

Option Description

Apply Auditing To Enables auditing to be applied to a subset of the impactedobjects based on a DQL qualifier; for example, specifyr_object_type = ‘target_type’ in the Apply Auditing To fieldto audit changes on objects of a specific type. Specify “*” toaudit changes on all impacted objects. Note that this canincur a lot of extra processing if many objects are affected.

Audited Event Name Specify the event name to be recorded in the audit trail foreach impacted item. If null or undefined, auditing is disabled.

Audited Event Arguments Up to 5 arguments can be recorded in the audit trail foreach modified object. The argument values can containattribute expressions, prefixed either by “$” symbols to referto attributes of the source object, or by “@” symbols to referto attributes of the target (impacted) object in each case. Forexample, “@value(object_name)” records the name of thesource object in the audit trail (that which caused the objectto be updated) in each case.

13. Click OK.

103


Extended Attribute ExpressionsD2 supports a number of built-in functions for referencing attribute values within configurationsettings such as $value(attribute). However, in some cases, additional functions are required.The Controlled Document Foundation (CDF) Layer, therefore, supports extended attributeexpressions. These can be used in the following cases:

• In various method arguments passed to CDF server methods in Apply Method lifecycle actions(for example, the –value argument to CDFSetAttributeMethod).

• In the Source and Target DQL qualifiers of cd_auto_inhert_config objects, used in theCDFApplyAttributeInheritanceMethod

The following extended attribute expression functions are supported.

Table 14. Extended attribute expressions

Extended Attribute Expression Functions Description

$user Returns the context username. This is thename of the user who caused this function tobe invoked. This is not necessarily the same asthe session user name, as the method could berunning as a privileged server method on behalfof the user. In this case, the D2 username shouldbe passed to the method in the -context_userargument so that it can be passed to this methodfor use in this function.

$value(<attribute>) Extracts the value of the specified attribute ofthe context object. For repeating attributes,a value index can be specified. For example,$value(r_version_label[0]) refers to theversion number of the object in Documentum. Ifan index is not specified, a comma-delimited listof repeating attribute values is returned.

$quotedvalue(<attribute>) Similar to $value(<attribute>), with thevalue(s) being surrounded by single-quotesand with internal quotes doubled-up. Use thisform when referring to attributes that may haveembedded quotes in them in DQL statements.

104



$dqlvalue(<query>) Runs the specified DQL query and returnsthe result in the first row/column position, ifany. Else, returns a blank string. For example,$dqlvalue(select count(*) fromls_tmf_doc where clinical_trial_id= $value(clinical_trial_id) andartifact_name = $quotedvalue(artifact_name) and is_placeholder =false returns the current number of documentsof the same type as the document/placeholderitself in the same trial.

$datevalue(<attribute>, <format>) Returns a date/time attribute value in thespecified format. In the format pattern, useMM to denote the month in year, and mmto denote the minute in the hour. The timepart can be omitted if necessary. For example,$datevalue(r_modify_date,MM/dd/yyyy)returns the last modify date in US-style dateformat.

$upper(<str>) Converts <str> to upper-case.

$lower(<str>) Converts <str> to lower-case.

$firstupper(<str>) Converts <str> to first-upper format, orproper-case; that is, the first letter of each wordis capitalized. For instance, $firstupper("anexample subject") returns “An ExampleSubject”.

$left(<str>,<n>[,<suffix>]) Extracts the leftmost <n> characters from<str>, and appends the optional <suffix> (ifspecified) if the string is truncated. For example,$left("ABCDEFG",3,"...") returns“ABC...”.

$right(<str>,<n>) Extracts the rightmost <n> characters from <str>.

$before(<str>,<separator>) Extracts the left part of <str> up to but notincluding the sub-string <separator>. Forexample, $before("ABC.DEF",".") returns"ABC".

$after(<str>,<separator>) Extracts the right part of <str> after but notincluding the sub-string <separator>. Forexample, $after("ABC.DEF",".") returns"DEF".

$trim(<str>) Removes leading/trailing spaces from <str>.

$length(<str>) Returns the number of characters in <str>.

105



$maxlength(<attr>) Returns the maximum number of characterspermitted for the specified string-valuedattribute <attr> according to the object model.Not valid for non-string data types.

$substring(<str>,<start>[,<n>]) Extracts up to <n> characters from <str>starting from position <start>, indexed from1. If the third parameter is omitted, allcharacters from the specified start positionto the end of the string are extracted. Forexample, $substring("ABCDEFG",3) returns"CDEFG", and $substring("ABCDEFG",3,2)returns "CD".

$replace(<str>,<find>,<replace>) Replaces all occurrences of <find>with <replace> in <str>. For example,$replace("ABC.DEF.GHI",".","-")returns "ABC-DEF-GHI".

$if(<dql-qualifier>,<true-value>[,<false-value>]) Evaluates a condition expressed as<dql-qualifier> against the context object,and returns either <true-value> or <false-value>depending on whether or not the conditionis satisfied. If the third parameter isomitted, either <true-value> or a blankstring is returned, as appropriate. Forexample, $if("is_placeholder =true","Placeholder","Document")returns "Placeholder" if the context object is aplaceholder, or "Document" if it is a document.

$integervalue(<str>) Returns the numeric integer value of <str>; 0 if<str> is not a numeric value. This can be used toremove leading zeroes from a string of digits.For instance, $integervalue("0000256")returns "256".

$inc(<n>) Returns the integer value n+1.

$dec(<n>) Returns the integer value n-1.

$add(<a>,<b>) Returns the sum of the integer values of a and b.For example, $add("256","1") is "257".

$subtract(<a>,<b>) Returns the difference of the integer values of aand b. For example, $subtract("256","1")is "255".

$position(<str>,<substr>) Returns the first position of <substr> in <str> ina left-to-right scan, indexed from 1; zero if thespecified substring is not found. For example,$position("ABRACADABRA","BR") is "2".

106



$lastposition(<str>,<substr>) Returns the first position of <substr> in <str> ina right-to-left scan, indexed from 1; zero if thespecified substring is not found. For example,$lastposition("ABRACADABRA","BR") is"9".

$pad(<str>,<n>[,<padding-chars>]) Pads <str> to <n> characters by inserting thefirst character of the specified <padding-chars>string (which defaults to the digit 0) at the startof the string as many times as necessary; forexample, $pad("123","6") returns "000123".If <padding-chars> comprises two characters,then the second character is used to signifyan overflow if the string exceeds the specifiedlength. For example, $pad("100","2","0*")returns "**".

$default(<str>,<default-value>) Returns <default-value> if <str> is a blankstring; otherwise it returns <str>. For example,$default($value(title),"Title isundefined") returns the value of the titleattribute if it is non-null, otherwise it returns"Title is undefined".

$lookup(<str>,<dictionary>,<alias|locale>) Retrieves the value of <str> from the specifiedD2 dictionary, using the specified alias or localecode to retrieve the value. Use this function toconvert strings to localized values or encodedvalues via D2 dictionaries. For example,$lookup("FR","TMF Countries","en")checks the en locale value (that is, Englishlanguage value) of the country code FR in theTMF Countries dictionary. In this case, the resultis "France".

$list(<attribute>,<expression>[,<separator>]) Evaluates the specified expression for an attributevalue or series of repeating attribute valuesand combines the results into a list. Within theexpression string, the "~" (tilde) character mustbe used to prefix embedded attribute expressionfunctions instead of the "$" (dollar) character.This is to prevent the attribute expressionfunctions from being evaluated prematurely.Use ~item or ~item() to refer to the list itemvalue in each case. The expression string mustalso be quoted if it contains embedded commas.For example, $list(keywords,"~upper(~left(~item,3))",",") takes the firstthree characters of each keyword attribute valuedefined for the context object, and convertsthem to uppercase, combining the values into

107


Extended Attribute Expression Functions Descriptiona comma-separated list. If a separator is notdefined, the values are concatenated withoutseparators.

$case(<expression>,<matching-pattern-list>,<result-list>)

Selects the ith value from <result-list>, wherethe value of <expression> matches the ithvalue in <matching-pattern-list>, comprisinga comma-delimited list of literal values orregular expressions. If no matching patternis found, a blank string is returned. If thelast item in <matching-pattern-list> is “*”(the wildcard character), it will match anyexpression; in this way, the last value of<result-list> is returned by default. For example,$case($value(domain),’Clinical,Non-Clinical,*’,’Clinical Trial,Pre-Clinical Study,Other’) returns “ClinicalTrial” if domain = Clinical, “Pre-Clinical Study”if domain = Non-Clinical, and “Other” if domainis some other value.

$lookup(<key-path>,<taxonomy>,<dictionary>[,<alias|locale>])

Extends the dictionary lookup function toretrieve a value from a D2 taxonomy. The firstparameter begins with the path prefix character“/”, and specifies the location of a parent node inthe taxonomy as a series of key values separatedby “/” characters. The path “/” denotes the rootnode in the taxonomy. The second parameter isthe D2 taxonomy configuration name. The thirdparameter denotes the subordinate D2 dictionaryname used in the taxonomy for the requiredvalue, which may be several levels below theparent node, provided that the interveninglevels in the taxonomy contain only one value.If multiple values are defined at the specifiedlevel, only the first value is returned. If an aliasor locale is not specified in the fourth parameter,the subordinate key value itself is returned. Forexample, to lookup the corresponding artifactnumber for a particular TMF artifact in the DIATMF 2.0 reference model, use $lookup(‘/DIATMF 2.0/$value(artifact_name)’,TMFClassification by Artifact,TMFArtifact Numbers).

Characters outside of function calls remain unchanged. Function names are not case-sensitive.Nested subexpressions can be specified in function argument lists, which are then evaluatedrecursively. There is no defined limit on the level of nesting that can be used.

Function arguments should be quoted if they contain embedded commas, so thatthey are parsed correctly. Either matching single or double quotes can be used for

108


these. For example, specify $substring(’$value(object_name)’,10,20) or$substring("$value(object_name)",10,20) if the object_name attribute value canpotentially contain commas. Unrecognized functions are not processed, and are passed into theresulting string unchanged.

Method arguments containing attribute expressions can be specified in D2 lifecycle configurations.However, D2 evaluates them where functions are recognized (for example, $value(...) and$dqlvalue(...) expressions) prior to passing the argument values to the method. To preventD2 from doing this, the alternative function prefix symbol “@” is supported – for example,"@dqlvalue(select ... where ...)”. These expressions are not recognized by D2 and arepassed to the method unresolved, so they can be evaluated by the method itself.

The Documentum Controlled Document Foundation Developer API Javadocs provides more details.

Context User Support in CDF MethodsCertain CDF methods when called by a lifecycle action, do not pass the context user argument.Instead, they use the Administrator session to run the method. The following table lists the CDFmethods that support context user, the operations performed by the context user, and whether thecontext user is passed in the Lifecycle configuration.

109


Table 15. Context User Support in CDF Methods

Methods Is Context User Param Applicable? Description Lifecycle Configuration Setup Comments

CDFAppendRepeatingAttributesMethod

CDFApplyAttributeInheritanceAsynchMethod

Y D2 Server method that appends valuesfrom one set of attributes to another,ensuring that the data is maintained in atable format (no missing cells).

Does not pass the context user in anyLifecycle method call in the defaultconfigurations.

Supports the -context_user argument.Method is executed with anAdministrator session. Contextuser is used to create audit entry.

CDFApplyAttributeInheritanceMethod Y D2 server method that copies ormerges attributes from arbitrary sourceobjects to arbitrary target objectsassociated with the currently-selectedobject (or the selected object itself)according to pre-configured attributeinheritance rules, defined in thecd_auto_inherit_config configurationobjects in the Documentum repository.



CDFApplyD2ConfigurationsMethod N NA

CDFAuditMethod Y D2 Server method that logs a specifiedevent in the Documentum audit trail.

Context user is mandatory. Supports the -context_user argument.Method is executed with anAdministrator session. Contextuser is used to create audit entry.

CDFCloseChangeRequestMethod Y The method is invoked by a user actionor a lifecycle batch to close the CIPChange Request based on its associateddocuments status. Currently, there is nosupport of context user available in themethod. Therefore, when the ChangeRequest is closed by a Coordinator, theaudit shows Administrator instead ofthe user name.

CDFCopyRelatedObjectAttrsMethod Y D2 Server method that copies specificattributes to or from other repositoryobjects related to the selected documentthrough dm_relations, for example, tosynchronize attributes from a documentto a Change Request or from a ChangeRequest to a document.


Supports the -context_user argument.Method is executed with anAdministrator session. Contextuser is used to update last modifier.

CDFCopyRelationMethod Y D2 Server method that copiesrelationships between the selecteddocument and a parent document, forexample, to repurpose a D2_COPY_OFrelation, which is created by D2 whena document is created with anotherdocument selected.

Not used in any Lifecycle action in thedefault configurations.

Supports the -context_user argument.Method is executed with anAdministrator session. Contextuser is not used in the logic.

110



CDFCreateObjectAsynchMethod Not used in any Lifecycle action in thedefault configurations.

CDFCreateObjectMethod

Y D2 Server method that creates a newobject of a specified type, optionallyinheriting content from a specifiedtemplate document, attributes from thecurrently-selected object, establishing arelation to that object, encapsulating thatobject as a child of a new parent virtualdocument and adding the new object toexisting virtual documents.



CDFCreateRelationMethod Y D2 Server method that establishesrelationships between the selected objectand a set of target objects identified bya DQL query, or an individual targetobject identified by object type and objectname.



CDFD2ContextOrderExportMethod N NA

CDFD2ContextReorderMethod N NA

CDFDeleteObjectAsynchMethod Y Does not pass the context user in anyLifecycle method call in the defaultconfigurations.

CDFDeleteObjectMethod Y

D2 Server method that deletes a specifiedobject, or a set of objects associated withit (for example, related objects).

Passes the context user in all the Lifecyclemethod call in the default configurations.


CDFDeleteRelationMethod Y D2 Server method that removesrelationships for the selected document,for example, to detach change requestsfrom an "Effective" version of adocument.



CDFHardDeleteMethod Y CDF method to perform Hard Deleteon documents by user based on thecd_delete_config specified in docbase.Audittrail entries to be captured prior toHard Delete, along with reason code.

Not used in any Lifecycle action in thedefault configurations.


CDFLoadAttributesFromContentFileMethod N NA

CDFNotifyUsersAsynchMethod Y Does not pass the context user in anyLifecycle method call in the defaultconfigurations.

CDFNotifyUsersMethod Y

Sends notification messages to users inthe appropriate roles on a set of objectsthrough the D2 InBox, optionally routingmessages through email. Not used in any Lifecycle action in the

default configurations.

Supports the -context_user argument.Method is executed with anAdministrator session. Context userused in resolving attribute expression.

CDFReAssignWorkflowPerformers N NA

CDFSaveAttributesInContentFileMethod N NA

111



CDFSetAttributeMethod Y D2 server method that sets a specifiedattribute on an object, or set of objectsidentified by a query, optionallyusing D2 dictionary lookups, attributeexpressions, and re-application of D2configurations to the specified objects.Note that this method is used to updateobjects with attribute values that can becomputed up-front, in terms of attributeexpressions. To set attribute valuesbased on DQL query restuls, you can usethe UpdateAttrsViaQuery method as analternative.

Does not pass context user in anyLifecycle method call in the defaultconfigurations.


CDFSetVersionNumberMethod N NA

CDFSetWFLists Y The method is responsible for updatingthe workflow attributes of the document.The method is invoked when thedocument is created in the (init) state ofits lifecycle. Therefore, it must run oncontext user session to capture the auditcorrectly.

CDFUpdateAttrsViaQueryMethod Y D2 Server method that runs a DQL"select" query and uses the resultsto populate the attributes of thecurrently-selected object, objectsreturned by the query itself, or objectsreturned by a separate query. Notethat this method is designed to be usedto update objects with attribute valuescomputed through DQL queries. Ifthey can be computed up-front, youcan use the SetAttribute method as analternative.

Does not pass context user in fewLifecycle method call in the defaultconfigurations.


CDFUpdateChangeRequestAttributesMethod Y The method is responsible for updatingthe change request attributes when thechange request is checked in by addingSOP documents to it. The method isinvoked when the document is checkedin by the user. Therefore, it must run oncontext user session to capture the auditcorrectly.

112



CDFUpdateRepeatingAttribute Y D2 Server method that updates arepeating attribute in place, adding,updating, or deleting a specific value asindicated.

Does not pass context user in anyLifecycle method call in the defaultconfigurations.


CDFVirtualDocumentMethod Y D2 server method that enables virtualdocument structures to be processed invarious ways:• component documents can be addedor removed,

• "snapshots" (assemblies) taken;lifecycle transitions applied selectivelyto the constituent documents,

• attributes propagated from the root tothe relevant subordinate documents,and

• validation to be applied on thestructure prior to invoking lifecycleoperations on it.

Passes the context user in all theLifecycle methods calls in the defaultconfigurations.

Supports the -context_user argument.Method runs in a user session if contextuser is passed. Context user is used tocreate audit entry.

CDFWorkflowManagerMethod Y D2 Server method that halts, resumes,restarts, or terminates D2 workflows.

The method is no longer in use in thedefault configurations.


SSVDiscoverSubmissionFoldersMethod Y Does not pass the context user in anyLifecycle method call in the defaultconfigurations.


SSVImportSubmissionMethod Y Passes the context user in all theLifecycle methods calls in the defaultconfigurations.


TMFAdminMethod N NA

TMFBulkUploadMethod Not used anymore

TMFCreateLinks N NA

TMFImportExportPackageAsynchMethod

TMFImportExportPackageMethod

Y Provides methods for initializing,zipping, and unzipping TMF documentpackages containing TMF documentcontent and metadata, suitablefor exporting, offline editing, andre-importing.

Passes context user in all theLifecycle methods calls in the defaultconfigurations.

Supports the -context_user argument.Method runs in a user session if thecontext user is passed. Context user isused to create audit entry.

113



TMFNotifyDocumentsNeedIndexing N NA

TMFReconcileArtifactsAsynchMethod Does not pass the context user in a fewLifecycle method calls in the defaultconfigurations.

TMFReconcileArtifactsMethod

Y D2 Server method that reconcilesa set of TMF documents against afile plan, as defined in a ClinicalTrial Registration Form (CTRF) inDocumentum. As a result of this process,any missing TMF placeholders forrequired, recommended, or optionalartifacts specified in the file plan aregenerated as required, and the existingplaceholders with matching documentsare updated or removed, depending onwhether or not they refer to repeatableor non-repeatable artifacts, respectively.Redundant placeholders referring tounplanned artifacts (for example, thosethat have been removed from the fileplan) are also deleted. The currentprogress statistics for the CTRF are thenupdated for each planned stage, plus thetrial overall; the validation status andcurrent progress of each planned artifactis also recorded in the file plan, if fileplan validation or progress tracking isenabled.

Passes the context user in all theLifecycle methods calls in the defaultconfigurations.


TMFUpdateContributorGroupsMethod N NA

TMFUpdateFolderAccessForDocumentMethod Not used in TMF methods.

TMFUpdatePlaceholderForDocumentMethod Y D2 Server method that copies, updates,or deletes the TMF artifact placeholderfor a document that has been uploadedby the user, either as a new version ofthe placeholder itself, or as a stand-alonedocument.

Passes the context user in a fewLifecycle method calls in the defaultconfigurations.


114


Special Naming ConventionsThe Special Naming Conventions alias is supported in the TMF Unique Artifacts dictionaryconfiguration in D2. The alias can be used to override the default naming conventions for placeholdersand/or documents on a per-artifact basis. The alias values are applied in the following ways:

• By the reconciliation process when placeholders are generated.

• By document lifecycle actions when TMF documents are created, as and where applicable.

If an alias value is not defined for a particular artifact, the standard D2 auto-naming rules apply. Thespecified naming convention can be applied later so that it can include references to propertiesgenerated by D2 auto-naming, such as document ID numbers. The uses_special_naming_conv flagis also set to true for these items to enable subsequent D2 auto-naming to be suppressed for thesedocuments.

Artifact-based Autonaming and Attribute Lists(LSTMF)To add flexibility to the eTMF system, the UI can specifically display a set of attributes dependingon the TMF 3.0 reference model artifact being worked on. Additionally, the naming convention ofthe object is based on the values of the attributes on the object. The TMF Unique Artifacts Names3.0 dictionary uses a Document Naming Convention alias to set the object name of the documentduring certain lifecycle transitions using the artifact_name attribute as the key. The Attributes andRequiredAttributes aliases are used to get the attribute values through the optional and mandatorytext fields. These fields appear on the property page of the document during creation or indexing.The attribute, variable_part_of_name, captures any additional information that should be appendedto the name of the document in the D2 Client. The Instructions alias provides the instructions topopulates the Variable Part of Name field, which is available in the property pages. The followingimage shows the aliases in a sample TMF Unique Artifacts Names 3.0 dictionary:

The system sets a new attribute, attribute_list, that contains a pipe delimited list of attributes that areappropriate for the selected document. This attribute is also set by the CDFSetAttributeMethod, usingthe TMF Unique Artifact Names dictionary Attributes alias to set the attribute_list during certainlifecycle transition using the artifact_name attribute as a key. During indexing, the system gets theattribute_list value in real time from the dictionary, using the artifact_name of the placeholderselected during indexing.

115


Each attribute that is part of this attribute_list is placed on the property page(s) with a visibilitycondition resulting in the attribute being displayed only if the attribute appears in the attributelist defined for that artifact.

Note: Attributes should not be editable when the document is in the Effective (Approved or Final)state as this can cause the object name to change. If there are temporal attributes that are alwayseditable, care should be taken that these are not part of the naming convention because after adocument is approved, its object name should not change.

In the case of Bulk Import/Export (BIE), the functionality has been updated to incorporate theRequiredAttributes aliases for an artifact and use them accordingly in the autonaming process. TheBIE spreadsheet has been updated with 41 additional columns and the schema has been updatedaccordingly to store the values for required attributes for the artifacts during BIE. When creating theBIE spreadsheet, the user has to manually add the required attributes to each of the artifacts listed inthe spreadsheet to ensure that the autonaming works as expected after BIE. For the list of requiredattributes for a particular artifact, refer to the TMF reference model.

Configuring the Existing Dictionary for Artifact-basedAutonaming

Although the artifact-based autonaming and attribute list is available out-of-the-box in the TMFUnique Artifacts Names 3.0 dictionary, this configuration can be extended to the existing dictionariessuch as the TMF Unique Artifacts Names 2.0 dictionary. To configure the existing dictionary tosupport artifact-based autonaming and attribute list:




4. Under Dictionaries, select TMF Unique Artifact Names 3.0 and click Export.

5. Select Excel as the format and click OK.

6. Under Dictionaries, select the existing dictionary such as TMF Unique Artifact Names 2.0and click Export.

7. Select Excel as the format and click OK.

8. Open both dictionaries and copy the Document Naming Convention, Attributes,RequiredAttributes, and Instructions columns from TMF Unique Artifact Names 3.0 to TMFUnique Artifact Names 2.0.

9. For each artifact listed in the TMF Unique Artifact Names 2.0 dictionary, update the values inthese columns as required.

10. Under Dictionaries, select TMF Unique Artifact Names 2.0 and click Import.

11. Import the updated TMF Unique Artifact Names 2.0 dictionary Excel sheet and click Save.

116


Preconfigured Cascading Attributes RulesThe following table describes the preconfigured cascading attribute rules included in DocumentumeTMF, Documentum R&D, and Documentum SSV:

ConfigurationRule Name

SolutionModules

Description Parameters (MethodArguments)

ChangeApplicationNumber

DocumentumR&D

DocumentumSSV

Propagates Application Numberchanges to the relevant documents.

$arg(old_value) =Previous ApplicationNumber

$arg(new_value) = NewApplication Number

ChangeApplicationNumber forSubmissionElements

DocumentumSSV

Propagates Application Numberchanges to the relevant submissionelements.



ChangeApplicationNumber forSubmissionFolders

DocumentumSSV

Propagates Application Numberchanges to the relevant submissionfolders.



ChangeApplicationNumber forSubmissionRegistration Form

DocumentumSSV

Propagates Application Numberchanges to the relevant submissionregistration form.



ChangeApplicationNumber forSubmission SubFolders

DocumentumSSV

Propagates Application Numberchanges to the relevant submissionsub folders.



Change ProductCode

DocumentumeTMF

DocumentumR&D

DocumentumSSV

Invokes through the ChangeProduct Code lifecycle action forProduct Registration Forms. Itpropagates product code changesto the relevant documents andregistration forms.

$arg(old_value) =previous product codevalue

$arg(new_value) = newproduct code value

117



SolutionModules


Combine ProductCodes

DocumentumeTMF

DocumentumR&D

DocumentumSSV

Invokes through the CombineProduct Codes lifecycle action forProduct Registration Forms. Itmerges documents and associatedregistration forms for one productinto another, and deletes thecurrent Product Registration Form.

$arg(old_value) =previous product codevalue

$arg(new_value) = newproduct code value

get Sourceinformation toCopy

DocumentumQ&M

Inherits the source documentinformation to newly-createddocument using technologytransfer.

None

Inherit ControlledFolder RoleChanges ToSub-Folders

DocumentumSSV

Applies role-based access controlsto the subordinate controlledfolders of a parent controlledfolder, in a top-down manner.

-event "Update"

Inherit ControlledFolder RoleChanges ToSubordinateDocuments

DocumentumSSV

Applies role-based access controlsto the subordinate controlleddocuments of a parent controlledfolder, in top-down manner(including historic versions).

-event "Update"

Inherit ClinicalTrial RegistrationForm Info

DocumentumeTMF

DocumentumR&D

Invokes automatically whenever anew Documentum R&D ControlCategory 1-3 Clinical or ClinicalTMF document is created. It copiestrial-related attributes from therelevant Clinical Trial RegistrationForm to the new document.

None

Inherit Non-Clinical StudyRegistration FormInfo

DocumentumR&D

Invokes automatically whenevera new Documentum R&DControl Category 1-3 Non-clinicaldocument is created. It copiesnon-clinical project-relatedattributes from the relevantNon-clinical Study RegistrationForm to the new document.

None

Inherit ProductRegistration FormInfo

DocumentumeTMF

DocumentumR&D

DocumentumSSV

Invokes automatically whenevera new Control Category 1-3document is created in anydomain. It copies product-relatedattributes from the relevantProduct Registration Form to thenew document, where applicable.

None

118



SolutionModules


Inherit ProjectRegistration FormInfo

DocumentumR&D

Copy project-related information tothe Trial Registration Form basedon the project settings.

None

Inherit QualityProjectRegistration FormInfo

DocumentumR&D

Invokes automatically whenever anew Documentum R&D ControlCategory 1-3 Quality document iscreated. It copies project-relatedattributes from the relevant QualityProject Registration Form to thenew document, where applicable.

None

Inherit RAPApplicationAnd SubmissionRole Changes ToRARFs

DocumentumR&D

DocumentumSSV

Propagates role changes forRegulatory Activity PackageRegistration Forms (RAPs) to theassociated Regulatory ApplicationRegistration Forms (RARFs).

-event "Update"

-if "reg_activity_permit_reqd = ’WRITE’"

Inherit RegulatoryApplicationRegistrationForm Info ToCorrespondence

DocumentumSSV

Copy Regulatory Applicationrelated attributes from therelevant Regulatory ApplicationRegistration Forms to a newCorrespondence document, basedon the application_descriptionsetting.

None

Inherit RegulatoryApplicationRegistration FormInfo To RegulatoryAdministrative

DocumentumR&D

DocumentumSSV

Copy Regulatory Applicationrelated attributes from therelevant Regulatory ApplicationRegistration Forms to a newRegulatory Administrativedocument, based on theapplication_description setting.

None

Inherit RegulatoryApplicationRegistration FormRoles To RDDocuments

DocumentumR&D

DocumentumSSV

Copy role-based attributes from therelevant Regulatory ApplicationRegistration Forms to a newregulatory documents, based onthe application_description setting.

None

Inherit SingleRegulatoryApplicationRegistration FormInfo

DocumentumSSV

Copy Single RegulatoryApplication-related attributesfrom the relevant RegulatoryApplication Registration Form toa new document, based on theapplication_description setting.

None

Inherit SRFRole ChangesTo SubmissionDocuments

DocumentumSSV

Applies role-based security toarchived submission documentsbased on the associated SubmissionRegistration Form (SRF).

-event "Update"

119



SolutionModules


Inherit SRFRole ChangesTo SubmissionFolders

DocumentumSSV

Applies role-based security toarchived submission folders basedon the associated SubmissionRegistration Form (SRF).

-event "Update"

Inherit SRFRole ChangesTo SubmissionSubfolders

DocumentumSSV

Applies role-based security toarchived submission subfoldersbased on the associated SubmissionRegistration Form (SRF).

-event "Update"

Inherit TMFPlaceholder Info

DocumentumeTMF

Invokes automatically whenever anewClinical TrialMaster File (TMF)Control Category 1-3 document iscreated. It copies attributes fromthe relevant placeholder to the newdocument, where applicable.

None

MD InheritClinical TrialRegistration FormInfo

DocumentumR&D

Copy trial-related attributesfrom the relevant ClinicalTrial Registration Form to anew document, based on theclinical_study_num setting.

None

MD InheritRegulatoryApplicationRegistration FormInfo To RegulatoryAdministrative

DocumentumR&D

Copy Regulatory Application-related attributes from therelevant Regulatory ApplicationRegistration Forms to a newRegulatory Administrativedocument, based on theapplication_description setting.

None

Merge ProductInfo to PRF

DocumentumeTMF

DocumentumR&D

DocumentumSSV

Invokes as part of the CombineProduct Codes lifecycle action forProduct Registration Forms. Itcopies product-related informationfrom one Product RegistrationForm to another.

$arg(old_value) =source product codevalue

$arg(new_value) =target product codevalue

Move ClinicalTrial to NewProduct

DocumentumeTMF

DocumentumR&D

Invokes through the Reassign toProduct lifecycle action for ClinicalTrial Registration Forms. It enablesa set of clinical trial documents tobe moved to a different product.

$arg(old_product_code) = previous productcode value

$arg(new_product_code) = new productcode value

120



SolutionModules


Move SiteRegistration toNew Location

DocumentumeTMF

Invokes through the Change SiteLocation lifecycle action for SiteRegistration Forms. It updates aTMF site registration to refer to adifferent country.

$arg(site_id) = siteidentifier code

$arg(site_name) = sitename / label

$arg(old_country_code) = previous countrycode value

$arg(old_area_code)= previous area code(U.S. state code, whereapplicable)

$arg(new_country_code) = new countrycode value

$arg(new_region) =new region code value

$arg(new_area_code) =new area code (U.S.state code, whereapplicable)

Move TMF SiteDocuments toNew Location

DocumentumeTMF

Same as Move Site Registration toNew Location. (It is part of thesame operation.)

Same as Move SiteRegistration to NewLocation.

Rename Site DocumentumeTMF

Invokes through the Change SiteName lifecycle action for SiteRegistration Forms. It updates aTMF site registration to refer to adifferent site name.

$arg(site_id) = siteidentifier code

$arg(old_site_name)= previous site name /label

$arg(new_site_name) =new site name / label

Rename Site-levelTMF Documents

DocumentumeTMF

Same as Rename Site. (It is part ofthe same operation.)

Same as Rename Site.

Update ClinicalTrial Info

DocumentumeTMF

DocumentumR&D

Invokes through the Update TrialInfo lifecycle action for ClinicalTrial Registration Forms. Itreapplies updated inherited clinicaltrial information to the relevantdocuments.

None

121



SolutionModules


Update ProductInfo

DocumentumeTMF

DocumentumR&D

DocumentumSSV

Invokes through the UpdateProduct Info lifecycle actionfor Product Registration Forms.It reapplies updated inheritedproduct information to therelevant documents and associatedregistration forms.

None

Update Referencefrom Document

DocumentumeTMF

Copy metadata from the selectedproduct document to its references.

None

Update ReferenceNew Study

DocumentumeTMF

Update the metadata of a referencefrom its study.

None

Using a Custom Attribute Inheritance Rule toReapply D2 Configurations to Selected ObjectsOccasionally it may be necessary to reapply D2 configurations, such as autonaming, autolinking,and security to existing objects in the repository. For example, after you change the auto-filing rulesor upgrade from a previous release of the Life Sciences Solution that uses new auto-filing rules. Toreapply the D2 configurations, you can create a custom attribute inheritance rule and invoke itthrough a DQL statement.

1. To create a custom attribute inheritance rule, log in to D2 Client as a member of the ControlledDocument Administrators group (cd_admingroup) or the installation owner (for example,dmadmin).

2. Select New > Content from the menu bar.

3. In the Creation profile field, select System Adminstration.

4. In the Document Type field, select Auto Inherited Attributes Rule and click Next.

5. On the Edit properties page, in the Configuration name field, type a name for the attributeinheritance rule. For example, Reapply D2 Configurations. Type an optional description toexplain its purpose. The system automatically enables the rule by default.

122


6. On the Rule applicability tab, configure the rule as described in the following table:

Field Description


Do not select this option. You should only enable it forrules that the system automatically applies when userscreate documents. For this rule, you invoke it only whennecessary using a DQL query.

Order of precedence Leave this option set to 1- High. You can ignore thisoption because it only applies when multiple rules applyto the same object to ensure that the rules apply in theappropriate order.

Applies to object types Select the wildcard symbol * (any object type). This fielddefines the scope of the rule by identifying the documentsin the repository that apply to the rule.

When you execute the rule, you specify the cabinet andfolder path of the top-level folder containing the relevantdocuments explicitly in a –folder_path methodargument. It is not necessary to specify an –id argument(a context object) in this field.

7. Skip the Inherit from tab. This tab specifies the source objects used for copying inheritedattributes and this rule does not apply inherited attributes.

8. On the Inherit to tab, specify the target objects to process as described in the following table:

123


Field Description

Inherit to Type aDQL qualifier (of the form <object-type>[(all)] where <criteria>) that identifies the targetobjects to update.

For this rule, type:

cd_controlled_doc(all) where folder(’$arg(folder_path)’, descend)

which selects all controlled documents at or below aspecified folder including historic versions. (You specifythe folder in the –folder_path method argument whenyou execute the rule.)

To only update the CURRENT versions, omit (all) afterthe object type.

For checked-out objects Specify how to handle checked-out documents.

For this rule, select Skip update (default). Any currentlychecked-out documents do not update until the relevantusers check them in. At that time, Documentum D2reapplies the configurations.

You can also elect to force check-ins or temporarily bypassthe check-out locks for these documents. If you use theforce check-in or bypass options, they could impact userswho are currently working on those documents.

9. Skip the Attributes and Folder updates tabs. They do not apply to this rule.

10. On the Deletion tab, select Delete empty folders. When documents auto-file to new locations,the system deletes any remaining empty folders automatically, including any empty parentfolders along the chain towards the cabinet level.

11. On the Post-processing tab, type the wildcard symbol * in the following Reapply D2configurations fields:• Reapply D2 autonaming where

• Reapply D2 autolinking where

• Reapply D2 security where

Leave the Custom processing fields blank.

12. On the Auditing tab, type or select values in the fields.

13. Click Next. The system creates the rule in the /System/CDF/Auto Attribute Inheritance Configfolder with the other rules.

14. To execute the rule, log in to Documentum Administrator or IDQL as the repository installationowner (for example, dmadmin) and issue a DQL statement of the following form:execute do_method with method = 'CDFApplyAttributeInheritanceMethod',arguments = '-docbase_name <repository-name> -user_name dmadmin

124


-password "" -auto_inherit_config "Reapply D2 Configurations"-folder_path "<repository-folder-path>'

You do not need a password if you execute the query from the Documentum Content Serveras the installation owner.For example:execute do_method with method = 'CDFApplyAttributeInheritanceMethod',arguments = '-docbase_name documentum -user_name dmadmin -password"" -auto_inherit_config "Reapply D2 Configurations" -folder_path"/Clinical/Cardiology-Vascular/Vasonin"'

The method should return a success code when it is completed. The Java Method ServerApplications log file provides additional details. For example:%DOCUMENTUM%\jboss7.1.1\server\DctmServer_MethodServer\logs\ServerApps.log

You can tune the performance of the method by adjusting themax_threads and content_serverssettings in the Documentum D2 System Parameters dictionary.

Extensions to Cascading Attributes andAuto-Inheritance Rules to Support AuditingTo support auditing of role changes at the individual object level, extensions to the existing CDFcascading attributes functionality and the cd_auto_inherit_config object type have been made. Thenew options enable auditing to be applied selectively to objects modified by a cascading attributesrule, or a sub-set of those objects, based on DQL qualifiers.

The audited event code and optional audit trail arguments are specified in the cd_auto_inherit_configrule as and where appropriate, and can include attribute values of the source folder or target object ineach case, via $-prefixed and @-prefixed attribute expressions. This mechanism that can be extendedto other cascading attribute rules as required.

When applying D2 auto-naming, the event code is taken into account, that is, the auto-naming rule fornew objects is used for the Create events, and the auto-naming rule for existing objects is used for theUpdate events. This enables auto-numbering to be applied selectively to newly-created objects only.

The following table lists the news attributes added to the cd_auto_inherit_config object type tosupport the auditing of role changes:

Attribute Type Description

apply_auditing_to CHAR(255) Enables auditing to be applied to a subsetof the impacted objects based on a DQLqualifier, just as for the existing apply_d2_auto_naming_to, apply_d2_auto_linking_to,apply_d2_security_to, and apply_plugin_tosettings. If left blank, auditing is disabled. Ifset to “*”, it applies to all impacted objects,otherwise it applies to those impacted objectsthat meet the specified criteria (For example,r_object_type = ‘cd_reg_submission_info’).

125


Attribute Type Description

audited_event_name CHAR(64) Specifies the event name to be recorded inthe audit trail for each impacted item, whereapplicable. If null or undefined, auditing isdisabled.

audited_event_args CHAR(200)REPEATING

Specifies a list of arguments to be recordedin the audit trail. Up to five arguments canbe specified, and they may contain attributeexpressions prefixed by “$” symbols referringto attributes of the context object (the firstsource object, by default), and attributeexpressions prefixed by “@” symbols referringto attributes of the target (impacted) object ineach case, as and where applicable.

automatic_events CHAR(32)REPEATING

Specifies the optional event code(s) for whichthis rule is applicable. This is used to filter“automatic” rules, for example, the applicableevents can be Create or Update (or both).

Extensions to the CDF ApplyInheritedAttributes Method

The existing Auto Inheritance Configuration properties page includes an Auditing tab, where newauditing properties can be configured as shown in the following image:

The automatic_events setting has been added to the main Rule Applicability tab, after theAutomatically applies to new objects setting. This setting becomes visible only if the Automaticallyapplies to new objects option is selected. A D2 dictionary, Auto Inheritance Event Codes, has beendefined for this, with the values “Create” and “Update”.

126


In the CDF ApplyAttributeInheritance server method:

• An optional –event argument enables the running of automatic rules based on specific events. Thedefault value for this is “Create”. This is to simplify the lifecycle configuration. It enables lifecycletransitions to invoke the method for either “Create” or “Update” events, as appropriate, withouthaving to specify the rule names explicitly. If the rules to apply are not specified explicitly in the–auto_inherit_config argument, it identifies all rules applicable to the selected object type thatare enabled, designated as automatic, and have a matching event code in the automatic_eventslist. For backwards-compatibility, automatic rules without automatic_events defined for themare considered as “Create” events.

• The auditing precondition rules are applied to each modified target object, and a post-processingtask generated for each qualifying object. These can then be submitted for processing in parallel ordistributed manner.

• The existing task processing method for each object has been extended to generate an audittrail entry for each modified object.

127


128

Chapter 8Workflows

Workflows comprise tasks that provide business logic to the lifecycle phases and pass content fromone state to another.

Workflow RolesThe Life Sciences solution provides a number of predefined, generic workflow templates andassociated D2 workflow configurations to process controlled documents. The number of states andworkflow task performers depends on each workflow.

Note: Workflow availability is determined by the type of document.

The typical workflow initiator for a workflow is a Document Author or Coordinator. A workflowinitiator is also the workflow supervisor. When an initiator starts a workflow, a dialog box appearswhere the workflow task performers must be specified. It is not possible to start a workflow withoutspecifying the performers.

The workflow task performers must be of the following roles:

• Document Author

• Reviewer

• Format Reviewer

• Approver

• QO Approver (Documentum Q&M only)

• Coordinator

• TBR Reader (Documentum Q&M only)

Workflow DiagramsThe Life Sciences solutions provide generic workflows to process Control Category 1–3 documents.Workflows are composed of tasks that provide business logic to the lifecycle phases and pass contentfrom one state to another.

129

Workflows

For Collaborative Editing (Categories 1 - 3)

Use this workflow to send a Control Category 1-3 document for collaborative editing before sendingit to one of the review and approval workflows. This workflow is configured for all solutions.

The system automatically performs the tasks indicated by the icon. Users with specific roles

perform the tasks with the icon. Users perform the tasks described in the following table:

User Task Description

Edit document Reviewers review and edit the document.

Incorporate changes Authors incorporate the changes from each Reviewer.

Submit for Review and Approval (Category 1)

Use this workflow to send Control Category 1 documents for formal review and approval. Thisworkflow is configured for LSQM only.

Users perform the tasks described in the following table:


For Review Reviewers review and annotate the content.

130

Workflows


Draft Authors review feedback on the document. After the Approver demotes thedocument to Draft, the Author can skip the review task after making thechanges and can send the document directly for approval.

Draft – Do not allowskip

Authors review feedback on the document and resend the edited draftdocument for another round of review. Authors cannot skip the reviewof the document.

For Approval Approvers approve the document. The document must be electronicallysigned on approval.

For Approval no Sig Approvers approve the document. Electronic signature is not required onapproval.

QO Approval Quality Organization (QO) Approvers approve the document.

Correct InvalidApprovers

The system validates the list of participants assigned as Approvers/QOApprovers of the document and checks if the workflow initiator is assignedas the sole participant in these roles. If so, the document is rejected back tothe workflow initiator who must correct the invalid list of Approvers.

Ready to MakeEffective

After all of the review and approval tasks are finished, the DocumentCoordinator releases the document to the Effective/Approved/Final state.

Submit for Approval (Category 1)

Use this workflow to send Control Category 1 documents directly for approval and skip the formalreview. This workflow is configured for LSQM only.



Draft Authors review feedback received from Approvers on the document.

For Approval Approvers approve the document. The document must be electronicallysigned on approval.

For Approval no Sig Approvers approve the document. Electronic signature is not required onapproval.

131

Workflows


QO Approval Quality Organization (QO) Approvers approve the document.


The system validates the list of participants assigned as Approvers/QOApprovers of the document and checks if the workflow initiator is assignedas the sole participant in these roles. If so, the document is rejected back tothe workflow initiator who must correct the invalid list of Approvers.

Ready to MakeEffective

After all of the review and approval tasks are finished, the DocumentCoordinator releases the document to the Effective/Approved/Final state.

Periodic Review (Category 1)

Use this workflow to send Control Category 1 documents that are in the Effective state for a periodicreview. This workflow is configured for LSQM only.


Coordinator When the workflow is triggered on the defined periodic review date, theassigned Document Coordinator receives a notification to initiate the reviewprocess. The Document Coordinator assigns the list of reviewers for theperiodic review and initiates the review process.

Review Reviewers review the document. All reviewers in the list of participantsmust review the document and accept the task for the review to completesuccessfully.

Reviewers have the option to either accept the task using the Review withoutComments option or reject the task using the Review with Commentsoption. If any of the Reviewers reject the document, they have to providetheir comments in the Comments field and the document returns to theAuthor for acknowledgment. Rejecting the task does not create a newversion of the document.

Acknowledge The Author acknowledges the rejected task and addresses all the commentsprovided by the Reviewers. The comments can be seen in Task Notes widgetafter selecting the task. The Author makes the necessary changes and sendsthe document to the Submit for Review and Approval or the Submit forApproval workflow to make the document Effective.

132

Workflows

Withdraw Document (Category 1)

Use this workflow to send Control Category 1 documents that are in the Effective state for approvalbefore being Withdrawn. This workflow is configured for LSQM only.


Approvers The list of Approvers must approve the withdrawal of a document andprovide the withdrawal reason before the document can be Withdrawn. Ifany one of the Approvers rejects the task, the document does not change tothe Withdrawn state and the workflow completes.

Send to TBR Distribution (Category 1)

This optional workflow notifies users in the To be Read (TBR) Distribution List of a Control Category1 document that it is time to read the document. Use this workflow for Release Pending documentsthat require users to understand a process or procedure. Users with specific roles can also reissuea task at any time for Release Pending documents so that new users can read and understand thedocuments. This workflow is configured for LSQM only.

When starting the workflow, the initial list of recipients contains the members of the TBR DistributionList for the selected document. The Document Coordinator can add and remove users from this list.The system adds new users to the TBR Distribution List but does not remove any users. Each timethe Document Coordinator starts the workflow, the Document Coordinator selects recipients fromthe members of the latest TBR Distribution List.


133

Workflows


Read Confirmation Sends a document to the members of the selected distribution list. Recipientsreview and electronically sign the documents. All members electronicallysign to indicate that their document review is complete. When all of theRecipients sign off on the document or reject the task, the workflow returnsto the Document Coordinator.

If a recipient rejects the task, the issuer receives a notification.

Read Completed The Document Coordinator receives a confirmation notification that theTo Be Read distribution list for the document is complete. The DocumentCoordinator can accept the task to finish the workflow process.

Recall Document

There are two recall workflows that trigger when a recall operation is initiated through the ControlledPrint widget, based on the whether the recipient of the controlled copy of the selected document isinternal or external. These workflows are configured for LSQM only.

• Internal Recipient Recall Workflow

If the controlled copy being recalled was sent to an internal recipient, then this workflow isinitiated. In this workflow, the internal recipient is required to sign-off on the recall operationby providing an electronic signature. On completion, the Requestor Acknowledgment task issent to all members of the cd_controlled_print group. After any member of cd_controlled_printacknowledges the recall task, the workflow ends and the controlled copy is considered recalled.

• External Recipient Recall Workflow

If the controlled copy being recalled was sent to an external recipient, then this workflow isinitiated. In this workflow, only a requestor sign-off is required. After the requestor signs off, theworkflow ends and the controlled copy is considered recalled.

134

Workflows

Submit for Review and Approval (Change Request)

Use this workflow for Change Requests. This workflow is configured for LSQM only.



Review CR Document Coordinators review the Change Request. When finished,Document Coordinators promote or reject the document.

Edit CR Authors review the Change Request rejected by the Coordinator, make thenecessary changes, and promote the document for a re-review or directlyfor approval.


The system validates the list of participants assigned as Approvers of theChange Request and checks if the workflow initiator is assigned as the soleparticipant in these roles. If so, the Change Request is rejected back to theworkflow initiator who must correct the invalid list of Approvers.

Approve CR Document Approvers review the Change Request. When finished,Document Approvers approve or reject the document.

AcknowledgeChanges

Users assigned as Acknowledgers can acknowledge that the Change Requestis approved and accepts the task to complete the workflow. The state ofthe Change Request changes to CIP.

135

Workflows

Submit for Approval (Change Request)

Use this workflow for Change Requests. This workflow is configured for LSQM only.



Approve CR Document Approvers review the Change Request. When finished,Document Approvers approve or reject the document.

Edit CR Authors review the Change Request rejected by the Approver, make thenecessary changes, and promote the document for approval.


The system validates the list of participants assigned as Approvers of theChange Request and checks if the workflow initiator is assigned as the soleparticipant in these roles. If so, the Change Request is rejected back to theworkflow initiator who must correct the invalid list of Approvers.

AcknowledgeChanges

Users assigned as Acknowledgers can acknowledge that the Change Requestis approved and accept the task to complete the workflow. The state ofthe Change Request changes to CIP.

Submit for Review and Approval (Category 2)

Use this workflow to send Control Category 2 documents for formal review and approval. Thisworkflow is configured for all solutions.

136

Workflows



Draft Authors review the feedback on the document. After the Approver demotesthe document to Draft, the Author can skip the review task after making thechanges and send the document directly for approval.


Authors review the feedback on the document and resend the edited draftdocument for another round of review. Authors cannot skip the reviewof the document.

Review Reviewers review the content.

Approval Approvers approve the document. The document must be electronicallysigned on approval.

Approval-no Sig Approvers approve the document. Electronic signature is not required onapproval.


The system validates the list of participants assigned as Approvers ofthe document and checks if the workflow initiator is assigned as the soleparticipant in these roles. If so, the document is rejected back to theworkflow initiator who must correct the invalid list of Approvers.

Document has beenissued

After the review and approval tasks are complete, the Author receives anotification to set the review dates.

Submit for Review-Format Approval (Category 2)

Use this workflow to send Control Category 2 documents for review, format review, and approval.This workflow is configured for LSTMF and LSRD.



Draft Authors review the feedback on the document. After the Format Reviewerdemotes the document to Draft, the Author can send the document to theReviewer, Format Reviewer or Approver. After the Approver demotes thedocument to Draft, the Author can skip the review task after making thechanges and send the document directly for approval.

137

Workflows



Authors review the feedback on the document and resend the edited draftdocument for another round of review. Authors cannot skip the reviewof the document.

Review Reviewers review the content.

Format Review Format reviewers review the content.





Submit for Approval (Category 2)

Use this workflow to send Control Category 2 documents directly for approval. This workflow isconfigured for all solutions.







138

Workflows


Draft Authors review the feedback on the document.

Document has beenissued

After the approval tasks are complete, the Author receives a notification toset the review dates.

Expiry Review (Category 2)

Use this workflow to send Control Category 2 documents for an expiry review. This workflow isconfigured for LSTMF, LSRD, and LSSSV.



Review Document Coordinator reviews the document and can withdraw thedocument, expire the document, or send it to the Author for revision.

Acknowledge Author acknowledges that revisions are required for the document, whichis in the Draft state.

Submit for Review (Category 3)

Use this workflow to process a Control Category 3 document. This workflow is configured for allsolutions.


139

Workflows


For Review Authors or Reviewers review the document.

Draft Authors review the feedback on the document.

Submit for Delegated Approval (Category 3)

Use this workflow to send reviewed Control Category 3 documents directly for approval. Thisworkflow is configured for all solutions.



Draft Authors review the feedback from Approvers on the document.

Delegated Approval Delegated Approvers approve the document. The document must beelectronically signed on approval.

Delegated Approval– no Sig

Delegated Approvers approve the document. Electronic signature is notrequired on approval.

Content Template Approval

Use this workflow to send a newly created content template for approval. This workflow isconfigured for all solutions.

140

Workflows



Draft Domain-specific template Authors review the feedback on the document.

For Approval Domain-specific template Approvers approve the document. The documentmust be electronically signed on approval.

Review Ingested Document

Use this workflow to review ingested documents and set their status. This workflow is configuredfor all solutions.

Document Coordinators perform the tasks described in the following table:


Review The Document Coordinator reviews the newly ingested Category 1, 2, or 3documents.

Configuring WorkflowsEach workflow has a workflow template and a corresponding configuration in D2-Config. Toconfigure a workflow, follow these steps:



3. Select the workflow you want to configure.

4. In the Task configuration section, you can update the following field:

Field Description

Subject Subject of the task that appears in the inbox of the performer.

Message Detailed message that explains the task.

Manual acquisition Acquire the task with or without a click action from the user.

Electronic signature Include an electronic signature with the message.

Audit Enable or disable auditing.

Task follow up Task duration can be defined on the this tab. Reminder notificationscan be configured by specifying the number of days before which thereminder has to be sent and to whom.

141

Workflows

Assigning Workflows to ArtifactsYou can assign workflows for specific artifacts through taxonomies. The following screenshotexplains the parts of the taxonomy sheet where you can assign workflows:

In the screenshot, the highlighted header row indicates the various workflow dictionaries for eachControl Category. For an artifact, a dictionary value for the workflow can either be N (No) or Y (Yes).For example, for the Debarment Certification artifact, the Collaboration workflow for Category 1documents is set to N, indicating that the workflow is not enabled. If the value is set to Y, when youright-click the document in the D2 Client, the Collaboration workflow option appears in the menu.

Before assigning workflows, start with the Object Type to Taxonomy mapping dictionary. Thisdictionary holds for each object type of the document the taxonomy/dictionary that is used toconfigure the workflow mappings. The alias, is dictionary, is used to specify the value mentioned invalue alias is the dictionary name or the taxonomy name. Check the value specified for the object typeand its dictionary alias setting. Then check that dictionary or taxonomy for the workflow mappings.

To assign workflows:

1. Log in to D2 Config as an administrator.

2. On the main toolbar, select All elements in the filter list.

3. Click Data > Taxonomy.

4. Under Taxonomies, select a Classification by Group taxonomy.

5. In the dialog box, selectModify and save a copy of the sheet on your machine.

6. In the taxonomy Excel sheet, enable or disable the workflow dictionaries for the required artifactsby setting the values as N or Y.

7. Import the updated sheet.

8. Click Save.

Modifying the Task Outcome LabelsThe Life Sciences solution uses a set of predefined labels configured out of the box to replacethe default ‘Accept’ and ‘Reject’ labels for the various workflows. The user guides for each of thesolutions provides a list of these preconfigured task labels for each of the workflows. However,you can change these labels in D2 Config according to your specific requirements. To modify theworkflow task outcome labels, follow these steps:


2. On the main toolbar, select All elements in the filter list.


142

Workflows

4. In theWorkflow List, select a workflow for which you want to modify the labels.

5. Under Task configuration, select a task.

6. On the Task parameters tab, underWorkflow labels, in the Replace “Accept” with and Replace“Reject” with fields, replace or add the new labels.

7. Click Save.

Configuring Workflow MessagesTo meet business requirements, Administrators can modify when task participants receive workflowreminder messages in D2 Config.


2. Select All elements from the configuration filter.

3. Select Go to > Workflow from the menu bar.

4. In theWorkflow List, select the workflow to change.

5. Navigate to the Task configuration area and select the task to modify.

6. On the Task follow up tab, modify these settings and the messages as needed:• Task duration in days: Type the total number of days allotted to the task.

• Remaining days before the end of task: Type the number of days remaining in the taskto send a workflow message. When the number of days remaining until the task deadlinereaches the entered number, the selected notification recipients receive a workflow message.

7. Save the configuration.

Workflow and Non-Workflow AttributesEach workflow task performer value is stored as an attribute of the document. When the workflow isstarted, values from these attributes are used to populate the workflow properties. These attributesare referred to as non-workflow attributes or document attributes.

In addition to task performers stored in the document attributes (Author, Reviewer, and so on),another set of attributes are provided, which are unique to workflows. These attributes include a“wf” prefix such as wf_authors, wf_reviewers, wf_approvers, and so on. These attributesare referred to as the actual workflow performers. The non-workflow performers or attributes donot include the “wf” prefix.

When a workflow is started, the non-workflow attribute values are copied to the corresponding actualworkflow attributes. Thereafter, these new attributes take part in the workflow. Any change to theactual workflow attributes does not affect the corresponding non-workflow attributes. The actualworkflow performers have the necessary permissions on the document only when the document is inthe state where the performer can perform the task.

143

Workflows

You can use the Update performers option to update the actual workflow attributes. The modifiedvalues are not stored in the non-workflow attributes and cannot be viewed in the documentproperties. Instead, they are stored only as part of the workflow attributes for the workflow.

144

Chapter 9Lifecycles

This section describes the lifecycle state of a document in the Life Sciences solution.

Document LifecycleA document created within the Life Sciences solution has predefined states in which it can be presentat any given point of time. These states, as a whole define the lifecycle of the document. Lifecycles area very important part of this solution, as security and workflows are directly linked to it. Standard D2lifecycle configurations are provided as part of the CDF layer to support each of the four securitycategories (Category 1-4). Additionally, lifecycles are defined for Change Request, Product andProject registration forms, and so on.

The lifecycle models for Category 1-3 controlled documents are designed to support the authoring,review, approval, and controlled release of documents, and also post-release management operationssuch as suspension, expiry, superseding, and withdrawal of previously-released versions. They areclosely-related to the corresponding review / approval workflows. The following table shows thedocument lifecycle states associated with the document control categories:

Solution Control Categories Lifecycle States

Category 1 DraftFor ReviewFor ApprovalRelease PendingEffectiveSuspendedSupersededWithdrawnExpired

Category 2 DraftFor ReviewFor ApprovalApprovedSuspendedSupersededWithdrawn

LSQM

145

Lifecycles

Solution Control Categories Lifecycle States

Category 3 DraftFor ReviewFor ApprovalApprovedSuspendedSupersededWithdrawn

Change Request DraftFor ReviewFor ApprovalCIPClosed

Category 2 DraftFor ReviewFormat ReviewFor ApprovalApprovedSuspendedSupersededWithdrawnExpired

LSRD

Category 3 DraftFor ReviewReviewedFor ApprovalApprovedSuspendedSupersededWithdrawn

Category 2 DraftFor ReviewFor ApprovalApprovedSuspendedSupersededWithdrawnExpired

LSSSV

Category 3 DraftFor ReviewReviewedFor ApprovalApprovedSuspended

146

Lifecycles

Solution Control Categories Lifecycle StatesSupersededWithdrawn

Category 2 DraftIndexQuality CheckFor ReviewFormat ReviewFor ApprovalFinalSuspendedSupersededWithdrawn

LSTMF

Category 3 DraftIndexQuality CheckFor ReviewReviewedFinalSuspendedSupersededWithdrawn

The following tables provides a description of each of the lifecycle states:

Lifecycle State Description

Draft Indicates new documents and versions added and preparedby Authors.

For Review Indicates documents submitted for review by Reviewers.

Reviewed Indicates that the review phase is completed.

Format Review Indicates documents submitted for format review by FormatReviewers.

For Approval Indicates documents submitted for sign-off by Approvers.

Release Pending Indicates documents that have been signed-off by all designatedApprovers. Document Coordinators make the documentEffective.

Effective/Approved/Final Indicates documents that are approved for use and current.Indicated by a major version number. Readers can view theEffective version of documents.

147

Lifecycles

Lifecycle State Description

Suspended Indicates an Effective document that was changed to Suspendedby a Document Coordinator. This state prevents the documentfrom being used while a modified version is being prepared,reviewed, and approved. Suspended documents can bereinstated to Effective if necessary, or changed to Supersededwhen the next version or replacement document becomesEffective. Alternatively, the entire document can be Withdrawn.

Superseded Indicates a previously-Effective version of a document thatwas replaced by a more recent version that was Reviewed,Approved, and made Effective. In general, Supersededversions are not recommended because they are, by definition,out-of-date. However, it is useful to retain them as historicalrecords.

Expired Indicates a document that was previously Effective but is nowpast its expiration date. Typically, Expired documents are notused, as they can be invalid. Before they expire, the documentsare reviewed and the expiration date is rescheduled or revisedto generate a new version.

Withdrawn Indicates retired documents. All versions are withdrawntogether. Cannot be versioned, but can be copied to create adocument. Document Coordinators can withdraw a documentat any time, which affects all versions. Users are not allowedto create new versions of a Withdrawn document. However, itcan be reverted to Draft if necessary, to enable its content to bereused, or deleted. Retain Withdrawn documents as historicalrecords.

Not Issued Indicates a work-in-progress version of an uncontrolleddocument that Authors are preparing and is not yet ready forgeneral consumption. Like the Draft state of Control Categories1-3 documents. Default state for all new versions of ControlCategory 4 documents.

Issued Indicates a Control Category 4 document that is ready forgeneral consumption by the Readers. This state is like theApproved state of Control Category 1-3 controlled documents.

Historic Indicates a Control Category 4 document that is obsolete.This state is like the Withdrawn state of Control Category 1-3documents. Authors can delete these documents or retain themas historic copies.

Document Lifecycle ModelsThis section describes the state transitions for the control category documents.

148

Lifecycles

LSQM Document Lifecycle Models

This section shows the state transitions for the documents in LSQM.

Control Category 0 Documents Lifecycle

The following figure illustrates the lifecycle state transitions in the Control Category 0 ChangeRequest Lifecycle Model:


The following figure illustrates the lifecycle state transitions in the Control Category 1 DocumentsLifecycle Model:

149

Lifecycles



150

Lifecycles



151

Lifecycles

LSTMF Document Lifecycle Models

This section shows the state transitions for the documents in LSTMF.



152

Lifecycles



153

Lifecycles

LSRD/LSSSV Document Lifecycle Models

This section shows the state transitions for the documents in LSRD/LSSSV.



154

Lifecycles



155

Lifecycles

Using Uniqueness Checks to ValidateTransitionDocuments go through state transitions very often. A draft document may become Effective (so thatits available for everyone to read) whereas an Effective document might be required to be withdrawnwhen it goes out-of-date. The state transitions can be defined in the D2 lifecycle configuration for eachand every state. There might be a large number of states of a document, but from a given state, thestates a document can transition to is defined in the “Next States” section of the lifecycle configuration.The “Next State” section is available for all states of the document. Users can click on the “+” sign toadd a new transition state. The following options are possible in the next state configuration:

• The actions to perform, for example, check-in and check-out

• The transition type, for example, Promote, Demote

• The label to be displayed for the transition (all possible lifecycle states can be viewed byright-clicking the state)

• Inclusion of electronic signature, if required

• If there is a need to launch a property pages on transition, that can be defined in a dialog box

• Inclusion of a confirmation message, if required

156

Lifecycles

The transition to any state can be restricted with the help of different checks. Uniqueness checks,which are conditions, can be posed to a document, such as “validate document is not checked out”.Any number of uniqueness checks can be created and restrictions can be applied based on any ofthem.

There are two types of checks available:

• Entry Condition: This is a generic check that can be applied to enter a state. In order to enterthis target state, the checks specified in the ‘Entry conditions” section must be met. Here, thesource state is any other state.

• Transition Condition: This is a specific check that can be applied from a fixed source state to afixed target state. This option is present at the bottom of the lifecycle configuration page. First thetarget state has to be selected from the “Next State” section, and then the transition condition canbe selected from the drop-down list.

Normal States and Pseudo StatesNormal states are the states which are set to the a_status attribute of the document. These arevisible in the UI and are used where the document state actually changes.

Pseudo states are not actual states. These are not set to the a_status attribute and are not shownin the UI. They are used to perform actions that do not require a state change on the document Forexample: if you want to update the security of a document, you can create a pseudo lifecycle actionsuch as “(Update Security)”. The pseudo state will be added as the “Next State” for the normal states.In the “Action Type” section of the lifecycle configuration, you can specify some actions. Also in theDialog box field, you can launch a property page that displays the current security settings. Users canchange the security and save it. All these changes do not change the actual state of the document. LifeSciences follows the standard to enclose pseudo states within brackets.

Creating or Modifying a New LifecycleConfigurationThere are two ways of creating a new lifecycle:

• By using the New button: From the D2-Config home page, select Go To > Lifecycle. Click theNew button. A blank lifecycle creation page appears. You can provide the details required in theconfiguration on this page.

• By using Create from button: This is a simpler way of creating a new lifecycle configuration. Youcan select an existing lifecycle and click the Create from button. The entire configuration fromthe selected lifecycle is copied to the new one; only the name needs to be different. You needto change the configuration based on the requirements. This option is useful when there arecommonalities between different lifecycle configurations.

After the lifecycle is created, it needs to be associated to the correct set of documents. You can click ontheMatrix button so that the home page of D2-Config is presented. In the rows section, expand thelifecycle group. In the columns section, locate the desired context. Once both are located, double-clickthe box that marks the intersection of the desired row and the column. Save the changes.

157

Lifecycles

Custom Business Logic Using LifecycleActionsCustom methods can be called from lifecycle actions. Follow these steps to configure custom businesslogic for lifecycle actions:

1. Create a custom method.

2. Compile it and create a JAR file.

3. Place the JAR file in the serverApps.ear/lib directory of the Java Method Server.

4. Log in to Documentum Administrator.

5. Go toMethods.

6. Select File > New method.

7. Specify the name, verb, and other fields, and then save the changes.The newly added method appears in the “Apply Method” list in the lifecycle configurationpage in D2-Config.

8. Select the method and pass the necessary arguments in the Extra Arguments field.

9. Click Save.The Life Science solution provides JAR files that have several dm_methods built in. Refer to thejavadocs and use any of them based on their requirements.

158

Chapter 10Security

This section describes the security model used in the Life Science solution.

Controlled Document Foundation SecurityModelThe CDF Security Model applies security at four different levels:

• At the document level, through Role-Based Access Controls (RBAC) and Role-Based LifecycleOperations (RBLO). Depending on the role of the user on a particular document (if any), andthe current state of the document in its lifecycle, the user has a specified level of access to thatdocument, and may or may not be able to carry out certain operations on it, such as making thedocument “Final”. Without a defined role, the user cannot access the document.

• At the group level, through control groups. Control groups are used to restrict the usersand subgroups that can be assigned to particular roles on a document. For instance, inorder for a user to act as an Approver for a clinical document, the user must belong to thecd_clinical_doc_approvers control group.

• At the project, study, trial ,or procedure level, through Registration Forms. The Managers of theseforms can change the status of the registration to an Inactive state if necessary. This preventsdocuments from being made Final, temporarily freezing the current set of Final documents. TheManager can reactivate the registration form to enable documents to be made Final again.

• At the product level, through Product Registration Forms. Products can have multiple activeprojects, studies, or trials associated with them. Product Managers can make product registrationsinactive to prevent documents from being made Final across all projects, studies, or trials.

PermissionsThe Life Sciences solutions configure the permissions of documents based on the user role and thedocument category. Permissions are defined for each item in the repository. Permissions identify thesecurity level needed for a group or user to access the item and their allowed actions.

159

Security

The basic permissions in D2 are:• NONE: Cannot access any object or object attributes.

• BROWSE: Can view the properties of the object.

• READ: Can view the properties of the object and content.

• RELATE: Same as READ, plus users can add object annotations.

• VERSION: Same as RELATE, plus users can change object content.

• WRITE: Same as VERSION, plus users can alter attributes and change content without updatingthe version.

• DELETE: Same as WRITE, plus users can delete any object.

The Documentum D2 User Guide provides additional information on permissions.

Permissions in Documentum eTMF

The Documentum eTMF permissions for TMF documents (Control Category 2 and 3) are listed in thefollowing table for the contributors, authors, document coordinators, and reviewers roles:

State Contribu-tors

Authors DocumentCoordinators

Reviewers FormatReviewers

Ap-provers

Index DELETE DELETE WRITE WRITE WRITE NONE

Draft DELETE DELETE WRITE WRITE WRITE NONE

For Review(Cat 2 only)

RELATE RELATE RELATE RELATE NONE NONE

Reviewed(Cat 3 only)

VERSION VERSION READ READ NONE NONE

For Approval(Cat 2 only)

READ READ READ READ READ READ

Format Review(Cat 2 only)

RELATE RELATE RELATE RELATE RELATE NONE

Effective/Approved/Final

VERSION VERSION READ READ READ READ

Quality Check VERSION VERSION READ READ READ READ

Superseded READ READ READ READ READ READ

Suspended VERSION VERSION READ READ READ READ

Withdrawn READ READ READ READ READ READ

The Documentum eTMF permissions for TMF documents (Control Category 2 and 3) are listed in thefollowing table for the readers and auditor roles:

State Readers Auditors

Index NONE NONE

160

Security

State Readers Auditors

Draft NONE NONE

For Review(Cat 2 only)

NONE NONE


NONE NONE

For Approval(Cat 2 only)

NONE NONE


NONE NONE

Effective/Approved/Final READ READ

Quality Check NONE NONE

Superseded NONE READ

Suspended NONE READ

Withdrawn NONE NONE

The permissions for Product Registration Forms, Clinical Trial Registration Forms, and Clinical TrialCountry and Site Registration Forms are listed in the following table:

User Group Permission

Form Managers WRITE

Form Users RELATE

External Readers BROWSE

Admin Group DELETE

Default NONE

Permissions in Documentum Q&M

The permissions for Control Categories 1–3 documents are listed in the following table for theauthors, document coordinators, reviewers, and approvers roles:

State Authors DocumentCoordinators

Reviewers Approvers QOApprovers(Cat 1 only)

Draft DELETE WRITE WRITE NONE NONE

For Review RELATE RELATE RELATE NONE NONE

For Approval READ READ READ READ READ

Release Pending(Cat 1 only)

VERSION READ READ READ READ

161

Security

State Authors DocumentCoordinators

Reviewers Approvers QOApprovers(Cat 1 only)

Effective(Effective/Approved/Final)


Expired(Cat 1 only)


Superseded READ READ READ READ READ

Suspended VERSION READ READ READ READ

Withdrawn READ READ READ READ READ

The permissions for Control Categories 1–3 documents are listed in the following table for therecipients, readers, and auditors roles:

State Recipients – TBRList (Cat 1 only)

Readers Auditors Recall

Draft NONE NONE NONE NONE

For Review NONE NONE NONE NONE

For Approval NONE NONE NONE NONE

Release Pending(Cat 1 only)

READ NONE READ NONE

Effective(Effective/Approved/Final)

READ READ READ NONE

Superseded BROWSE NONE READ NONE

Suspended BROWSE NONE READ READ

Withdrawn BROWSE NONE NONE NONE

The permissions for Change Requests (CRs) are:

State Au-thors

Docu-ment Co-ordina-tors

Review-ers

Ap-provers

QOAp-provers

Read-ers

Audi-tors

Regu-latoryAf-fairs

Noti-fica-tionUser

Draft DELETE DELETE NONE NONE NONE NONE NONE NONE NONE

ForReview

READ READ RELATE NONE NONE NONE NONE NONE NONE

ForApproval

READ READ NONE READ READ NONE NONE NONE NONE

CIP READ READ READ READ READ NONE NONE NONE READ

Closed READ READ NONE NONE READ READ READ READ READ

162

Security

Permissions in Documentum R&D and DocumentumSSV

The permissions for Control Categories 2-3 documents are listed in the following table for theAuthors, Reviewers, and Approvers roles:

State Authors DocumentCoordina-tors

Reviewers Approvers(Cat 2 only)

FormatReviewers(Cat 2 only)

Draft DELETE WRITE WRITE NONE WRITE

For Review RELATE RELATE RELATE NONE NONE


VERSION READ READ NONE NONE

For Approval READ READ READ READ READ


RELATE RELATE RELATE NONE RELATE



Expired(Cat 2 only)


Superseded READ READ READ READ READ

Suspended VERSION READ READ READ READ

Withdrawn READ READ READ READ READ

The permissions for Control Categories 2–3 documents are listed in the following table for theReaders, Auditors, and Regulatory Affairs roles:

State Readers Auditors RegulatoryOperations(cd_regulatory_publisher)

Draft NONE NONE WRITE

For Review NONE NONE WRITE


NONE NONE WRITE

For Approval NONE NONE WRITE


NONE NONE WRITE


READ READ WRITE

Expired(Cat 2 only)

NONE READ READ

163

Security

State Readers Auditors RegulatoryOperations(cd_regulatory_publisher)

Superseded NONE READ READ

Suspended NONE READ READ

Withdrawn NONE NONE READ

The permissions for Control Category 4 documents are listed in the following table:

State Authors Readers

Not Issued DELETE NONE

Issued VERSION READ

Historic READ BROWSE

The permissions for Registration Forms are listed in the following table:

Access Control Groups Registration Form Permission

Managers WRITE

User Groups RELATE

Default NONE

These permissions apply to the access control groups on all registration forms. Form managers definethe access control groups on the Access Control tab of the Registration Form properties.

To manage the registration form, the manager must be listed on the Managers list. For example, in theProduct Registration Form, the Product Managers product_mgr1, product_mgr2, and product_mgr3have the DELETE permission.

To access the registration form, the user group must be on the Primary User Groups list. Thecd_clinical, cd_non_clinical, and cd_quality groups have the RELATE permission.

Users or groups not listed on the Access Control tab of the Registration Form have the NONEpermission.

Assignment of Control CategoriesEach document type (or artifact) that can be created in the repository is assigned an appropriatecontrol category automatically. This is done by setting the category attribute (which is defined for thecd_controlled_doc object type) to the relevant value, 1-4, in the default value template. Examples ofthis can be found in the Clinical Documents creation matrix. This contains a row for each artifactin the DIA Reference Model: for example, Clinical Literature References is assigned to Category 2through the Clinical Cat 2 Default Values template as shown in the following figure:

164

Security

You can reconfigure the security categories for the various artifacts by changing the Default valuestemplate settings in the creation matrix. However, you must ensure that the corresponding lifecyclemodel is assigned in the Lifecycle column in each case.

After the correct category value is assigned, the corresponding lifecycle and security model can beapplied through the configuration matrix as shown in the following figures:

165

Security

Note that there are four separate lifecycle configurations defined for each of the four controlcategories, but only two control configurations are defined: one for Category 1-3 controlleddocuments and a separate one for Category 4 documents. This simplifies the reconfiguration processand maintains a consistent security model, so that access to documents in specific lifecycle states isdefined uniformly. For example, Authors always have DELETE permits on “Draft” documents,irrespective of the security category. However, these documents may have different lifecycles andworkflows associated with them, depending on the security category in each case.

Role-Based Access ControlThe system automatically imposes role-based access controls on all documents created in therepository and grants the relevant level of access to the appropriate users and groups automatically,according to the role member settings and the document’s status in its lifecycle in each case. This isachieved through security configurations in D2.

Internally, D2 uses the security configuration applied to a document to construct an Access ControlList (ACL) in Documentum and applies it to the document, granting the role members the appropriatelevel of access in each case. Where a user has two or more roles on the same document, the effect isadditive, so that the highest applicable permit level is granted to that user. For example, if a user isdesignated as both an Author with WRITE access and a Reader with READ access, the higher permit(WRITE) takes precedence. If the roles or lifecycle state is updated for a particular document, D2updates the underlying ACL automatically. For example, if the document is in a “Draft” state, onlythe Document Authors (generally) can access it, but when it becomes “Effective”, the Authors’ permitis reduced to VERSION, and Readers should be given at least READ access (in practice, they may begiven RELATE access, which enables them to cross-reference the document in change requests, aswell as being able to access the document on a read-only basis).

D2 also has a built-in ACL re-use mechanism to reduce the number of distinct ACLs generated bythe system. This provides certain performance advantages in normal operations but can adverselyaffect mass update operations in which the role members are updated for multiple documents. Toavoid these updates, the use of groups instead of individual users as role members is recommended.The group members can be updated independently of the documents and ACLs that refer to them,

166

Security

without incurring performance penalties. This also makes the system easier to maintain as changes torole group members immediately affect all documents that use them. If a very large number of rolegroups are defined, this can also lead to performance issues, particularly for users belonging to manygroups because of the way in which the Documentum Content Server filters out objects that the usershould not see while navigating and searching the repository. (As a general rule, if a user belongs tono more than 20-30 groups this does not cause any significant performance problems, but if theybelong to 200 groups or more the performance degradation can be significant.)

Ownership of Category 1-3 DocumentsIn standard Documentum, documents are owned by the user who creates them, and this user hasspecial privileges, as they are able to change the ACL permissions assigned to the document inthe repository. This is known to cause problems in role-based access control systems, where thepermissions should be enforced in accordance with business rules, and where the “ownership”of objects changes as the document progresses through its lifecycle, and as users join or leave theorganization or change roles within it.

To circumvent this problem, the system automatically transfers ownership of all Category 1-3documents to the admingroup (the Documentum Administrators group), and adds the Creator asan initial Author/Document Coordinator by default, so that they are given the appropriate level ofaccess according to the document state. When the document becomes “Final”, the Authors are givenVERSION access but as they are not the owners of the document they created, they cannot overridethe permits assigned to them by the role-based access control policy. The Document Creator has nospecial privileges; the documents are effectively “owned” by the system, as opposed to individualusers.

To accomplish this, the Category 1-3 lifecycle models contain a dummy initial state, “(init)”, whichtransfers ownership to the admingroup, assigns the creating user to the Authors role, sets the initiallifecycle state to “Draft”, and applies the role-based security accordingly. Thus, although the initiallifecycle state is set to “(init)”, the actual initial lifecycle state is “Draft”. (The “Draft” state cannotbe used to transfer ownership, because documents are sometimes reverted back to “Draft” fromother states, for example, as a result of creating a new version of an “Effective” document, and thiswould fail if the user does not belong to the admingroup. Therefore, a dummy initial state must beused in the D2 lifecycle configuration.)

In the Cat 1-3 security model, users who can bring about state changes (that is, Authors andDocument Coordinators) are given the “change state” and “change permit” extended permits, sothey can affect state transitions even though they are not the document owners. The owners (that is,admingroup) are given full permissions, so they can fix up documents as and where necessary. It isnot necessary to reassign Category 1-3 documents to new owners as users leave the organizationor change roles, or for the admingroup to change permissions in order to make adhoc changes,making the repository easier to maintain.

167

Security

Folder SecurityCabinets and folders may be created automatically by D2 as a result of auto-filing/auto-linkingrules. Access to these folders is governed by separate security configurations that are referenced inthe auto-filing/auto-linking path configuration at each level. This enables access to be restricted tousers in the appropriate functional area master groups, and for cabinets/folders to be hidden to usersin other groups. For example, the auto-linking path for Clinical documents use the Clinical FolderSecurity Model configuration, which grants DELETE access to members of the cd_clinical group andsets the default (dm_world) permit to NONE for all other users, so that only users in the cd_clinicalgroup can see these folders (apart from the admingroup that is, who, being privileged users, canalways access all folders in the repository). Note that this does not mean that cd_clinical users candelete any folder in the “Clinical” cabinet – they can only delete empty folders.

Similarly, the auto-filing path for Change Requests (CRQs) uses the Change Request Folder SecurityModel configuration at each level, which grants public DELETE access to all users. This enables anyuser to create a change request and access it through the Change Requests cabinet/folder structure. Itdoes not necessarily mean they can delete any change request folder; they can only delete emptyfolders. For example, by deleting CRQs that they themselves have raised but not yet submitted, thendeleting the now-empty folder(s) that were created for them.

TMF Dynamic Role-Based Access Control(LSTMF)In the Documentum eTMF solution, external trial participants involved in a clinical trial can beregistered for access to specific parts of the Trial Master File (TMF) related to that trial. This enablesthem to access the relevant documents and folders in the repository depending on their role, andthe scope of access required.

In Documentun eTMF, registration forms represent the TMF. There is a Product Registration Form foreach product and a Clinical Trail Registration Form for the trial. There is also a separate registrationform for each country in which the trial is conducted (Country Registration Forms) and each site ineach country (Site Registration Forms), which can be added to the repository as the trial is rolled-out.These registration forms are used to build out the TMF in accordance with a prescribed file plan.

However, managing access to external users centrally in an adhoc manner is not a workable solution.A trial may involve many sites spread over many countries, involving thousands of external users,such as Clinical Investigators, Inspectors, and external Authors/Reviewers, who are not part of thesponsoring organization. Given the large-scale, global nature of clinical trials and the relativelyshort-term engagement of external users in each site, coupled with the need to maintain strictcontrols over access to the trial documentation, an automated system is required using devolvedadministration, to safeguard against IP theft, protect patient confidentiality and to ensure Corporategovernance and regulatory compliance.

To this end, extensions are provided in Documentum eTMF to enable external users to be registeredfor access to a TMF at the appropriate level, that is against a trial, country or site-registrationform, and in an appropriate role, such as Clinical Investigator. Registrations are valid for adesignated period only. They can be set up in advance by local Administrators, and are activatedand deactivated automatically by the system accordingly. The external user roles to be supportedare centrally-configurable, and the access levels to be granted to each role on specific artifacts

168

Security

(document types) in the TMF are also centrally-configurable, according to the security requirementsof the business. In this way, the registration of external users is simplified and devolved to localAdministrators, and the predefined security model is enforced automatically by the system.

External User Registration

External users must be named Documentum users. They must have Documentum user accountscreated for them in the repository. The user accounts for external users can be managed byconventional means, for example, through Active Directory, and synchronized with Documentumthrough the standard LDAP synchronization job.

They are then registered in the system by associating them with a suitable role, such as Inspector orContributor, against the appropriate registration form:

• For site-level access, users are registered against the relevant Site Registration Form.

• For country-wide access to all sites in a particular country, users are registered against the relevantCountry Registration Form.

• For study-wide access to all sites in all countries, they are registered against the relevant TrialRegistration Form.

The access level that a registered external user is granted on a particular document – whether theyhave read-write access, read-only access, or no access at all – is then governed automatically by thesystem, and depends on the following factors:

1. The level at which the user is registered in the system such as for a specific site, country, oran entire trial (study).

2. The role assigned to the user in their registration such as Inspector, Investigator or Contributor(the roles are configurable, although these are the standard roles that are provided out-of-the-box).

3. The time period during which the user registration is to be active. This enables access to beplanned in advance, and revoked automatically when the time period expires.

4. The position of the document in the TMF folder structure such as site-specific, country-specific,trial-level, or product-level.

5. The artifact name of the document such as Investigator Brochure. External users can be givendifferent levels of access to different artifacts, according to their role. For example, as aContributor, they may be able to edit certain TMF artifacts, but not others.

6. The current status of the document in its lifecycle – whether it is a Draft or Final/Effective version.

The system also grants access to the relevant folders in the TMF structure automatically, enablingexternal users to navigate the cabinet/folder structure and locate documents in the relevant areas ofthe TMF while their registration is active. However, they cannot see the folders for products, trials,countries and sites that they are not registered to access. They are also provided browse-level accessto the relevant registration forms, so that they can search for documents based on product codes,trial IDs, countries and sites for which they are registered. However, they cannot search on productcodes, trial IDs, countries and sites that they are not registered to access – access is strictly on aneed to know basis.

If an external user is registered for access at a higher level than for an individual site, that is at thecountry or trial level, the registration is assumed to apply to all of the relevant sites for that country or

169

Security

trial. In other words, their registration fans down to the site level. Likewise, if a TMF document iscreated at the country, trial or product level, then it is assumed to apply to all of the relevant sites. So,if a user has been granted access to a particular artifact at the site-level, they also have the same levelof access to the same artifact at the country, trial and product level. In other words, their access alsofans up to the relevant artifacts at the peer levels.

Note that for logistical reasons it is not possible to register external users for compound orproduct-level access to all sites across all studies or trials associated with a particular product usingthis mechanism. Doing so would impact the system extensively whenever a product-level registrationis updated. However, it may be possible to accomplish this through other means, for example, bymanaging access to individual documents manually on an adhoc basis.

Granular Security for Submissions (LSSSV)For regulatory submission folders and documents, the system assigns role-based security to thedocuments and folders in the archived submission folder based on the roles assigned in theRegulatory Application Registration Form for the associated application. This security is establishedat the time of the import of the regulatory submission. However, to address requirements where thesystem might want to restrict access to imported submissions initially until they have been verified,or provide access to specific parts of the submission to the relevant users and groups, and so on, thesystem enables managers to assign role-based security at a granular level, that is, at the SubmissionRegistration Form, submission folders, subfolders, and documents level.

Granular security on submissions provides the following benefits:

• Allow the default security settings for submissions to be specified in advance for individualpre-registered Submission Registration Forms or at the application or regulatory activity level,prior to importing them.

• Enables authorized users to change the roles assigned to an individual archived submissiondocument after it has been imported.

• Enables authorized users to change the roles assigned to an archived submission subfolder orindividual submission document after it has been imported, and these roles are propagated tothe subfolders and documents within that folder automatically.

• Enables authorized users to change the submission roles assigned to a Regulatory ApplicationRegistration Form and have these changes applied automatically by default to any newSubmission Registration Form created for the application. However, this does not impact existingSubmission Registration Forms and existing archived submission folders and submissiondocuments associated with the application.

• Enables authorized users to change the submission roles assigned to a RAP and have thesechanges applied automatically to the related Regulatory Application Registration Forms so thatthe new roles apply to all new submissions associated with the activity. However, existingSubmission Registration Form, submission folders, and documents associated with the activityare not impacted.

170

Security

Security Settings in the Regulatory ApplicationRegistration Form

The following table lists the security attributes that can be set through the Regulatory ApplicationRegistration Form:

AttributeLabel/Name

Default Users/Groups

Can be Set withthe followingUsers/Groups

Used in LSSSVSecurity Cascade

Tab Name

ApplicationManagers(form_managers)

<current-user> cd_regulatory_managers

No Access Control

Application Users(form_users)

cd_ad_promo,cd_clinical,cd_corres,cd_labeling,cd_non_clinical,cd_quality,cd_regulatory,cd_safety


No Access Control

SubmissionManagers(submission_managers)

<current-user> cd_regulatory_managers

Yes Access Control

Submission Users(submission_users)



Yes Access Control

DocumentCoordinators(doc_coordinators)



No Default users/Groups Control

Reviewers(reviewers)



171

Security

AttributeLabel/Name




Tab Name

Approvers(approvers)

cd_regulatory_doc_approvers,cd_regulatory_managers


Readers (readers) cd_ad_promo_doc_readers,cd_clinical_doc_readers,cd_corres_doc_readers,cd_labeling_doc_readers,cd_non_clinical_doc_readers,cd_quality_doc_readers,cd_regulatory_doc_readers,cd_safety_doc_readers

cd_ad_promo_doc_readers,cd_clinical_doc_readers,cd_corres_doc_readers,cd_labeling_doc_readers,cd_non_clinical_doc_readers,cd_quality_doc_readers,cd_regulatory_doc_readers,cd_safety_doc_readers


The security changes in the Regulatory Application Registration Form cascades to new SubmissionRegistration Forms only.

Security Settings in the Submission Registration Form

The following table lists the security attributes that can be set through the Submission RegistrationForm:

AttributeLabel/Name




Tab Name

SubmissionManagers(form_managers)

<Derived fromRegulatoryApplicationRegistrationForm-(submission_managers)>


Yes Access Control

Submission Users(form_users)

<Derived fromRegulatoryApplicationRegistration

cd_regulatory,cd_clinical,cd_non_clinical,cd_quality,cd_safety,cd_labeling,

Yes Access Control

172

Security

AttributeLabel/Name




Tab Name

Form-(submission_users)>

cd_corres,cd_ad_promo

The security changes in the Submission Registration Form cascades to the submission folder,subfolders, and documents.

Security Settings in the Regulatory Activity Package

The following table lists the security attributes that can be set through the Regulatory ActivityPackage:

AttributeLabel/Name




Tab Name

RegulatoryActivityManagers(form_managers)

<current_user> cd_regulatory_managers

Yes Access Control

RegulatoryActivity Users(form_users)



Yes Access Control

SubmissionManagers(submission_managers)

<current-user>,cd_regulatory_activity_managers


Yes Access Control

Submission Users(submission_users)


cd_regulatory Yes Access Control

The security changes in the Regulatory Activity Package cascades to the Regulatory ApplicationRegistration Form.

173

Security

Security Settings on Submission Folders

The following table lists the security attributes that can be set on submission folders:

AttributeLabel/Name




Tab Name

Folder Managers(folder_managers)

<Derived fromSubmissionRegistrationForm-(submission_managers)>


No Access Control(non-editable)*

Folder Users(folder_readers)

<Derived fromSubmissionRegistrationForm-(submission_users)>


No Access Control(non-editable)*

* — For submission folders and its children, security can only be adjusted through the SubmissionRegistration Forms. Therefore, it is non-editable in this Properties page.

Security Settings on Submission Subfolders

The following table lists the security attributes that can be set on submission subfolders:

AttributeLabel/Name




Tab Name

Folder Managers(folder_managers)



Yes Access Control

Folder Users(folder_readers)

<Derived fromSubmissionRegistrationForm-(submission_users)>


Yes Access Control

The security changes on the submission subfolders cascades to subfolders and documents.

174

Security

Security Settings on Submission Documents

The following table lists the security attributes that can be set on submission documents:

AttributeLabel/Name




Tab Name

Coordinators(doc_coordinators)



Yes Process Info

Readers (readers) <Derived fromSubmissionRegistrationForm-(submission_users)>


Yes Process Info

Other role-based attributes such as Authors, Reviewers, Approvers, and Auditors are not available inthe Properties page for submission documents.

175

Security

176

Chapter 11Workspaces and Welcome Pages

This section describes the workspaces and welcome pages used in the Life Science solutions.

WorkspacesA workspace is a container of widgets that allows you to personalize functionality for availability andconvenience. D2 includes preconfigured workspace templates. These templates contain the layoutand positioning of widget areas. The templates also come with a predetermined set of widgets.

Administrators can configure workspaces to contain workspace views. Views function the sameway as workspaces but provide a method for organizing widgets without losing widget-to-widgetinteraction.

In the Life Sciences solution, the organization of the D2 workspace is based on user roles. This meansthat all role-based view contexts, widgets, menus, and query forms are assigned to a single workspacethat includes the embedded views necessary for users in that role to perform their tasks and activities.

Workspace Views and Tasks

The following table lists the different workspaces available in the Life Sciences solution and thetasks that can be performed in each of them.

Table 16. Workspace views and tasks

Roles View Tasks

BusinessAdministrator

• Browse

• Task

• Administration

• View Submission

• Compare

The following tasks can be performed in thisworkspace:

• Navigate the cabinets and folders

• Search for documents using either quick searchor saved searches

• View details about documents such as Preview,Properties, Locations, Versions, Renditions,

177

Workspaces and Welcome Pages

Roles View TasksRelations, Audit trails, Workflow overview, andPermissions

• Add or remove group memberships

• Manage dictionaries

• Manage taxonomies

• Manage lifecycle transitions

• Manage the workflow

• Create new content, folder, cabinet, and group(user needs to have Create Group privileges)

• Import content such as file, rendition, or a newversion of a document

• Check in, check out, or cancel the checkout of adocument

• Edit a document

• View a document

• View native content

• Insert annotations

• C2 views (Audit Report, TBR Audit Report)

• Locate a document

• Manage Favorites

• Export a document or a folder

• Print a document

• Request a rendition

• Delete a document

• Create a relation

• Copy link to clipboard

• Process workflow tasks

178


Roles View Tasks

Coordinator • Browse

• Task

• Administration

Dashboard

The tasks that can be performed in this workspaceare similar to the Business Administrator tasks,except for managing dictionaries and taxonomies.

Author • Welcome

• Browse

• Task

• Dashboard

The tasks that can be performed in this workspaceare similar to the Coordinator tasks.

Reviewer/Approver • Welcome

• Browse

• Task

The tasks that can be performed in this workspaceare similar to the Author tasks, except thatReviewers/Approvers cannot create or importdocuments.

Consumer(read-only)

• Welcome

• Browse




• View details about documents such as Preview,Properties, Locations, and Relations


• View a document

• C2 views (Audit Report, TBR Audit Report)



• Export a document

• Print a document

• Copy link to clipboard

• Process workflow tasks (needed by recipients toprocess TBR task)

179


Roles View Tasks

Regulatory Manager • Browse

• Task

• Administration

• View Submission

• Compare

• Dashboard




• View details about documents such as Preview,Properties, Locations, and Relations


• View the submissions and also the documentsimported in the submission in the PDF Viewer.


• Compare two documents.


• View the locations, rendition, versions, relations,audit, and workflow overview of the content.

• View the virtual document created as part ofregulatory correspondence email import.

• Access the tasks assigned to the user and alsoview its attachment and properties.

• Preview the thumbnail of the object and alsoprovide notes to tasks and view tasks details.

• Control group, dictionary, and taxonomyadministration

SubmissionContributors

• View Submission

• Browse

• Task

• Compare

The tasks that can be performed in this workspaceare similar to the Regulatory Manager tasks,excluding the administration tasks.

180


Workspace Groups

Workspace groups provide users with the flexibility to reassign the same workspace to multiple userroles and not bound to the primary role groups that exist in the default Life Sciences solutions.Workspace groups provide a mechanism to separate UI-based groups from security groups so thatworkspaces can be assigned to the UI groups and not the security groups. The following table liststhe workspace groups and the user roles that are part of that group:

Solution Group Name Description Member Subgroups

ws_lsrd_authors LSRD authorsworkspace group

Users of the followinggroups:

cd_ad_promo_doc_authors

cd_ad_promo_template_authors




cd_labeling_template_authors


cd_md_doc_authors




cd_non_clinical_template_authors


cd_quality_template_authors

Documentum R&D

181




cd_regulatory_template_authors


cd_safety_template_authors

ws_lsrd_coordinators LSRD coordinatorsworkspace group


cd_ad_promo_doc_coordinators







cd_non_clinical_doc_coordinators

cd_quality_doc_coordinators


cd_safety_doc_coordinators

ws_lsrd_consumers LSRD consumersworkspace group


cd_ad_promo_doc_auditors

182



cd_ad_promo_doc_readers






cd_md_doc_auditors

cd_md_doc_readers











183





ws_lsrd_managers LSRD managerworkspace group


cd_ad_promo_managers



cd_md_clinical_trial_mgrs

cd_md_managers









ws_lsrd_product_managers

LSRD productmanager workspacegroup


cd_product_managers

184



ws_lsrd_reviewer_approver

LSRD reviewer andapprover workspacegroup


cd_ad_promo_doc_approvers

cd_ad_promo_doc_reviewers

cd_ad_promo_template_approvers




cd_format_reviewers



cd_labeling_template_approvers



cd_md_doc_approvers

cd_md_doc_reviewers




185






cd_non_clinical_tem_approvers



cd_quality_template_approvers



cd_regulatory_template_approvers



cd_safety_template_approvers

ws_lsssv_authors LSSSV authorworkspace group


cd_corres_doc_authors


cd_submission_archivists

Documentum SSV

186



ws_lsssv_consumers LSSSV consumersworkspace group


cd_corres_doc_auditors

cd_corres_doc_readers


ws_lsssv_coordinators LSSSV coordinatorsworkspace group


cd_corres_doc_coordinators

ws_lsssv_managers LSSSV managersworkspace group


cd_corres_managers

cd_product_managers



ws_lsssv_reviewer_approver

LSSSV reviewer andapprover workspacegroup


cd_corres_doc_approvers


cd_corres_template_approvers

ws_lsqm_authors LSQM authorsworkspace group

Users of the followinggroup:

cd_gmp_authors

ws_lsqm_consumers LSQM consumersworkspace group


cd_gmp_auditors

cd_gmp_readers

Documentum Q&M

187



ws_lsqm_coordinators LSQM coordinatorsworkspace group


cd_gmp_coordinators

ws_lsqm_reviewer_approver

LSQM reviewers andapprovers workspacegroup


cd_gmp_approvers

cd_gmp_qo_approvers

cd_gmp_reviewers

ws_lsqm_managers LSQM managersworkspace group


cd_md_managers



ws_lstmf_authors LSTMF authorsworkspace group



cd_clinical_tem_authors_tmf

ws_lstmf_consumers LSTMF consumersworkspace group




ws_lstmf_coordinators

LSTMF coordinatorsworkspace group



ws_lstmf_contributors LSTMF contributorsworkspace group


tmf_contributors

Documentum eTMF

188



tmf_external_contributors

ws_lstmf_managers LSTMF managersworkspace group


cd_clinical_trial_managers_tmf

ws_lstmf_product_managers

LSTMF productmanagers workspacegroup


cd_product_managers

ws_lstmf_inspectors LSTMF inspectorsworkspace group


tmf_inspectors

ws_lstmf_investigators

LSTMF investigatorsworkspace group


tmf_investigators

ws_lstmf_reviewer_approver

LSTMF reviewers andapprovers workspacegroup


cd_clinical_tem_approvers_tmf


cd_format_reviewers

ws_lstmf_qc LSTMFquality checkgroup


cd_clinical_qc_tmf

Workspace Views for Workspace Roles

For the Life Sciences solutions, each out-of-the-box Life Sciences workspace role is mapped to aworkspace view D2 context as shown in the following tables.

189


Table 17. Workspace Views for eTMF Workspace Roles

Workspace Name Welcome Screen Browse Task Quality Check My Sites Dashboard Administration Concurrent View eTMF

WS eTMF AuthorWorkspace

Y Y Y Y N Y N N N

WS eTMFConsumerWorkspace

Y Y Y N N N N N N

WS eTMFContributorWorkspace

Y Y Y Y N N N N N

WS eTMFCoordinatorWorkspace

N Y Y Y N Y Y N N

WSeTMF InspectionWorkspace

Y N N N N N N Y Y

WS eTMFMulti-view(Coordinators)

N Y Y N N Y N N N

WS eTMFProduct ManagersWorkspace

N Y Y N N Y Y N N

WS eTMFReviewer-ApproverWorkspace

Y Y Y N N N N N N

WS Life SciencesTMF InvestigatorWorkspace

Y N Y N Y N N N N

190


Table 18. Workspace View for Q&M Workspace Roles

Workspace Name Welcome Screen Browse Task Dashboard Administration

WS QnMMulti-view (Authors) Y Y Y Y N

WS QnMMulti-view (Consumers) Y Y Y N N

WS QnM Multi-view(Coordinators)

N Y Y Y Y

WS QnM Multi-view(Reviewer-Approver)

Y Y Y N N

191


Table 19. Workspace View for R&D Workspace Roles

Workspace Name Welcome Screen Browse Task Dashboard Administration

WS RnD Multi-view (Authors) Y Y Y Y N

WS RnD Multi-view (Consumers) Y Y N N N

WS RnD Multi-view (Managers) N Y Y Y Y

WS RnD Multi-view(Reviewer-Approver)

Y Y Y N N

192


Table 20. Workspace View for SSV Workspace Roles

Workspace Name Welcome Screen Browse Task View Submission Dashboard Compare Administration

WS SSV Multi-view(Authors)

Y Y Y Y Y Y N

WS SSV Multi-view(Consumers)

Y Y N Y N Y N

WS SSV Multi-view(Managers)

N Y Y Y Y Y Y

WS SSV Multi-view(Reviewer-Approver)

Y Y Y Y N Y N

193


Display LabelsLabels can be set to show different values for attributes than those that are stored in Content Server.The Life Sciences solution utilizes this functionality to change the way the status label for Effectivedocuments displays for non-Good Manufacturing Practices (GMP) documents. The display label isset to show Approved or Final instead of Effective for these documents despite the attribute beingsaved in Content Server with an a_status of Effective.

Welcome PagesWelcome pages in the Life Science solution are .jsp files that are called through an external widgetwithin D2. When the user first logs in to the D2-Client, the Welcome view is displayed with a singleexternal widget that points to these .jsp files. In addition, there is a utility .jsp file for each Welcomepage that contains the DQL queries and a CSS file that contains the style information. There alsoexists an imgs folder that contains the images displayed on the pages.

There are three basic identical Welcome pages for the Documentum Q&M, Documentum R&D,and Documentum SSV for the following roles:

• Authors

• Reviewers/Approvers

• Readers

Documentum eTMF includes Welcome pages for the following roles:

• Author

• Contributor

• Inspector

• Investigator

• Reviewers/Approvers

• Readers

Each Welcome page includes a menu bar and a quick action bar. The menu bar changes basedon each workspace. The menu bar provides an actionable button for one view available in theworkspace, which is displayed on the top left of the Welcome page. Clicking this button switches theuser to the specified view.

The menu bar also includes the following buttons with numbers next to them indicating the numberof documents the user needs to address:

• Tasks: Number of workflow tasks assigned to the user. This button appears for all solutions.

• Index: Number of documents the user has uploaded but not yet indexed. This button appearsonly in Documentum eTMF.

• My Sites: Number of key documents uploaded to a site. This button appears only in DocumentumeTMF.

These values do not update dynamically. You must refresh the D2-Client page to update the values.

194


The quick action bar includes the following two buttons:

• Create: Invokes the D2 create_object method and displays the Creation Profile interfaceto the user.

• Import: Invokes the D2 import_object method and displays the Import Creation Profileinterface to the user.

195


196

Chapter 12Reports

This section provides an overview of reporting implemented in Documentum for Life Sciencessolutions.

OverviewAMPLEXOR myInsight for Documentum (myInsight) is a third-party reporting tool developed byAMPLEXOR and is integrated with the Life Sciences solutions to provide reporting functionality.myInsight can be integrated into the Documentum Administrator, Documentum Webtop, orDocumentum D2 user interfaces, enabling reports to be run directly from those clients. For the D2integration, myInsight includes a web application that can be deployed along with the D2-based LifeSciences solution to provide reporting widgets.

The myInsight web application dynamically generates reports based on Report Definitions. A ReportDefinition is a Documentum object that defines one or more variables and DQL queries that willgenerate data for the report. The look and feel and the format of a report are defined through ReportPresentation .xsl files, which are referenced in the Report Definition. Report Presentation .xsl filescan be stored as Documentum objects or can be present on the file system where the JMS (JavaMethod Server) is running.

The reports enable users to determine the following:

• Documents and placeholders that exist for a specified site (that is, site inventory)

• Trials that exist for a given product

• Missing documents for a selected trial

• Progress of a trial

• Progress of each stage of a trial

• Status of each site for a selected trial

• List of audited events

• Progress of the workflow tasks for a document

• Open tasks in a workflow

• List of document templates

• List of documents assigned for periodic review

197

: http://www.amplexor.com/content/myinsight/en/downloads/softwaredownload.html

Reports

• Completed TBR tasks

• Regulatory Submissions for a region

Some Life Sciences reports use the Fusion Charts JavaScript library, which is bundled with myInsight4.x (http://www.fusioncharts.com/) to generate graphical reports.

Report WidgetsThe Life Sciences solution includes reporting widgets to display reports in the D2 user interface.When a user selects a document that matches the type of document required for a reporting variable(such as a Clinical Trial, Site, or Product Registration Form), any reporting widgets that are displayedin the user’s workspace, updates to display the report defined by the widget.

The following screenshot shows the configuration of a reporting widget.

TheWidget type is External Widget. TheWidget url references the myInsight web application andthe URL parameters include login information, the object ID of the select objects, and the object IDof the Report Definition object. The D2_EVENT_SELECT_OBJECT communication channel event isselected, which enables the widget to be notified when the user selects an object.

198

http://www.fusioncharts.com/

Reports

Report Generation ProcessWhen you display a report in a Life Sciences solution, the following processing takes place:

1. The Life Sciences solution issues an HTML request to the myInsight web application. The objectID of the selected object is passed as the objectid URL parameter. For example:

http://localhost:8080/myInsight/?user=$LOGIN&repository=$DOCBASE&objectid=$value(r_object_id)&openreport=090002da8007b664&ticket=$TICKET

2. The myInsight web application populates the parameters of the Report Definition queries withthe URL parameter values and executes the queries against the Documentum repository.

3. myInsight converts the query results to XML.

4. myInsight fetches the corresponding Report Presentation XSL and applies the definedtransformations to the XML result in order to output the report with the look and feel definedin by the Presentation XSL.

Configuring External Widgets for myInsightReportsThe external widget URL needs to be associated with a specific report to make it show the actualreports. To configure the External Widget for viewing myInsight reports, follow these steps:

1. Query eTMF Report Definitions.

SELECT r_object_id, object_name, report_name FROM my_report_definition(ALL) WHERE FOLDER ('/myInsight/Categories/Life Sciences/eTMF')

199

Reports

Each resulting r_object_id represents a specific report. The object id for a Report Definition mustbe associated with the External Widgets corresponding to that report. For consistency, objectname and location of the report is used for specific reports.

2. Specify the object_id in the External Widget URL. You can also specify the report location insteadof r_object_id.

This configuration is only required if the report is needed in a standalone widget. Other optionsinclude:

• Run the report from the myInsight Reporting widget.

• Run the report from the "Reports by Object Type" widget.

Accessing the ReportsThe myInsight reports in the Life Sciences solution suite are categorized as follows:

• Standard reports: These report are packaged with the Life Sciences solution and includes folderreports, repository reports, and user reports.

• Life Sciences Generic reports: These reports enable you to monitor active workflows, audit trails,document status, and so on. These reports are common across all Life Sciences solutions.

• Solution-specific reports: These report show information related to a specific solution.

You can access the reports in the following ways:

• Dashboard widget: You can view the Life Sciences generic reports through the Dashboard widget.The Dashboard widget reports do not require user input or a specific document to be selected togenerate the report. These reports provide data for all documents in the repository.

• Report List widget: The Report List widget is available for all Managers and Coordinators in theLife Sciences solution suite. You can double-click a report in this widget, provide the requireduser input value or artifact, and generate the report for that artifact.

200

Chapter 13Change Request

The following sections provides steps to disable the Change Request functionality in DocumentumQ&M and steps to prevent a Change Request document from being sent to a workflow when anon-current version of a document is attached to it.

Disabling Change Request for Category 1DocumentsThe following procedure enables you to send a Category 1 document to a workflow withoutassociating it to a Change Request:


2. Select All elements from the configuration filter on the main toolbar.


4. UnderWorkflow List, select Cat 1 Approve Site Performers [1-GMP-APPROVE].

5. UnderWorkflow entry conditions, remove the Condition checked by method with the valueCDFValidateAffectedDocumentHasApprovedCR uniqueness condition and click Save.

6. Perform steps 4 and 5 for the Cat 1 Review Approve Site Performers [1-GMP-REVIEW-APPROVE] workflow.

7. Select Go to > Lifecycle.

8. Under Lifecycles, select QM Cat 1 Controlled Document Lifecycle.

9. Under Properties, in the Lifecycle state table, select (launch withdraw wf).

10. Under Entry conditions, remove the Condition checked by method with the valueCDFValidateAffectedDocumentHasApprovedCR uniqueness condition and click Save.

11. Perform steps 9 and 10 for the (Reinstate as effective) lifecycle state.To disable the Change Request functionality:



3. Select Creation > Creation profile.

201

Change Request

4. Under Profiles, select Change Request.

5. Under Properties, in the Users group field, replace cd_gmp_authors with admingroup.

6. Click Save.

Configuring the Change Request PropertiesIf you want to configure the properties page of a Change Request such as set the Change Descriptionand Impact Assessment fields as optional or remove these fields entirely, follow these steps:



3. Select Go to > Property page.

4. Under Property page, select Change Request Document Properties.

5. Under Structure, expand Properties, and then expand Affected Documents.

6. To make a field optional, in the left pane, select the particular field and in the right pane, on theRequired condition tab, clear the Creation mode, Edit mode, and Import mode checkboxes.

7. To remove the fields, select a field and click Delete.

8. Click Save.

Configuring Release Pending as the Final Statefor Category 1 DocumentsYou can configure Category 1 documents to have Release Pending as the final state instead ofEffective by using the following steps:




4. Under Lifecycles, select QM Cat 1 Controlled Document Lifecycle.

5. Under Properties, in the Lifecycle state table, select the Release Pending row.

6. In the Action Type table, click the + icon to add an action.

7. SelectMake version from the list and under Action Parameters, in the Version type list, selectSame document with major version number.

8. Select the Keep symbolic version label checkbox.

9. Make the new action as the first action in the Action Type table.

10. Click Save.

202

Change Request

11. In the Next state table, go to the (Cancel release) row.

12. Under Transition parameters, remove the values in theMenu label en field and click Save.

13. In the Lifecycle state table, select the Effective row.

14. In the Entry condition table, delete the Condition checked by Method entry condition row thathas the parameter CDFValidateAffectedDocumentHasApprovedCR and click Save.

15. In the Action Type table, delete theMake version action type row and click Save.

16. Select Creation > Default values template.

17. Under Values templates, select GMP Change Request Default Values.

18. In the Properties table, for the cr_document_final_state property, in the Default values field,append |Release Pending at the beginning of the existing default value. The end value should be|Release Pending|Effective|Withdrawn|.

19. Click Save.

Binding Rules for Change RequestsA Change Request workflow can be started only when there is at least one document associated withit and when all the mandatory fields in the affected document tab are filled. The following table liststhe binding rules configured in the system for Change Requests:

Document Version Default (out-of-the-box)Binding Rule

CURRENT Binding Rule

0.X 0.1 0.X

X.Y X.0 X.Y

When the CURRENT binding rule is configured, the Change Request workflow cannot be startedunless the affected documents information is updated with the current version of the child documents.Update the Change Request properties for the affected documents and save the property page.

A Change Request in the CIP state can be reverted to Draft when the following conditions are met:

• The user requesting the state change must be the Author or Document Coordinator of the ChangeRequest.

• The associated documents must not be participating in any active workflows. Any activeworkflows must be aborted.

• None of the associated documents on the same Change Request has already reached its finalstatus. For the change type New or Revise, it is Next Major Version. For Reinstate and Withdraw,it is Bound Major Version with status Effective for the change type Reinstate and Withdrawn forthe Withdraw change type.

203

Change Request

Note:— Next Major Version: If an X.Y version document is bound to a Change Request, the finalstatus is Effective or Suspended with the next major version, that is, the document versionwill be X.0 + 1.0.

— BoundMajor Version: If an X.Y version is bound to Change Request, final status is Withdrawnwith the major version, that is, the document version will be X.0.

A CIP Change Request can be closed when the following conditions are met:

• The user requesting the state change must be the Document Coordinator of the Change Request.

• The associated documents must not be involved in any active workflows.

• All of the associated documents must reach its final status. For the change type New or Revise,it is Next Major Version. For Reinstate and Withdraw, it is Bound Major Version with statusEffective for the change type Reinstate and Withdrawn for the Withdraw change type.

Note:— Next Major Version: If an X.Y version document is bound to a Change Request, the finalstatus is Effective or Suspended with the next major version, that is, the document versionwill be X.0 + 1.0.

— BoundMajor Version: If an X.Y version is bound to Change Request, final status is Withdrawnwith the major version, that is, the document version will be X.0.

Documents can be sent to the Review/Approval, Approval, or Withdrawal workflows only whenthere is a valid Change Request created and approved (indicated by the CIP status) for the document.For example, one CIP Change Request can be used to make the SOP document final only once. Oncethe document reaches its final status, a new CR can be created and approved to make any revisions tothe document or to withdraw the document irrespective of the old CR status.

Exceptions: An X.0 version of a document attached to a CIP Change Request is sent to the Withdrawalworkflow. If the Approvers reject the workflow, the version of the document remains in the X.0Effective state. The Change Request cannot be closed until the document is Withdrawn.

Configuring the CURRENT Binding Rule for aChange RequestYou can make this configuration at any time in such a way that the system has some Change Requeststhat follow the default binding rule and other Change Requests that follow the CURRENT bindingrule. The Change Requests follow the binding rule as defined in the Change Request at the timeof creation.



3. Select Creation > Default values template.

4. Under Values templates, select GMP Change Request Default Values.

204

Change Request

5. In the Properties table, for the cr_binding_at_creation property, type CURRENT in the Defaultvalues field.

6. Click Save.

205

Change Request

206

Chapter 14Controlled Print

The Controlled Print overlay and cover page templates can be created using PDF acro-forms. PDFacro-forms can be created by creating an Open Office document and then exporting it to PDF or bycreating the PDF using Adobe Acrobat. The following sections describe the permitted form fieldsin the templates.

Note: By default, Controlled Print is configured for use with Documentum Q&M only.

Cover Page ConfigurationThe following table lists the tags that are allowed on the cover page. These tags represent theacro-fields of the PDF template. In the generated PDF these tags are replaced by the actual values.

Tag Description

#controlled_copy_number Controlled Copy Number.

#requestor Requestor of the print.

#recipient Recipient of the print.

#selectedAction Print or reprint.

#printer Name of the printer.

#profile Name of the print profile.

#pageRange Page range printed. Works only for reprints.

#profileAttributes Profile attributes and values separated by asemicolon.

#reason Print reason.

#datetime Prints the current system date and time.

Overlay ConfigurationOverlay configuration is a two-step process:

1. Configure the profile attributes—Attribute is a descriptive label. The profile attributes section inthe Controlled Print widget displays the labels as specified in the attribute. Value represents the

207

Controlled Print

look-up parameter. For example, $object_name retrieves the document name. These parametersare used to retrieve the values from the repository and present them to the user on the profileattributes section in the Controlled Print widget. These values will be printed on the overlaytemplate.

In the current configuration, this process is no longer required to be performed by the systemwiththe exception of #user_input, which represents the user-input field and needs to be preconfiguredfor the overlay template in the profile. Instead, the system can retrieve any property directly fromthe document and make it available in the overlay.

Therefore, you can put the document properties directly in the PDF template and avoidconfiguring them in the Print Profile. See Creating the Overlay PDF Template, page 210 for thesteps to create the PDF. This follows the same principles of C2 overlays, which is to put theDocumentum property name as the field name, <property_name>, for example, object_name.For backward compatibility, it also supports property names from the profile. In addition, itsupports $<property_name>, for example, $object_name, and all of the # coverpage variables aswell. In addition, CDF functions that display document status can be added as values in the PDFtemplate field. For more information about the CDF functions, see the AttributeExpressionJavaDocs. For an example of how to add CDF function in the PDF field, see Creating the OverlayPDF Template, page 210.

If you want to specify a value on the Controlled Print widget at run-time, you need to configurethat value in the Print Profile.

2. Configure the PDF template—The overlay template acro-fields need to have the same stringsas the attribute labels. In the rendered PDF, the attribute specified in the acro-field is replacedwith either the value retrieved from the repository or with the value specified by the user. Thisprocess is described in the following diagram:

208

Controlled Print

Note that the Profile Attributes are now optional but supported for backwards compatibility in theoverlay as mentioned in Step 1. For example, instead of the form having Modify Date as the fieldname, you can use r_modify_date as the field name and not have the Modify date in the profile.

209

Controlled Print

Creating the Print ProfileDocumentum Q&M provides two Print Profile configurations, Print Profile #1 and Print Profile #2,each with its own cover page and overlay configurations, which you can use out-of-the-box. Theconfigurations for the Print Profiles is as follows:

• Print Profile #1 — This profile does not include a cover page. It includes an overlay and theattributes, Comments and #user_input.

• Print Profile #2 — This profile include a cover page and an overlay. The cover pagecontains the information, Document Name <$object_name>Title <$title>Version<$r_version_label>

In both profiles, the overlay contains the following information:

Printed by <#requestor>Print Date and Time <#datetime>CC# <#controlled_copy_number>Printed For <#recipient>

Using these default Print Profile configurations as samples, you can create your own custom PrintProfiles. The supported Print Profile attributes that can be added through the D2-Config UI are:• #user_input

• $<property>, for example, $object_name

Note: CDF functions are not supported in the overlay in the Print Profile attributes through theD2-Config UI.

Follow these steps to create a Print Profile:



3. Select Controlled Printing > Profiles.

4. On the Profiles page, click New.

5. In the Profile Name field, specify the profile name.

6. In the Overlay File field, click the ellipsis button and browse to the template. Select the file andclick OK.

7. In the Cover Page File field, click the ellipsis button and browse to the template. Select the file andclick OK. This field is optional and can be left blank if you do not want to include the cover page.

8. Select the C2 Print Profile you want to associate with the Controlled Print Profile.

9. Specify the Attribute and Value for the overlay template.

10. Click Save.

Creating the Overlay PDF TemplateFollow these steps to create a custom controlled print overlay PDF template.

1. Create a blank Word document in Microsoft Word and convert it to PDF.

210

Controlled Print

2. Open the PDF in Adobe Acrobat.

3. Select File > Create > PDF Form.

4. In the Create or Edit Form dialog box, select Use the current document or browse to a fileand click Next.

5. Select Use the current document and click Next.

6. In the Tasks pane, click Add New Field and select Text Field.

7. Place the Text Field on the PDF.

8. In the Field Name box, type the name of the controlled print property or document property,such as #<controlled print property>, $<Documentum Object Property>, <Print Profile AttributeName>, and so on. For example, $object_name, #datetime, $version_label, and so on.

CDF functions can also be added as a value in the PDF Field Name box. If you want to displaythe document status by retrieving the information from the Dictionary alias, you can use thefollowing syntax:$lookup(<property>, <dictionary name>, <dictionary alias>)

For example:$lookup($value(a_status), Document Domain Status Display,$value(r_object_type))

The value that you need to add in the Field Name box for a document with a_status = ‘Effective,’r_object_type = ‘cd_quality_gmp_approved,’ and the following value in the dictionary is:

$lookup(Effective, Document Domain Status Display, cd_quality_gmp_approved)

In the PDF overlay, Approved is displayed as the result.

9. To add text to the PDF, add another Text Field and in the Text Field Properties dialog box, in theName field, type the required text.

10. Fill the property field in the other tab in the dialog box and click Close.

11. Save the PDF.To import the PDF template to an existing print profile:


211

Controlled Print


3. Select Controlled Printing > Profiles.

4. In the Profiles page, select a profile.

5. In the Overlay File field, click the ellipsis button and browse to the PDF template. Select thefile and click OK.

6. Click Save.

Mapping the Contexts to the Controlled PrintProfiles1. Log in to D2-Config as Administrator.


3. Under Configuration elements, expand Controlled Print Profiles.

4. Under Contexts, expand Controlled Documents.

5. For the Cat 1 Controlled Documents context, select the Print Profile 1 and Print Profile 2configuration element.

Note: You can extend the functionality to Category 2 and 3 documents if required.

6. Click Save.The client URLs for D2 and D2-Config must be configured in D2-Config for the Controlled Printfunctionality to work properly.

Setting Up the Printers1. Add or configure the required physical network printers on the Application Server machine

using the Control Panel > Add Printers option.

2. In D2-Config, add the printer name as it appears on the Application Server to the ControlledPrint Approved Printers dictionary.

Print ReasonsRefer to the following table and update appropriate dictionaries to add or remove the reasons forPrint, Reprint, and Recall.

Action Dictionary

Print reasons for internal users Controlled Print Reason Internal

Print reasons for external users Controlled Print Reason External

212

Controlled Print

Action Dictionary

Reprint reasons Controlled Print Reprint Reason

Recall reasons Controlled Print Recall Reason

Configuring Auto-RecallPrinted documents can be recalled automatically based on the lifecycle state. The following stepsoutline the configuration needed for auto-recall:



3. Under Lifecycles, select the lifecycle that must be configured.

4. Under Lifecycle state, select the lifecycle state on which the auto-recall needs to be configured.

5. Under Action Type, select Apply method.

6. In theMethod field, select ControlledPrintRecallLCMethod.

7. In the Extra arguments field, add the following code:-objectId "$value(r_object_id)" -service_url "ControlledPrint/rest/controlledprint/doprint?_username=<<iouser>>&_docbase=<<docbase>>&objId=<<objid>>" -dql "SELECT document_id asobjectId, requestor, recipient, controlled_copy_num as ccNum FROMdm_dbo.controlled_print WHERE document_id = '<<objid>>' AND event_nameIN ('print') AND print_status = 'Printed'" -reason "Recall reason"

Note: "Recall reason" can be substituted with any valid reason.

8. Click Save.

213

Controlled Print

214

Chapter 15Virtual Document Templates

A virtual document (VDoc) is a document composed of other documents. VDocs are used to organizecomponent documents that are located in various folders across functional areas, such as ClinicalStudy Report components, CTD Module 2 or 3 components, and so on. Documentum R&D providesvirtual document (VDoc) support where users can create documents, convert them to a virtualdocument, and add child documents to it to make a virtual document structure.

In the out-of-the-box solution, a Clinical Study Report (CSR) Assembly virtual document is shippedwith a predefined structure to accommodate the most common use-case in the industry. The sectionprovides instructions on how to create custom VDoc templates.

Currently, the Life Sciences solution only supports creating virtual documents in the Clinicaltemplate management. However, template authors can create a template by dragging and droppingdocuments into the Virtual Document widget and approve the template in other domains. However,this template cannot be used when creating documents of that artifact. This is because currently VDoctemplate configurations are available for only the Clinical domain.

Installing the Clinical Study Report VDocTemplateThe following steps are run automatically as part of the standard LSRD installation to install thesample CSR VDoc template. See the Documentum Research and Development Installation Guide formore information.

1. The predefined CSR document / folder structure is installed in the /Templates/D2/StudyReport Assembly folder through the LSRD DocApp.

2. The ProcessVirtualDocument command-line tool is used to assemble the folder structure into aVDoc. Documentum Composer does not support VDoc assembly.

You can use the same technique to install your own VDoc templates. The following figure shows thedefault CSR VDoc template:

215

Virtual Document Templates

Each folder represents a level in the template VDoc structure and has a corresponding no-contentdocument with the same name alongside it. The order in which the subordinate documents areinserted at each level is governed by the outline heading numbers stored in the a_special_appattribute (not necessarily by object_name). The resulting template VDoc structure can be previewedin D2 through the Virtual Doc widget.

Note: For performance reasons, the D2 Virtual Doc widget does not refresh automatically wheneveryou select a VDoc in the browser. Right-click the top-level VDoc and select Display VirtualDocument to preview it

D2 Configuration for the VDoc TemplateThe default D2 configuration for the CSR VDoc template is as follows:



3. Select Go to > VD Template.

4. Under VD templates, select Clinical Virtual Document Template.

5. The following table lists the fields in the right pane that must be filled or selected:

Field Description

Copy This behavior is governed by a D2 VD Template configuration.

New object type The VDoc components are created as objects of type cd_clinical.

Inherit content The template structure can include placeholder documents providinginitial content for each node.

Default values The default values is derived from the category attribute on the contenttemplate. If it is set to 2, it uses Cat 2. The same rule is applicable forlifecycle as well. If the category is set to 2 on template component, thenCat .2 lifecycle is used on document. The logic for this is defined usingQualification DQL.

Version label The initial version is 0.1.

216


If the components of the VDoc template are a combination of Category 2 and 3 documents,two separate building rules must be defined for them. This causes D2 to apply the appropriatedefault values template, inherited attribute rules, and lifecycle to each component. D2 alsoapplies the initial lifecycle actions to each component, so that they are initialized correctly. Sincethe creation of the VDoc is configured to be asynchronous, users can perform other actions tillthe VDoc is created.

6. Select Go to > Inheritance.

7. Under Inheritances, select Clinical Virtual Document Template Component Inheritance.The Clinical Virtual Document Root Inheritance configuration is also applied to each node inthe VDoc copy, which specifies the attributes to be inherited from the root VDoc node to thesubordinate nodes in the copy. This enables the VDoc child documents to inherit the sameproperties and default roles as the root VDoc when the VDoc structure is created.

8. In the Selection field on the right pane, add the following values from the Source pane so that theVDoc inherits these attributes from the VDoc template node:• artifact_name

• category

• subject ( = sub-folder path)

• title

Note: Do not include the template-inherited attributes in this list.

9. ClickMatrix.

10. Under Contexts, expand Content Templates.

11. Under Configuration elements, expand VD Template.

12. Ensure that the Clinical Virtual Document Template configuration element is mapped to theClinical Virtual Document Templates context.The D2 context for this is defined as:• Object type: cd_content_template

• Qualifier: domain = ‘Clinical’ and r_is_virtual_doc = 1

VDoc Template ApprovalVDoc templates must be approved before they are used. They use the same Content TemplateLifecycle Model and Template Approval Workflow Content Template Approval, page 140. In theworkflow lifecycle transition tasks, additional D2 actions are used to transition the VDoc childdocuments as well as the root VDoc. To configure the template approval in D2-Config:




4. Under Lifecycles, select Content Template Lifecycle Model.

217


5. In the Lifecycle state table, select the Effective row.

6. In the Action Type table, add the Apply Method action.

7. In theMethod field, select CDFVirtualDocumentMethod.

8. In the Extra arguments field, type:-child_objects ALL -if_child "a_status not in ('Effective', 'Withdrawn', 'Suspended', 'Superseded', '$value(a_status)') and r_lock_owner = ' '" -apply_d2_security true -transition_child "Effective" -context_user "$USER" -run_as_server true

9. Click Save.On template approval (promotion to “Effective” state), the child VDoc components are also promotedto “Effective” in a recursive fashion. For large or complex VDoc templates, it may be more efficient touse the CDF Virtual Document Method (server method) to accomplish this. This method is moreflexible and configurable, for example, you can transition child documents conditionally. See Reviewand Approval of VDocs, page 221 for more information.

Creating a Custom VDoc Template1. In the D2 Client, log in as a member of the template author group for a particular domain (for

example, cd_clinical_template_author).

2. Select New > Content.

3. On the Edit properties page, select or type the required information for each of the fields asdescribed in the following table:

Field Description

Name Provide a name for the template

Artifact Name Select the relevant artifact for the template. Although this is not amandatory field, it is important to specify an artifact for a virtualdocument template so that all the child documents in the VDocstructure inherit this artifact name from the template.

Classification Applicable Artifacts: Select the artifact for which the templateis applicable. For artifact-specific templates, ensure that therelevant Artifact Name is selected in the Applicable Artifacts list.The top-level VDoc node is defined as a cd_content_templateobject associated with the relevant artifact. In the case of the CSRVDoc, it is Study Report Assembly.

Virtual Document Parent: Select Yes if you want to create thisdocument as the no-content parent node that will contain childnodes as part of the VDoc template, or as a VDoc with content.Select No if you want to create a child document. The VirtualDocument Parent option must be enabled on each VDoc node inthe template and disabled for the leaf document templates (itis disabled by default).

218


Field Description

Process Info Specify the default users in the Authors and Approvers fieldsfor this template.

Template-InheritedProperties

Category: Select the control category that will be inherited tothe documents to use the correct configurations like defaultvalues, lifecycles, and so on , as configured in the VDoc Templateconfiguration. Therefore, it is very important to select thecategory correctly.

Sub-folder Name: Specify the name of the folder underthe Templates/D2 folder where you want to store thistemplate. This option enables you to organize your VDoctemplate nodes into an easily accessible structure underthe Templates/D2 folder. For example, the figure showsthe folder structure for the Study Report Assembly VDoc

template:

When specifying a subfolder within a subfolder, use the syntax<parent subfolder name>/<child subfolder name>. For example,in the above Study Report Assembly VDoc template, for achild document in the 16.1-Study Information folder,the value in the Sub-folder Name field will be Study ReportAssembly/Study Report Appendix Assembly/16.1-StudyInformation as shown in the following figure:

When the template is instantiated, the entire VDoc structureis copied and the template-inherited properties applied tothe corresponding nodes in the copy. This ensures that eachcomponent in the VDoc has the correct control category andlifecycle associated with it and a suitable default title.

219


The value in the Title field is inherited for the component document when the VDoc is created.

4. Click Next.

5. On the Choose template page, select either the Word document template to create a documentor no content to create a no-content placeholder. Click Next.

6. Repeat steps 2 through 5 to create all the required artifacts for the VDoc template components.

7. After creating all the artifacts, navigate to the Templates/D2 folder and in the Doc List,right-click the parent virtual document, and click Display Virtual Document. The templateappears in the Virtual Doc widget.

8. Drag and drop the artifacts from the Doc List to the Virtual Doc widget as child documents.

9. In the Virtual Doc widget, right-click the parent document and click Checkin.

Creating an Instance of a Clinical Study ReportAssemblyA new D2 creation profile Clinical Virtual Document Artifacts (Compound Artifacts) is provided forcreating VDocs. This is restricted to the Clinical Doc Authors group (cd_clinical_doc_authors) asfor other clinical documents. In the default configuration, there is only one VDoc artifact definedhere – the Clinical Study Report Assembly. You can add others.



3. Select Creation > Creation profile.

4. Under Profiles, select Clinical Virtual Document Artifacts (Compound Artifacts).

5. Under Properties, select the VD Structure Inheritance option.This enables the user to select an existing CSR VDoc and create a copy of that VDoc. Otherwise, theassociated VD Template is used (according to the D2 configuration matrix). If you always want tocreate the new VDoc from the predefined template (regardless of the current selection), you canturn this off.

D2 creates a copy of the template VDoc structure and applies the attribute inheritance rules. Thecomponent docs inherit the artifact_name, title, and subject from the template, and the initial lifecyclestatus (Draft) from the root VDoc as shown in the following image.

220


The usual D2 auto-naming rules apply to the component docs (Clinical Document Auto Naming inthis case). Each component document gets its own unique document number (just as for otherClinical documents).

D2 auto-linking also applies to the component document – Clinical Study Documents (study-Specific)in this case as shown in the following image:

These documents are auto-filed in /Clinical/<product-code>/<clinical-trial-Id>/.

Review and Approval of VDocsThe standard RD-SSV Cat 2 Lifecycle Model and associated review and approval workflows can beapplied to VDoc artifacts as well as non-VDocs. For VDocs, additional lifecycle transition actions areused to keep the component documents in-sync with the root as it progresses through its lifecycle.However, the standard D2 Action on VD Children action is not used here because it applies to allchild nodes indiscriminately.

The system should apply transitions to component documents in the appropriate states only, forexample, those that are in the Draft, For Review, or For Approval states, but not those that are alreadyEffective (approved) or Withdrawn. This would then enable subsections of the VDoc and individualleaf documents to be preapproved or withdrawn if necessary, without affecting other parts of theVDoc structure.

221


To accomplish this in a configurable way, the CDF Virtual Document server method is invoked in theRD-SSV Cat 2 lifecycle (which applies to the root VDoc). For example, in the “For Review” lifecycletransition, argument for the CDFVirtualDocumentMethod field is set to:

-id <root-Vdoc-object-id> -child_objects ALL -if_child"a_status not in ('Effective', 'Withdrawn')" -copy_attrs"a_status,authors,reviewers,approvers,readers,auditors,wf_authors,wf_format_reviewers,wf_reviewers,wf_approvers,wf_doc_coordinators"-apply_d2_security true -context_user "$USER"

Based on the argument, all child documents except those with the status of Effective or Withdrawnwill have the listed attributes and D2 security applied based on the context of the user. Similarlyfor VDoc templates, the CDF Virtual Document server method is invoked in the Content TemplateLifecycle Model. For example, in the “For Approval” lifecycle transition, argument for theCDFVirtualDocumentMethod field is set to:

-child_objects ALL -if_child "a_status not in ('Effective', 'Withdrawn','Suspended', 'Superseded', '$value(a_status)') and r_lock_owner = ' '"-apply_d2_security true -transition_child "For Approval" -context_user"$USER" -run_as_server true -bind_children true

The CDFVirtualDocumentMethod has a number of significant enhancements over the standard D2“Action on VD children” feature that can potentially be useful in your application. See the CDFJavaDocs for details.

Versioning of Virtual DocumentsEven though each document in the virtual document structure is treated as an individual documentand can be processed individually in a workflow, the virtual document itself can also be sent toa workflow and approved by the workflow participants. In the process of sending individualdocuments or the VDoc to a workflow, binding rules define what version of the child document isbound to the approved and non-approved version of the virtual document root.

At the time the VDoc is approved, the VDoc is bound to the latest implicit version (version number)of the children at the time of approval. When the VDoc is in progress (for example, Draft, For Review,and other states), the VDoc is bound to the CURRENT version of the children, that is, the versionlabel CURRENT.

222


Currently, the VDoc binding rules are configured in the LSRD solution. However, the CDFVirtualDocumentMethod is available in the CDF layer and is exposed for all the solutions. TheCDF VirtualDocumentMethod allows binding to be set when adding children to the virtualdocument. To handle setting the binding outside of adding children, the method has been updatedto support a new command line parameter indicating that the binding of the children should beset (-bind_children). When -bind_children is set to true, it checks the -binding_type passed tothe method. If the -binding_type is early, the system checks the -version_label. The followingtable provides a description of these parameters:

Parameter Description

-binding_type Either early or late to denote the VDoc bindingmode to use for new child documents (notcase-sensitive). Early binding means that theVDoc structure refers to predefined versionsof each version with a specific version label atany given time. Late binding means that theVDoc is not bound to a defined version of eachcomponent and instead the relevant versionis selected as and when the VDoc structure istraversed, as stipulated in the “with ...” clauseof the relevant DQL query. OPTIONAL - earlybinding is assumed by default.

-version_label Specifies the child component versionlabel to use for early binding. For staticbindings, specify an explicit version numbersuch as 1.0 or use an attribute expressionsuch as @value(r_version_label[0]) tofix the virtual document to the currentversion of the child document in each case.$value(r_version_label[0]) refers to the versionnumber of the parent virtual document node,which may not be appropriate. For dynamicbindings, specify a symbolic version label suchas "CURRENT". OPTIONAL - if undefined orblank, the "CURRENT" version label is assumedby default.

Based on the values passed for -binding_type and -version_label, the binding rules are enforced onthe VDoc.

223


224

Chapter 16Configuration Tasks

This section explains how to perform certain common configuration tasks for the Life Science solution.

Configuring Credential EnforcementCredential enforcement is required to prevent unauthorized use of passwords or identification codes,and to detect and report in an immediate and urgent manner any attempts at their unauthorizeduse to the system security unit and the organizational management. This can be enforced at therepository level as dm_docbase_config object for any Documentum repository provides the followingconfiguration options regarding account lockout:

Configuration Option Description

max_auth_attempt Maximum number of unsuccessful loginattempts allowed.

auth_failure_interval Length of time, in minutes, in which consecutivefailed login authorizations will cause a useraccount to be deactivated. The number of failedattempts that must occur within the intervalto trigger deactivation is determined by themax_auth_attempt property. The default is 0,meaning that deactivation always occurs whenthe maximum number of consecutive failedlogin attempts is reached, regardless of howlong that takes.

auth_deactivation_interval Account deactivation and automaticreactivation. If this is 0, the account is notautomatically reactivated. The value is specifiedin minutes.

If a user account in the repository was created through synchronization with an LDAP directory(for example, Active Directory), and the Documentum Content Server delegates authenticationto this directory (either through LDAP or Kerberos authentication), and the LDAP directoryimplements more stringent policies regarding account lockout, these policies would override thedm_docbase_config settings.

225

Configuration Tasks

The following changes have been made in the Life Sciences solutions to address above process:

• The default value for consecutive failed login attempts is set to 3. If the user failed to providecorrect password for 3 times consecutively, the system makes the user inactive automatically. Thisis applicable while providing the credentials for electronic signatures. The default value can bechanged by modifying the DM_DOCBASE_CONFIG object:

update dm_docbase_config objects set max_auth_attempt = <NEW_VALUE>where object_name = <DOCBASE_NAME>

where <NEW_VALUE> is the value for the failed login attempts and <DOCBASE_NAME> isthe name of repository used

Note: If required, you can configure the other options listed in the table above.

• A LSReportDeactivatedUser job is created to send a report of the deactivated users to the users inrole cd_report_locked_users, which is disabled by default. This job runs on 24-hours cycle andsends the list of deactivated users in HTML format. To enable this job:


2. Navigate to Job Management > Jobs.

3. Right-click the LSReportDeactivatedUser job and select Info.

4. Change the stage of the job from Inactive to Active and then click OK.

The frequency of the job can be changed in the Schedule tab according to your requirements.The LSReportDeactivatedUser job calls CDFCreateObjectMethod, which generate the report ofdeactivated users and save it as object in repository. The following parameters are used:

Parameter Name Value Description

type dm_document Type of object created bymethod.

object_name Locked User Account Report Name of the created object.

acl System Admin Report ACL to be applied on thereport.

folder /Temp Location where report will besaved.

mail_config Send locked user report Mailing configuration that isused to send the mail.

report_queryselect deactivated_utc

_time, user_name,

user_address,

failed_auth_attempt,

first_failed_auth_utc

_time from dm_user

where user_state >= 1

order by 1 desc, 2

Query used to generate thereport.

report_style /System/CDF/ReportStylesheets/Default ReportStylesheet

Stylesheet to be used forgenerating the report HTML.

226

Configuration Tasks

Parameter Name Value Description

report_title Deactivated user accounts Title of the report.

report_text List of Documentum useraccounts that have beenlocked out due to repeatedfailed login attempts:

Text for the report.

report_hyperlinks user_address:email

• You can use the Find all deactivated users search query to search the list of inactive users. This isenabled for users in the Controlled Document Admins Role, that is, cd_admingroup.

• Inline passwords are not used and authentication is typically handled by the platform (NT/LDAP).User authentication and lockout can be enforced at the platform level. The Life Sciences solutionrelies on the underlying operating system to enforce lockout and notification. Refer to thecorresponding documentation for more information.

D2 Mailing ConfigurationsEmail configuration in D2 can be used for the following purposes:

• Create mailing lists that end users can use to send preconfigured batch email messages.

• Send email messages directly from the D2 Client.

• Create email distributions based on events.

• Create subscriptions-based events such as workflows, lifecycle transitions, and so on.

Types of Mailing Configurations

The following table lists the object types used in the configuration of D2 mailing:

Table 21. Object Types for Configuring D2 Mailing

Object Type Description Configurations Result

d2_mail_config You can configurethe mailing server,event-based mailing,and subject andmessage for triggeringevent mails.

D2-Config > Tools >Email

Ensure that the emailserver is configuredand the relevant emailevents are configuredbased on the businessrequirement.

End users receivenotifications when aworkflow is initiatedfor a document. Youcan enable hyperlinksfor enabling the userto directly navigate tothe task and approveor reject it based on thebusiness use case.

227

Configuration Tasks


d2_sendmail_config You can configure theemail subject, message,and attachmentbehavior to enable endusers to send emailmessages concerning aselected object.

D2-Config > Go to >Send Email

Email templates canbe configured andmapped with differentrole-based contextsenabling those usersto use the templatewhen they use theSend Email option.

End users wantthe ability to sendmessages to bothinternal and externalusers of the D2 systemfor a selected object.Using the Send Mailconfiguration, you canpredefine the messageand subject of the emailto streamline this task.

d2_mail_attachment_config

You can configurecontent importsuch that when anend user importsan email messagewith an attachment,the attachment isprocessed and savedin the repository asa rendition. Thesupported contenttypes are .eml orOutlook formats.

D2-Config > Creation> Mail Attachments

This is a global settingthat allows users toimport attachments inemail messages andallow the system tocreate a rendition ofthe imported emailmessage and itsattachments.

End users need toimport email messageswith attachmentsand retain the sameformat of the emailand create renditionsof the email messagesand its attachments.

d2_mailing_config You can configurethe recipients,subject, message,and attachments thatshould be included inan email message.

D2-Config > Go to >Mailing list

Ensure mailing listsare configured for thespecific set of usersin the system andcan be used whenconfiguring lifecycletransitions, contextmapping based onconditions and enableemail trigger to theusers based on theconditions.

End users need tosend the messagesto users notifyingor reminding themof a document thatneeds to be reviewed.The end user selectsthe document andchooses the mailinglist that has beenconfigured, which isthen automaticallysent to the predefinedrecipients withapplicable messageand attachment.

228

Configuration Tasks


d2_subscription_config

You can define specificevents and associatedemail messages thatendusers can subscribeto, so that they can bealerted when the eventoccurs.

D2-Config > Go to >Subscription

Subscription templatescan be created forevents and mappedwith differentrole-based contexts.This enables users tosubscribe events toget email notificationsusing the Subscribeoption and selecttemplates based on thebusiness requirement.

Note: You cannotpreset subscriptionsfor users. It is based onuser preference.

End users want to benotified any timesomeone checksin a new versionof a particulardocument. By creatinga subscription, theycan subscribe to thisevent for the documentand be notified byemail when a newversion has beenchecked in.

d2_distribution_config You can configure asimple workflow-likeprocess where you candefine attachments,property pages,recipients, emailmessages, and anyelectronic signaturerequirements whenaccepting or rejectingthe requesteddistribution actions.

D2-Config > Go to >Distribution

Enable users to sendbulk email. Thedistribution templatesor user email messagescan be preconfiguredand mapped to contextbased on which userscan use the same inthe system through theDistribution option.

End users want aquick way of sendinga document for reviewto reviewers but wantto make sure that theyaccept or reject thenew changes in thedocument. Further,any approval must beelectronically signedand the approver mustindicate the reason forapproval.

Configuring Mailing Configurations

The Documentum D2 Administration Guide provides the information for configuring the MailServer, Mailing list configurations, Send mail configurations, subscriptions, and distributionsconfigurations in D2.

List of Task Variables

The following table lists the task variables that you can use to configure D2 email configuration, forexample, event dm_startedworkitem

229

Configuration Tasks

Table 22. List of Task Variables

Variable Syntax

docbase_name: $value(docbase_name)

due_date: $value(due_date)

event_name: $value(event_name)

message_text: $value(message_text)

object_name: $value(object_name)

package_id: $value(package_id)

planned_start_date: $value(planned_start_date)

task_priority: $value(task_priority)

router_id: $value(router_id)

router_name: $value(router_name)

sender_name: $value(sender_name)

supervisor_name: $value(supervisor_name)

task_name: $value(task_name)

task_number: $value(task_number)

recipient_login_name: $value(recipient_login_name)

recipient_os_name: $value(recipient_os_name)

recipient_name: $value(recipient_name)

platform: $value(platform)

mail_user_name: $value(mail_user_name)

stamp: $value(stamp)

date_sent: $value(date_sent)

link_cnt: $value(link_cnt)

package_type: $value(package_type)

content_type: $value(content_type)

content_size: $value(content_size)

dos_extension: $value(dos_extension)

web_server: $value(web_server)

web_server_type: $value(web_server_type)

temp_file_name: $value(temp_file_name)

mailScript: $value(mailScript)

bulk_mail_file: $value(bulk_mail_file)

smtp_server: $value(smtp_server)

Subject $value(Subject)

Message $value(Message)

230

Configuration Tasks

Variable Syntax

task.subject $value(task.subject)

task.message $value(task.message)

user_name $value(user_name)

password $value(password)

domain_name $value(domain_name)

launch_async $value(launch_async)

document.object_name $value(document.object_name)

Message Configuration

When mapping the appropriate events in the Email Configuration, you can specify the subject andmessage for events. You can embed HTML messages with hyperlinks and images in the emailmessages. The following sample code shows HTML messages with hyperlinks and images in theemail messages:<html><head><meta http-equiv=Content-Type content="text/html; charset=windows-1252"><meta name=Generator content="Microsoft Word 14 (filtered)"><style></style></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-family: "Arial", "sans-serif"'>The following workflow task has been assignedto you ($value(recipient_os_name))by $value(sender_name):</span></p><p class=MsoNormal><span style='position: absolute; z-index: 251659264; margin-left: -7px; margin-top: 18px; width:778px; height: 3px'><img width=778 height=3 src="notification%20message%204_files/image001.png"></span><span style='font-family: "Arial", "sans-serif"'><br> <br></span></p><table class=MsoTableGrid border=0 cellspacing=0 cellpadding=0 style='border-collapse: collapse;border: none'><tr style='height: 31.9pt'><td width=101 valign=top style='width: 76.1pt; padding: .05in 5.75pt .05in 5.75pt; height:31.9pt'><p class=MsoNormal align=right style='text-align: right'><b><span style='font-size: 10.0pt; font-family: "Arial", "sans-serif"'>Task:</span></b></p></td><td width=537 valign=top style='width: 402.7pt; padding: .05in 5.75pt .05in 5.75pt; height:31.9pt'><p class=MsoNormal><span style='font-size: 10.0pt; font-family: "Arial", "sans-serif"'>$value(task_name) forvalue(document.object_name)</span></p></td></tr><tr style='height: 30.1pt'><td width=101 valign=top style='width: 76.1pt; padding: .05in 5.75pt .05in 5.75pt;height: 30.1pt'><p class=MsoNormal align=right style='text-align: right'><b><span style='font-size: 10.0pt; font-family: "Arial", "sans-serif"'>Subject:</span></b></p></td><td width=537 valign=top style='width: 402.7pt; padding: .05in 5.75pt .05in 5.75pt; height:30.1pt'><p class=MsoNormal><span style='font-size: 10.0pt; font-family: "Arial", "sans-serif"'>$value(task.subject)</span></p></td></tr>

231

Configuration Tasks

<tr style='height: 31.0pt'><td width=101 valign=top style='width: 76.1pt; padding: .05in 5.75pt .05in 5.75pt;height: 31.0pt'><p class=MsoNormal align=right style='text-align: right'><b><span style='font-size: 10.0pt; font-family: "Arial", "sans-serif"'>Description:</span></b></p></td><td width=537 valign=top style='width: 402.7pt; padding: .05in 5.75pt .05in 5.75pt;height: 31.0pt'><p class=MsoNormal><span style='font-size: 10.0pt; font-family: "Arial", "sans-serif"'>$value(task.message)</span></p></td></tr></table><p class=MsoNormal><span style='font-size: 10.0pt; font-family: "Arial", "sans-serif"'> </span></p><p class=MsoNormal><span style='font-family: "Arial", "sans-serif"'> </span></p><p class=MsoNormal><span style='font-family: "Arial", "sans-serif"'>Please click</span><a href="http://rbauv148.bas.roche.com:8180/D2/?docbase=$value(docbase_name)&locateId=$value(stamp)&locateTarget=TaskFoldersWidget"><span style='font-family: "Arial", "sans-serif"'>here</span></a><span style='font-family: "Arial", "sans-serif"'> to open task. </span></p><p class=MsoNormal> </p></div></body></html>

Font definitions for the above sample:@font-face {font-family: Calibri;panose-1: 2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */p.MsoNormal,li.MsoNormal,div.MsoNormal {margin: 0in;margin-bottom: .0001pt;font-size: 12.0pt;font-family: "Times New Roman", "serif";}a:link,span.MsoHyperlink {color: blue;text-decoration: underline;}a:visited,span.MsoHyperlinkFollowed {color: purple;text-decoration: underline;}.MsoChpDefault {font-family: "Calibri", "sans-serif";}.MsoPapDefault {margin-bottom: 10.0pt;line-height: 115%;}@page WordSection1 {size: 8.5in 11.0in;margin: 1.0in 1.0in 1.0in 1.0in;}div.WordSection1 {page: WordSection1;}

232

Configuration Tasks

All aliases are resolved when using through actual D2 environment. Images can be included in theHTML. This can be done by deploying the D2 War file or any custom War files and then using anAlias-set to point to the correct URL and file in each environment.

Disabling Email Notifications1. To turn off notifications globally for all events, update the Content Server

$DOCUMENTUM\dba\config\documentum\server.ini file with the valuemail_notification= F.

2. To turn off notifications for certain users, update the dm_user object and remove the attributevalue set for user_address for the user that you d do not want to send email notificationas follows:UPDATE dm_user OBJECT set user_address = '' where user_name='$user_name$';

3. To turn off notifications for certain events, update the dm_event_sender.ebs script and addexit sub for the events you do not want to send email notifications. For example, to stop emailalerts for the dm_startedworkitem event:Case "dm_startedworkitem"exit subobject_info_flag = "false"task_event_flag = "false"router_event_flag = "false"subject_line = "Started workitem: " & CleanQuote(package_id) & " in docbase " &CleanQuote(docbase_name)

Auditing EventsD2 auditing is used to capture and record key events as documents progress through their lifecycle.It is possible to reconfigure the audited events for each category of documents independently, ifnecessary. In the default configuration, the following events are audited.

For Cat 1-3 controlled documents and Change Requests, the following events are audited:

• Document creation

• Document deletion (including D2 recycle bin delete/restore events)

• Document versioning (check-in events)

• Document property updates, including changes to role members and/or Effective, Review, andExpiry dates, as and where applicable (audited explicitly)

• Document lifecycle state changes

• Creation of relations

• Removal of relations

• Workflow initiation

• Workflow termination (abort events)

233

Configuration Tasks

• Workflow task acquisition

• Workflow task forwarding (completion)

• Workflow task rejection

• Workflow task delegation

For Cat 4 documents, the same events as Cat 3 are audited except for workflow events, since thereare no defined workflows for these documents in the default configuration. (Auditing of Cat 4events can be disabled if preferred.)

In the case of Registration Forms, the following events are audited:

• Form creation

• Form deletion

• Form property updates, including changes to the primary key values such as product codes(audited explicitly)

• Form lifecycle state changes

Configuring Audit Events

Administrators can specify the events that the system audits in D2-Config. Administrators canalso restrict the audited events shown to users.

Auditing an event creates an audit trail entry, which captures the process of creating, reviewing,approving, and releasing information in an electronic record. Audit trails facilitate the reconstructionof events relating to an electronic record. The Life Sciences solutions are preconfigured to auditevents according to best practices, but you can modify the events based on your own requirementsor preferences.

1. Log in to D2-Config as an administrator.

2. Select a Life Science solution from the configuration filter.

3. Select Audit from the Configuration elements list.

4. Select the document group to audit.

5. Specify the events to audit:• Select events from the Auditable events list and add them to the Audited events list. Thesystem audits the events in the Audited events list.

• To no longer audit events, select the events from the Audited events list and move them tothe Auditable events list.

6. Specify the audited events shown to users:• Select events from the Audited events list and add them to the Displayed events list. Userscan only see events in the Displayed events list.

• To hide audited events from users, select events from the Displayed events list and movethem to the Audited events list.


234

Configuration Tasks

8. To view the audit events in D2 Client, administrators grant users the View Audit extendedprivilege in Documentum Administrator.

Configuring Automated DelegationUse the automated delegation tool to create automated delegation on behalf of other users. Forexample, if a user goes on vacation for two weeks and forgets to set up self delegation usingDelegations widget, another user from the team can set up the delegation on his behalf toautomatically delegate all the workflow tasks from that user to specified users and groups.



3. Select Tools >Manage Delegations.

4. Click New to create a delegation control.If you want to create a child delegation control that inherits the properties of an existingdelegation control, select a delegation control and click Create from. See the Documentum D2Administration Guide for more information about child configurations.

5. Under Properties, in the User/Group name field, select a user or group who can setup adelegation for other D2 Client users.

6. In theManage user/group delegations field, select the list of users or groups for whom theautomated delegations can be targeted. Click Browse and then use the list controls to add orremove automated delegation targets.

7. Click Save.

Media FilesMedia files, such as video, can be previewed in Documentum through the Life Sciences DocumentPreview widget. Any media file format supported by Windows Media Player can be previewed: theformats that are supported can be specified in the optional "mediaFormats" URL parameter to theLife Sciences Document Preview widget as a comma-delimited list of dm_format names. Whereunspecified, the default formats are: wmv, avi, mpg/mpeg/mpg-4v, quicktime, and wav files.

Search Configuration ChangesThe legacy search configurations, that is Basic Search, Advanced Search, and Facets, have beenchanged such that each Life Sciences solutions now have one configuration that is mapped tocorrect context. Previously, each user-based context was configured with one consolidated searchconfiguration. D2 would run multiple queries for each configuration mapped for the user and for thefacets, which was a huge performance impact on the system. For example, if there are two searchconfigurations mapped for a single context, the search runs the queries twice. Now, each role has

235

Configuration Tasks

one search configuration mapped to it, which has the types used in the solution along with relevantattributes.

The number of predefined (default) facets that apply to Basic Search has been limited resulting inimproved search performance. In addition, each solution is configured with additional facets that canbe selected in the Advanced search dialog box.

Configuring Search CriteriaAdministrators can change the Advanced Search Configuration in D2-Config. This feature allowsadministrators to define types and properties from the repository that appear in the D2 ClientAdvanced Search interface.


2. Select a Life Science solution from the configuration filter.

3. Select the Search element from the Configuration elements list and then select the AdvancedSearch Configuration element.

4. In the Search configuration & properties mapping area, select a type from the Type list. Use thearrows to add or remove items from the selection list.

5. In the Properties of selected type area, add or remove properties to refine the search.

6. Save the configuration.If additional attributes are added as facets, configure the attributes for indexing by DocumentumxPlore as described in the Documentum xPlore Administration Guide.

Configuring XML DocViewer to Display PDFs inExcel FormatBy default, the XML DocViewer widget does not display PDFs in Excel format. To enable this, youmust configure the XML DocViewer widget using the following procedure:

1. In D2-Config, select All elements from the configuration filter.

2. SelectWidget view > Widget from the menu bar.

3. UnderWidgets, selectWG EXT LSCI LSS Doc Viewer (Browse).

4. In theWidget url field, remove the following value from the query:&excludeFormats=excel8book,excel12book

5. Perform step 4 for the following widgets:• WG EXT LSCI LSS Doc Viewer (Initial Browse)

• WG EXT LSCI LSS Doc Viewer (QC Index)

• WG EXT LSCI LSS Doc Viewer (Tasks)

236

Configuration Tasks


Hard Delete (LSTMF)Documentum eTMF enables users to permanently remove documents using the Hard Deletefunctionality. When users perform a Hard Delete of a document, Documentum eTMF audits theevent. You can search for these events in the audit trail. For example, if a user improperly scansor imports a document into the TMF, users with permissions can perform a Hard Delete on thedocument to remove it. By default, the system is configured to only allow clinical documentcoordinators (members of the cd_clinical_doc_coordinators group) to perform a Hard Delete ofdocuments in the Withdrawn state.

Prerequisites for performing a Hard Delete of document(s):

• The selected document(s) should not be in the checked-out state.

• The document should match the criteria specified through the cd_delete_config object.

Hard Delete of placeholders is not supported. The Deletemenu item can be disabled/hidden.

The Hard Delete feature can be configured through the docbase object cd_delete_config. Adefault instance of this object is provided with the Documentum eTMF DAR file that is configured asshown in the following table.

Table 23. Configuring the Hard Delete feature

Attribute Name Single/Repeating Purpose Default Value

doc_type Single Document type onwhich users canperform a Hard Delete.

cd_clinical_tmf_doc

doc_statuses Repeating Documents status(refers to validvalues for a_statusattribute like Draft,Withdrawn, Expiredand so on).

Withdrawn

roles Repeating User roles who canperform a Hard Deleteoperation.


auditted_attributes Repeating Attributes ofdocuments selectedfor Hard Delete thatmust be added in thedm_audit_trailtable for the eventcdf_hard_delete(maximum limit 6).

Note: This attribute isnot used to validate if

NIL

237

Configuration Tasks

Attribute Name Single/Repeating Purpose Default Value

the document qualifiesfor hard delete or not.

You can adjust the default configuration of the Hard Delete feature to meet your businessrequirements by following these steps.

1. Log in to D2-Client as a member of cd_admingroup.

2. From the Repository browser, navigate to System/CDF/Delete Config.

3. Right-click the TMF Doc Delete Config object and click Properties.

Caution: Only one instance of this object can exist at any point in time. If you createmultiple instances of this object, Hard Delete may not work correctly.

4. Configure the TMF Doc Delete Config properties as defined in the following table:

Field Description

Name Shows TMF Doc Delete Config.

Title Shows TMF Doc Delete Config.

Document Type Select the document type that selecteduser roles can hard delete. For example,cd_clinical_tmf_doc.

Document Statuses Select the statuses that the document must bein before users can hard delete it.

User Roles Select the user roles that can perform the harddelete.

Attributes to Audit Select the document attributes to capture inthe audit trail for the cdf_hard_deleteevent. The system audits a maximum of sixattributes.

5. Click OK.

You can view hard deleted documents in D2-Client using the Find Delete Audit Events search queryform.

Note: In the repository, you can delete related documents by setting the integrity_kind attributein the dm_relation_type table for that relationship type to 2. The system deletes both the originaldocument (referred to by parent_id in the dm_relation table) and the related document (child).However, deleting the child does not delete the parent in the repository. The system records only thedm_destroy event (not the cdf_hard_delete event) for the related document. If the integrityattribute is set to 0 or 1, the hard delete fails with an error message.

The standard Documentum functionality is that after an object is deleted, the content file relatingto it is not deleted until the dm_DMClean job is run. Therefore, prior to execution of dm_DMClean,it is possible to recover the content. Configuring the dm_DMClean job as part of Hard Delete isnot supported.

238

Configuration Tasks

Bulk Import-Export (LSTMF)A document package is an arbitrary collection of documents, folders and/or virtual documents inDocumentum that can be packed into a ZIP file (including content files, renditions and metadata)and unpacked from a ZIP file back into the repository. Using document packages, users can easilypackage up and export a set of documents and send these to an external agency for offline editing andcompletion. Any changes can then be imported back into the repository as a ZIP file and unpacked.

The Documentum eTMF solution uses document packages to import and export TMF placeholders,documents, and associated document information (metadata). A document pack is represented asan object of type cd_document_pack in the repository (a sub-type of cd_controlled_doc) with aseries of dm_relations linking it to the various objects included in the package. The following figureillustrates this representation.

The document package is the parent object in a Package Item relation, and the various items are childobjects. The child objects can be individual documents, folders, or virtual document nodes. In thecase of folders and virtual documents, the subordinate objects are included automatically in thedocument pack, in recursive fashion.

The document pack has a main content file that is either a Microsoft Excel spreadsheet (when newor unpacked) or a ZIP file (when packed). The Excel spreadsheet is derived from a template and isused to record the Documentum metadata for each item when the document pack is packed. TheExcel spreadsheet template is part of the default installation and is defined as a cd_content_templateobject in the repository, with the domain set to Document Pack.

239

Configuration Tasks

Lifecycle Model for Document Packages

A document pack has a D2 lifecycle configuration associated with it, comprising the following states.

Table 24. Lifecycle model for document packages

State Description

New Newly-created document pack.

Refreshing A transient state representing a document pack that is being refreshed (thatis, the spreadsheet is being regenerated with the appropriate metadata).When the refresh process is complete, it reverts to New.

Packing A transient state representing a document pack that is in the process of beingpacked (through an asynchronous server method).

Packed A document pack that has been packaged up into a ZIP file and is ready forexport or unpacking, as appropriate.

Unpacking A transient state representing a previously packed document pack (or onethat has been imported as a ZIP file) that is in the process of being unpacked(through an asynchronous server method).

Unpacked A document pack that has been successfully unpacked into the repository,that is, any changes such as new or modified documents have been applied.

Invalid A document pack that could not be processed for some reason; for example,it refers to document files that do not exist.

The “Importing and Exporting Multiple Documents” section in the Documentum Electronic Trial MasterFile User Guide provides more information about the bulk import-export process.

Note: In the Bulk Import-Export Excel spreadsheet, the LIFECYCLE_STATE is set to Read-only(‘Y’) by default. This setting does not allow lifecycle transition to be considered when importingdocuments. All documents will be imported in the “Draft” state even if the user specifies a differentstate in the Status column, such as Final, To be Reviewed, and so on. To import documents to therepository in the specified document status and perform lifecycle transitions, you must set theRead-only column to ‘N’.

Configuring the Bulk Import-Export Spreadsheet

Documentum eTMF provides the ability to import and export Trial Master File (TMF) placeholders,documents, and associated document information (metadata). The package contains a MicrosoftExcel spreadsheet that contains metadata, known as the bulk import-export spreadsheet.

You can configure the spreadsheet to use any properties that exist on the cd_clinical_tmf_doc typeor your own custom type. The system synchronizes any dictionaries associated to properties onthe Schema worksheet of the spreadsheet. This procedure shows you how to add a Documentumattribute to the bulk import-export spreadsheet. You can find detailed information within thespreadsheet template to make additional configurations.

1. Log in to D2 Client as a member of cd_admingroup.

240

Configuration Tasks

2. From the Repository browser, navigate to Templates/D2.

3. Right-click TMF BulkUpload.xls and select Edit.

4. Add a column to the File List worksheet. For example, add a Subject column.

5. On the Schema worksheet, add a row for the data field definition as described in the followingtable:

Column Description

Worksheet Type File List to indicate that the dataresides in the File List worksheet.

Column Heading Type the column name for your attribute. Forexample, Subject.

Data Field Type the Documentum attribute name or yourcustom attribute name. For example, subject.

Default Value (Optional) Type a default value for blank cells.

Read-only Type Y if it is a read-only attribute. Duringan export, the system reads the attributesfrom the repository and writes them to thespreadsheet. The system ignores this columnon import. Consider highlighting the columnin light blue so that the end users know that itis a read-only column.

Type N to enable the system to read themetadata in this column and write it to therepository on import.

Do not change the information for thepre-populated system data fields.

The following example shows information added to the Schema worksheet for the Documentumattribute column:

241

Configuration Tasks

The following example shows the Documentum attribute column highlighted in light blue toindicate that it is a read-only column:

6. Save the Microsoft Excel Spreadsheet in Microsoft Excel 97-2003 format (.xls format).AnAlias column has been added to the Schema worksheet to enable dictionary aliases to be specified.For example, you can add a "Synonym" alias to the "TMF Unique Artifact Names" dictionary andoverride the default artifact display names in this column. If a dictionary alias is not specified orblank, the locale setting is used for dictionary lookups. The default locale is "en" (English) althoughthis can also be specified in the schema settings.

Configuring Roles and Permissions forExternal Participants (LSTMF)Documentum eTMF allows you to provide direct, tailored access to TMF documents and placeholdersfor external trial participants such as Inspectors or Contract Research Organizations (CROs).Documentum eTMF contains four preconfigured roles, but you can add additional roles or disablethe default roles as needed. You can configure each role defined in the system to have differentpermissions at the artifact level. For example, an External Contributor can have Reader access to someartifacts, Author access to other artifacts, and no access to others.

Configuring the roles and their permissions in the Documentum eTMF system is a two-step process.First, you define the role and then you assign the role permissions at the artifact level. An IT

242

Configuration Tasks

administrator performs this configuration based on business requirements. Changes to the roledefinitions do not affect existing trials and related registration objects unless the security is refreshedexplicitly, so it is important to define your business rules as part of your implementation project. Inthis way, the roles and their permissions are consistent across your system, regardless of the countryor site assigned to an external participant.

This section describes how to create the external roles in your system and assign the roles security atthe artifact level. Once defined, the roles are available to Trial Managers so they can assign a user asan external role to a country or site. For example, if a regulatory authority is inspecting two sites, theTrial Manager can add the user as an External Inspector to those sites. By doing so, the user receivesthe configured access to only the documents in those sites (including all country, trial, and productdocuments related to those sites), and nothing more in the system.

The preconfigured roles are:

• External Contributor

• External Reviewer

• Inspector

• Investigator

To define the roles and permissions, complete the following procedures:

• Defining External Trial Participant Roles, page 243

• Defining Permissions for External Participant Roles, page 246

The following procedure provides an example of how to add a new role in your system:

• Adding an External Participant Role Example, page 247

Defining External Trial Participant Roles

Documentum eTMF includes predefined roles that enable you to provide direct access to yourDocumentum eTMF system for external trial participants. You can configure the roles based onyour business requirements.


2. Select EMC Life Sciences eTMF Solution from the configuration filter.

3. Select Data > Dictionary from the menu bar.

4. In the Dictionaries list, select TMF External Contributor Roles.

5. On the Alias tab, configure the external participant roles as defined in the following table:

243

Configuration Tasks

Column Description

(Checkbox) Select the checkbox for each role to include asan external participant.

To add a role, type information in a blank rowwith the checkbox selected.

To remove a role, clear the checkbox for thatrole.

Key Type a user-friendly role name. Theseparticipant role names appear as selections forusers in drop-down lists. For example, youcan type Contractor in the Key column fora new role.

Group Name Suffix Type a unique suffix for your participant roles.For example, you can type _contract for anew document Contractor role.

The system uses this suffix to configure thedynamic role group naming conventions. TheDocumentum Electronic Trial Master File UserGuide provides additional information onexternal trial participant groups.

It is not necessary to change the Group NameSuffix for the default roles.

Note: By convention, Documentum groupnames use lower-case letters and underscoresymbols. Do not specify excessively longgroup name suffixes, as the group names arelimited to 48 characters in total.

Taxonomy Dictionary Level Type the participant names to use for thedictionary referenced by the taxonomy.This name must be identical to the nameof the dictionary created for a particularparticipant role. For example, if you type TMFContractor Access for a new role in thiscolumn, the system requires a dictionary forthis role with the same name.

It is not necessary to change the TaxonomyDictionary Level name for the default roles. Ifyou decide to change it, the system requires adictionary for the role with the same name.

244

Configuration Tasks

Column Description

File Plan Column Alias Type a column alias in upper case letters withno spaces. This alias is for system use. Forexample, you can type CONTRACTOR for a newrole.

Context Group Note: This setting is not currently used. It isreserved for future use.

Type the name of the top-level groupassociated with this role. For example, for thepreconfigured External Contributor role, thetop-level group is tmf_external_contributors.This is used to associate a Documentum D2workspace with the members of this groupso that users working in a particular rolecan access the appropriate workspace. Youcan modify the predefined workspaces andconfigure additional workspaces if necessary,and associate them with the relevant groups.If a user has only one workspace available, itis preselected automatically when they log into D2 Client. Otherwise, they can choose theappropriate workspace when they log in.

For example, you can type tmf_contractor.

The Documentum Electronic Trial Master FileUser Guide provides additional information onexternal trial participant groups.


7. For each context group that you add:

a. In Documentum Administrator (DA), create a role with the same name as the context group.For example, if you create the context group tmf_contractor, create a role in DA namedtmf_contractor.

b. In D2-Config, select Go to > Context from the menu bar, click New, to create a context with asimilar name.

c. In the Group area, move the context group to the Selection area of the context and save theconfiguration.

d. ClickMatrix and map the context to a workspace. Click to place a checkmark at theintersection of the context and the workspace.

8. For each participant role that you add, copy the TMF Document Roles dictionary to create anew dictionary:

a. Select Data > Dictionary from the menu bar.

b. In the Dictionaries list, select TMF Document Roles and click Create from on the toolbar.

245

Configuration Tasks

c. Type a name for this copy of the dictionary. This name should be the same as the namedefined for the participant role in the Taxonomy Dictionary Level column of the TMFExternal Contributor Roles dictionary. For example, TMF Contractor Access.

d. Do not make any other changes and save the configuration.

9. Update the TMF Classification by Artifact taxonomy with your participant roles:

a. Select Data > Taxonomy from the menu bar.

b. In the Taxonomies list, select TMF Classification by Artifact.In the dialog box, select Excel as the file format and clickModify. Save the file to your localmachine.

c. Adjust the default TMF External Contributors, TMF External Reviewers, TMF InspectorAccess, and TMF Investigator Access columns of the spreadsheet based on your roledefinitions. These columns must match the name of the dictionaries created for each role. Forexample, TMF Contractor Access. Add a column for each additional role. If you remove arole, remove the column for that role.

d. Save the file, import it, and save the configuration.Related topic:

• Adding an External Participant Role Example, page 247

Defining Permissions for External Participant Roles

Documentum eTMF provides predefined document permissions for each external trial participantrole. If necessary, you can define individual document access permissions (for example: None,Reader, Author, Reviewer) for each external trial participant role.



3. Select Data > Taxonomy from the menu bar.

4. In the Taxonomies list, select TMF Classification by Artifact and edit the taxonomy.In the dialog box, select Excel as the file format and clickModify. Save the file to your localmachine.

5. In the TMF External Contributors, TMF External Reviewers, TMF Inspector Access, andTMF Investigator Access columns of the spreadsheet, type the document-level roles for eachartifact in the cells of the columns. If you adjusted or added additional role columns, type thedocument-level roles for each artifact for your defined roles.The following figure shows an example of document-level access changes in the TMF ExternalReviewers column and an additional TMF Contractor Access column added for a new role:

246

Configuration Tasks

In practice, these role setting are most likely to be Author to provide read and write access andeither Reader or Auditor for read-only access. The available roles are defined in the followingtable:

Role Description

Document Coordinator Has full access and can reassigndocument-level roles and define theeffective period of a Category 1 document

Author Has read and write access to work-in-progressversions and can self-approve Category 3documents

Reviewer Can participate in a review and approvalworkflow

Approver Electronically-signs a Category 1-2 documentthrough a review and approval workflow

Reader Has read-only access to Effective versions

Auditor Has read-only access to release-ready versions,including historic release-ready versions.For example, Release Pending, Effective,Superseded, but not work-in-progress andWithdrawn versions.

None Has no access to this artifact (the artifact ishidden)

6. Save the file, import it, and save the configuration.The Documentum D2 Administration Guide provides more information on configuring D2-Config.

Adding an External Participant Role Example

This procedure provides an example of how to add an external trial participant role, Contractor,to your system.



247

Configuration Tasks


4. In the Dictionaries list, select TMF External Contributor Roles.

5. On the Alias tab, configure the blank row for the new role as defined in the following table:

Column Configuration example

(Checkbox) Select the checkbox.

Key Type Contractor.

Group Name Suffix Type _contract.

Taxonomy Dictionary Level Type TMF Contractor Access.

File Plan Column Alias Type CONTRACTOR.

Context Group Type tmf_contractor.


7. In Documentum Administrator (DA), create a role with the same name as the context group.In this example, create a role in DA named tmf_contractor since the context group is namedtmf_contractor.

8. Create a context for the role:

a. In D2-Config, select Go to > Context on the menu bar, click New, and create a context with asimilar name, such as TMF Contractors.

b. In the Parents area, select TMF Roles.

c. In the Group area, select and move the context group to the Selection area of the contextand save the configuration.

248

Configuration Tasks

9. ClickMatrix and map the context to a workspace:.

a. Expand the TMF Roles context.

b. Click to place a check mark at the intersection of the context and a workspace.

249

Configuration Tasks

c. Save the configuration.

10. Copy the TMF Document Roles dictionary to create a new dictionary:

a. Select Data > Dictionary from the menu bar.

b. In the Dictionaries list, select TMF Document Roles and click Create from on the toolbar.

c. Type TMF Contractor Access as the name for this copy of the dictionary. This name shouldbe the same as the name defined for the participant role in the Taxonomy Dictionary Levelcolumn of the TMF External Contributor Roles dictionary.

d. Do not make any other changes and save the configuration.

11. Update the TMF Classification by Artifact taxonomy with the participant role:

a. Select Data > Taxonomy from the menu bar.

b. In the Taxonomies list, select TMF Classification by Artifact.In the dialog box, select Excel as the file format and clickModify. Save the file to your localmachine.

c. Add a column with the label TMF Contractors next to the other external participant rolecolumns. The column name must match the name of the dictionary that you created for therole.

d. In the cells of the TMF Contractors column, type the document-level roles for each artifactfor your defined roles. For this example, type Reviewer in the cells to provide read-onlyaccess for each artifact to the role.

e. Save the file, import it, and save the configuration.

Configuring Quality Check (LSTMF)Documentum eTMF provides a scalable Quality Check (QC) process for documents that are importedinto the system. Documents imported into the system in the Index state may be associated with aspecific QC group as described in Quality Check (LSTMF), page 29 based on the QC type definedfor that artifact in the TMF Unique Artifact Names dictionary in D2-Config. This QC group willbe responsible for inspecting the document for quality and finalizing the document. By default,

250

Configuration Tasks

documents that need to undergo QC have the QC type defined in the TMF Unique Artifact Namesdictionary:• Technical—Indicates that a document requires a technical quality check. Only users belonging tothe Technical QC group can access these documents.

• Business—Indicates that a document requires a business quality check. Only users belonging tothe Business QC group can access these documents.

• To Draft—Indicates that the imported document moves to the Draft state.

• <Blank>—Indicates that the document is not assigned to any QC process and can be moved tothe Final state.

QC types are set on the placeholders when they are created and does not change if the referencemodel is updated. As such, a document’s QC process is based on the QC process for the artifact thatwas in place when the placeholder was created and not its current value in the reference model.

To view the QC types that are currently defined in the system, you can open the TMF QC Typesdictionary in D2-Config. During the QC process, when you reject a document, you must provide aQC reject reason. The reject reasons are defined in the TMF QC Reject Reasons dictionary, where youcan define additional reject reasons for each QC type.

If you do not want a document to go through the QC process or change the QC type, perform thefollowing steps:




4. Under Dictionaries, select TMF QC Types.

5. Under Properties, on the Alias tab, you can define additional QC types.

6. Under Dictionaries, select the dictionary, for example, TMF Unique Artifact Names 2.0 orTMF Unique Artifact Names 3.0.

7. To export the dictionary to an Excel sheet, click Export and select Excel as the file format.

8. In the dictionary Excel sheet, in the QC Type column for a particular artifact, change the QC typeor leave it blank if you do not want the document to go through the QC process.

9. To import the dictionary, click Import and select the updated dictionary Excel sheet.

10. Click Save and then click Update repository.

Distributed Server Method ProcessingIn the Life Sciences solution, a concurrent server method processing framework is provided toimprove the efficiency and scalability of server methods. Life Sciences supports both multi-threadingand distributed processing for the following operations:

• Applying attribute inheritance rules to multiple documents and registration forms inDocumentum Q&M, Documentum eTMF, and Documentum R&D. For example, to reapply

251

Configuration Tasks

Documentum D2 auto-naming to affected documents and registration forms when a Managerchanges a product code.

• Generating missing TMF placeholders on trial activation and refresh in Documentum eTMF.

• Updating the dynamic access control groups for external participants in a TMF in DocumentumeTMF.

For these operations, the standard settings allocate up to five threads for local multi-threadedprocessing, but disable distributed processing. To use distributed processing, set up a multi-nodeContent Server architecture with at least two Content Servers. Using D2-Config, enable thedistributed processing options in the System Parameters dictionary. Because of the caching of thedictionary settings, ensure that you restart the relevant Java Method Server services to make theconfiguration changes effective.

If there is sufficient CPU capacity, you can also increase the number of processing threads per server.Do not over-optimize the system solely for TMF processing, because it can result in diminishedperformance of the repository overall. It is important to remember that Documentum has to serveinteractive users, Documentum D2 lifecycle operations, workflows, and other batch processes at thesame time. To balance the loads effectively in multi-node architectures, it is possible to allocate someof the servers for interactive use and others for batch processing. Contact Documentum ProfessionalServices for assistance with analyzing your TMF system architecture and performance tuning. Forimproving the performance of server methods, see Improving Performance of Server Methods,page 334.

Enabling Distributed and Multi-threaded Processing

Distributed processing enables large batch jobs to execute across multiple Content Servers. Thesystem balances the workload over the available content servers and uses distributed processingonly for large datasets.

1. Verify that multiple Content Servers are available. The repository should have more than onedm_server_config object registered.


3. Select All elements from the configuration filter.


5. In the Dictionaries list, select System Parameters.

6. On the Alias tab, configure the system parameters as defined in the following table:

252

Configuration Tasks


content_servers Type the Content Servers availablefor distributed processing. Use acomma-separated list of dm_server_confignames, or * to use all available servers.

To enable distributed processing, specify twoor more Content Servers.

To disable distributed processing, set thisvalue to a blank string.

distributed_processing_threshold Type the minimum data size for invokingdistributed server methods in multi-nodeContent Server architectures.

To enable distributed processing, set thisparameter to at least 2. For example, if youset it to 1000, batches of 1000 objects or moredistribute across the available servers, butbatches with less than 1000 process locally.

To disable distributed processing, set thisparameter to 0 (zero). Distributed processingis disabled by default.

Note: Set this value to a reasonably highlevel to avoid the overhead of distributingprocessing tasks when there are relatively fewobjects for processing. In this case, it would bemore efficient to process them locally.

max_threads Type the maximum number of servermethod threads per Content Server for localprocessing.

The minimum value is 1, in which casethe tasks are processed sequentially insingle-threaded mode. The default settingis 5. There is no defined maximum value,but increasing it up to or beyond the pointat which the Content Server CPU becomessaturated is not recommended, as this canbe detrimental to the performance of therepository overall.

shared_folder (Optional) Type a dm_location name orexplicit path of a network-shared folder touse to interchanges data efficiently betweencontent servers for distributed processes.

253

Configuration Tasks


If you do not define this value, data exchangesoccur through temporary binary objects storedin the repository.


8. Restart the Java Method Server.

Disabling Parallel Processing for CFD Methods

Distributed parallel processing has been implemented for the following CDF methods and utilities,which helps create multiple threads across available content server instances to share the load whileprocessing logic:

• CDFVirtualDocumentMethod

• CDFApplyAttributeInheritanceMethod

This existing distributed parallel processing logic reads the System Parameters dictionary andprocesses the content_servers configured in the dictionary, assuming that all the server namesconfigured in the dictionary are up and running. In addition, it just picks the threshold as 100, whichis the default value. It is up to users to enable or disable the distributed processing by configuring thefollowing parameters in the dictionary:

• content_servers

• distributed_processing_threshold

To disable the parallel processing, the parameters must be set to null.

Creating a dm_method Object

To support distributed processing in multi-node Content Server architectures, you must create adm_method object in Documentum to enable remote processing:

1. Log in to DocumentumAdministrator (or equivalent tool) as the Documentum installation owner.

2. Run the following DQL statement:create dm_method objectset object_name = 'CDFApplyD2ConfigurationsMethod',set title = 'CDF',set method_verb = 'com.emc.d2.api.methods.D2Method -class_name com.documentum.cdf.methods.ApplyD2Configurations,set method_type = 'java',set use_method_server = true,set launch_async = false,set run_as_server = true,set timeout_min = 3600,set timeout_max = 86400,set timeout_default = 7200

254

Configuration Tasks

This creates the required dm_method object with timeout set to 7200s (2 hours) by default (adjustthe timeout parameters if necessary).

Due to security enhancements in Content Server 7.1 and 7.2, the bindfile API no longer works.Although this does not affect the Life Sciences system, it may have an impact if the user changes therun_as_server property to false on the following dm_method objects:

• CDFCreateObjectAsyncMethod

• CDFCreateObjectMethod

• TMFCreateLinks

Ensure that the run_as_server attribute is always set to True (1) for these dm_method objects.

Enabling the Trace Level of the D2 Core Method

Whenever the ApplyD2Configurations method is invoked internally through server methods, theD2 core method is called for each object. By default, the D2 core method called through the servermethods is in INFO mode. If you want to enable DEBUG for the D2 core method, follow these steps:

1. Log in the D2-Config.



4. Under Dictionaries, select System Parameters.

5. On the Alias tab, for the d2_core_method_trace_level key, set any value between 0 and 10 toenable the tracing level.

6. Click Save.

7. Clear the Documentum cache both on the server and client side.

Note: This D2 core method tracing is only for core method calls invoked through Life Sciences servermethods. For setting the DEBUG level for the default D2 Core Method calls, see the Documentum D2Administration Guide.

Enabling the “Convert to virtual document”Menu OptionIn certain Life Sciences solutions, such as Documentum Q&M, the Convert of virtual document menuoption is disabled by default. If you want to enable this option, follow these steps:



3. Select Go to > Menu D2.

4. UnderMenus, select CDF Contributor Menu.

255

Configuration Tasks

5. Under Contextual menus, click <Right click> and click Convert to virtual document.

6. Under Conditions, ensure that Selection is not object type "....." is selected.

7. Under Condition parameters, for the Type field, click the ellipsis (...) button.

8. Under Selection, remove the following values:• cd_quality_gmp_approved

• cd_quality_gmp_effective

9. Click OK and then click Save.

Updating the PDF DocInfo Parameter in D2DictionaryThe source_object_pdf_docinfo_field parameter specifies an optional PDF Document Information(DocInfo) field used by the submission publishing tool to record the Documentum r_object_ids ofthe original source documents in the published PDF documents. When publishing documents fromDocumentum, it is useful to embed the source object IDs in the corresponding published PDFs ina designated DocInfo field.

In some instances, multiple source documents are combined to generate a single published outputdocument in the publishing tool. In these cases, the source_object_pdf_docinfo_field parameter canbe updated with multiple r_object_ids of the source documents separated by a delimiter, that is, anyspecial character such as comma, semicolon, backslash, and so on. This enables navigating to multiplesource documents from a single archived submission element to provide a complete view.

Any of the standard DocInfo fields can be used for this purpose such as Subject. Alternatively,a custom DocInfo field can be used, such as SourceObjectId, which will not be shown on thedocument properties page of Adobe Acrobat. Configuring the Document Information parameterenables the system to track the original source documents and relate them to the correspondingpublished submission documents when they are imported into the repository through the ImportSubmission function.

Follow these steps to update the PDF document information in the System Parameter D2 dictionary.



3. On the Dictionary page, select All elements in the filter on the toolbar.


5. On the Alias tab, add a standard or custom DocInfo field, such as SourceObjectId or Subject, asthe value of source_object_pdf_docinfo_field.

6. In the source_object_pdf_multipleIDs_delimiter field, add the delimiter value that is used toseparate the list of source document r_object_ids in source_object_pdf_docinfo_field such ascomma, semicolon, backslash, colon, and so on.

7. Click Save.

256

Configuration Tasks

On the Relations tab in the D2 Client, the user can click an imported submission document andview the original source document that was used to generate it. The published version usuallycontains additional markups such as headers, footers, watermarks, bookmarks, and hyperlinksgenerated by the publishing tool, but it is sometimes useful to refer back to the original documentfor publishing fidelity checking or to enable the original document to be identified and repurposedfor other applications.

If the publishing tool does not support embedding of Documentum attributes into PDF DocInfofields, or where the original documents are stored in a different repository, leave this setting blank;source document relations will not be created at submission import time in that case.

257

Configuration Tasks

258

Chapter 17Regulatory Submissions

This section provides an overview of regulatory submissions and how it is configured in the LifeSciences solution.

Submission OverviewA regulatory submission is a collection of documents (submission elements) sent to a regulatoryAuthority with respect to an application. For example, an Investigational New Drug (IND)application to the US Food and Drugs Administration (FDA) for approval to commence clinical trialsin humans or a NewDrug Application (NDA) to the FDA for approval to market a drug in the US. Theapplication type denotes the purpose of the application (IND or NDA, in the preceding examples).

An application may require several submissions to be made before it is approved. Variousamendments, queries, and requests for supplementary information may be requested by theAuthority and post-approval, additional submissions may be necessary from time to time, suchas Periodic Safety Update Reports (PSURs). The submission type indicates the purpose of eachsubmission, for example, an Initial Filing, Amendment, or PSUR. Both application types andsubmission types are regional – different application and submission types are used in differentgeographic regions. For example, the IND and NDA application types pertain to the US, whereasthe European equivalents are CTA (Clinical Trials Approval) and MAA (Marketing AuthorizationApplication), respectively.

The following figure illustrates the relationship between the various submission-related objects.

259

Regulatory Submissions

An application is typically made to one health authority in one country, in accordance with aNational Procedure (NP). The exception is for applications to European member states, which canfollow either a National Procedure for specific member states (a separate application being madeto each member state in that case), or a Centralized Procedure (CP), in which case the applicationis made directly to the European Medicines Agency (EMA), the central European regulatoryauthority. If the application is approved by the EMA, it is approved for use across all EU memberstates. For certain types of applications, such as Biological License Applications (BLAs), approvalby the EMA through the CP is mandatory; for others, it is discretional. There is also an option touse the Mutual Recognition Procedure (MRP) in the EU, which enables the same application to bemade to two or more member states simultaneously. Once one member state decides to evaluatethe product, it becomes the Reference Member State. The others become Concerned Member States,acting in a reviewing or monitoring capacity. In this way, the MRP is designed to share the workloadin evaluating medicinal products across national regulatory authorities within the EU, withoutcompromising safety or regulatory scrutiny. To support MRP applications, it must be possible for anapplication to be associated with multiple health authorities within the EU region.

260


Electronic Common Technical DocumentSubmissionAn application can adopt the electronic Common Technical Document (eCTD) format, as definedby the International Committee on Harmonization (ICH). In an eCTD submission, each submissionrepresents a sequence of the eCTD, enumerated from sequence number 0000 for the initial filing. AnXML backbone file (index.xml) is included within the top-level sequence folder, referencing thedocuments included in that sequence. The documents in a sequence are organized into the prescribedICH eCTD module structure:

• Module 1 (Regional)

• Module 2 (Summaries)

• Module 3 (Quality)

• Module 4 (Non-Clinical)

• Module 5 (Clinical)

The structure of the regional module m1 is not defined by the ICH, but is defined by the regulatoryauthorities in each region. It has its own regional XML file in the appropriate format (for example,us-regional.xml for US, eu-regional.xml for Europe) referring to the regional-specificdocuments included in module m1 of the sequence. Document-specific metadata may be included inthe XML backbone and regional XML files, such as the drug substance and manufacturer to which aparticular document pertains and submission-specific metadata may also be included in the regionalXML file, such as the product trade names intended to be used in each country.

The initial submission for an eCTD comprises only new documents. Each subsequent submission(numbered 0001, 0002, and so on) contains only incremental changes that is, additional(new) documents, replacements, and supplements to previously-submitted documents, andpreviously-submitted documents to be considered as withdrawn. Each sequence includes a newversion of the XML backbone file, specifying the alterations to be made for each leaf document interms of operations (new, replace, append or delete).

Regional XML Files for Other Agencies

Additional regional XML files may be included in the standard installation, or downloaded from therelevant agency websites and manually-imported into the repository post-installation, to supportother regions.

Additional XSL Style Sheets

The XSL style sheets provided by the ICH and regional agencies are installed on the applicationserver as part of the Documentum SSV installation. However, they are not required for XMLprocessing and import purposes.

These files can be used to preview regional XML files in the Submission Viewer if the HTML renditionsare not available. However, HTML renditions are usually generated during import, in which case the

261


XSL stylesheet files are not required for previewing. They may be useful as examples if additionalstylesheets need to be provided to support new regions or new DTD formats for existing regions.

Submission History XML FilesThe submission history view (model) is compiled and maintained automatically by the system as eachsubmission or sequence is imported into the repository. The model is represented in several XML files:

• The overall submission history file, or Table of Contents view, is stored as the primary content file ofthe relevant Regulatory Application Registration Form in XML format. This is used to renderthe initial table of contents view when a Regulatory Application Registration Form is selected forpreviewing in the Submission Viewer.

• A separate submission view file is also generated for each imported submission or eCTD sequence,which is stored as the primary content file of the relevant Submission Registration Form (SRF)in each case. SRFs can be pre-registered prior to importing. Otherwise, new SRFs are createdby the system during import. The SRF XML file is used to render the individual sequence orsubmission views in the Submission Viewer when they are selected for previewing. Hyperlinksare also provided in the left column of the Table of Contents view to facilitate navigation tothe individual submission or sequence views.

• In the case of eCTD submissions, a Current SRF object is also generated as a hidden object in therepository, in which the cumulative view XML file is stored. This is used to render the Currentand Cumulative views in the Submission Viewer, showing the consolidated set of files in eacheCTD section across all sequences. The Current view shows only the latest versions of each file,hiding replaced or deleted files, whereas the Cumulative view shows all files.

• Cross-reference files are also generated and attached as xml_rarf_xref renditions to the SRF, currentSRF, and individual submission document objects. These are used internally by the SubmissionViewer to open the view in the appropriate mode when an SRF or archived submission documentis selected for previewing in the Submission Viewer. For example, you can search for a submissionor archived submission document based on certain criteria using the search widgets provided,and select the appropriate SRF or document to view it in the Submission Viewer.

Submission Import Progress Monitoring andError HandlingDuring submission import operations, a progress report and summary of the outcome of the lastimport operation is recorded in the log_entry attribute of the Regulatory Application RegistrationForm. This is labelled as User Comments in Documentum. It is useful to add the User Commentsfield to the column settings in D2, so that the current progress and last outcome can be tracked byrefreshing the display from time to time. When the import operation is completed, the status of theRegulatory Application Registration Form is changed from Importing to Active or Import Failed.If errors or warnings are reported in the User Comments field, the submission import log file canthen be opened to obtain further information. This file contains a rolling log of the import operationscarried out for the regulatory application, including details of any errors or validation warningsencountered during the import process, for example, PDF files containing invalid cross-reference

262


hyperlinks. The submission log file is attached to the Regulatory Application Registration Form as atext or crtext rendition that can be opened in Notepad from the Renditions tab in D2.

The selected submissions or eCTD sequences for the application are downloaded, imported, andcommitted in the repository one by one, so that the submission view XML files (including the eCTDcumulative view) are kept up-to-date and are valid for the last successfully-imported submissionor eCTD sequence. In the event of an irrecoverable error, such as the submission files could not bedownloaded and imported due to a network outage, the changes for the current submission are notapplied to the submission view files. In some cases, the SRF and submission files for the failedsubmission or sequence may exist in the repository, even though that submission or sequence is notvisible in the Submission Viewer. However, the SRF itself is not marked as imported until the importprocess is complete. This enables the failed submissions or sequences to be re-imported after theerror has been rectified and the system restored. On re-importing the remaining submissions orsequences, any files that currently exist in the repository are automatically deleted prior to importingthe new files.

To enable previously-imported submissions or sequences to be re-imported, it is necessary to updatethe relevant SRFs to mark them as not imported (or the SRFs can be deleted completely). For securityreasons, this can only be accomplished by a Documentum Superuser account, for example inDocumentum Administrator, through the following DQL statement:update cd_reg_submission_info objectset is_imported = falsewhere application_description = '<application-description>'[and submission_number = '<submission-number>']

To enable all imported submissions or sequences for the application to be re-imported, omit the lastand submission_number ... clause, so that all SRFs for the application are updated. It is notnecessary to delete the existing submission folders, subfolders, and documents from the repository,or to reset the XML view files. This is done automatically when the submissions or sequences arere-imported.

Supporting New eCTD XML FormatsDocumentum SSV supports the following eCTD XML formats by default:

eCTDModules Region/HealthAuthority

DTD/SchemaVersions

SpecificationVersion

PredefinedXML SchemaConfigurationNames

0.9 0.9 eCTD AustralianRegional XML filev 0.9

Australia(TherapeuticGoodsAdministration(TGA)

3.0 3.0 eCTD AustralianRegional XML filev 3.0

1.0 1.0Canada (HealthCanada) 2.2 2.2

eCTD CanadaRegional XML filev x.y

M1

263



DTD/SchemaVersions



1.0 1.0

1.1 1.1

1.2.1 1.2.1

1.3 1.3

1.4 1.4

2.0 2.0

Europe (EMAandall EU MemberState HealthAuthorities)

3.0 3.0

eCTD EURegional XMLfile v x.y

1.0 1.2 eCTD GulfCoopeartionCouncil RegionalXML file v 1.2

Gulf CooperationCouncil (SaudiFood and DrugAuthority)

1.1 1.5 eCTD GulfCoopeartionCouncil RegionalXML file v 1.5

Japan (Ministry ofHealth, Labourand Welfare(MHLW))

1.0, 1.0A, 1.0B 1.0 eCTD JapanRegional XMLfile v 1.0

South Africa(MedicinesControl Council(MCC)

1.0 1.0 eCTD SouthAfrican RegionalXML File v 1.0

1.0.1 1.0.1 eCTD SwissRegional XMLfile v 1.0.1

1.1 1.1

1.2 1.2

Switzerland(Swiss Medic)

1.3 1.3

eCTD SwissRegional XMLfile v x.y

0.92 0.92 eCTD ThailandRegional XML filev 0.92

Thailand (Bereauof Drug Control(BDC))

1.0 1.0 eCTD ThailandRegional XML filev 1.0

2.01 2.01 eCTD US-FDARegional XML filev 2.01

US (FDA)

264



DTD/SchemaVersions



3.3 2.3 eCTD US-FDARegional XML filev 2.3

M2-M5 Global (ICH)* 3.2 3.2 eCTD ICH XMLBackbone File v3.2

M4-M5 Studytagging files(STFs)

US (FDA) 2.2 2.2 ICH StudyTagging File v2.2

StructuredProduct Labelingfile

US (FDA) 1.0 1.0 FDA StructuredProduct LabelingFile

*The ICH is not a health authority, but an international industry body responsible for defining andmaintaining standard models such as the format used for eCTD module M2-M5 XML backbone files.

Documentum SSV uses the XML schema configuration objects in the repository to represent theseeCTD module formats. The predefined XML schema configuration objects are created automaticallyin the repository as objects of type cd_ectd_xml_schema, which are stored in the /System/SSV/XMLSchemas folder. These objects are used by Documentum SSV to identify and handle XML files thatare encountered in eCTD sequences during the submission import process.

To support additional eCTD XML formats, such as M1 regional XML formats for other regions ordifferent eCTD versions for existing regions, it is possible to extend the standard configurationas follows:

1. Using Documentum Administrator, copy and rename an existing cd_ectd_xml_schemaconfiguration object in the /System/SSV/XML Schemas folder that is similar to the formatrequired. For example, for US FDA v 2.3 regional M1 XML files, use the eCTD US-FDARegional XML file v 2.3 configuration as a starting point. It is also possible to create a newcd_ectd_xml_schema configuration object through DQL although it is generally easier tocopy and adjust the existing objects. It is recommended that the existing naming conventionsare followed, including the format version number suffix, so that the applicability of eachconfiguration object can be easily identified.

2. Adjust the properties of the configuration object. See XML Schema Configuration Object Settings,page 266 for more information.

3. Create an XSL transformation script, if required, to convert the XML into a standard format andstore it in the main content file of the XML schema configuration object as an xsl content file.Then, enable the XSLT processing option for this schema. This is only required for handling XMLfiles that use a format or element naming convention that is dissimilar to the standard ICHformat, such as Japanese regional M1 files. See Processing Standard XML Files, page 273 andTransforming Non-Standard XML Files, page 276 for more information.

4. On the application server, set up an XSL script to extract the regional M1 XML metadata forpreviewing in Documentum SSV. The easiest way to do this is to copy and edit one of thepredefined XSL scripts or adapt an agency-supplied XSL script to enable the regional XML

265


metadata to be previewed (see Previewing and Processing eCTD Module 1 Regional XMLFiles, page 279). Link this script to the XML schema configuration object by adjusting thexml_envelope_stylesheet property accordingly.

5. If necessary, add entries to the D2 dictionary, Submission Regional Metadata Conversions, toconvert regional XML-encoded values into suitable values for storage in Documentum. SeeMapping XML Values to Documentum Attributes, page 289 for more information.

6. Import a sample submission to test the new configuration and ensure that it can be navigatedand previewed correctly.

When working with different locales, you must adjust the operating system and the database withappropriate locale settings as suggested in the Documentum Content Server Installation Guide and makethe necessary changes in the Content Server. In addition, you must also ensure that JMS is adjustedaccordingly to the appropriate locale settings to be in sync with the Content Server and the database.For example, in the JMS startup script, add the following line in JAVA_OPTS and restart the service:'-Dfile.encoding=UTF-8'

XML Schema Configuration Object Settings

The attributes of the cd_ectd_xml_schema objects must be configured in Documentum as follows:

Attribute Data type Description Example Valuesfor eu-regional.xmlVersion 2.0 Schema

object_name Char(255) An arbitrary uniqueidentifier for this XMLschema configurationobject in the repository.

eu-regional.xml v 2.0

title Char(400) An optionaldescription of the XMLformat that this schemaobject represents.

eCTD EU RegionalXML file v 2.0

origin_url Char(255) An optional URLreferring to the websiteof the organization orHealth Authority thatowns the specificationof this XML format.

http://esubmission.ema.europa.eu/eumodule1/index.htm

266






xpath_qualifier Char(255) An XPath expressionidentifying the rootelement in an XMLfile that conformsto this format. Thisis used by SSV toidentify and selectthe appropriate XMLschema configurationobject to use for eachXML file discovered inthe eCTD sequence.

/eu-backbone[@dtd-version=’2.0’]

schema_category Char(32) Indicates the typeof this XML file, asfollows:

• eCTD RegionalXML File

• eCTD ICH XMLBackbone File

• eCTD ICH StudyTagging File

eCTD Regional XMLFile

xml_format_code Char(32) An abbreviateddisplay label denotingthis XML format, usedin the SSV Viewerto show the eCTDmodule formats orversions used in aparticular submission.

EU-2.0

enable_xslt_preprocessing

Boolean Indicates whetherthis XML file needsto be pre-processedthrough an XSLTtransformation scriptwhen loaded, in orderto convert it intoa form that can beprocessed more easily.The XSLT script itselfshould be stored as amain content file orrendition of the XMLschema configuration

F

267



object, using theDocumentumformat code “xsl”.See TransformingNon-Standard XMLFiles, page 276.

preview_stylesheet Char(32) Specifies the nameof the XSL stylesheetto be used to renderthe XML as HTML inthe relevant previewwidget (optional).

To support server-based prerenderingof XML to HTML, thespecified stylesheetmust be installed inthe /System/SSV/Stylesheetsfolder as a standarddm_document object(with format xsl).

To supportclient-based renderingof XML to HTML,the stylesheet mustalso be installed onthe application serverin the %WEB-APPS%/XMLViewer/stylefolder.

eu-regional_2-0.xsl

preview_widget_id Char(32) Specifies the widget IDof the target widgetthat should be usedfor previewing,for example,SSVStudyTaggingFileViewer. Optional – ifundefined orblank, the defaultpreview widget,SSVLeafDocumentViewer,is used.

SSVLeafDocumentViewer

268



contains_leaf_docs Boolean Indicates whetheror not this XML filecontains referencesto “leaf elements,”that is, documents tobe imported into therepository.

T

xml_extract_leaf_docs Boolean Indicates whetheror not leaf elementsshould be extractedfrom this XML fileand incorporated intothe main SubmissionHistory View. Thissetting should beenabled for RegionalM1 files and studytagging files, anddisabled for ICHbackbone files.

T

xml_extract_leaf_docs_from

Char(128) Specifies the XPathof the top-level XMLnodes that contain leafdocuments. Requiredif contains_leaf_docs isenabled. The wildcardvalue “*” indicates thatall elements should beincluded.

/eu-backbone/m1-eu

xml_leaf_doc_element Char(32) Specifies the name ofthe XML elementsrepresenting leafdocuments (after XSLTpre-processing, wherenecessary). Required ifcontains_leaf_docsis enabled andxml_extract_leaf_docs_from is not “*”.

leaf

269



xml_leaf_doc_attrs Char(128) Repeating Specifies thedocument-levelXML attributes tobe extracted fromleaf documentelements into thesubmission historyview or Documentumattributes, usingthe notation<target-Documentum-attribute-name>=<XPath-expression-for-XML-leaf-element>. Appliesto eCTD ICH XMLBackbone Files only(not regional M1XML files). See XMLMetadata Extraction,page 281.

(none)

is_required_leaf_doc_attr

Boolean Repeating For each value inthe above, indicateswhether a defined,non-blank attributevalue is required foreach leaf element(T), or whether it isoptional (F). This is notcurrently used.

(none)

override_leaf_attrs_on_rarf

Boolean Repeating For each of the above,specifies whetherthe value extractedfrom the XML filecan be used as adefault attribute valuefor the RegulatoryApplicationRegistration Form.This is not currentlyused.

(none)

270



contains_envelope Boolean Indicates whetheror not this XMLfile containssubmission-levelmetadata.

T

xml_envelope_element

Char(32) Specifies the nameof the top-levelXML elements thatcontain metadata tobe extracted fromregional XML files.Required if thecontains_envelopeflag is enabled.

envelope

xml_envelope_stylesheet

Char(32) The file name of theXSL stylesheet to useto render the regionalXML metadata asHTML in the SSVdocument previewscreen. The specifiedXSL stylesheetmust be installed inthe %WEBAPPS%/XMLViewer/stylefolder on the D2application server.See Previewing andProcessing eCTDModule 1 RegionalXML Files, page 279.

eu-regional.xsl

xml_envelope_attrs Char(128) Repeating Specifies the XMLattributes to beextracted from theenvelope elements intothe submission historyview or Documentumattributes using thenotation <target-attribute>=<XPath-expression>, where<XPath-expression> isevaluated in relation tothe envelope elementin each case.

health_authority= agency-name;country_code= @country;application_number =application/number;…

271



is_required_envelope_attr

Boolean Repeating For each value inthe above, indicateswhether a defined,non-blank attributevalue is required foreach leaf element(T), or whether it isoptional (F). This is notcurrently used.

T;T;T;…

override_env_attrs_on_rarf

Boolean Repeating For each of the above,specifies whetherthe value extractedfrom the XML filecan be used as adefault attribute valuefor the RegulatoryApplicationRegistration Form.This is not currentlyused.

T;T;T;…

The system can support multiple versions of the same XML format. A separate XML schemaconfiguration object must be defined for each format or version. The xpath_qualifier setting isused to identify and select the appropriate XML schema configuration object for each XML fileencountered during the eCTD import process, depending on whether the specified XPath expressionmatches an element in that XML file. The xpath_qualifier should include a qualifier in each caseso that it only matches XML files of the appropriate format and version, for example, the XPathexpression /eu-backbone[@dtd-version=’1.2.1’] only matches XML files containing a root elementnamed “eu-backbone” (ignoring the ”eu:” XML namespace prefix) where the “dtd-version” attributevalue of the root element is set to “1.2.1”. In other words, this schema only applies to XML files thatuse version 1.2.1 of the EU regional M1 XML format, such as the following:<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE eu:eu-backbone SYSTEM "../../util/dtd/eu-regional.dtd"><?xml-stylesheet type="text/xsl" href="../../util/style/eu-regional.xsl"?><eu:eu-backbone xmlns:eu="http://europa.eu.int" xmlns:xlink="http://www.w3c.org/1999/xlink"dtd-version="1.2.1"><eu-envelope><envelope country="uk"><application><number>N123456</number>

</application><applicant>Acme Pharma Inc.</applicant><agency-name>MHRA</agency-name><atc>C10AB05</atc><submission type="initial-maa" /><procedure type="national" /><invented-name>My Wonder Drug</invented-name><inn>wonderdrug</inn><sequence>0000</sequence>

272


<submission-description>Submission of registration dossier</submission-description></envelope>

</eu-envelope><m1-eu><m1-0-cover><specific country="uk">

<leaf operation="new" xlink:href="10-cover/uk/en-cover-wonder-drug-50mg.pdf"xlink:type="simple" checksum-type="md5" application-version="PDF 1.4"checksum="b132fc1e9e0c5c9f5401a4288f20f60f">

<title>Cover Page (English)</title></leaf>

</specific></m1-0-cover>

…etc.</m1-eu>

<eu:eu-backbone>

In this way, different XML formats or versions can be matched to different XML schema configurationobjects with different settings. The file system filename of the XML file itself is not significant (an EUM1 regional XML file does not need to be named eu-regonal.xml, for instance); neither is the locationof the XML file within the folder structure – the XML file recognition depends only on the contents ofthe XML file. If none of the XML schema configuration objects defined in the repository return a matchfor a particular XML file, the system logs a warning indicating that the XML file is not recognized,and treats it as a standard leaf document. It is not possible to extract metadata from unrecognizedXML files. It is also not possible to preview them in the Documentum SSV Document Viewer.

Processing Standard XML FilesIf the eCTD XML file conforms to a standard format, it is possible for Documentum SSV to processit directly by setting up XML schema configuration objects in the repository, as described in theSupporting New eCTD XML Formats, page 263 section.

To conform to the standard format:

1. The XML file should encapsulate all regional metadata (if any) directly or indirectly in oneXML node, known as the envelope node, and all leaf documents in a separate document node.For example, in US regional M1 files, the regional metadata is defined in the envelope node/fda-regional/admin, and the leaf documents in the document node /fda-regional/m1-regional.Similarly, in EU regional M1 files, the envelope node is /eu-backbone/eu-envelope, and thedocuments node is /eu-backbone/m1-eu. ICH eCTD M2-M5 XML files do not have an envelopenode because the regional metadata is stored in a separate M1 XML file. The document nodefor these is the root element, /ectd.

2. Each leaf document in the document node must be represented as a <leaf> element with thefollowing attributes defined for it:• operation: Denotes incremental modifications to previously-submitted documents, asand where necessary. Expected values are “new” for new documents; “replace” for newversions of previously-submitted documents; “append” for extensions (supplements) topreviously-submitted documents; or “delete” for previously-submitted documents to be

273


regarded as withdrawn. In the initial sequence 0000, only “new” documents are permitted.(Required)

• xlink:href: Specifies the document content file in terms of a relative file system path from thesequence-level folder. (Required except where operation = “delete”)

• xlink:type: Specifies the type of the xlink:href value, which is expected to be “simple”, wheredefined. (Optional)

• checksum: Specifies a checksum for the content file, which can be used to verify that thecontent file has not been modified since the XML file was generated. (Optional)

• checksum-type: Specifies the algorithm used to generate the checksum; usually “md5”(where defined). This is not currently used by DocumentumSSV. (Optional)

• application-version: Denotes the application name and version number associated with thecontent file, that is, the content file format. For example, “PDF-1.4”. (Optional)

• modified-file: Denotes the previously-submitted file affected by the operation (if any) as arelative file path from the top-level folder containing the sequence folders; the first pathelement being the previous sequence number. (Required where operation code is “replace”,“append” or “delete”; not applicable where it is “new”)

Each <leaf> element should also have a <title> sub-element, in which the document title isspecified. In practice, it is possible to use a different XML element name for leaf documents,provided the element has attributes and a <title> sub-element defined as above – the actual leafdocument element name is configured in the XML schema configuration object.

3. Non-leaf nodes in the document section are used to represent standard eCTD modules, sections,and subsections, nested to an arbitrary depth. These usually represent the file system folderstructure of the eCTD sequence. Non-leaf nodes can have the following additional attributevalues defined for them, indicating sections pertaining to specific contexts:

• substance—Name of drug substance

• product-name—Name of drug product

• manufacturer—Manufacturer of drug substance or product

• indication—Specific therapeutic indication

• dosageform—Specific dosage form

• excipient—Name of excipient (inactive ingredient)

These attributes are defined in the relevant ICH DTD. In practice, Documentum SSV enablesarbitrary metadata to be specified for non-leaf nodes.

4. <node-extension> elements may also be used to represent custom extensions to the standardeCTD folder structure. Each <node-extension> element has a <title> sub-element defining thesection title (display label), and one or more <leaf> document elements or <node-extension>sub-elements recursively.

5. In M1 regional modules, <specific> elements can be used to denote country-specific sections,where the country attribute value denotes the ISO country code in each case. For example,<specific country="de"> represents a section that is applicable to Germany only. In practice, theseelements only appear in EU regional M1 XML files. The country code value eu or the aliases ema,

274


emea, or common can be used to denote elements pertaining to the central European MedicalAuthority (EMA) or to the EU region in general.

6. In M1 regional modules, <pi-doc> elements can be used to denote package informationdocuments, such as labeling documents. This may be country-specific (with a country codedefined as above). These elements may also specify a type attribute value indicating the type oflabeling document in each case, although Documentum SSV does not use this. These elementsonly appear in EU regional M1 XML files.

All the XML files supported in the out-of-the-box configuration conform to this standard formatexcept for the Japanese regional M1 XML files.

Note: Whenever a large amount of processing is involved during the import of an eCTD submissionthat has multiple submission folders, it is better to allocate more resources to the Java Method Server.For example, memory should be preferably 1024 MB or greater.

275

Transforming Non-Standard XML FilesFor Documentum SSV to process non-standard-format XML files, it is necessary to provide atransformation script written in extensible stylesheet language (XSL) to enable Documentum SSV toconvert them into the standard format so that they can be processed. For example, Japanese regionalM1 XML files use a non-standard format as shown below:<?xml version="1.0" encoding="UTF-8"?><?xml-stylesheet type="text/xsl" href="../../util/style/jp-regional-1-0.xsl"?><universal xmlns="universal" xmlns:xlink="http://www.w3.org/1999/xlink"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="universal ../../util/dtd/jp-regional-1-0.xsd" lang="ja" schema-version="1.0"><document-identifier><title>Japanese title</title><doc-id>Document identifier</doc-id>

</document-identifier><document><content-block param="admin">…Japanese envelope metadata</content-block><content-block param="m1"><block-title>Japanese section label </block-title><content-block param="m1-03"><block-title> Japanese sub-section label </block-title><doc-content xlink:href="relative content file path"><title>1.3.5. Japanese document title</title><property name="operation" info-type="jp-regional-m1-toc">new</property><property name="checksum" info-type="jp-regional-m1-toc"> content file checksum

</property><property name="checksum-type" info-type="jp-regional-m1-toc">md5</property>

</doc-content>…etc.</content-block>

</content-block></document>

</universal>

To convert Japanese regional M1 XML files into the standard format, the following XSL transformationscript is used:<?xml version=”1.0" encoding="UTF-8" standalone="no"?><xsl:transform version="1.0" xmlns:xsl = "http://www.w3.org/1999/XSL/Transform"xmlns:ectd= "http://www.ich.org/ectd" xmlns:xlink = "http://www.w3.org/1999/xlink"xmlns:gen = "universal"><xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/><xsl:template match="/"><xsl:element name="jp-backbone"><xsl:attribute name="dtd-version"><xsl:value-of select="/gen:universal/@schema-version"/>

</xsl:attribute><xsl:apply-templates select="*"/></xsl:element></xsl:template><xsl:template match="gen:universal">



<xsl:element name="admin"><xsl:element name="title">

<xsl:value-of select="gen:document-identifier/gen:title"/></xsl:element>

<xsl:element name="document-id"><xsl:value-of select="gen:document-identifier/gen:doc-id"/>

276

</xsl:element><xsl:element name="properties"><xsl:attribute name="label"><xsl:value-of select="/gen:universal/gen:document/gen:

content-block[@param = 'admin']/gen:block-title"/></xsl:attribute><xsl:for-each select="/gen:universal/gen:document/gen:content-block[@param = 'admin']/*"><xsl:choose><xsl:when test="name() = 'doc-content'"><xsl:element name="property"><xsl:attribute name="item-number"><xsl:value-of select="@param"/></xsl:attribute><xsl:attribute name="name"><xsl:value-of select="./gen:property/@name"/></xsl:attribute><xsl:attribute name="label"><xsl:value-of select="./gen:title"/></xsl:attribute><xsl:attribute name="value"><xsl:value-of select="./gen:property"/></xsl:attribute></xsl:element></xsl:when><xsl:when test="name() = 'content-block'"><xsl:element name="property"><xsl:attribute name="item-number"><xsl:value-of select="@param"/></xsl:attribute><xsl:attribute name="name"><xsl:value-of select="./gen:doc-content/gen:property/@name"/>

</xsl:attribute><xsl:attribute name="label"><xsl:value-of select="./gen:block-title"/></xsl:attribute><xsl:attribute name="value"><xsl:value-of select="./gen:doc-content/gen:property"/>

</xsl:attribute></xsl:element></xsl:when></xsl:choose></xsl:for-each></xsl:element></xsl:element>

<xsl:element name="m1-jp"><xsl:attribute name="label"><xsl:value-of select="/gen:universal/gen:document/gen:

content-block[@param = 'm1']/gen:block-title"/></xsl:attribute><xsl:apply-templates select="/gen:universal/gen:document/gen:

content-block[@param = 'm1']/gen:content-block"/></xsl:element></xsl:template>

<xsl:template match="gen:content-block"><xsl:element name="{@param}"><xsl:attribute name="label"><xsl:value-of select="./gen:block-title"/></xsl:attribute><xsl:apply-templates/></xsl:element></xsl:template>

<xsl:template match="gen:doc-content"><xsl:element name="leaf"><xsl:attribute name="operation"><xsl:value-of select="./gen:property[@name = 'operation']"/>

</xsl:attribute><xsl:attribute name="checksum-type"><xsl:value-of select="./gen:property[@name =

'checksum-type']"/></xsl:attribute>

<xsl:attribute name="checksum"><xsl:value-of select="./gen:property[@name = 'checksum']"/></xsl:attribute>

<xsl:attribute name="xlink:href"><xsl:value-of select="@xlink:href"/></xsl:attribute><xsl:if test="string-length(./gen:property[@name = 'modified']) > 0"><xsl:attribute name="modified-file"><xsl:value-of select="./gen:property[@name = 'modified']

"/></xsl:attribute>

</xsl:if><xsl:element name="title"><xsl:value-of select="./gen:title"/></xsl:element>

277


</xsl:element></xsl:template>

<xsl:template match="*"/></xsl:transform>

This script is included in the standard installation, and is stored in the repository as the main contentfile of the XML eCTD schema configuration object for Japanese regional M1 files. The XSL file is thendownloaded and applied automatically to Japanese M1 XML files at import time as they are loaded,prior to processing them. A copy of this XSL transformation script can also be found on theApplicationServer in the file %WEBAPPS%/XMLViewer/style/jp-regional-1-0-normalize.xslt forreference, although it is not used by the Viewer.

The output from the XSL transformation script is another XML file, of the following form:<jp-backbone dtd-version=”Japanese schema version”><admin><title>Japanese title</title><document-id>document identifier</document-id><properties label="Japanese section label"><property item-number="nn" name="property-code" label="Japanese property label"

value="Property value"/>...</properties></admin><m1-jp label="Japanese section label "><m1-01 label="Japanese sub- section label "><m1-01-03><leaf operation="new " checksum-type="md5" checksum="content file checksum"

xlink:href="relative content file path"<title>Japanese document title</title></leaf>...</m1-01-01></m1-01>...</m1-jp></jp-backbone>

This now conforms to the standard XML format required by Documentum SSV. The XML schemaconfiguration settings are configured accordingly for this XML file to enable it to be processed asnormal. For example, the xml_envelope_element XPath setting is set to /jp-backbone/admin in theeCTD schema configuration object for Japanese M1 files; similarly, xml_extract_leaf_docs_from is setto /jp-backbone/m1-jp, and so on.

It is possible to use a similar technique to support new eCTD formats that do not conform to thestandard XML format, as follows:

1. Create an XSL transformation script to convert the eCTD format into a standard format, just as inthe example above.

2. Test the XSL transformation script by linking a sample eCTD XML file to it, for example, add anXML preprocessing instruction of the form <?xml-stylesheet type="text/xsl" href="filename.xsl"?>to the XML header in the sample file, and opening it in the browser.

3. After verifying that the XSL transformation script is generating XML output appropriately inthe standard format, create a new XML configuration object in the repository representingthe new eCTD format, and configure the settings as described previously. Ensure that theenable_xslt_processing option is enabled and import the XSL transformation script as the

278


main content file of the XML configuration object in the repository, using the Documentumformat code xsl.

4. Test the installation by importing a sample eCTD that contains the XML files that use the newformat.

You can also add XSL scripts to the existing XML schema configuration objects to transform themetadata in XML files, for example, to convert values to lower-case, translate country names intocorresponding country code values, truncate values that are too long, and so on. However, in thedefault installation, XSL transformation is only used for converting Japanese regional M1 XMLfiles and study tagging files. XSL scripts can also be used on the application server to generateXML preview renditions.

Previewing and Processing eCTD Module 1Regional XML FilesXML preview renditions (of format xml_preview) are generated and stored for each module M1 XMLfile at import time, alongside the original XML file. This enables the metadata contained in theseXML files to be previewed in the Submission Document Preview panel in the same way as for PDFdocuments. At the same time, any leaf documents referenced in the regional XML file are extractedand incorporated into the main submission history view, so that these files can be navigated andpreviewed alongside the main eCTD module 2-5 files. To enable this, the following settings mustbe configured in the relevant eCTD schema configuration object:

contains_envelope Set to T (enabled).

xml_envelope_element Specifies the elements to be included in the XMLpreview rendition, after having transformed theXML file into the standard format. This is alsoused for XML metadata extraction purposes.

xml_envelope_stylesheet Specifies the name of the stylesheet usedto render the XML file into HTML in theSubmission Document Viewer. Predefinedstylesheets are provided for each of thesupported regions (US, Europe, Canada, andJapan). Custom stylesheets can be created tosupport other regions.

contains_leaf_docs Set to T (enabled) if the XML file contains <leaf>elements as well as metadata, or F (disabled)otherwise.

xml_extract_leaf_docs_from Specifies the top-level document elementcontaining <leaf> elements (indirectly), afterhaving transformed the XML file into thestandard format, where necessary. The specifiedelement, together with all of its subordinates,is removed from the XML preview rendition,so that the XML preview rendition containsonly envelope metadata. This is because the

279


leaf document nodes themselves cannot benavigated from the Submission DocumentViewer pane used for previewing. Instead,these elements are incorporated directly intothe Submission History XML, so they can benavigated through the Submission Navigatorview. In this way, the Submission Navigatorprovides a consolidated view across all of theM1-M5 eCTD modules, even though the M1module is actually defined as a separate XMLfile.

For example, the following settings are preconfigured in the schema configuration object named“us-regional_2-01”, which can be found in the /SSV/XML Schemas folder, and is used to generatepreviews of “us-regional.xml” files:

XML Schema Configuration Settings: us-regional_2-01

Configuration Setting Value

contains_envelope T

xml_envelope_element admin

xml_envelope_stylesheet us-regional.xsl

contains_leaf_docs T

xml_extract_leaf_docs_from /fda-regional/m1-regional

This tells the system to extract the XML metadata from the admin element of us-regional.xmlfiles below the root element, fda-regional, to generate the xml_preview rendition, and extractthe leaf document elements from the m1-regional element below the root element into the mainsubmission view. If the user clicks the us-regional.xml element in module 1 in the SubmissionViewer, the xml_preview rendition is rendered into HTML by the relevant stylesheet (in this case, the“us-regional.xsl” stylesheet is used) and displayed in the document preview panel.

Note: The xml_preview rendition is generated and stored in the repository automatically at importtime. It is attached to the regional XML file as a rendition. This is used only for previewing the XMLmetadata in SSV. The primary content of the regional XML file is not affected, and preserves a recordof the XML file that was included in the submission. If the imported submission folder is exportedback out to the local filesystem, only the original primary content files are exported, and not the SSVrenditions, so that an exact copy of the submitted files is exported.

If a new region or eCTD version for an existing region is to be supported, a new XSL stylesheet for itmust be provided to enable the XML preview to be generated. These stylesheets must be installedin the %WEBAPPS%/XMLViewer/style folder on the application server, with the predefinedstylesheets. In some cases, the XSL stylesheets provided by the relevant Authority itself can be useddirectly, or adapted as necessary. For example, standard eu-regional.xsl stylesheet provided withDocumentum SSV is based on the stylesheet provided by the EMA. However, in other cases, a customstylesheet will need to be developed, where the Agency does not provide one (such as Canada), orwhere it is unsuitable for direct use, for example, it contains JavaScript or XSL functions that refer toM1 leaf elements, which are not included in the XML preview (such as the US FDA stylesheet). In

280

these cases, you can use one of the standard stylesheets that are pre-installed with Documentum SSVas a guideline for developing new stylesheets.

The following is a transcript of the us-regional.xsl script that is provided for this purpose:?xml version="1.0" encoding="UTF-8"?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"xmlns:fda-regional="http://www.ich.org/fda"><xsl:template match="/"><html><head><meta http-equiv="content-type" content="text/html; charset=UTF-8"/></head><body><h3><img src="icons/countryflags/us.gif" style="padding-right: 10px;"/>US Food and Drugs Administration - Regulatory Information</h3><table border="0" cellspacing="20px"><tr><td>Applicant:</td><td><xsl:value-of select="/fda-regional:fda-regional/admin/

applicant-info/company-name"/></td></tr><tr><td>Product Name:</td><td><xsl:value-of select="/fda-regional:fda-regional/admin/

product-description/prod-name"/></td></tr><tr><td>Application Number:</td><td><xsl:value-of select="/fda-regional:fda-regional/admin/

product-description/application-number"/></td></tr><tr><td>Application Type:</td><td><xsl:value-of select="/fda-regional:fda-regional/admin/

application-information/@application-type"/></td></tr><tr><td>Submission Type:</td><td><xsl:value-of select="/fda-regional:fda-regional/admin/

application-information/submission/@submission-type"/></td></tr><tr><td>Date of Submission (<xsl:value-of select="/fda-regional:fda-regional/admin/

applicant-info/date-of-submission/date/@format"/>):</td><td><xsl:value-of select="/fda-regional:fda-regional/admin/

applicant-info/date-of-submission/date"/></td></tr><tr><td>Sequence Number:</td><td><xsl:value-of select="/fda-regional:fda-regional/admin/

application-information/submission/sequence-number"/></td></tr></table></body></html></xsl:template>

</xsl:stylesheet>

Note that this stylesheet is only used for previewing the XML metadata in SSV: the standardagency-supplied regional stylesheets can still be included in the eCTD submission itself (in the utilsfolder) and used for navigating the submission when it has been exported to the local file system.

XML Metadata ExtractionSubmission-level metadata can be extracted from eCTD regional M1 XML files into Documentum,in order to facilitate browsing and searching for submissions and regulatory applications. Thismetadata is extracted from the envelope section of the XML file and stored in the correspondingDocumentum attributes of the top-level cd_submission_folder object representing the sequence folderin the repository, the cd_reg_submission_info object representing the Submission Registration form,and the cd_reg_admin_info object representing the Regulatory Application Registration Form for theapplication. The following attributes are defined in the default installation for each of these objecttypes, for XML metadata extraction purposes:

281


Documentum Attribute Data Type Description

country_code Char(2) The ISO country code forthe country to which theapplication is being submitted,for example, “ca” for Canada.For European submissions,the country code “eu” shouldbe used for CentralizedProcedure (CP) submissionsto the EMA, or otherwise thecountry code for the relevanttarget EU Member State orReference Member State forNational Procedure (NP) orMutual Recognition Procedure(MRP) should be used, forexample, “sv” for Sweden. Byconvention, this is assumed tobe the country code of the first“envelope” element in the EURegional XML file

concerned_member_states Char(2) REPEATING ISO country codes for otherEU Member States actingas reviewers of Europeansubmissions using the MRP.By convention, this is assumedto be the country codes forall except the first “envelope”element in the EU RegionalXML file. Applies only to MRPsubmissions to the EU.

dosage_form Char(128) REPEATING The forms in which a drugproduct is provided for adefined administration route.

dosage_strength Char(32) REPEATING For each dosage form, specifiesthe amount of active ingredientin terms of a defined unit ofmeasure. For example, theamount of active ingredientcontained in one dose asspecified in the label.

282


Documentum Attribute Data Type Description

drug_product_manufacturer Char(128) REPEATING The business entity/entitiesengaged in making,assembling, processing ormodifying a finished drugproduct; or packaging,repackaging or otherwisechanging the container orwrapper for a drug product.

drug_product_name Char(64) REPEATING For each drug productmanufacturer, the nameof the manufactured drugproduct in each case.

drug_substance_manufacturer Char(128) REPEATING The business entity/entitiesengaged in making,assembling, processing ormodifying the pharmaceuticalingredients used in a drugproduct.

drug_substance_name Char(64) REPEATING For each drug substancemanufacturer, the name of themanufactured drug substancein each case.

excipients Char(128) REPEATING A list of excipients (inactiveingredients) used in themanufacture of a drug product.

indication Char(128) REPEATING The indications (diseases) thata particular drug product isdesigned to treat.

product_generic_name Char(128) REPEATING The unique non-proprietaryor common name for a drugdefined by establishing logicalnomenclature classificationsbased on pharmacological orchemical relationships andapproved by USAN or INN.

product_trade_name Char(128) REPEATING The proprietary name (brandname) of a drug productdesignated for regulatoryapproval/marketing.

submission_type Char(48) The type of individualsubmission within theapplication, as defined bythe relevant Agency.

Some of these attributes, such as region, health_authority, submission_number, submission_type,and submission_date, may be specified in the Import Submission dialog box at import time, or they

283


may be overridden with metadata extracted from the XML file, where defined. To enable XMLextraction for these attributes:

1. Ensure that the relevant attributes are defined for the cd_submission_folder andcd_reg_admin_info object types in Documentum; add them to both object types if necessary.

2. In the relevant XML schema configuration object for the regional M1 XML file:

a. Enable the contains_envelope setting.

b. Set xml_envelope_element to the name of the “envelope” elements containing the regionalmetadata in the XML file. In most cases there will be only one such element; however, EUregional XML files for submissions using the MRP contain multiple “envelope” elements– one for each EU Member State to which the submission is sent. In that case, the first“envelope” element is assumed to pertain to the Reference Member State, and the remainderto Concerned Member States.

c. Specify the attributes to be extracted in the xml_envelope_attrs repeatingattributes of the XML schema configuration object, using values of the form“<Documentum-attribute-name>=<XML-XPath-expression>”.

The specified XPath expression is evaluated for each envelope element in the regional XMLfile and the first defined, non-null value found is used. In the case of repeating Documentumattributes, the values in each envelope element are combined into a set of distinct values. Forinstance, in the EU regional XML files, the submission type is defined in the type attribute ofthe <submission> sub-element below the <envelope> element:<envelope><submission type=”initial-maa”/>

</envelope>

To extract this value into Documentum, the xml_envelope_attrs repeating attribute settingsfor the EU regioinal schemas contain the following entry:submission_type=submission/@type

In this case, the extracted value is initial-maa. It is possible to convert the extracted valuesusing attribute expressions or through an XSLT transformation script. See Mapping XMLValues to Documentum Attributes, page 289 for details.

d. For each of the above, set the corresponding flags in the is_required_envelope_attr andoverride_env_attrs_on_rarf repeating attributes to T (true) or F (false), accordingly.

If an attribute is marked as “required” in the XML envelope but is missing from the XML file or has ablank value specified for it in the XML file, this is logged as a warning. If the “override on RARF”setting is enabled, the extracted attribute is copied to the relevant Regulatory Application RegistrationForm as well as the submission folder, even if it is already defined at that level. If this flag is disabled,the extracted attribute is only copied to the Regulatory Application Registration Form if the formitself does not already have a defined value, that is, it is used as a default value for the RegulatoryApplication Registration Form in that case.

284


Example 1: US Submission to the FDA

The following code shows part of a sample us-regional.xml file included in module M1 of an eCTDsubmission to the US FDA:<?xml version="1.0" encoding="utf-8"?><!DOCTYPE fda-regional:fda-regional SYSTEM "..\..\util\dtd\us-regional-v2-01.dtd"><?xml-stylesheet type="text/xsl" href="..\..\util\style\us-regional.xsl"?><fda-regional:fda-regional xmlns:fda-regional="http://www.ich.org/fda" xmlns:xlink="http://www.w3c.org/1999/xlink" dtd-version="2.01" xml:lang="en"><admin><applicant-info><company-name>Acme Pharmaceuticals Inc.</company-name><date-of-submission><date format="yyyymmdd">20141205</date></date-of-submission></applicant-info><product-description><application-number>123456</application-number><prod-name type="proprietary">Wonder Drug</prod-name></product-description><application-information application-type="ind"><submission submission-type="original-application"><sequence-number>0000</sequence-number></submission></application-information></admin><m1-regional>

…etc.</m1-regional></fda-regional:fda-regional>

The standard XML schema configuration object for the above is called “us-regional_2-01”, and ithas the following predefined settings:

XML Schema ConfigurationSetting Name

XML Schema ConfigurationSetting Values

Documentum Attribute ValueExtracted from Example XMLFile (if any)

xml_envelope_element admin —

country_code=’us’ us

health_authority=’FDA’ FDA

submission_date=./applicant-info/date-of-submission/date

20141205

submission_date_format=./applicant-info/date-of-submission/date/@format

yyyymmdd

application_num=./product-description/application-number

123456

application_type=./application-information/@application-type

ind

xml_envelope_attrs

285



XML Schema ConfigurationSetting Values


submission_number=./application-information/submission/sequence-number

0000

submission_type=./application-information/submission/@submission-type

original-application

product_trade_name=./product-description/prod-name[@type=’proprietary’]

Wonder Drug

product_generic_name=./product-description/prod-name[@type=’established’]

—

In the above, XPath expressions are used to extract the relevant metadata from theadmin node of the XML file. For more information on using XPath expressions, refer to:http://www.w3schools.com/XPath/.

Example 2: EU Submission to Multiple EU Countries

This next example is for an eu-regional.xml file included in a submission to three EU Member States(Sweden, Germany, and France) using the MRP. It has three envelope sections, one for each country:<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE eu:eu-backbone SYSTEM "../../util/dtd/eu-regional.dtd"><?xml-stylesheet type="text/xsl" href="../../util/style/eu-regional.xsl"?><eu:eu-backbone xmlns:eu="http://europa.eu.int" xmlns:xlink="http://www.w3c.org/1999/xlink"dtd-version="1.2.1"><eu-envelope><envelope country="sv"><application><number>pending</number>

</application><applicant>ACME Pharmaceuticals Inc.</applicant><agency-name>SV-MPA</agency-name><atc>C10AB05</atc><submission type="initial-maa" /><procedure type="mrp" /><invented-name>Wonder Drug</invented-name><inn>cureimol monosulphate</inn><sequence>0000</sequence><submission-description>Submission of registration dossier</submission-description>

</envelope><envelope country="de"><application><number>pending</number>

</application><applicant>ACME Pharmaceuticals Inc.</applicant><agency-name>DE-BfArM</agency-name><atc>C10AB05</atc><submission type="initial-maa" />

286

http://www.w3schools.com/XPath/


<procedure type="mrp" /><invented-name>Wunderdroge</invented-name><inn>cureimol monosulphate</inn><sequence>0000</sequence><submission-description>Einreichung des Registrierungsdossiers </submission-description>

</envelope></eu-envelope><envelope country="fr"><application><number>pending</number>

</application><applicant>ACME Pharmaceuticals Inc.</applicant><agency-name>FR-AFSSAPS</agency-name><atc>C10AB05</atc><submission type="initial-maa" /><procedure type="mrp" /><invented-name>Médicament miracle</invented-name><inn>cureimol monosulphate</inn><sequence>0000</sequence><submission-description>Présentation d'un dossier d'inscription</submission-description>

</envelope></eu-envelope><m1-eu>

…etc.</m1-eu>

</eu:eu-backbone>

In this case, since the XML file contains multiple envelope elements, multiple values can beextracted for repeating attributes, such as concerned_member_states, product_trade_name, andproduct_generic_ name. Duplicate values are ignored. The first envelope element pertains to theReference Member State, and the others pertain to Concerned Member States (this only applies to EUsubmissions using the MRP; otherwise there would be only one envelope element). The standardXML schema configuration object for the above is “eu-regional_1-2-1.xml” in this case, and has thefollowing predefined settings:


XML Schema ConfigurationSetting Value(s)


xml_envelope_element envelope —

country_code=@country sv

concerned_member_states=.[position()>1]@country

de; fr

application_number=application/number

pending

health_authority=agency-name SV-MPA

atc_code=atc C10AB05

submission_type=submission/@type

initial-maa

submission_procedure_type=procedure/@type

mrp

product_trade_name=invented-name

Wonder Drug; Wunderdroge;Médicament miracle

xml_envelope_attrs

287



XML Schema ConfigurationSetting Value(s)


product_generic_name=inn cureimol monosulphate

sequence_number=sequence 0000

title=submission-description Submission of registrationdossier

Note the use of the [position()>1] condition in the XPath expression for concerned_member_states,which means that all country codes except that of the first envelope element are extractedand combined together into the concerned_member_states repeating attribute. In the case ofsingle-valued attributes such as country_code, application_number, and title, where there aremultiple envelope elements, the first element that has a defined, non-null value takes precedence;usually those that are specified in the first envelope element. Therefore, in this example, country_codeis set to sv (the code for Sweden, as specified in the country attribute of the first envelope element)and title is set to “Submission of registration dossier” (the first title value; the German and Frenchtitle values are ignored in this case, because title is a single-valued attribute in Documentum).

Submission-level metadata is also recorded in the Submission History XML file for each submission,enabling this metadata to be displayed by the SSV Viewer. By default, the following attributes arerecorded for each submission or eCTD sequence:

• submission_number—Recorded in the id XML attribute.

• submission_date—Recorded in separate day, month, and year XML attributes, in order tofacilitate localization.

• submission_type–Recorded in the type XML attribute.

• submission_procedure_type—Recorded in the procedure-type XML attribute (applies to EUsubmissions only).

• health_authority—Recorded in the health-authority XML attribute.

• concerned_member_states—Recorded in the concerned-member-states XML attribute (applies toEU MRP submissions only).

In the standard XSL stylesheet, which is provided as part of the SSV web application(submission-navigator-4.0.xsl), these attributes are listed in the Table of Contents (TOC) view whenan application is selected. You can extend the standard XSL stylesheet to include additional customsubmission-level metadata in this view. However, only metadata that is recorded in the SubmissionHistory XML file can be displayed in this view. To arrange for custom metadata to be recorded in theSubmission History XML file at import time, you can change the D2 lifecycle configuration settingsfor the Regulatory Application Registration Form lifecycle to include a –record_submission_attrsargument, overriding the default settings.

Note: Including submission-level metadata in the Submission History XML file that can changeafter the submission has been imported is not recommended. This would mean that the valuesrecorded in the XML file may be different to the corresponding values in Documentum, leading toinconsistencies between the TOC view in the Submission Navigator and the Submission RegistrationForm properties page in Documentum. For this reason, properties such as submission_status areomitted from the Submission History XML file in the default installation. However, it is safe toinclude properties that are read-only after importing.

288


Document-level metadata can also be extracted for each <leaf> element, from both regionalM1 XML files and ICH M2-M5 eCTD backbone files, and populated on the correspondingcd_submission_element objects representing the archived submission documents in Documentum.These attributes are defined in the xml_leaf_doc_attrs setting of the ICH eCTD XML Backboneschema configuration object. The default settings for this are as follows:

• country_code=@country

• dosage_form=ancestor::*[@dosageform != ’’]/@dosageform

• drug_product_manufacturer=ancestor::*[@manufacturer != ’’ and @product-name !=’’]/@manufacturer

• drug_product_name=ancestor::*[@manufacturer != ’’ and @product-name != ’’]/@product-name

• drug_substance_manufacturer=ancestor::*[@manufacturer != ’’ and @substance !=’’]/@manufacturer

• drug_substance_name=ancestor::*[@manufacturer != ’’ and @substance != ’’]/@substance

• ectd_application_version=@application-version

• ectd_checksum_type=@checksum-type

• ectd_checksum=@checksum

• ectd_element_name=../name()

• ectd_operation=@operation

• ectd_prev_submitted_file=@modified-file

• excipients= ancestor::*[@excipients != ’’]/@excipient

• indication=ancestor::*[@indication != ’’]/@indication

• title=title

Note that some of these attributes, such as dosage_form, drug_product_manufacturer, and so on, aredefined in the parent XML elements containing the <leaf> element, which is why the ancestor XPathexpression function (or axis) is used for those items.

Mapping XML Values to Documentum Attributes

To address the issue of importing a submission that contains XML metadata that does not match themetadata in Documentum, it is possible to transform the XML before it is processed so that theextracted XML values are mapped to the corresponding Documentum attributes. To enable this, anoptional D2 dictionary, Submission Regional Metadata Conversions, has been provided.

The keys in this dictionary are of the syntax, "<attribute-name>.<XML-value>", for example,"health_authority.ukmhra". The Converted Value alias specifies the value to be used in DocumentumSSV, for example, "MHRA". This enables regional XML files that use different data encodings inDocumentum SSV to be processed correctly.

It is also possible to use CDF attribute expressions in the XML schema "attributes" configurationsettings, using the syntax:<attribute-name>=<XPathExpression> => <attribute-expression>

289


For example,health_authority=submission/@agency-code=>$upper($arg(xmlvalue))

In the example, the expression converts the agency code attribute in the regional XML file intouppercase. The $arg(xmlvalue) function refers to the raw extracted XML value.

Worked Example: Extending SSV to Support the USRegional 2.3 eCTD Format (DTD Version 3.3)

From June 2015, the US FDA announced the acceptance a new regional eCTD M1 format, version 2.3,which uses a revised XML Document Type Definition (DTD) version 3.3. This format is supported inDocumentum SSV as standard, except for grouped applications (in which multiple related sequencesare included in one submission relating to different drug products).

You can use the following steps as a guide to extend the SSV configuration to support this newformat and to extend the configuration further to support additional regions or new DTD formatsfor existing regions:

1. Download the regional eCTD XML specification and stylesheet from the relevant Agencywebsite and obtain a sample XML in the relevant DTD format. For example, the USregional eCTD M1 specification and stylesheet can be downloaded from the FDA website(http://www.fda.gov/Drugs/DevelopmentApprovalProcess/FormsSubmissionRequirements/ElectronicSubmissions/ucm153574.htm).

A transcript of a sample us-regional.xml file using the DTD 3.3 format:<?xml version="1.0" encoding="UTF-8" standalone="no"?><!DOCTYPE fda-regional:fda-regional SYSTEM "http://www.accessdata.fda.gov/static/eCTD/us-regional-v3-3.dtd"><?xml-stylesheet type="text/xsl" href="http://www.accessdata.fda.gov/static/eCTD/us-regional.xsl"?><fda-regional:fda-regional dtd-version="3.3" xml:lang="text" xmlns:fda-regional="http://www.ich.org/fda" xmlns:xlink="http://www.w3c.org/1999/xlink"><admin><applicant-info><id>123456789</id><company-name>Wonder Drug Company</company-name><submission-description>Pre-Launch Video Sample</submission-description><date-of-submission><date format="mmddyy">062315</date>

</date-of-submission><applicant-contacts><applicant-contact><applicant-contact-name applicant-contact-type="fdaact4">Regulatory Manager X

</applicant-contact-name><telephones><telephone telephone-number-type="fdatnt1">1-123-456-7890</telephone>

</telephones><emails><email>[email protected]</email>

</emails></applicant-contact><applicant-contact><applicant-contact-name applicant-contact-type="fdaact1">Regulatory Manager Y

</applicant-contact-name><telephones><telephone telephone-number-type="fdatnt1">1-123-456-7891</telephone>

290

http://www.fda.gov/Drugs/DevelopmentApprovalProcess/FormsSubmissionRequirements/ElectronicSubmissions/ucm153574.htm



</telephones><emails><email>[email protected] </email>

</emails></applicant-contact>

</applicant-contacts></applicant-info><application-set><application application-containing-files="true"><application-information><application-number application-type="fdaat1">123456</application-number>

</application-information><submission-information><submission-id submission-type="fdast8">0000</submission-id><sequence-number submission-sub-type="fdasst1">0000</sequence-number>

</submission-information></application>

</application-set></admin><m1-regional><m1-2-cover-letters><leaf operation="new" xlink:href="102-cover-letters/cover.pdf" xlink:type="simple"

checksum-type="md5" ID="id123" application-version="PDF 1.4" checksum="8241a7c5bb98dee28b1385dc261345b2">

<title>Cover Letter - Sample</title></leaf>

</m1-2-cover-letters><m1-15-promotional-material promotional-material-audience-type="fdapmat1"><m1-15-2-materials promotional-material-doc-type="fdapmdt2"><m1-15-2-1-material promotional-material-type="fdapmt28" material-id="A"><m1-15-2-1-1-clean-version><leaf operation="new" xlink:href="115-promo-material/1152-materials/a/

tvc-storyboard-0814.pdf" xlink:type="simple" checksum-type="md5" ID="ddjwv124" application-version="PDF 1.4" checksum="8241a7c5bb98dee28b1385dc261345b2">

<title>TV Storyboard</title></leaf><leaf operation="new" xlink:href="115-promo-material/1152-materials/a/

tv-ad-video-draft.wmv" xlink:type="simple" checksum-type="md5" ID="ddjwv1124" application-version="PDF 1.4" checksum="a28a808f9b7cb01dee5e11779a70c51c">

<title>Proposed Television Advertisement</title></leaf>

</m1-15-2-1-1-clean-version><m1-15-2-1-2-annotated-version><leaf operation="new" xlink:href="115-promo-material/1152-materials/a/

annotated-tvc-storyboard-0814.pdf" xlink:type="simple" checksum-type="md5" ID="ddjwv125"application-version="PDF 1.4" checksum="8241a7c5bb98dee28b1385dc261345b2">

<title>Annotated TV Storyboard</title></leaf>

</m1-15-2-1-2-annotated-version></m1-15-2-1-material>

</m1-15-2-materials></m1-15-promotional-material>

</m1-regional></fda-regional:fda-regional>

2. Formulate an XPath expression that can be used to identify the new XML files and distinguishthem from other XML files, including other versions of the regional XML file for the same region.In this example, a suitable XPath expression is:/fda_regional[@dtd-version='3.3']

291

This XPath expression only matches an element in the XML files with a root element namedfda_regional (ignoring the fda_regional: namespace prefix) and a dtd-version attribute in thatroot element with the value 3.3. This is used to set the xpath_qualifier setting in the new eCTDXML schema configuration object, so that it only applies to US Regional v 2.3 XML files.

Note: The DTD version number is specified as 3.3 within the XML file, and not 2.3. In addition,the XML namespace prefix, fda_regional:, should not be included in the XPath expression.Otherwise, it will not be evaluated correctly.

3. Determine whether or not an XSL preprocessing transformation script needs to be applied tothe XML file to convert it into a form that can be processed by LSSSV. Develop one if necessary.See Processing Standard XML Files, page 273 and Transforming Non-Standard XML Files, page276 for more information.

In this case, the XML conforms to the standard eCTD format (apart from the fact that it containsFDA-specific metadata in the <admin> section), so it would appear that an XSL transformationscript is not required and LSSSV can process these XML files directly. However, special encodingsare used to denote the metadata in the XML file, instead of literal values: for example,

• applicant-contact-type="fdaact4"

• telephone-number-type="fdatnt1"

• application-type="fdaat1"

• submission-type="fdast8"

• submission-sub-type="fdasst1"

It is necessary to convert these encodings into meaningful values in the XML preview for displaypurposes. For example, according to the US FDA guidance documents, the applicant contacttype code “fdaact4” should be displayed as “Promotional Labeling and Advertising RegulatoryContact”. One way to convert XML values is to add entries to the D2 value mapping dictionary,Submission Regional Metadata Conversions. However, this only applies to XML metadataextracted from the XML file into Documentum. Moreover, some of the XML metadata, such asapplicant contact type codes, are not extracted into Documentum attributes at all, as they are notpart of the standard object model.

An XSL transformation script can be used to convert the encoded values into literal values in theXML preview used in the Submission Viewer. A partial transcript of this script is shown below:<?xml version="1.0" encoding="UTF-8"?><xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:ectd="http://www.ich.org/ectd"xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xlink-ectd="http://www.w3c.org/1999/xlink"><xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>…<xsl:variable name="APPLICATIONCONTACTTYPES" select="concat('fdaact1=Regulatory', ';','fdaact2=Technical', ';','fdaact3=US Agent', ';','fdaact4=Promotional / Advertising', ';')"/>…<xsl:template match="@* | node()"><xsl:copy><xsl:apply-templates select="@* | node()"/></xsl:copy><-- Translate contact type codes -->

292


<xsl:template match="//@applicant-contact-type"><xsl:attribute name="applicant-contact-type"><xsl:value-of select="substring-before(substring-after($APPLICATIONCONTACTTYPES,

concat(., '=')), ';')"/></xsl:attribute></xsl:template>…</xsl:transform>

A copy of the complete XSL transformation script can be found on the application server, in the%WEBAPPS%/style/us-regional_2-3-normalize.xslt file. This file is provided forreference purposes only and is not used by LSSSV itself.

In the above sample script, the application contact type encoding mappings to correspondingdisplay labels are defined in the XSL variable “APPLICATIONCONTACTTYPES” as a series ofname=value pairs delimited by semicolon characters. A default XSL processing rule is thendefined, which applies to all XML nodes except those that match other, more specific rules. Thiscopies the XML elements, attributes, and textual data values to the output XML file unchanged.Then, a rule is defined for converting the “applicant-contact-type” attribute values (in anyXML element) from the encoded forms into the corresponding display values. For example,the element:

<applicant-contact-name applicant-contact-type="fdaact4">RegulatoryManager X</applicant-contact-name>

in the input XML file is converted to:

<applicant-contact-name applicant-contact-type=" Promotional /Advertising'">Regulatory Manager X</applicant-contact-name>

in the output XML file. This enables the Submission Viewer to display applicant contact typecodes as meaningful values in the XML preview. Similar variables and XSL processing rules forthe other FDA value encodings can be defined in the same way, for converting application typecodes, submission type codes, submission sub-type codes, and so on.

Another issue with the US regional XML files is that, according to the FDA regional M1 eCTDspecification, certain documents such as administrative forms can appear in the <admin> section,as well as in the <m1-regional> section. However, LSSSV requires all of the leaf documentsto be encapsulated within a single XML element, separate to the XML metadata section (the<admin> element, in this case) so that they can be extracted into the consolidated module m1-m5submission tree view. To address this, an additional rule can be added to the XSL transformationscript to copy the <form> elements to a dummy section, named <m1-1-admin-forms>, below the<m1-regional> node in the output XML file, as follows:<xsl:template match="//m1-regional"><xsl:element name="m1-regional"><xsl:element name="m1-1-admin-forms"><xsl:for-each select="//form"><xsl:element name="form"><xsl:attribute name="form-type"><xsl:value-of select="substring-before(substring-after($FORMTYPES, concat(@form-type,

'=')), ';')"/></xsl:attribute><xsl:copy-of select="node()"/></xsl:element></xsl:for-each></xsl:element><xsl:apply-templates/></xsl:element>

293


</xsl:template>

These forms is then extracted along with the other <m1-regional> leaf documents, appearing in the“m1-1-admin-forms” section in the submission tree view. (The form type codes are also convertedinto meaningful display values as part of this process, using the technique described previously.)

It is possible to test a new XSL transformation script before installing it by linking a sample XMLfile to it. To do this, copy the sample XML file and XSL script to a temporary folder in the localfile system, and open the sample XML file in Notepad or any other XML Editor. Insert an XMLprocessing instruction into the XML sample file, immediately after the XML header, to link itto the XSL stylesheet script file, as follows:<?xml version="1.0" encoding="utf-8"?><?xml-stylesheet type="text/xsl" href="us-regional-2-3-normalize.xslt"?><fda-regional:fda-regional xmlns:fda-regional="http://www.ich.org/fda" xmlns:xlink="http://www.w3c.org/1999/xlink" dtd-version="2.01" xml:lang="en">…</fda-regional:fda-regional>

In this example, the XSL script file to be tested is named “us-regional-2-3-normalize.xslt”,and must reside in the same folder as the XML file itself – a relative path to a script file ina sub-folder can be specified if preferred. (If the sample XML file already contains an XMLstylesheet processing instruction, change the file name or URL to refer to the local XSL scriptfile in the href parameter).

Save the changes, then use the Open with menu option in Windows Explorer to open theXML file in your preferred HTML browser such as Internet Explorer. The transformed outputappears as garbled text in the in the main browser window because it is not formatted as anHTML document. However, the transformed XML output can be navigated via the browser’sDevelopment Toolsview, in the HTML tab:

In the Developer Tools HTML window, it is possible to drill down into the transformed XMLoutput (which is itself an XML document, and not an HTML document in this case) to verify that

294


the XML structure has been passed through correctly and the encoded attribute values have beentranslated into the corresponding display values. If the XML output appears not to have beentransformed, check the Console tab for errors and make sure the stylesheet script file name inthe sample XML file is specified correctly in the XML header.

When the XSL stylesheet is working correctly, it can be installed as the primary content file ofthe new schema configuration object and the enable_xslt_preprocessing option turned on forthat schema. LSSSV then downloads and applies the transformation script automatically tothe relevant XML files at import time, prior to any further processing, such as XML metadataextraction or extraction of module 1 leaf documents into the submission tree view. Note that thisprocess does not alter the original regional XML file included in the m1 section of the eCTDsubmission: instead, the original XML file (the input file) is saved as the primary content of theregional XML document in the repository, and the transformed XML output file is saved as aseparate xml_preview rendition of this document. This rendition is only used internally by LSSSVto generate the XML preview when the regional XML file is selected in the Submission Viewerweb application. If the imported submission files are subsequently exported from Documentumback out to the local file system, only the original primary content files are exported. Therefore, inthis case, the original regional XML file that was submitted to the FDA is exported, containingthe original encoded values, and not the transformed version.

4. Identify the top-level XML elements containing:a. the regional XML metadata, and

b. the leaf document references.

In this case, the regional XML metadata is contained in the <admin> element and the leafdocument references reside in the <m1-regional> element (including the admin forms aftertransformation, as described previously). These are recorded in the xml_envelope_element andxml_extract_leaf_docs_from configuration settings in the new schema configuration object,accordingly.

5. Determine the XML metadata that can be usefully-extracted from the regional XML file intoDocumentum. Formulate XPath expressions to extract them in each case. These will be used toset up the xml_envelope_attrs repeating attribute of the schema configuration object. In this case,from the FDA eCTD regional M1 XML specification, it can be determined that the followingmetadata can be extracted:

Documentum Attribute XPath Expression (Relative to the <admin> Node)

submission_date applicant-info/date-of-submission/date

submission_date_format* applicant-info/date-of-submission/date/@format

application_num application-set/application/application-information/application-number

application_type application-set/application/application-information/application-number/@application-type

submission_number application-set/application/submission-information/sequence-number

295

Documentum Attribute XPath Expression (Relative to the <admin> Node)

submission_type application-set/application/submission-information/submission-id/@submission-type

* The submission_date_format attribute is not defined explicitly in the Documentum objectmodel, but it is recognized by LSSSV as a special case. This is used to define the format inwhich the submission date value is specified in the XML file. LSSSV uses this to convert thespecified date value in the XML into a standard date format so that the correct date value isstored in the submission_date attribute in Documentum.

As part of this process, it may be necessary to define attribute expressions or D2 dictionarymappings to be applied as the metadata is extracted (see Mapping XML Values to DocumentumAttributes, page 289 for details). In this case, the XSL pre-processing transformation script isresponsible for converting the metadata. Additional data conversion is not required.

6. Devise an XSL preview stylesheet for converting the XML file into HTML. Note that this is aseparate stylesheet to the XSL preprocessing transformation stylesheet. If used; the preprocessingtransformation stylesheet converts the input XML file (the regional XML file) into anotherXML file that can be processed by LSSSV, whereas the preview stylesheet converts the XMLfile (transformed if necessary) into HTML. This is used to generate the XML preview in theSubmission Viewer.

In some cases, an Agency-supplied stylesheet can be adapted for this purpose or else one of theexisting SSV preview stylesheets can be copied and adapted to suit the new XML format. Thesecan be found in the %WEBAPPS%/XMLViewer/style folder in the repository. When developingexisting stylesheets for previewing in SSV, the following points should be noted:

a. The stylesheet only needs to render the “envelope” section of the XML file, containing theregional XML metadata. The leaf document references will be extracted from the XML fileinto the main submission tree view to combine them with the main eCTD backbone filereferences for modules 2-5.

b. The HTML page should include a top-level <div class="envelope"> element in the HTMLbody, in order to provide scroll bars in the Submission Viewer document preview panel.See the following example.

c. Predefined icons for various country flags are provided as part of the LSSSV XMLViewer webapplication and can be added to the title bar if required. See the following example.

<?xml version="1.0" encoding="UTF-8"?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:fda-regional="http://www.ich.org/fda"><xsl:template match="/"><html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"/> </head><body><div class="envelope"><h3> <img src="icons/countryflags/us.gif" style="padding-left: 10px; padding-right:

10px;"/>US Food and Drugs Administration - Regulatory Information</h3><table border="0" cellspacing="20px">

<tr><th align="left">Applicant ID:</th><td colspan="2"><xsl:value-of select="/fda-regional:fda-regional/admin/applicant-info/id"/></td></tr>

<tr><th align="left">Company Name:</th><td colspan="2"><xsl:value-of select="/fda-regional:fda-regional/admin/applicant-info/company-name"/></td></tr>

<tr><th align="left">Submission Description:</th><td colspan="2"><xsl:value-of select="/fda-regional:fda-regional/admin/applicant-info/submission-description"/></td></tr>

296

</table><p/>

<table width="100%" border="1" bordercolor="#564742">

<th width="150px" bgcolor="#FEF4F0" style="color=#333333">Contact Information</th>

<td><xsl:for-each select="/fda-regional:fda-regional/admin/applicant-info/

applicant-contacts/applicant-contact"><table width="100%" border="0" cellpadding="2"><tr> <td style="border:0;"><strong><xsl:value-of select="applicant

-contact-name"/></strong> - <xsl:value-of select="applicant-contact-name/@applicant-contact-type"/></td> </tr>

<xsl:for-each select="telephones"><tr> <td style="border:0;">Tel.: <font color="red"><xsl:value

-of select="telephone"/></font> - <xsl:value-of select="telephone/@telephone-number-type"/></td> </tr>

</xsl:for-each><tr> <td style="border:0;">E-mail: <a href="mailto:{emails/email

[1]}?subject={concat(/fda-regional:fda-regional/admin/application-set/application[1]/application-information/application-number/@application-type, ' application ',/fda-regional:fda-regional/admin/application-set/application[1]/application-information/application-number,' - ', /fda-regional:fda-regional/admin/applicant-info/submission-description)}"><xsl:value-of select="emails/email[1]"/></a></td> </tr>

<xsl:if test="position()!=last()"> <tr> <td style="border:0;"><hr/> </td>

</tr> </xsl:if><xsl:if test="position()=last()"> <tr> <td style="border:0;">

<p/> </td></tr> </xsl:if></table>

</xsl:for-each></td>

</table></p>

<table width="100%" border="1" bordercolor="#564742">

<th width="150px" valign="middle" bgcolor="#FEF4F0" style="color=#333333">Application Information</th>

<td><table width="100%" border="0">

<xsl:for-each select="/fda-regional:fda-regional/admin/application-set/application"><tr><td><table width="100%" border="0" bordercolor="#564742" cellpadding="2"><xsl:choose>

<xsl:when test="@application-containing-files='true' or @application-containing-files='false'">

<tr> <td style="border:0;">Application Containing Files: <xsl:value-of select="@application-containing-files"/></td> </tr>

</xsl:when><xsl:otherwise>

<tr> <td style="border:0;">Application Containing Files: Thisvalue must be set to either true or false.</td> </tr> </xsl:otherwise>

</xsl:choose><tr> <td style="border:0;">Application Type: <xsl:value-of select="descendant::

application-number/@application-type"/></td></tr><tr><td style="border:0;">Application Number: <xsl:value-of select="descendant::

application-number"/></td></tr><tr><td style="border:0;">Submission Type: <xsl:value-of select="descendant::

submission-id/@submission-type"/></td></tr><xsl:if test="(string-length(/.//submission-id/@supplement-effective-date-type)

> 0) and (.//submission-id/@supplement-effective-date-type != ' ')"><tr><td style="border:0;">Supplement Effective Date: <xsl:value-of select=".//

submission-id/@supplement-effective-date-type"/></td></tr></xsl:if>

297


<tr><td style="border:0;">Submission Id: <xsl:value-of select="descendant::submission-id"/></td> </tr>

<tr><td style="border:0;">Submission Sub-Type: <xsl:value-of select=".//sequence-number/@submission-sub-type"/></td></tr>

<tr><td style="border:0;">Sequence #: <xsl:value-of select='substring(format-number(descendant::sequence-number, "0000"),1, 4)'/></td></tr>

<xsl:if test="(string-length(/descendant::cross-reference-application-number) > 0) and (descendant::cross-reference-application-number != ' ')">

<xsl:for-each select=".//cross-reference-application-number"><tr><td style="border:0;">Cross Reference Number:

<xsl:value-of select="."/></td></tr><tr><td style="border:0;"><xsl:value-of select="@application-type"/>

</td></tr></xsl:for-each>

</xsl:if><xsl:if test="position()!=last()"> <tr><td style=

"border:0;"> <hr/></td></tr> </xsl:if><xsl:if test="position()=last()"> <tr> <td style="border:0;"> <p/>

</td> </tr> </xsl:if></table>

</td></tr>

</xsl:for-each></table>

</td></table>

</div></body>

</html></xsl:template></xsl:stylesheet>

To test the preview stylesheet prior to installing it, link a sample XML file to it using the techniquedescribed previously for preprocessing transformation stylesheets. For example:<?xml version="1.0" encoding="utf-8"?><?xml-stylesheet type="text/xsl" href="us-regional-2-3.xsl"?><fda-regional:fda-regional xmlns:fda-regional="http://www.ich.org/fda" xmlns:xlink="http://www.w3c.org/1999/xlink" dtd-version="2.01" xml:lang="en">…</fda-regional:fda-regional>

In this case, the preview stylesheet is named us-regional-2-3.xsl and is expected to reside in thesame folder as the XML document itself. When the XML sample file is opened in the browser,the transformed HTML output should be displayed correctly:

298


Note that in this case, the encoded XML metadata values are displayed because the HTML outputis generated directly from the original XML file and not the pre-transformed XML file. But atleast it enables the preview format to be verified. When the preview stylesheet is used in LSSSV,it uses the pretransformed XML file and shows the decoded values.

7. Install the XSL preview script in the %WEBAPPS%/XMLViewer/style folder on the D2 webapplication server. If the stylesheet refers to external files such as images or auxiliary scripts,make sure these are also installed in the appropriate locations. There is no need to restart theapplication server.

Note: It is not necessary to install the new DTD file or stylesheet file provided by the Agency.These files are included automatically by the eCTD publishing tool as part of the submission,in the util/dtd and util/style folders below the eCTD sequence folder. LSSSV importsthese into the repository alongside the other submission files, so that the entire sequence foldercan be exported back out to the local file system from Documentum if necessary. The DTD and

299


stylesheets can then be used to validate and preview the eCTD XML files in the local file system,outside of Documentum. However, they are not processed or required by LSSSV itself.

8. To represent the new regional XML format, create a new XML schema configuration object oftype cd_ectd_xml_config in the /System/SSV/XMLSchemas folder in the repository. This isnot currently possible in D2 itself because a D2 creation profile is not defined for these objects.However, a new schema configuration can be created in Documentum Administrator as follows:

a. Log into Documentum Administrator as the Documentum installation owner, for example,dmadmin, with Superuser privileges in Documentum.

b. Navigate to the /System/SSV/XMLSchemas folder in the repository.

c. Select an existing XML schema configuration object that is most similar to the new schema,for example, the us_regional-2-01 schema, or select an arbitrary schema.

d. Create a copy of this schema.

e. Modify the new schema properties as described in the following table:

XML SchemaAttribute

Description Example Settings for US Regional2.3 XML Schema

Object Name Specify a unique object name forthis schema configuration objectbased on the standard namingconventions.

us-regional_2-3

Title Enter a descriptive summary ofthe XML files to which this schemaapplies.

eCTD US-FDA Regional XML Filev 2.3 (DTD v 3.3)

Origin URL Specify the web site of the Agencyfrom which the XML specificationwas obtained.


XML FormatCode

Specify an abbreviated format codefor this XML file, displayed in theSubmission Navigator bar whenan eCTD sequence that uses thisformat is viewed.

US-2.3

XPath Qualifier Enter the XPath expression usedto recognize these XML files,identified in step 2.

/fda-regional[@dtd-version=’3.3’]

SchemaCategory

Denotes the type of this XML file(should be preset to the examplevalue).

eCTD Regional XML File

Enable XSLTPre-processing

Enable (set to T) if an XSLpre-processing script is requiredfor these XML files, as identifiedin step 3. Disable (set to F) if XSLpre-processing is not required.

T

300


XML SchemaAttribute


PreviewStylesheet

Specify the XSL file name used toconvert the XML file (transformedif necessary) into HTML to renderthe XMLpreview in the SubmissionViewer.

us-regional_2-3.xsl

PreviewWidgetID

Denotes the widget used forpreviewing this XML file in theSubmission Viewer (should bepreset to SSVLeafDocumentViewer or left blank).

SSVLeafDocumentViewer

Contains LeafDocuments

Enabled (set to T) if the XML filecontains leaf document referencesto be extracted; disabled (set to F) ifit only contains regional metadata.

T

Extract LeafDocuments

Whether or not the leaf documentreferences should be extracted intomodule 1 of the main submissiontree view, combined with modules2-5 for the main eCTD backbonefile.

T

Extract LeafDocumentsFrom

Specify the path of the top-levelXML element containing leafdocument references to beextracted (from the transformedoutput identified in step 4).

/fda-regional/m1-regional

XML LeafDocumentElement

Specify the name of the XMLelement used for leaf documentreferences (identified in step 4;usually “leaf”).

leaf

ContainsEnvelope

Enabled (set to T) if the XMLfile contains contains regionalmetadata to be extracted.

T

XML EnvelopeElement

Specify the name of the top-levelXML element containing theregional metadata to be extracted(identified in step 4).

admin

301


XML SchemaAttribute


XML EnvelopeAttributes

Specify the Documentum attributenames and corresponding XPathexpressions to be used to extractthe regional metadata from theenvelope element(s), as identifiedin step 5.

submission_date=./applicant-info/date-of-submission/date

submission_date_format=./applicant-info/date-of-submission/date/@format

application_num=application-set/application/application-information/application-number

application_type=application-set/application/application-information/application-number/@application-type

submission_number=application-set/application/submission-information/sequence-number

submission_type=application-set/application/submission-information/submission-id/@submission-type

Required For each XML envelope attributeabove, specify T (enabled) ifthe attribute is mandatory, or F(disabled) if it is optional.

If an attribute is marked asmandatory and there is no definedvalue in the regional XML file for it,or the specified value is blank, anda value is not specified explicitlyin the SRF (or inherited from theRARF), a warning message willbe logged in the import log file atimport time.

T

After the XML schema configuration properties have been set up correctly, click OK to savethe changes in Documentum.

f. If an XSL preprocessing script is to be applied, check out the new XML schema configurationobject, and use the check-in from file option to upload the preprocessing script to it fromthe local file system as the primary content file. Select the XSL Stylesheet format for this file(Documentum format code xsl) and use the Check-in as same version option.

Note: It is possible to check-in the changes as a new version of the schema configurationobject. LSSSV always uses the latest (“CURRENT”) version in each case.

302


This completes the SSV configuration process and it is now possible to import eCTD sequences usingthe new format. It is not necessary to restart the Content Server, Java Method Server, or ApplicationServer. LSSSV should pick up the new XML schema configuration automatically on the next importcycle.

Non-eCTD Electronic SubmissionApplications that do not adopt the eCTD format use a non-eCTD electronic submission (NeeS) format.For these, each submission has a manually-specified, distinct submission number, and is assumed tobe a complete copy of the files sent to the authority in that submission. Incremental changes are notsupported by this model. After the first submission has been imported into Documentum SSV, it isnot possible to change the application from NeeS to eCTD format. If the Sponsor decides to adopt theeCTD format midway through an application, a new application must be made.

Submission FilestoreSubmissions are generated by some kind of publishing tool and stored in a network filestore that isaccessible to both the users and the Documentum Content Server. This enables submission foldersto be selected in the D2 browser, and the contents of those folders to be retrieved asynchronouslythrough the submission import process, which runs as a back-end server method on the ContentServer (Java Method Server).

The folder path from the Content Server to the submission filestore can be different to the folder pathfrom the desktop of the user to the same submission filestore. For example, if the Content Server isrunning on Unix, the submission filestore path could be /mnt/ext/eSubmissions, dependingon where it is mounted, whereas on the desktop of the user, it could be a UNC path to the relevantserver, for example, \\FSVRM1\eSubmissions. Windows-mapped drives can also be used for theclient path, but the same drive letter must be mapped on each user desktop for the path to be valid in

303


all cases, for example, S:/eSubmissions. However, Windows-mapped drives cannot be used forthe Content Server path, because Windows does not allow them to be used by processes running as aservice, such as Documentum. A UNC path from the server is required.

If the Content Server is behind a firewall, it may be necessary to replicate the filestore at thestorage level, or through a sync-and-share utility, such as Syncplicity, so that the same content isaccessible from both sides. WRITE access is required to select the submission filestore because ofa D2 limitation. Documentum SSV does not write to the submission filestore (write access is onlyrequired for submission publishing). If necessary, enable sharing on the submission filestore itself,so that the appropriate users (including the Documentum installation owner account used by theContent Server, such as dmadmin) have at least Read access to the appropriate folder. You may needto set up a local user account for dmadmin on the machine hosting the filestore, so that the ContentServer can connect to it as that user.

The Documentum for Life Sciences Solution Suite Installation Guide provides the steps for registeringsubmission filestores.

For eCTDs, the user must select either an individual sequence folder, or a parent folder containing aseries of sequence folders (that is, an application-level folder), in which case those sequences that havenot already been imported are imported into the repository in increments. For NeeS, the selectedfolder must be a submission-level folder to be imported in its entirety. Existing submission folders inthe repository are not updated. To replace existing submission folders in the repository, you mustdelete the existing submission folder from the repository and reimport it from the external filestore.

Updating the D2 URL in D2 DictionaryFollow these steps to update D2 URL in the System Parameter D2 dictionary, in case it has beenchanged.



3. On the Dictionary page, select All elements in the filter on the toolbar.


5. On the Alias tab, replace the value of the d2_url key from localhost to the correct URL addressof D2 on the application server.

6. Click Save.

7. Select Tools > Refresh cache.

Note: If the D2 application server URL is changed subsequently, it will break hyperlinks in existingpdf_preview renditions. To avoid this, consider using network-address translation (NAT) to providea virtual application server URL instead of referencing the IP address or hostname of the applicationserver directly. You can also use host-address translation (HAT), for example, through the /etc/hostsfile (on UNIX) or C:\Windows\System32\drivers\etc\hosts file (on Windows), to map virtual servernames to physical servers. This enables physical servers to be changed in the future if necessary,without affecting the URL.

304


Configuring the SSV Viewer Widget URLsThe Documentum SSV Viewer uses the following external widgets that connect into the D2 client:

• The Submission Navigator widget provides a navigation panel in the “View Submission”workspace view, enabling the user to select the required view for the application or submission,drill down into the submission folder structure and select documents for previewing.

• The Submission Document Preview widget displays the currently-selected document in aseparate panel in the “View Submission” workspace view, enabling the user to browse individualdocuments and switch between documents easily. This widget can also be used to displayregional metadata in XML files selected in the Submission Navigator.

• TheWG EXT SSV Compare Viewer 1 andWG EXT SSV Compare Viewer 2 widgets provide aside-by-side view of two selected documents in the “Compare” workspace view to enable themto be compared easily. These are separate instances of the same widget used by the SubmissionDocument Preview widget, but with their own configurations in D2, enabling each widget torespond to different document selection events and display the relevant content in its own panel.

These widgets may need to be configured to use the widget parameters in the URL. Follow these steps:


2. In the filter on the main toolbar, select EMC Life Sciences Submission Storage and Viewing.

3. SelectWidget view >Widget.

4. UnderWidgets, selectWG EXT Submission History View.

5. In theWidget url field, ensure the Widget URL setting is configured appropriately for yourenvironment. The following parameters can be specified in the URL:

Submission Navigator Widget URL Parameters (“WG EXT Submission History View”);Default URL Path: /XMLViewer/XMLViewer.html

URL Parameter Description Default ConfigurationSetting

type List of object type(s) to berendered by this widget.

cd_reg_admin_info,

cd_reg_submission_info

cd_submission_element

style XSL stylesheet to use to renderthe XML file for the relevantapplication into HTML inthe widget panel. (Thespecified stylesheet must beinstalled in the %WEB-APPS%/XMLViewer/style folderon the Application Server.)

submission-navigator.xsl

docViewerWidget Widget ID of the SubmissionDocument Preview widget.

SSVLeafDocViewer

305




docViewerEvent D2 event code to send tothe Submission DocumentPreview widget when adocument is selected in thenavigation panel.

D2_CUSTOM_EVENT

initView Initial display mode to usefor application-level views, asfollows:

• toc–Table of Contents view

• current–eCTD “current”view or first NeeSsubmission (asappropriate)

• cumulative–eCTD“cumulative” view orfirst NeeS submission (asappropriate)

• first–first eCTD sequenceor NeeS submission, asappropriate

This setting only applies ifa Regulatory ApplicationRegistration Form is selected.If a Submission RegistrationForm or Submission Element,that is, an importedsubmission document, isselected, the appropriatesubmission or sequence viewis opened automatically.

toc

initMessage Message to display whenthe widget is initially loadedand nothing is selected.Underscore characters can beused here to represent spaces,to make it easier to specify themessage in the URL.

Select_a_Regulatory_Application_Registration_Form, Submission_Registration_Form_or_archived_submission_document

306




refreshLoginTicketInterval Periodic interval, in seconds,to refresh the D2 loginticket, to prevent ticketsfrom expiring. The specifiedvalue should be less than theDocumentum login tickettimeout value, as configuredin the dm_server_config objectfor the repository (default =5 minutes). It should allow amargin of at least 10 secondsfor D2 to respond to newticket requests.

240

workspaceView D2 view labels in theworkspace in which thiswidget is installed. Acomma-delimited list ofview labels can be specifiedif necessary; use “%20” todenote a space characterin the URL. To avoidunnecessary processing, thecurrently-selected RegulatoryApplication RegistrationForm or SubmissionRegistration Form XMLfile is not downloaded andrendered until the relevantview is selected.

Submission%20View

active Indicates whether or notthe widget is active in thedefault workspace view. Insingle-view workspaces, thevalue should be set to true;for multi-view workspaces,specify active=true if thewidget is in the initial (default)view, and active=falseotherwise.

false

docbase Repository name. The D2token $DOCBASE can be usedhere.

$DOCBASE

307




username Username to use for thecurrent session. The D2 token$LOGIN can be used here.

$LOGIN

password Password to use for thecurrent session. The D2 token$TICKET can be used here.

$TICKET

A following URL is an example widget URL for the Submission Navigator widget:/XMLViewer/XMLViewer.html?workspaceView=View%20Submission&active=false&format=xml&type=cd_reg_admin_info,cd_reg_submission_info,cd_submission_element&style=submission-navigator&docViewerWidget=SSVLeafDocViewer&docViewerEvent=D2_EVENT_CUSTOM&initMessage=Select_a_Regulatory_Application_Registration_Form,_Submission_Registration_Form_or_archived_submission_document&docbase=$DOCBASE&locale=en&username=$LOGIN&password=$TICKET

6. Click Save.

7. UnderWidgets, selectWG EXT SSV Leaf Element View and configure the widget URL usingthe following URL parameters:

Submission Document Preview Widget URL Parameters (“WG EXT SSV Leaf ElementView”); Default URL Path: /XMLViewer/DocViewer.html

URL Parameter Description Default Setting

widget_id The ID of this widget,as specified in thedocViewerWidget widgetin the Submission NavigatorURL.

SSVLeafDocViewer

workspaceView D2 view labels in theworkspace in which thiswidget is installed. Acomma-delimited list ofview labels can be specifiedif necessary; use “%20” todenote a space characterin the URL. To avoidunnecessary processing, thecurrently-selected RegulatoryApplication RegistrationForm or SubmissionRegistration Form XMLfile is not downloaded andrendered until the relevantview is selected.

Submission%20View

308




active Indicates whether or notthe widget is active in thedefault workspace view. Insingle-view workspaces, thevalue should be set to true;for multi-view workspaces,specify active=true if thewidget is in the initial (default)view, and active=falseotherwise.

false

autoSelect Indicates whether or notthe widget should track andpreview the currently-selecteddocument in the D2 Doc Listwidget. If false, the widgetresponds to custom menuevents or events fired by someother widget (for example, theSubmission Viewer widget)targeted at this widget ID.

false

type Comma-delimited list ofexpected object types. Wherespecified, only selecteddocuments of the specifiedtype are rendered. Optional;if unspecified, all object typesare rendered, if they havesuitable content.

null

useC2Overlays Set as true to display PDFrenditions with watermarksor signature pages, accordingto the C2 view configuration;false to display PDFs withoutC2 watermarks or signaturepages.

false

imageFormats Comma-delimited listof in-line image formatssupported by the browser.

jpeg,gif,png

docCompareLeftWidgetId Widget ID of the leftdocument preview panelused in the “Compare” view.Optional. If undefined or leftblank, the comparison view isdisabled.

lsDocViewer1

309




docCompareRightWidgetId Widget ID of the rightdocument preview panelused in the “Compare” view.Optional. If undefined or leftblank, the comparison view isdisabled.

lsDocViewer2

docCompareEvent D2 event code to send to thecomparison widgets to initiatea side-by-side comparisonoperation.

D2_EVENT_CUSTOM

initMessage Message to display whenthe widget is initially loadedand nothing is selected forpreviewing. Underscorecharacters can be used torepresent spaces here, tomake it easier to specify themessage in the URL.

Select_a_document_in_the_submission_viewer.

docbase Repository name. The D2token $DOCBASE can be usedhere.

$DOCBASE

username User name to use for thecurrent session. The D2 token$LOGIN can be used here.

$LOGIN

password Password to use for thecurrent session. The D2 token$TICKET can be used here.

$TICKET

8. Click Save.The use of the standard D2 PDF Preview widget is not recommended in multi-view workspacesbecause it responds to all document selection events in the Doc List widget irrespective of whetheror not the widget is visible. This can lead to performance issues when navigating the repository.Instead, it is recommended that the custom Life Sciences document preview widget is used forpreviewing. In the standard workspaces, the Life Sciences document preview widget is used bydefault in several places, with different URL parameters passed to it in each case, so that the widgetonly downloads and renders content when it is in the currently-active view.

The following table summarizes the default widget configurations used for document previews:

310


D2 WidgetConfiguration

Applies To Default URL

WG EXT LSCI LSS DocViewer (Browse)

Browse and MySites views inworkspaces witha Welcome page

/XMLViewer/DocViewer.html?widget_id=lsDocViewerBrowse&active=true&config=WG_EXT_LSCI_LSS_Doc_Viewer_(Browse)&workspaceView=Browse,My_Sites&autoSelect=true&useC2Overlays=true&excludeTypes=dm_cabinet,dm_folder,cd_submission_folder,cd_submission_subfolder,cd_clinical_trial_info&excludeFormats=excel8book,excel12book&initMessage=Select_a_document&docbase=$DOCBASE&locale=en&username=$LOGIN&password=$TICKET&d2WebContext=D2

WG EXT LSCI LSS DocViewer (Initial Browse)

Browse view inworkspaces withouta Welcome page

/XMLViewer/DocViewer.html?widget_id=lsDocViewerInitialBrowse&config=WG_EXT_LSCI_LSS_Doc_Viewer_(Initial_Browse)&active=true&autoSelect=true&useC2Overlays=true&excludeTypes=excludeTypes=dm_cabinet,dm_folder,cd_submission_folder,cd_submission_subfolder,cd_clinical_trial_info&excludeFormats=excel8book,excel12book&initMessage=Select_a_document&docbase=$DOCBASE&locale=en&username=$LOGIN&password=$TICKET&d2WebContext=D2

WG EXT LSCI LSS DocViewer (Tasks)

Tasks view /XMLViewer/DocViewer.html?widget_id=lsDocViewerTasks&active=true&config=WG_EXT_LSCI_LSS_Doc_Viewer_(Tasks)&workspaceView=Tasks&autoSelect=true&excludeTypes=dm_cabinet,dm_folder,cd_submission_folder,cd_submission_subfolder,cd_clinical_trial_info&excludeFormats=excel8book,excel12book&useC2Overlays=true&initMessage=Select_a_document&docbase=$DOCBASE&locale=en&username=$LOGIN&password=$TICKET&d2WebContext=D2

311


D2 WidgetConfiguration

Applies To Default URL

WG EXT LSCI SSV DocCompare Viewer 1

Compare view onthe left pane

/XMLViewer/DocViewer.html?widget_id=lsDocViewer1&config=WG_EXT_LSCI_SSV_Doc_Compare_Viewer_1&workspaceView=Compare&initMessage=Select_a_document_for_comparison_in_Viewer_1&docbase=$DOCBASE&locale=en&username=$LOGIN&password=$TICKET&refreshTicketInterval=240&d2WebContext=D2

WG EXT LSCI SSV DocCompare Viewer 2

Compare view onthe right pane

/XMLViewer/DocViewer.html?widget_id=lsDocViewer2&config=WG_EXT_LSCI_SSV_Doc_Compare_Viewer_2&workspaceView=Compare&initMessage=Select_a_document_for_comparison_in_Viewer_2&docbase=$DOCBASE&locale=en&username=$LOGIN&password=$TICKET&refreshTicketInterval=240&d2WebContext=D2

WG EXT LSCI SSV LeafElement Viewer

Right documentpreview panel in theView Submissionview

/XMLViewer/DocViewer.html?widget_id=lsSSVLeafDocViewer&config=WG_EXT_LSCI_SSV_Leaf_Element_Viewer&workspaceView=View_Submission&useC2Overlays=false&docCompareLeftWidgetId=lsDocViewer1&docCompareRightWidgetId=lsDocViewer2&initMessage=Select_a_document_in_the_Submission_Viewer&docbase=$DOCBASE&locale=en&username=$LOGIN&password=$TICKET&refreshTicketInterval=240&d2WebContext=D2

If you decide to remove the Welcome pages, change the standard view labels or allow users to addthe Life Sciences Document Preview widget to other workspace views, it may be necessary to adjustthe widget URL parameters so that the widget is enabled correctly for the new view labels. Do notactivate the same widget in more than one view within a multi-view workspace, as this will causeperformance issues. If necessary, create a new D2 widget configuration in D2-Config for the newview, with the appropriate URL parameters, alongside the standard widget configurations describedabove. This must then be enabled in the D2 configuration matrix for the appropriate roles and addedto the default workspace view configuration XML files as necessary. In addition, make sure that thewidget description is set appropriately in D2-Config in each case. When users want to add previewwidgets to the standard workspaces, they can identify the correct widget in the gallery.

312


Updating the XML Viewer D2 External WidgetsThe XML Viewer configuration is necessary to provide the ability to view imported submissions byDocumentum SSV-related roles in workspaces. The automatic installation updates the URLs. You canchange the URLs as required.

1. In D2-Config, select All elements from the configuration filter.

2. SelectWidget view > Widget from the menu bar.

3. Select theWG EXT LSCI SSV Leaf Element Viewer widget and in theWidget url, type thefollowing:/XMLViewer/DocViewer.html?widget_id=lsSSVLeafDocViewer&config=WG_EXT_LSCI_SSV_Leaf_Element_Viewer&workspaceView=View_Submission&useC2Overlays=false&docCompareLeftWidgetId=lsDocViewer1&docCompareRightWidgetId=lsDocViewer2&initMessage=Select_a_document_in_the_Submission_Viewer&docbase=$DOCBASE&locale=en&username=$LOGIN&password=$TICKET&refreshTicketInterval=240&d2WebContext=D2

4. Select theWG EXT LSCI Submission History View widget and in theWidget url, type thefollowing:/XMLViewer/XMLViewer.html?widget_id=lsSSVSubmissionViewer&config=WG_EXT_LSCI_Submission_History_View&workspaceView=View_Submission&format=xml&type=cd_reg_admin_info,cd_reg_submission_info,cd_submission_element&style=submission-navigator&docViewerWidget=lsSSVLeafDocViewer&docViewerEvent=D2_EVENT_CUSTOM&stfViewerWidget=lsSSVStudyTaggingFileViewer&initMessage=Select_a_Regulatory_Application_Registration_Form,_Submission_Registration_Form_or_archived_submission_document&docbase=$DOCBASE&locale=en&username=$LOGIN&password=$TICKET&d2WebContext=D2

5. Select theWG EXT LSCI SSV Doc Compare Viewer 1 widget and in theWidget url, type thefollowing:/XMLViewer/DocViewer.html?widget_id=lsDocViewer1&config=WG_EXT_LSCI_SSV_Doc_Compare_Viewer_1&workspaceView=Compare&initMessage=Select_a_document_for_comparison_in_Viewer_1&docbase=$DOCBASE&locale=en&username=$LOGIN&password=$TICKET&refreshTicketInterval=240&d2WebContext=D2

6. Select theWG EXT LSCI SSV Doc Compare Viewer 2 widget and in theWidget url, type thefollowing:/XMLViewer/DocViewer.html?widget_id=lsDocViewer2&config=WG_EXT_LSCI_SSV_Doc_Compare_Viewer_2&workspaceView=Compare&initMessage=Select_a_document_for_comparison_in_Viewer_2&docbase=$DOCBASE&locale=en&username=$LOGIN&password=$TICKET&refreshTicketInterval=240&d2WebContext=D2

7. Select theWG EXT LSCI Study Tagging File Navigator widget and in theWidget url, typethe following:/XMLViewer/DocViewer.html?widget_id=lsSSVStudyTaggingFileViewer&config=WG_EXT_LSCI_Study_Tagging_File_Navigator&workspaceView

313


=View_Submission&useC2Overlays=false&docViewerWidget=lsSSVLeafDocViewer&initMessage=Select_a_study_tagging_file_in_the_Submission_Viewer&docbase=$DOCBASE&locale=en&username=$LOGIN&password=$TICKET&refreshTicketInterval=240&d2WebContext=D2


Note: If you use Documentum D2 in HTTPS mode, then you must also specify the DocumentumSSV URLs in HTTPS mode. This is also applicable in cases where the HTTP login gets automaticallyredirected to the HTTPS mode for D2.

Processing of PDFs and Inter-DocumentHyperlinksDocumentum SSV generates a PDF preview rendition (represented by the pdf_preview object inthe Documentum SSV object model) for each document in an eCTD or NeeS submission that has theeCTD PDF Document or NeeS PDF Document element type, respectively, in the file info map. Thegenerated renditions include hyperlinks to other submission documents. The document is openedfor reading through the itext PDF library, which is included with D2 and is used by the C2 plug-into process PDF files.

If the document contains a PDF Document Information (DocInfo) field, which represents the sourcedocument object ID with a non-null value referring to a valid dm_document object in the currentrepository, a relation of type Source Document is created in the repository between the parentdocument and the imported child document in the repository. A Used in Submission relation is alsocreated between the source parent document and the child submission folder.

The source_object_pdf_docinfo_field parameter specifies an optional PDF DocInfo field used by thesubmission publishing tool to record the Documentum r_object_ids of the original source documentsin the published PDF documents. When publishing documents from Documentum, it is useful toembed the source object IDs in the corresponding published PDFs in a designated DocInfo field.

Any of the standard DocInfo fields can be used for this purpose such as Subject. Alternatively, acustom DocInfo field can be used, such as SourceObjectId, which will not be shown on the documentproperties page of Adobe Acrobat. Configuring the Document Information parameter enables thesystem to track the original source documents and relate them to the corresponding publishedsubmission documents when they are imported into the repository through the Import Submissionfunction. The Documentum for Life Sciences Solution Suite Installation Guide provides the steps forconfiguring the PDF DocInfo parameter in the D2 dictionary.

If the document contains inter-document hyperlinks (that is, relative filepath links, also known as“/GoToR” links in PDF terminology), they are converted into D2 hyperlinks (“/URI” links) to therelevant object in the repository. The resulting document, if modified, is saved as a new PDF file andis checked-in as a pdf_preview rendition of the relevant document in the repository. The originalPDF content file/rendition is preserved. The format attribute of the corresponding XML DOM objectis updated to the pdf_preview object accordingly. If the file does not contain any inter-documenthyperlinks, the system does not generate a pdf_preview rendition; the primary content file (pdfformat) is previewed. Note that this processing does not apply to other types of PDF links, such asintra-document links (“/GoTo” links) or web links (“/URI” links). Such links are preserved as isin the PDF rendition.

314


A limitation is that hyperlinks to specific pages or named destinations within the target documentare not supported in the preview renditions. Instead, these links navigate to the first page of thetarget document. This is a D2 product limitation.

When a submission is imported, the inter-document PDF hyperlinks are resolved during import basedon the ’d2_url’ parameter value specified in System Parameters dictionary. However, if you changeApplication Server URL after importing the submission, it impacts the PDF hyperlink navigation onthe imported submission documents because they still reflect the old Application Server URLs.

Another option is to use an LBR (load balancing router) or proxy server as it enables the targetapp server hosts to be reconfigured easily. You then configure the base URL for D2 to point to theLBR or proxy server, and it forwards the HTTP requests to the relevant app server. It should beconfigured to use “sticky sessions” so that the same app server is used for a particular client session,rather than spreading it across multiple servers. For example, you can set up an Apache Tomcatproxy server. For setting up the proxy server, refer to the “Proxy Support HOW-TO” article onthe Apache Tomcat website.

Study Tagging FilesStudy Tagging Files (STFs) are XML files that may be included in the m4 (Non-Clinical) and m5(Clinical) sections, primarily for submissions to the US FDA. These are optional for Europeansubmissions, and are not allowed for Japanese submissions. Each STF relates to a specific study, andmay refer to several study documents (for example, Clinical Study Reports) in a particular section ofthe eCTD. By convention, the STF XML file is named “stf-<study-id>.xml”, where <study-id> is aunique study identifier, and is located in the appropriate folder in the eCTD, alongside the documentsit references. There may be several STFs in one folder, one for each study.

The purpose of an STF is to:

• Provide additional metadata about each study, for example, the study ID, title, duration, speciesand type of control used in each case

• Enable the individual study documents to be grouped by study

• Provide additional information about the contents of each study document, known as its filetags. Usually, there is one file tag per study document indicating the purpose of that document,if defined; for example, “synopsis” or “study-report-body”. However, it is possible for a studydocument to have multiple file tags in an STF.

If an STF is not provided for a particular study, the SSV Viewer displays the study documents in therelevant eCTD section as a flat list, exactly as they appear in the eCTD XML backbone file.

Each section in modules M4 and M5 can contain multiple study report documents pertaining tomultiple studies. However, where there are many study documents, it may be difficult for users tonavigate the submission structure and find documents related to a particular study. STFs facilitatethis process by providing additional metadata for each study, over and above that which is providedin the standard ICH XML backbone file. An example code is as follows:<?xml version=”1.0” encoding=”UTF-8”?><!DOCTYPE ectd:study SYSTEM "../../util/dtd/ich-stf-v2-2.dtd"><?xml-stylesheet type="text/xsl" href="../../util/style/ich-stf-stylesheet-2-2a.xsl"?><ectd:study xmlns:ectd="http://www.ich.org/ectd" xml:lang="en" dtd-version="2.2"xmlns:xlink="http://www.w3.org/1999/xlink"><study-identifier>

315


<title>Wonderdrug Phase III Clinical Study Report: SN-3.001</title><study-id>3.001</study-id><category name="species" info-type="ich">human</category><category name="route-of-admin" info-type="ich">oral</category><category name="type-of-control" info-type="ich">dose-response-without-placebo</category></study-identifier><study-document><doc-content xlink:href="../../../../index.xml#id106245"><title>SN-3.001.01 – Overview of study objectives</title><file-tag name="synopsis" info-type="ich"/></doc-content><doc-content xlink:href="../../../../index.xml#id106246"><title>SN-3.001.02 – Long-term dose response results in human trials for Wonderdrug 50mg

capsules</title><file-tag name="study-report-body" info-type="ich"/></doc-content><doc-content xlink:href="../../../../index.xml#id106247"><title>SN-3.001.03 – Amendments to Clinical Study Protocol</title><file-tag name="protocol-or-amendment" info-type="ich"/></doc-content></study-document></ectd:study>

The STF XML file resides in the same folder as the study report documents; in this case, the5312-compar-ba-be-stud-rep folder (used for comparative bioavailabilty/bioequivalence studies).Documentum SSV uses a built-in XSL script, stf-2-2-normalize.xslt, to convert the STF XML files intoa standard format that is easy to process (just as for other non-standard XML files, such as Japaneseregional M1 XML files). This script is installed as the primary content file of the XML schemaconfiguration object named stf_2-2, which applies to v 2.2 Study Tagging Files; XSL transformation isenabled for this schema, so that all STF XML files are transformed automatically by this script.

This information can then be manifested in the main Submission Viewer panel, with links to the threestudy reports arranged underneath the study tagging file node itself. If the version 2.2 study taggingfile format is revised in the future, a new XSL transformation script may need to be developed totransform it into the same format as above, so that it can be processed by SSV. To accomplish this:

1. Copy the /XMLViewer/style/stf-2-2-nornalize.xslt script provided, rename it accordingly, andedit it to convert the new format into the same “normalized” XML format described above.

2. In Documentum Administrator, copy the stf_2-2 XML schema configuration object and rename itaccordingly. Adjust the xpath_qualifier setting to refer to the new version of the STF.

3. Use the check-out/check-in from file functionality in Documentum Administrator to replace themain content file of the new XML schema configuration object with the new XSL transformationscript developed in step 1.

4. Import a sample eCTD submission using the new STF format and verify that it can be navigatedcorrectly.

Previewing of Media FilesMedia files, such as video, can be included in submissions and previewed in Documentum SSV.See Media Files, page 235 for more information.

316


Adding Custom Format Icons

If new content formats are to be supported, it may be necessary to provide icons for them in the%WEBAPPS%/XMLViewer/icons/format folder, so that the correct icons are displayed in theSubmission Viewer. Icons for the standard formats are pre-installed. Additional icon files mustbe provided as GIF (Graphics Interchange Format) files of size 16x16 pixels, and the file namemust be the same as the corresponding dm_format name in each case (for example, mpeg.gif). Inmany cases, GIF files for new formats can be obtained from the Documentum Administrator webapplication folder, %WEBAPPS%/da/wdk/theme/documentum/icons/format. Copy the relevantf_<format>_16.gif file to the %WEBAPPS%/XMLViewer/icons/format folder, and renamethe file as <format>.gif. Do not use the larger 32-bit icon files as this can disrupt the tree viewin Documentum SSV.

317


318

Chapter 18Migration and Integrity Check Utilities

This section describes how to install and use migration and integrity check tools included in theLife Science solutions.

D2 Configuration Migration ToolThe D2 Configuration (ApplyD2Configurations) Migration tool is a command-line tool that can beused by System Administrators to apply D2 auto-linking, auto-naming and/or security configurationsselectively to specific objects in the repository. You may need to run this tool in the following cases:

• After migrating a set of new or legacy documents into the repository into a staging area folder, D2auto-linking may need to be applied to them.

• After making changes to the D2 auto-linking, auto-naming, or security configurations that are tobe applied to the existing documents.

• After a bulk DQL update operation that changes the users and groups assigned to various roles, inorder to update the security on those documents.

The tool supports multi-threaded parallel processing, and also distributed processing across multipleContent Servers. The tool can be scaled-out both horizontally, by providing more servers, andvertically, by increasing the number of parallel processing threads on each server.

You may face significant challenges when migrating legacy repositories to D2-enabled applicationssuch as the Life Sciences solutions. Although the Migration Appliance (EMA) tool can beused to convert legacy object types and metadata between object models and migrate contentefficiently between repositories, it does not apply D2 context-based auto-naming, auto-linking,security, and initial lifecycle state transition actions to migrated objects. To accomplish this, theApplyD2Configurations command-line utility (provided as part of the Life Sciences ControlledDocument Foundation (CDF) package) can be used to apply the relevant D2 configurations selectivelyto repository objects, after having processed them in EMA.

The EMA tool can migrate objects at a rate of approximately 300,000 objects per hour. However, eventhough the ApplyD2Configurations tool supports multi-threaded and distributed processing, it isdifficult to achieve processing rates of more than 50,000 objects per hour per server, and in manycases, depending on the number and complexity of the D2 configurations that need to be applied,the processing rate can be less than 25,000 objects per hour. This is therefore a significant bottleneckin the migration process. To process 1 million documents at 25,000 documents per hour, it wouldtake 400 hours, or around 17 days of processing.

319

Migration and Integrity Check Utilities

The root cause is because of the way in which the underlying D2 core method is implemented. Thisis the server method (part of the D2 core product) that is responsible for applying the relevant D2configurations to an individual repository object. It processes objects one by one in serial fashion,and in each case it evaluates the D2 context rules, as defined in the D2 configuration matrix for theapplication (which are essentially DQL qualifiers), to determine which auto-naming, auto-linking,and security configurations apply to the object. This does not scale up well when applied to a largeset of repository objects. It does not support multi-threaded processing, and causes redundantprocessing for objects with similar properties. The processing rate when using the default D2 coremethod in this way is very poor – typically around 3000 objects per hour.

The ApplyD2Configurations utility provides a wrapper around the D2 core method that supportsmulti-threaded processing, which can boost the processing rate by a factor of 10 or more. With amulti-node Content Server architecture (comprising two or more active Content Servers), it is possibleto scale the process out horizontally, using the distributed processing options. However, to match theprocessing rate of EMA, some 10 Content Servers or more may be required.

Another limitation of the ApplyD2Configurations utility is in a Content Server failover setup wherethe method does not have the capability to check if the Content Server instance is available to processthe batch. It assumes all the Content Server instances are up and running and available to processthe batch. Therefore, you must enable the distributed parallel processing only when all the ContentServer instances are available but not in the failover setup.

The Documentum Controlled Document Foundation Developer API Javadocs provides more informationabout the ApplyD2Configurations tool.

Installing the D2 Configuration Migration Tool

The D2 Configuration Migration tool is shipped as part of the Life Sciences solution suite. Batchscripts for both UNIX and Windows installations are provided within the utils/migration folderof the Life Science solution installation package. These files can only be executed on a DocumentumContent Server host that has the Life Sciences solution server components installed on it. To installthe scripts, copy the relevant files to an arbitrary folder on the Content Server. On UNIX, ensure thatthe shell scripts are set to be executable through the chmod o+x command.

To install the tool on a system that has D2 but does not have any of the Life Sciences Solutionmodules installed:

1. Copy the CDF-Methods.jar file (the Controlled Document Foundation server method library)and the CDFBase.jar file to the Java Method Server lib folder on each Content Server, alongwith the D2 jars, found in the location, %Documentum%\jboss7.1.1\server\DctmServer_MethodServer\deployments\ServerApps.ear\lib

2. Restart the Java Method Server on each node after installing the JAR file, so that it loads thenew JAR.

3. To support distributed processing in multi-node Content Server architectures, see Creating adm_method Object, page 254.

320


Configuring the D2 Configuration Migration Tool

To view the usage notes for the tool:

• On Windows, double-click the ApplyD2Configurations.bat script in Windows Explorer.

• On UNIX, run the ApplyD2Configurations.sh script without any parameters, or with thehelp parameter.

You can configure the default settings for the tool parameters in the D2 System Parameters dictionary,which contains the default settings for distributed / parallel processing methods, in D2-Config, ratherthan specifying them explicitly on the command line.

The following is an example of a Windows command that applies D2 configurations(auto-naming, auto-linking, and security) to all controlled documents below the/Clinical/Cardiology-Vascular/Vasonin folder, including subfolders of this folder:C:\Users\dmadmin> ApplyD2Configurations -docbase_name documentum -user_name dmadmin -password ""-qualifier "cd_controlled_doc where folder('/Clinical/Cardiology-Vascular/Vasonin', descend)"-verbose true

In this example, C:\Users\dmadmin> is the Windows command prompt, indicating the folder wherethe scripts are installed. The parameters are the same for UNIX:$ sh ApplyD2Configurations -docbase_name documentum -user_name dmadmin -password ""-qualifier "cd_controlled_doc where folder('/Clinical/Cardiology-Vascular/Vasonin', descend)"-verbose true

D2 auto-naming, auto-linking and security are applied by default. To apply them selectively, specifythe appropriate flags on the command line explicitly; for example,C:\Users\dmadmin> ApplyD2Configurations -docbase_name documentum -user_name dmadmin -password ""-qualifier "cd_controlled_doc where folder('/Clinical/Cardiology-Vascular/Vasonin', descend)"-verbose true –auto_naming false –auto_linking false –security true

To process new documents, include the –new true argument, so that D2 applies auto-naming andauto-numbering correctly. Otherwise, it retains the existing auto-numbering values. You can alsospecify a D2 lifecycle state transition to apply to each document, through the –state_transitionargument. For example, –state_transition "(init)" applies the initial lifecycle state actionsto each document, as specified in the D2 lifecycle configuration for the “(init)” state.

The –delete_empty_folders option is also useful for cleaning up any empty folders below thespecified top-level folder. For example,C:\Users\dmadmin> ApplyD2Configurations -docbase_name documentum -user_name dmadmin -password ""-qualifier "cd_controlled_doc where folder('/Clinical/Cardiology-Vascular/Vasonin', descend)"-verbose true –auto_naming true –auto_linking true –security true –delete_empty_folders"/Clinical/Cardiology-Vascular/Vasonin"

When using the –auto_linking option, empty folders are sometimes generated as a result ofconflicts between parallel processing threads. These are prefixed by dm_fix_me labels in the foldernames. Such folders can be cleaned out by enabling the –delete_empty_folders option.

Note that the use of the –auto_linking and –state_transition options, in particular, canincrease the processing time required by the tool substantially. If the documents can be migratedinto the relevant folders directly and initialized with the appropriate metadata in advance, it isbetter to do so, in order to avoid lengthy processing. If this cannot be avoided, and there are manydocuments to be processed, consider increasing the number of processing threads available throughthe –max_threads parameter. If multiple Content Servers are available, you can enable distributedprocessing as follows:

321


C:\Users\dmadmin> ApplyD2Configurations -docbase_name documentum -user_name dmadmin -password ""-qualifier "cd_controlled_doc where folder('/Clinical', descend)"-verbose true –content_servers "^*" –max_threads 8 –distributed_processing_threshold 1000

In this example, assuming there are more than 1000 documents to be processed (the -distributed_processing_threshold value), the tool splits the processing tasks across all available servers.Note the use of the caret symbol before the “*” symbol, which prevents the Windows command-lineshell from expanding this symbol into a list of files in the current directory. On UNIX, use–content_servers “\*” to achieve the same results.

To improve the processing rate, specify the -use_private_sessions parameter in the D2 SystemParameters dictionary. If the value of this parameter is null or undefined, ’false’ is taken as thedefault value.

TMF Admin Integrity Checking and Repair ToolThe TMF Integrity Checking and Repair tool (also known as the TMF Admin tool) is a command-linesystem administration utility. This tool enables System Administrators to validate the external rolegroup security settings for TMF documents and folders and optionally repair them.

This tool can:

• Examine the TMF documents and subfolders in a specified top-level folder, and highlight thosethat have incorrect role groups assigned to them. Optionally, it can automatically fix thosedocuments and folders and reapply D2 security to them, create any missing groups as required,and delete groups that are no longer used.

• Force a refresh of the external group members for specific trials, countries, and sites. This ensuresthat appropriate levels of access are granted to the external users on the relevant TMF artifacts. Italso ensures that read-only access is granted to the TMF folders and registration forms to enablenavigation and searching on specific products, trials, countries and sites.

• Dump selected group hierarchies to enable group members to be examined more closely, andoptionally purge or delete them completely.

You may need to run this tool in the following scenarios:

• After migrating a set of new TMF documents into the repository for a currently-active trial.

• After upgrading from a previous version of the Life Sciences eTMF solution to migrate the correctTMF role-based security settings to the existing documents.

• After updating the external user registrations in a registration form outside of the D2-Client, forexample, through the TMF SDK or bulk DQL update.

• After changing the TMF role group naming conventions in D2-Config.

• After changing product codes, combining products, moving a trial to a different product, ormoving a site to a new trial, requiring the role groups to be reconstructed.

322


Installing the TMF Admin Tool

The TMF Admin tool is provided in the form of batch scripts in the utils/tmf subfolder withinthe Life Sciences solution package. Batch scripts for both UNIX and Windows installations areprovided. These scripts must be installed on a Documentum Content Server host that has the LifeSciences solution server components installed on it. Copy the relevant files to an arbitrary folder onthe Content Server. On UNIX, ensure that the shell scripts are set to be executable through thechmod o+x command.

To view the usage notes:

• On Windows, double-click the TMFAdmin.bat script in Windows Explorer to view the usagenotes.

• On UNIX, run the TMFAdmin.sh script without any parameters, or with the help parameter.

Examining Access Control Groups

The –show command can be used to dump the contents of a group, including the group membersand its sub-groups. For example, the following Windows command dumps the entire dynamicrole group hierarchy:C:\Users\dmadmin> TMFAdmin -docbase_name documentum -user_name dmadmin -password "" –showtmf_contributors | more

In the above example, C:\Users\dmadmin> is the Windows command prompt, indicating thefolder where the scripts are installed. The parameters are the same for UNIX:$ sh TMFAdmin.sh -docbase_name documentum -user_name dmadmin -password "" -show tmf_contributors| more

In both cases, the output is piped to the more command to enable it to be scrolled through.

The tool can generate a lot of output if you dump the entire group structure in this way. It is moreuseful to focus on a particular subgroup. For example, the groups for clinical trial AMX001 onlycan be obtained using the command:C:\Users\dmadmin> TMFAdmin -docbase_name documentum -user_name dmadmin -password ""–show tg_amx001 | more

Checking and Repairing the TMF Security Settings forExternal Users

The –show command can be used to perform an integrity check on the external access control groupscurrently assigned to documents and folders at and below a specified TMF folder. In this case, youshould specify the cabinet or folder path of the top-level folder to check. For example,C:\Users\dmadmin> TMFAdmin -docbase_name documentum -user_name dmadmin -password ""–show "/Clinical/Cardiology-Vascular/Vasonin" –verbose true

323


The output shows that the access control groups on all of the TMF documents and folders for theproduct named “Vasculin” are configured correctly. However, the groups themselves may stillneed to be refreshed.

In the next example, another product named “AIR” is selected, and this time, the tool reports anumber of issues. To focus on the errors, the –verbose option is turned off:C:\Users\dmadmin> TMFAdmin -docbase_name documentum -user_name dmadmin -password ""–show "/Clinical/Cardiology-Vascular/AIR" –verbose false

324


The output shows that there are 95 documents and one folder that must be repaired, and oneredundant group “tg_A001” that should be deleted. These issues were brought about by bulk DQLupdates to the repository, which caused the trial “A001” to be deleted, and changes to the TMFconfiguration in D2 affecting the way the external roles and folder levels are interpreted. To fix this,run the tool again in repair mode, as follows:C:\Users\dmadmin> TMFAdmin -docbase_name documentum -user_name dmadmin -password ""–repair "/Clinical/Cardiology-Vascular/AIR" –verbose false

The parameters are the same except that –show has been changed to –repair. The tool thenfixes all documents and folders that need repairing, reapplying D2 security in each case to ensurethe access controls are corrected. You can combine both the –show and –repair arguments inone operation. For example,C:\Users\dmadmin> TMFAdmin -docbase_name documentum -user_name dmadmin -password ""–repair "/Clinical/Cardiology-Vascular/AIR" –show "/Clinical/Cardiology-Vascular/AIR"–verbose false

In this case, the repair phase is always carried out first followed by the revalidationphase. The repair phase uses the same distributed/parallel processing mechanism as theD2-Configuration Migration tool and supports the same -max_threads, -content_servers,and –distributed_processing_threshold parameters, enabling potentially very large-scalerepairs to be carried out in extreme scenarios.

325


Refreshing TMF Access Control Groups for RegisteredExternal Users

External user registrations are stored:

• at the trial (study) level, in the Clinical Trial Registration Forms

• at the country (regional) level, in the Country Registration Forms for a particular trial

• at the site level, in the Site Registration Forms for a particular trial/country

The registrations are stored in repeating attributes associated with these forms. Whenever theseattributes are updated through the Manage External Users lifecycle action in D2, the correspondingrole groups are updated automatically to include only those users with active registrations. Thisimmediately grants or revokes access to the relevant TMF documents and folders to the externalusers. It is not necessary to update the documents and folders themselves; only the group membersmust be updated.

The group refresh operation is also carried out automatically on a daily basis for those registrationsthat are active through the D2 batch lifecycle job. This operation takes account of registrations thatare active for a specified time interval. However, it is also possible to trigger the refresh operationon-demand through the TMF Admin tool. To do this, specify the –refresh parameter on thecommand line, followed by a DQL qualifier identifying the registration forms to be processed.

For example, to refresh the external user groups for a specific site, with site ID “CH000001”, use:C:\Users\dmadmin> TMFAdmin -docbase_name documentum -user_name dmadmin -password ""-refresh "cd_clinical_site_info where tmf_site_id = 'CH000001'"

To refresh the external user groups for all sites in a specific country, it is only necessary to identifythe relevant Country Registration Form. For example, the following refreshes the groups for trial“AMX001” and country code “CH” (Switzerland), both at the country level and at the site level:C:\Users\dmadmin> TMFAdmin -docbase_name documentum -user_name dmadmin -password ""-refresh "cd_clinical_country_info where clinical_trial_id = 'AMX001' and country_code = 'CH'"

Likewise, to refresh all site/country groups across all countries for a particular trial, it is onlynecessary to identify the relevant Clinical Trial Registration Form. For example,C:\Users\dmadmin> TMFAdmin -docbase_name documentum -user_name dmadmin -password ""-refresh "cd_clinical_trial_info where clinical_trial_id = 'AMX001'"

To refresh all groups for all currently-active trials for a particular product, for example, “Vasonin”,use:C:\Users\dmadmin> TMFAdmin -docbase_name documentum -user_name dmadmin -password ""-refresh "cd_clinical_trial_info where product_code = 'Vasonin' and a_status = 'Active'and use_dynamic_access_ctrls = true"

The use_dynamic_access_ctrls = true qualifier avoids unnecessary processing of TMFs thatdo not have dynamic access controls enabled.

Finally, to refresh all external role groups throughout the repository, use:C:\Users\dmadmin> TMFAdmin -docbase_name documentum -user_name dmadmin -password ""-refresh "cd_clinical_trial_info where a_status = 'Active' and use_dynamic_access_ctrls = true"

Note: This can potentially involve a lot of processing if there are many active trials in the system,and it should be used with caution. The mechanism utilizes the distributed/parallel processingmechanism to process the groups when a large number of groups must be updated, and you can

326


use the -max_threads, -content_servers, and –distributed_processing_thresholdparameters.

In each case, the –reset true option can be specified in order to purge the relevant groups. Forexample, the following command can be used to revoke all external access to a particular trial:C:\Users\dmadmin> TMFAdmin -docbase_name documentum -user_name dmadmin -password ""-refresh "cd_clinical_trial_info where clinical_trial_id = 'AMX001' –reset true"

Purging and Deleting Specific Groups

The –purge and –delete commands can be used to forcibly revoke external user access as a lastresort:

• -purge <group-name> clears out all of the user members from the specified group, includingits sub-groups in recursive fashion, leaving the group hierarchy empty but intact.

• -delete <group-name> detaches the specified group from any ACLs that refer to it, thendeletes the group from the repository, including its subgroups recursively.

These commands can be used to purge and drop any Documentum group and not just TMF accesscontrol groups. However, they should be used with caution, as the effects may be irreversible. Abackup of the repository database should be taken before making such changes.

The following example purges the external access control groups at and below the trial level forthe Clinical Trial “AMX001”:C:\Users\dmadmin> TMFAdmin -docbase_name documentum -user_name dmadmin -password ""–purge tg_amx001"

The same effect can be brought about by refreshing the relevant Clinical Trial Registration Form withthe –reset option enabled as described previously, which is the preferred technique, as this ensuresthe correct groups are purged. However, it may occasionally be necessary to revoke external useraccess to all trials for a particular product. The most efficient way to do this is to purge the relevantproduct group. For example, for the product “Vasonin”:C:\Users\dmadmin> TMFAdmin -docbase_name documentum -user_name dmadmin -password ""–purge pg_vasonin"

The relevant trial, country, and site registration forms may also need to be deactivated to preventthem from being refreshed and reinstating external user access. The following DQL query can beused to achieve this:IDQL> update cd_common_ref_model objects set a_status = 'Inactive'where r_object_type in ('cd_clinical_trial_info', 'cd_clinical_country_info','cd_clinical_site_info') and product_code = 'Vasonin'

The –delete option can be used where the group hierarchy needs to be rebuilt, for example, ifthe group structure has been reorganized. This is usually only necessary for migration/upgradepurposes. It is possible to rebuild the entire TMF group hierarchy using the following technique:

• Delete the top-level tmf_contributors group.

• Run the tool in repair mode against the entire /Clinical cabinet. This rebuilds all of the requiredgroups, although they will not be populated at this stage.

• Refresh all active trials to repopulate the groups.

• Verify that the groups have been created successfully.

327


The following command accomplishes this in one operation:C:\Users\dmadmin> TMFAdmin -docbase_name documentum -user_name dmadmin -password ""–delete tmf_contributors –repair "/Clinical" -refresh"cd_clinical_trial_info where a_status = 'Active' and use_dynamic_access_ctrls =true" –show "/Clinical"

This command should only be used as a last resort to rebuild the access control groups, as it is likelyto involve very substantial processing, especially in mature repositories.

328

Chapter 19Life Sciences Software DevelopmentKit

This section provides an overview of the Life Sciences solution Software Development Kit (SDK).

OverviewThe Life Sciences solution Software Development Kit (SDK) enables System Integrators andDevelopers to integrate an individual solution such as Documentum eTMF, R&D, or SSV withan existing external application or management system. Developers can develop plugins for themanagement system in Java and use the SDK to synchronize the Documentum repository in responseto the management system events.

The SDK exposes basic functions of the solution, such as creating registration forms, through a JavaAPI and uses standard Documentum Foundation Services (DFS) Web Service calls for integrationpurposes. Detailed JavaDocs on the SDK are provided in the javadocs folder of the SDK package.

Web Services IntegrationDFS provides a set of Web Services for integrating applications with Documentum in a standard way.This enables external applications to store, retrieve, and manipulate objects in the repository, executequeries, and download or upload content files from and to the repository. DFS is a separate WARfile that has to be deployed for the SDK to use the DFS Web Services. By default, DFS is hosted bythe Documentum Java Method Server (JMS) running under JBoss. However, it is possible to hostDFS Web Services on a separate host if necessary. The DFS documentation available on EMC OnlineSupport (https://support.emc.com/) provides more information about installing and using DFS.

DFS provides basic repository services and uses a generic data model for representing repositoryobjects such as documents and folders. It does not use D2 configurations implicitly, althoughit is possible to query D2 configurations and appIy them through DFS service calls. It does notprovide data models for Life Sciences solution-specific entities, for example, TMF-specific entitiessuch as Clinical Trial Registration Forms, TMF documents, and so on. It does not support LifeSciences solution-specific functionality either. Therefore, to facilitate the development of externalapplications that integrate with a Life Sciences solution, a Java Client Library (JCL) is provided aspart of the solution.

329

https://support.emc.com/

Life Sciences Software Development Kit

Java Client Library

The JCL acts as a productivity layer on top of the standard DFS SDK client library, simplifying accessto the repository and providing a set of solution-specific Java classes. The following diagram showsthe DFS Web Service architecture for the Life Sciences solution:

The JCL productivity layer is packaged as a JAR file that can be included in Java applications.Although it is possible for client applications to directly call the DFS Web Services through theSDK, it is recommended that the operation be carried through the JCL to safeguard the applicationagainst future changes to the Life Sciences solution.

Supported Functionality in the SDKThe JCL in the Life Sciences solution SDK supports the following functionality:

• General convenience functions for managing connections to the Documentum repository,retrieval of login credentials and other applications-specific parameters from properties files,running DQL queries, and so on.

• Creation, retrieval, modification, and deletion of eTMF registration forms of various types,including Product Registration Forms, Country / Site Registration Forms, and Clinical TrialRegistration Forms, including template registration forms for each of the above.

• Retrieving, merging, and modifying file plans associated with registration forms of varioustypes, that is, lists of expected artifacts (document types) to be created at the product, trial, countryand/or site level in the TMF structure. This includes Product, Country, Trial, and Site-level fileplans and associated templates.

• Validation of file plans to ensure the relevant fields are defined and valid in the context of the trial,for example, to ensure country codes or site IDs refer to registered countries or sites for the trial.

• Storage and retrieval of file plans in Microsoft Excel format, which is predefined with built-invalue-assistance provided in the form of lookup tables.

330


• Activation and deactivation of file plans to create or remove placeholders for the expecteddocuments. File plans can be planned in stages if preferred, and activated in incremental fashion;an initial trial setup stage followed by an active trial stage, then a final close-out stage. A rolloverfunction is provided to enable the next stage to be activated (this can also be configured to occurautomatically if necessary). Alternatively, all defined stages can be activated at once if preferred,so that stages can be used to break up the overall file plan into manageable units.

• Update and retrieval of progress statistics indicating the current level of completion of a trial (upto and including the currently-active stage).

• D2 configuration lookup functions for dictionary entries, default value sets, creation matrices,and taxonomies, to enable country codes to be translated into locale-specific names, defaultvalues to be applied to new repository objects, and so on. Currently, this is restricted to read-onlyoperations. D2 configuration changes are not supported through the JCL; this must be donethrough D2-Config.

• TMF placeholder retrieval/update functions, enabling placeholders in the repository to beidentified and replaced with document content programmatically for example, to transfer a SiteManagement Report (SMR) document from a Clinical Trial Management System (CTMS) intoDocumentum eTMF in response to a particular CTMS event such as SMR review/approval.

• Ability to invoke D2 lifecycle transition actions on TMF documents and placeholders, enablingthe relevant actions to be configured through D2-Config and invoked through the SDK just asin the D2 Client.

• Registration of external users for access to the TMF documents at the trial, country and sitelevels in the appropriate roles, with automatic refresh of the corresponding role groups whenthe forms are saved.

• Creation, retrieval, modification, and deletion of Non-Clinical Study Registration Formsincluding updating the Group, Subgroup, and other information specific to the registration form.

• Creation, retrieval, modification, and deletion of Non-clinical documents including updatingthe metadata of the Non-clinical documents during creation or modification.

• Creation, retrieval, modification, and deletion of Regulatory Application Registration Formsincluding updating the Group, Subgroup, and other information specific to the registration form.

• Creation, retrieval, modification, and deletion of Regulatory documents including updating themetadata of the Regulatory documents during creation or modification.

• Creation, retrieval, modification, and deletion of Quality Project Registration Forms includingupdating the metadata during the creation or modification of the registration form.

• Creation, retrieval, modification, and deletion of Regulatory Application Labeling documentsincluding updating the metadata during the creation or modification of the document.

• Creation, retrieval, modification, and deletion of Regulatory Core Labeling documentsincluding updating the metadata during the creation or modification of the document.

• Creation, retrieval, modification, and deletion of Regulatory Correspondence documentsincluding updating the metadata during the creation or modification of the document. This alsoincludes importing Correspondence email containing attachments.

• Creation, retrieval, modification and deletion of Regulatory Clinical documents includingupdating the metadata during the creation or modification of the document.

331


• Creation, retrieval, modification and deletion of Regulatory Safety documents includingupdating the metadata during the creation or modification of the document.

• Creation, retrieval, modification and deletion of Regulatory Quality documents includingupdating the metadata during the creation and modification of the document.

• Creation, retrieval, modification and deletion of GMP documents including updating themetadata during the creation and modification of the document.

• Creation, retrieval, modification, and deletion of Generic Life Science documents includingupdating the metadata during the creation or modification of the document. Domain-specificmethods are not included because this is a generic implementation. Therefore, there are noimplied CDF Auto Inheritance calls wrapped inside convenience methods similar to those in otherdomains. It is up to the user to ensure that the additional updates are done either manually, orthrough a lifecycle transition that supports the additional calls.

For more information, see theWorking with the Life Sciences Software Development Kit whitepaper onEMC Online Support.

332

Chapter 20Configuration Settings to ImprovePerformance

This section provides various configuration settings that you can make to improve the performance ofthe Life Sciences solutions.

D2 4.7 Performance Best PracticesRefer to theD2 4.7 Best Practiceswhitepaper, available at https://community.emc.com/docs/DOC-56719which summarizes the best practices and guidelines to get better performance with D2 4.7.

Deactivating the myInsight Agent JobThe myInsight Agent job is configured to run once every five minutes, which can impact the overallperformance. To improve performance, you can decrease the frequency to hour level or deactivatethe job.


2. On the left pane, expand Job Management, and click Jobs.

3. On the right pane, right-clickmyInsight Agent, and click Properties.

4. In the Job Properties dialog box, select Inactive and click OK.Deactivating the myInsight Agent job does not affect report generation.

Disabling RSA Security Providers for myInsightReportsTo ensure that the performance of myInsight reports are good, it is recommended that you disable theRSA security providers in the Java Method Server’s JDK. Once the myInsight reports were enabled,

333

https://community.emc.com/docs/DOC-56719

Configuration Settings to Improve Performance

the following two RSA related JDK security providers can introduce severity performance impact toany JMS related events, mostly related to lifecycles:

• security.provider.2=com.rsa.jsafe.provider.JsafeJCE

• security.provider.3=com.rsa.jsse.JsseProvider

Comment out these two security providers in the java.security file on Content Server (forexample, <documentum>/java64/<JDK version>/jre/lib/security)

Internet Explorer Browser Settings (LSSSV)The response time in Internet Explorer is slow when a user selects the Current View tab of theSubmission Viewer for a Regulatory Application Registration Form that contains a large submission.For better performance, it is recommended that you disable any virus scanning add-ons such as thescriptproxy add-on from McAfee. To improve the response time in Internet Explorer, follow thesesteps:

1. In Internet Explorer, go to Tools > Internet options.

2. In the Internet Options dialog box, under Browsing history, click Delete.

3. In the Delete Browsing History dialog box, ensure that only the History option is selectedand click Delete.

4. Click OK.

5. Go to Tools >Manage add-ons.

6. In theManage Add-ons dialog box, disable the virus scanning add-on and then click Close.

Improving Performance of Server MethodsServer methods that support distributed or parallel processing, now support an additional argument,-use_private_sessions true|false, which is disabled by default. use_private_session is anew feature of parallel tasks handling mechanism in the Life Sciences solution.

When it is enabled, every thread is able to create its own Content Server session for handling the tasksin the thread. The benefit is that each session holds its own connection between JMS and the ContentServer, and therefore, its process does not block processes being handled by other threads at the sametime. Enabling this option can improve the performance of process-intensive operations, such as TMFtrial activation, submission import, and so on, at the expense of additional Content Server or JMSresources. A default value for the -use_private_sessions argument can be configured in the SystemParameters dictionary, or it can be specified explicitly in the method arguments.

If allowed, remove RSA providers from the JRE security file as it can maximize the benefit of parallelhandling mechanism in the Life Sciences solutions.

This argument applies to the following server methods:

• ApplyD2Configurations (all solutions)

• ApplyAttributeInheritance (all solutions)

334


• ImportSubmissionMethod (LSSSV only)

• ReconcileArtifacts (LSTMF only)

• TMFAdmin (LSTMF only)

• UpdateContributorGroups (LSTMF only)

Note: Avoid using max_file_processing_threads and max_import_processing_threadsin the Import Submissions Lifecycle parameters when use_private_sessions is set to true as itcan exhaust the sessions at a faster rate than they are released.

Database SettingsThis section provides the different configuration settings that you can make to improve performancefor the following databases that you use in your environment.

SQL Server

As a general rule, the performance on SQL Server can degrade if statistics and fragmentation are notkept in check. There are a number of tables that are rapidly modified, which make the fragmentationand index maintenance a key issue. Client Database Administrators (DBAs) must identify theirmost volatile tables in the day-to-day operation to determine the best schedule for daily, weekly, ormonthly maintenance.

Recommended settings:

• Increase the memory allocated to SQL Server to 20 GB for small to mid-sized clients

• Run the DB Statistics job as outlined in the Documentum Content Server Administration andConfiguration Guide.

The following table lists the parameters that you can modify for each of the components:

Component Parameters

SQL Server • Max Degree of Parallelism = 0

• Auto Create Statistics = False

• Auto Update Statistics = True

• Auto Update Statistics Asynchronously = True

• Is Read Committed Snapshot On = True

• Parameterization = Forced

335


Component Parameters

Content Server Server.ini• return_top_results_row_based = F

• concurrent_sessions = 1000

System environment variable• DM_LEFT_OUTER_JOIN_FOR_ACL=T

Application Server— D2

D2FS.properties• maxResultSetSize=1000

Oracle

Changes to the default SPFIle properties:

• processes 1000 (2X concurrent sessions)

• sessions 500

• open_cursors 2000

• cursor_sharing = Forced

• optimizer_mode = ALL_ROWS

Content Server SettingsThis section provides the different configuration settings that you can make to the Content Server toimprove performance.

Scheduled Jobs

The dm_LogPurge job cleans up the myInsight TEMP logs. This has to be scheduled to run in orderto clean the JOB logs from the repository. When the reports are generated, it creates a repository copyof the HTML file, which needs to be purged. This can be done by writing a custom job to clean thegenerated HTML file while running myInsight reports.

You can also disable unnecessary jobs by running the following commands:update dm_job object set is_inactive=True where object_name='D2JobWFFollowUpTaskNotif'update dm_job object set is_inactive=True where object_name='D2JobImportMassCreate'update dm_job object set is_inactive=True where object_name='D2JobWFReceiveTaskMail'update dm_job object set is_inactive=True where object_name='D2JobWFSendTaskMail'update dm_job object set is_inactive=True where object_name='dm_Initialize_WQ'update dm_job object set is_inactive=True where object_name='dm_QmThresholdNotification'update dm_job object set is_inactive=True where object_name='dm_QmPriorityNotification'update dm_job object set is_inactive=True where object_name='dm_QmPriorityAging'update dm_job object set is_inactive=True where object_name='dm_bpm_XCPAutoTaskMgmt'

336


update dm_job object set is_inactive=True where object_name='myInsight Agent'update dm_job object set run_mode=1,set run_interval=60 where object_name='D2JobSubscription'

In the Life Sciences solutions, the D2JobWFLaunchScheduledWorkflows job is made Inactive bydefault as it can cause conflicts in launching workflows.

Server.ini File Settings

Make the following changes in the server.ini file:

• DM_LEFT_OUTER_JOIN_FOR_ACL=T

• DM_GROUP_LIST_LIMIT=500

• concurrent_sessions = 500 (The maximum setting is based on the server operating system. ForWindows – 3275, for Linux – 1020.)

• return_top_results_row_based = F

• validate_database_user = F

• gethostbyaddr = F

• check_user_interval = 0

• upd_last_chg_time_from_db = F

JBOSS Access Log

You can configure the JBOSS log by editing the standalone.xml located in the<DOCUMENTUM_HOME>/jboss7.1.1/server/DctmServer_MethodServer/configuration/folder. The log files are created in the specified location with the format, access_log.<date>

Java Server Method Settings

The JMS setting needs to be 40 to 50% of available memory of the system. Run the followingcommand:set USER_MEM_ARGS=-Xms2048m -Xmx2048m -XX:PermSize=128m -XX:MaxPermSize=256M -Xss192k-XX:+DisableExplicitGC -Xrs -verbose:gc -Xloggc:D:/shared/Documentum/MethodServer/jms_gc.log

D2 Web Server SettingsThis section provides the configuration settings that you can make to the D2 Web Server to improveperformance.

337


JMS Configuration

For a mid-size client (1000 to 3000 seat count), run the following command to configure theApplication Server JVM settings:set USER_MEM_ARGS=-Xms4096m -Xmx4096m -XX:PermSize=64m -XX:MaxPermSize=1024m -Xss256k-XX:+DisableExplicitGC -Xrs -Xloggc:gc.log -verbose:gc -XX:+UseParNewGC

For a small-size client (100 to 300 seat count), configure the following Application Server JVM settings:HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Apache Software Foundation\Procrun 2.0\Tomcat8080\Parameters\JavaJvmMs = 2048 (Mb)JvmMx = 2048 (Mb)JvmSs = 256 (k)Options =-XX:PermSize=256m-XX:MaxPermSize=256m-XX:+UseParNewGC-XX:NewRatio=4-XX:NewSize=256m-XX:-UseAdaptiveSizePolicy-XX:SurvivorRatio=8-XX:MaxTenuringThreshold=0-XX:+UseConcMarkSweepGC-XX:+CMSClassUnloadingEnabled-XX:+CMSPermGenSweepingEnabled-verbose:gc-Xloggc:D:/shared/Tomcat8080/tomcat_gc.log

D2 Caching

Open the <App_Server>/webapps/D2/WEB-INF/classes/d2-cache.xml file and add thefollowing lines before the <cache> tag named xml-cache:<cache name="object_ids-cache"maxElementsInMemory="10000"eternal="false"overflowToDisk="false"memoryStoreEvictionPolicy="LFU"><cacheExtensionFactory class="com.emc.common.java.cache.PropertiesExtensionFactory"properties="type=d2_documentset, d2_documentset_switch, d2_filter_config,x3_preferences, x3_image, d2_query_config, d2c_preferences" propertySeparator=";"/>

</cache>

D2 Client ConfigurationsThis section provides the Life Sciences-specific UI configurations and recommendations to improveperformance.

338


Optimizing the D2 GUI Performance

Minimize the number of widgets in your workspace views. All widgets in all views are loaded intothe browser at login time. More number of widgets results in D2 taking longer time to open andload the widgets. When more widgets are available in the workspace view that responds to objectselection, it takes time for all the widgets to refresh.

Avoid using high-impact widgets that are active by default because it impacts browsing as thesewidgets respond to every selection event. The D2 Properties Preview widget is particularly highimpact. Move these widgets away from the first tab position so that it is not active unless explicitlyselected by the user.

D2 PDF Preview widget is not recommended for use in multi-view workspaces. It is alwaysactive; it downloads and renders the selected document even when in an inactive view. If used inmultiple views, all instances will respond to each selection event, causing multiple downloads,which degrades performance of the D2 client.

D2 Thumbnail Preview widget is not recommended for large documents as it requires the ThumbnailServer and Advanced Document Transformation Services (ADTS) to generate additional thumbnailrenditions.

Use the Life Sciences Document Preview widget instead as it is an external widget that is includedwith all Life Sciences solutions and used in all Life Sciences workspaces by default. It can beconfigured to respond in active views and only for selected objects of the appropriate type or format.This helps avoid unnecessary downloads or renderings. It is used for multiple purposes in the LifeSciences solutions as a standard document preview widget, left/right compare widget, and as a SSVleaf document viewer. It supports additional formats such as JPEG, GIF, BMP images, and mediafiles. It avoids D2 login ticket timeout by requesting new tickets automatically.

Life Sciences Document Preview Widget Configuration

To configure the Life Sciences Document Preview widget, pass the following arguments in the D2widget URL configuration setting:

Argument Value

widget_id Unique ID for this widget instance. Used for event filtering

workspaceView View (label) in which this widget instance is used such as Browse.Used to prevent unnecessary downloads

active Whether or not the widget is in the initial view that is, is activeby default

autoSelect • true — the widget should respond to selection events (forexample, standard doc preview)

• false — the widget should respond to custom menu eventsor on-click events raised by other widgets (for example, SSVSubmission Viewer) for the specified widget_id

useC2Overlays Whether or not to render PDFs with dynamic C2 watermarks

339


Argument Value

type, excludeTypes,excludeFormats

Optional filters

refeshLoginTicketInterval Ticket auto-refresh period (default = 240 seconds = 4 minutes)

There are multiple D2 widget configurations predefined for this widget with different URLparameters. The relevant widget configuration is referenced in the default workspace view definitionfiles in each case. For example,WG EXT Doc Viewer (Browse) is used in the Browse view of theworkspaces that have a welcome page for the default view. Similarly,WG EXT Doc Viewer (InitialBrowse) is used in the Browse view of the workspaces that do not have a welcome page; Browse” isthe default view.

TheWG EXT SSV Doc Compare Viewer 1 widget configuration is used in the left-hand side-by-sidecomparison view. This is configured to respond to the Show in Viewer 1menu events. TheWG EXTSSV Doc Compare Viewer 2 is configured similarly for the right-hand comparison view (widget IDlsDocViewer2). Accordingly, the D2 menu configuration for Show in Viewer 1 is configured to passthe appropriate widget ID in the widget_id parameter of the event message. In this case, the widgetonly responds to D2_EVENT_CUSTOM events targeted at lsDocViewer1 and ignores other events.The right-hand view menu is configured similarly, with events sent to widget ID lsDocViewer2.

340

Appendix A

Configuration Planning Checklist

Table 25. Configuration planning checklist

Configuration Components Steps

1. Security 1. Determine mapping to existing roles in thesolution.

2. Determine if additional roles must be added.

3. Identify the users or groups that should beadded to each solution role. Determine theauthors, reviewers, coordinators, managers,and so on in each department within yourorganization.

4. Determine if security configuration needs tobe adjusted.

5. Determine if access to creation/administration configurations mustbe adjusted.

6. Determine if preconditions on menus mustbe adjusted.

2. Object model Review the Life Sciences standard object modelto identify how your organization’s documentsand metadata will map to the object model.

341


Configuration Components Steps

3. D2 processing Review the following Life Sciencesconfigurations and identify any changesneeded for alternate processing (documents andregistration forms).

• Creation Profiles

— Addition or removal of creation profiles

— Addition or removal of individualdocument types within existing creationprofiles

— Changing the control category for artifacts.

— Registration forms

• Default values

• Lifecycles

• Workflows

• Check in/check out

• Rendition requests

4. Artifacts 1. Review the Life Sciences set of artifactsand identify any additions or modificationsneeded.

2. Identify the attributes applicable to theartifact.

3. Identify the scopes applicable to the artifact(some organizations make each artifactscope specific (for example, artifact name(site), artifact name (country)).

4. Identify default templates for each artifactif the artifact is to be created within eTMF(not needed if all documents are createdelsewhere and imported).

5. Identify naming conventions if usingCDFSetAttribute mechanism for objectnames (if relying on D2 auto-naming, there

342


Configuration Components Stepswill be one configuration for all documents.This, needs to be identified as well).

5. Review the procedures and best practices inChapter 2, Customizing D2-Based Solutions.

343


344

Appendix B

Troubleshooting

This appendix provide information on the log files that you can refer to in case you want totroubleshoot any issue in the Life Sciences solution.

Log FilesThe logs are the combination of D2–specific logs, Life Sciences-specific logs, and the supportingcomponent logs.

D2 Log Files

D2 logs can be accessed during runtime when using the application. The files can also be accessedduring design time when making configuration changes. The list of D2 logs in the ApplicationServer machine are listed as follows:

• C:\logs\D2-config.log

• C:\logs\D2.log

The list of D2 logs in Content Server are listed as follows:

• C:\logs\D2-CS.log

• C:\logs\D2-JMS.log

You can use both D2 Content Server and Application Server logs to troubleshoot many issues,including D2 Configuration-related issues and workflow and lifecycle-related problems.

Life Sciences Log Files

During the automated installation of the Life Sciences solution, installation log files are created.These logs are available on both Windows and Linux in the <Temp Extracted InstallationPackage>/<Installation package name>/working/logs folder.

The log files for the individual solutions listed in the following table:

345

Troubleshooting

Solution Log File

Life Sciences solutionsuite

• LSSuite_config.log

• LSSuite_copy_serverlibs.log

• LSSuite_dars.log

• LSSuite_eSubmission.log

• LSSuite_index.log

• LSSuite_populateroles.log

• LSSuite_populateroles_myInsight.log

• LSSuite_postInstall.log

• LSSuite_updateversion.log

• LSSuite_UrlUpdate.log

• LSSuite_virtualDocTemplate.log

Documentum eTMF • LSTMF_config.log

• LSTMF_copy_serverlibs.log

• LSTMF_dars.log

• LSTMF_index.log

• LSTMF_populateroles.log

• LSTMF_populateroles_myInsight.log

• LSTMF_postInstall.log

• LSTMF_updateversion.log

• LSTMF_UrlUpdate.log

Documentum Q&M • LSQM_config.log

• LSQM_copy_serverlibs.log

• LSQM_dars.log

• LSQM_index.log

• LSQM_populateroles.log

• LSQM_populateroles_myInsight.log

• LSQM_postInstall.log

• LSQM_updateversion.log

346

Troubleshooting

Solution Log File

• LSQM_UrlUpdate.log

Documentum R&D • LSRD_config.log

• LSRD_copy_serverlibs.log

• LSRD_dars.log

• LSRD_index.log

• LSRD_populateroles.log

• LSRD_populateroles_myInsight.log

• LSRD_postInstall.log

• LSRD_updateversion.log

• LSRD_UrlUpdate.log

• LSRD_virtualDocTemplate.log

Documentum SSV • LSSSV_config.log

• LSSSV_copy_serverlibs.log

• LSSSV_dars.log

• LSSSV_eSubmission.log

• LSSSV_index.log

• LSSSV_populateroles.log

• LSSSV_populateroles_myInsight.log

• LSSSV_postInstall.log

• LSSSV_updateversion.log

• LSSSV_UrlUpdate.log

Underlying Products Log Files

You can use the log files for the underlying products, such as Content Transformation Servers,xPlore, Content Server, Thumbnail Server, and Java Method Server, to troubleshoot issues relatedto Life Sciences.

347

Troubleshooting

Content Transformation Services

The default location of the log file on the Content Transformation Services host is the%CTS_HOME%\logs folder. The Content Transformation Services log files include:

• CTS_Log.txt: Contains the errors and exceptions that are specific to the server.

• <Plug-In>_Log.txt: Contains individual plug-in-related errors and exceptions.

• IMAGE3_log.txt: Contains the errors that are specific to the Image3 plug-in. The Image3plug-in logs errors when generating storyboards because the PDFStoryBoard plug-in cannotproduce images at a resolution higher than 96 dpi.

Note: If separate logging is enabled, log files can be found in the %CTS_HOME%\docbases\<docbasename>\config\logs folder.

The Documentum Content Transformation Services Administration Guide provides more informationabout the log files.

xPlore

You can view indexing, search, content processing service (CPS), and xDB logs in xPloreAdministrator. To view a log file:

1. In xPlore Administrator, select an instance and click Logging.

2. Click the tabs for dsearch, cps, cps_daemon, or xdb to view the last part of the log. Indexingand search messages are logged to dsearch.

3. Click Download All Log Files to obtain download links for each log file.

The Documentum xPlore Administration and Development Guide provides more information aboutthe log files.

Content Server

Content Server logging and tracing provides information about Content Server operations. Thislogging information and tracing information is recorded in the following files:

• Repository log file: Contains information about root server activities. This file is also sometimesreferred as the Content Server log file.

• Session log files: Contains all information, warning, error, and fatal error messages and, bydefault, all SQL commands generated from DQL commands.

Session log files are stored in the %DOCUMENTUM%\dba\log\hex_repository_id\username($DOCUMENTUM/dba/log/hex_repository_id/username) directory, where hex_repository_id isthe repository ID expressed as a hexadecimal value and username is the user account under whichthe session is running. The session log name is the session ID.

The server creates a separate session log for each new connection. Sessions that are connectedto the primary Content Server create their session logs under the primary server. Sessions thatare connected to one or more remote Content Servers create their session logs under the remote

348

Troubleshooting

server(s). Because sessions are assigned using a round-robin method, you must look in both placesfor session logs. Some features, such as jobs, also record tracing and logging information specificto those features in log files.

The Documentum Content Server Administration and Configuration Guide provides more informationabout the log files.

Java Method Server

The CDF-Methods.jar, CDFBase.jar, TMF-Methods.jar, SSV-Methods.jar, andControlledPrintServerMethods.jar files run on the Java Method Server. The server logserrors for these JMS method execution in the server.log file located in the %DM_HOME%\jboss[version]\server\DctmServer_MethodServer\log\ folder.

Third-Party Log Files

You can use the log files for the supported third-party products, such as myInsight, to troubleshootissues related to these products.

myInsight

When an myInsight report is generated manually or as a scheduled task, a log file is created andplaced in the Temp cabinet in the Life Sciences solution. If the myIsight Agent job is run, the log file iscreated in the /Temp/jobs/myInsight Agent folder.

The AMPLEXOR myInsight User Guide provides more information about the messages that appears inthe log file.

Enabling Logging, Debugging, and TracingYou can enable logging for D2, the underlying products, and the third-party products.

Configuring Logging for D2

For D2-Client issue:

• To troubleshoot D2-Client-related (4.x) issues, set the trace level to 5 for the Java Console log.

• Charles/Fiddler Traces can help in troubleshooting Client-Server or AppServer-Server relatedissues.

349

Troubleshooting

For D2-Config related issues:

• Refer to the D2-Config.properties file located in the <webapp_root>\WEB-INF\classesfolder.

• To enable tracing, set logLevel=trace. Restarting the application server should not be required.If the new logLevel trace setting does not take effect, then log in to D2-Config and select Tools >Reload D2 Options. Note that this requires the client URL information to be correctly filled out inD2-Config>Tools>Client URL box, that is, http://<url>/D2-Config. Incorrect/unreachableURLs results in errors being reported in the D2 logs.

• An alternative method of enabling debug tracing for D2-Config is through the<webapp_root>\WEB-INF\classes\logback.xml file.

• Edit the <level>${logLevel:-warn}</level> and set to the desired logging level suchas debug, that is <level>debug</level>.

• Reproduce an issue and make sure it is captured in the trace output.

For D2 (4.x client) related issues:

• The Logback.xml file can be found in the <webapp_root>\WEB-INF\classes folder.

• To enable tracing, find the <level>xxx</level> tags in the log file and set the value to<level>debug</level>. Changes to the logging level should be picked up automaticallywithin 60 seconds.

• Enable Java Console logging (level 5) on the client side through the Java Console window.

• Reproduce an issue and make sure the problem is captured in the trace output.

Configuring Logging for Controlled Print

Debug logging should be enabled for the Controlled Print functionality to retain the generatedprints and to see the finer details of controlled print execution steps. The logging level for controlledprint can be updated by changing the following line in the log4j.properties file found in the path,<webapp_root>\ControlledPrint\WEB-INF\classes:log4j.logger.com.emc.services=DEBUG

The generated prints are saved in the path, <<root_directory>>/tmp/<<object_id of the document>>, ifthe log level is set to DEBUG. These files will be cleaned up by the application when the log levelis set to INFO.

Configuring Debugging for Custom External Widgets

For all the default external widgets provided by Life Sciences (other than myInsight externalwidgets), you can set the debug = true parameter in the external widgets URL. This will showthe URL parameters passed and will help in debugging. If required, you can explicitly add the URLparameter debug=true in the required external widgets for debugging.

For example:

350

Troubleshooting

/XMLViewer/DocViewer.html?debug=true&initMessage=Select_a_document_for_comparison_in_Viewer_1&docbase=$DOCBASE&locale=en&username=$LOGIN&password=$TICKET&widget_id=viewer1&useC2Overlays=true&refreshTicketInterval=240

You can set the debug parameter for the following external widgets:

• WG EXT SSV Leaf Element Viewer

• WG EXT PDF Viewer 1

• WG EXT PDF Viewer 2

• WG EXT Submission History View

• WG EXT LSCI LSS Doc Viewer (Browse)

• WG EXT LSCI LSS Doc Viewer (Initial Browse)

• WG EXT LSCI LSS Doc Viewer (Tasks)

• WG EXT LSCI SSV Doc Compare Viewer 1

• WG EXT LSCI SSV Doc Compare Viewer 2

• WG EXT LSCI Study Tagging File Navigator

• WG EXT LSCI LSS Doc Viewer (QC Index)

Configuring Logging for Underlying Products

You can configure logging for the underlying products, such as Content Transformation Servers,xPlore, Content Server, Thumbnail Server, and Java Method Server, to troubleshoot issues relatedto Life Sciences.

Content Server

For Content Server 7.1 and above, because of JBOSS changes, certain configuration changes mustbe made to get proper D2 Java Method Server log information:1. Delete the jboss-log4j.xml file from the <dctm_home>\jboss7.1.1\server

\DctmServer_MethodServer\deployments\ServerApps.ear\APP-INF\classesfolder.

2. Create a logback.xml file in the <dctm_home>\jboss7.1.1\server\DctmServer_MethodServer\deployments\ServerApps.ear folder. You can use the following samplelog file to create your log file.

351

Troubleshooting

3. Stop the Documentum JMS Service.

4. Delete the contents of the following folders:

• {jBoss Home}/server/DctmServer_MethodServer/log

• {jBoss Home}/server/DctmServer_MethodServer/logs

• {jBoss Home}/server/DctmServer_MethodServer/tmp

• {jBoss Home}/server/DctmServer_MethodServer/work

5. Start the Documentum JMS Service.

6. To enable tracing, in the logback.xml file, find the <level>#####</level> tag and setthe value to DEBUG. Changes to the log file are automatically picked up within 60 seconds. Ifnot, restart the Java Method Server.

Content Transformation Services

Separate logging appenders are added to the log4j.properties file for logging the polling andcapability caching information. Refer to the following entries in the log4j.properties file:

• log4j.category.POLLINGAppender=INFO, POLLINGAppender

• log4j.appender.POLLINGAppender=org.apache.log4j.DailyRollingFileAppender

• log4j.appender.POLLINGAppender.File=R $C(CTS, PARENT_DIR)\\logs\\Polling_log.txt

• log4j.appender.POLLINGAppender.Append=true

• log4j.appender.POLLINGAppender.layout=org.apache.log4j.PatternLayout

• log4j.appender.POLLINGAppender.layout.ConversionPattern=%d{HH\:mm\:ss,SSS} %10r %5p[%10t] %-20c - %5x %m%n

• log4j.appender.POLLINGAppender.DatePattern=’.’yyyy-ww-dd

• log4j.category.CAPABILITYAppender=INFO, CAPABILITYAppender

352

Troubleshooting

• log4j.appender.CAPABILITYAppender=org.apache.log4j.DailyRollingFileAppender

• log4j.appender.CAPABILITYAppender.File= $C(CTS, PARENT_DIR)\\logs\\Capability_log.txt

• log4j.appender.CAPABILITYAppender.Append=true

• log4j.appender.CAPABILITYAppender.layout=org.apache.log4j.PatternLayout

• log4j.appender.CAPABILITYAppender.layout.ConversionPattern=%d{HH\:mm\:ss,SSS} %10r%5p [%10t] %-20c - %5x %m%n

• log4j.appender.CAPABILITYAppender.DatePattern=’.’yyyy-ww-dd

The log files, Polling_log.txt and Capability_log.txt, corresponding to these appenderscontain the logs related to polling and capability caching information respectively. This informationis not logged to the main CTS_log.txt file. The log level can be set to DEBUG for more informationto be captured in the log file.

xPlore

Basic logging can be configured for each service in xPlore administrator. Log levels can be setfor indexing, search, CPS, xDB, and xPlore administrator. You can log individual packageswithin these services, for example, the merging activity of xDB. Log levels are saved toindexserverconfig.xml and are applied to all xPlore instances. xPlore uses slf4j (Simple LoggingFaçade for Java) to perform logging.

To set logging for a service:

1. In xPlore Administrator, click System Overview.

2. Click Global Configuration.

3. On the Logging Configuration tab, configure logging for all instances. Open one of the servicessuch as xDB and set levels on individual packages.

To customize the instance-level log setting, edit the logback.xml file in each xPlore instance. Thelogback.xml file is located in the WEB-INF/classes folder for each deployed instance war file.Levels set in logback.xml take precedence over log levels in xPlore Administrator.

Note: Logging can slow the system and consume disk space. In a production environment, run thesystem with minimal logging.

Each logger logs a package in xPlore or in your custom code. The logger has an appender thatspecifies the log file name and location. DSEARCH is the default appender. Other defined appendersin the primary instance logback configuration are XDB, CPS_DAEMON, and CPS. You can add alogger and appender for a specific package in xPlore or your custom code. The following exampleadds a logger and appender for the package com.mycompany.customindexing:<logger name="com.mycompany.customindexing" additivity="false" level="INFO"><appender name="CUSTOM" class=" ch.qos.logback.core.rolling.RollingFileAppender"><file>C:/xPlore/jboss7.1.1/server/DctmServer_PrimaryDsearch/ logs/custom.log </file><encoder> <pattern>%date %-5level %logger{20} [%thread] %msg%n</pattern><charset>UTF-8</charset></encoder><rollingPolicy class="ch.qos.logback.core.rolling. FixedWindowRollingPolicy"><maxIndex>100</maxIndex><fileNamePattern>C:/xPlore/jboss7.1.1/server/DctmServer_ PrimaryDsearch/logs/custom.log.%i</fileNamePattern>

353

Troubleshooting

</rollingPolicy><triggeringPolicy class="ch.qos.logback.core.rolling. SizeBasedTriggeringPolicy"><maxFileSize>10MB</maxFileSize></triggeringPolicy></appender></logger>

You can add custom logger and appender to logback.xml. To capture log entries in thelogs in xPlore Administrator, add the custom logger to a logger family, which are defined inindexserverconfig.xml. This is an optional step – if you do not add your custom logger to alogger family, it still logs to the file that you specify in your appender. Logger families are used togroup logs in xPlore Administrator. You can set the log level for the family, or expand the familyto set levels on individual loggers.

The log levels include TRACE, DEBUG, INFO, WARN, and ERROR. The levels are in increasingseverity and decreasing amounts of information. Therefore, TRACE displays more than DEBUG,which displays more than INFO.

Thumbnail Server

To activate thumbnail logging:

1. Log in to the Thumbnail Server host as an Administrator.

2. Stop the Thumbnail Server service.

3. Navigate to the %DM_HOME%\thumbsrv\container\webapps\thumbsrv\web-inf folderand open the web.xml file in any text editor.

4. Change the <debug> flag to TRUE.

5. Save and close the web.xml file.

6. Start the Thumbnail Server service.

Java Method Server

To enable logging for CDF, TMF, and SSV server methods, set the logging level to DEBUG on theJava Method Server by adding the following settings to the log4j.properties file, locatedin \Documentum\jboss[version]\server\DctmServer_MethodServer\deployments\ServerApps.ear\APP-INF\classes:

• log4j.logger.com.documentum.d2=INFO

• log4j.logger.com.documentum.cdf=DEBUG

• log4j.logger.com.documentum.tmf=DEBUG

• log4j.logger.com.documentum.ssv=DEBUG

• log4j.logger.com.documentum.utils=DEBUG

• log4j.logger.com.emc.documentum.ls.utils=DEBUG**

354

Troubleshooting

** Only for LSTMF and Life Sciences solution suite setups where lock mechanism is used whilecreating dynamic groups during trial activation and reactivation.

Life Sciences SDK

The log4j logging framework is used in the Life Sciences SDK. The log4j properties can be set for thelogs specific to the SDK by setting the log levels. For example:log4j.logger.com.documentum.ws=DEBUG.

Configuring Logging for Third-Party Products

myInsight

To troubleshoot issues related to myInsight reports, myInsight logs can be collected by placingthe logging.properties file the WEB-INF/classes folder in the myInsight web applicationand restarting the Application Server. The log levels can be FINE and FINEST. The following codecan be added to the log file:handlers = org.apache.juli.FileHandler############################################################# Handler specific properties.# Describes specific configuration info for Handlers.############################################################org.apache.juli.FileHandler.level = FINEorg.apache.juli.FileHandler.directory = ${catalina.base}/logsorg.apache.juli.FileHandler.prefix = myInsight.java.util.logging.ConsoleHandler.level = FINEjava.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter

ARender

To troubleshoot issues related to ARender, ARender application-specific logs can be collectedby placing the logging.properties file the WEB-INF/classes folder in the ARender webapplication and restarting the Application Server. The log levels can be FINE and FINEST.

Connection IssuesThe Life Sciences solution suite is a web-based application. If the repository does not appear or otherconnection issues occur, verify that the required services are running.

To start the required services:1. Log in to the Windows system using the login credentials.

355

Troubleshooting

2. Open the Services console.

3. Start the following services in the listed order:a. Documentum Docbroker Service Docbroker

b. Documentum Docbase Service <Repository Name>

c. Documentum Java Method Server

4. Start the respective Application Server where D2 and other web applications are running.

D2 Performance IssuesD2 is taking time to load the workspace, widgets, creation profiles, and other configurations.

Resolution

Follow these steps to improve the performance of the application with respect to the workspace,widgets, creation profiles, and other configurations.

1. Stop the application server.

2. Update the D2FS.properties file located in the /WEB-INF/classes folder in D2.war byturning onmaxResultSetSize by uncommenting the line (remove the #). For example:maxResultSetSize=1000

3. Configure the d2-cache.xml file located in the /WEB-INF/classes folder in D2.war, byadding more d2-cache configurations:<?xml version="1.0" encoding="UTF-8"?><ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:noNamespaceSchemaLocation="d2-cache.xsd"updateCheck="false" monitoring="autodetect">

<cache name="xml-cache" maxElementsInMemory="10000" eternal="false" overflowToDisk="false"/>

<cache name="dictionary_dico-cache" maxElementsInMemory="10000" eternal="false"overflowToDisk="false"/>

<cache name="dictionary_dql-cache" maxElementsInMemory="10000" eternal="false"overflowToDisk="true" maxElementsOnDisk="10000000" diskPersistent="false"memoryStoreEvictionPolicy="LFU"/>

<cache name="object_ids-cache" maxElementsInMemory="10000" eternal="false"overflowToDisk="false" memoryStoreEvictionPolicy="LFU">

<cacheExtensionFactory class="com.emc.common.java.cache.PropertiesExtensionFactory"properties="type=d2_acl_config,d2_documentset,d2_documentset_switch,x3_widget_config,d2c_preferences,d2_create_config" propertySeparator=";"/>

</cache><cache name="user_group-cache" maxElementsInMemory="10000" eternal="false"

overflowToDisk="false"/></ehcache>

4. Start the application server.

356

Troubleshooting

Submission Viewer Timeout Issue (LSSSV)When viewing a submission in the Submission Viewer widget, if you try to view the submission aftera few minutes, the Viewer does not display the submission. This issue occurs because the SubmissionViewer gets timed out after five minutes.

The login ticket time-out period can be configured in the Documentum dm_server_configparameters. You can also configure it in the server.ini configuration file on the server. By default,this is set to 5 minutes, but it can be changed.

You can also specify the automatic ticket refresh interval used by the Submission Viewer widgetby passing a refreshLoginTicketInterval=<n> parameter in the URL in the D2-Configconfiguration for the Ext SSV Submission Viewer widget, where <n> is the required interval inseconds. By default, n=240s (4 minutes). To prevent the Submission Viewer ticket from timing out,the specified refresh interval <n> should be less than the login ticket time-out value defined in theDocumentum server configuration object.

Exporting Large Folders IssueExporting folders that contain a large number of files from the D2 Client, it may sometimes fail incompleting the operation successfully.

Resolution

To resolve this issue, you need to adjust the following parameters in both D2 and Content Server toenable the export operation to succeed and also enhance the performance of the operation:

• contentTransferUrlTicketTimeout=15 (in the /WEB-INF/classes/D2FS.propertiesfile of the D2 Client deployment in the Application Server.)

• download.folderexport.batchsize=250 (in the /WEB-INF/classes/settings.properties file of the D2 Client deployment in the Application Server.)

• concurrent_sessions=100 (in the server.ini file on Content Server.)

As these values are interconnected, it is advisable not to provide large variations over therecommended settings.

357

Troubleshooting

358

Appendix C

DIA EDM and TMF Reference ModelDictionaries

Table 26. Clinical domain dictionaries


Clinical Groups List of values in the Group column on theClinical domain tab of the DIA EDM referencemodel spreadsheet. These values are the logicalgroupings or CTD modules in the Clinicaldomain.

Clinical Subgroups List of values in the Sub-Group column on theClinical domain tab of the DIA EDM referencemodel spreadsheet. Within the Clinical domain,categories of documents within a group, usuallybased on CTD module subsets.

Clinical Artifact Names Complete list of Clinical artifacts defined inthe Artifact Name column on the Clinicaldomain tab of the DIA EDM reference modelspreadsheet.

Clinical Literature References Artifact Names List of artifacts in the Literature Referencesgroup on the Clinical tab of the DIA EDMreference model spreadsheet.

Clinical Report Component Artifact Names List of artifacts defined on the Clinical ReportComponents tab of the DIA EDM referencemodel spreadsheet.

Clinical Summaries Artifact Names List of artifacts in the Summaries group on theClinical tab of the DIA EDM reference modelspreadsheet.

359

DIA EDM and TMF Reference Model Dictionaries

Table 27. Non-Clinical domain dictionaries


Non-Clinical Groups List of values in the Group column on theNon-Clinical domain tab of the DIA EDMreference model spreadsheet. These values arethe list of logical groupings in the Non-Clinicaldomain.

Non-Clinical Subgroups List of values in the Sub-Group column onthe Non-Clinical domain tab of the DIA EDMreference model spreadsheet. Within theNon-Clinical domain, categories of documentswithin a group, usually based on CTD modulesubsets.

Non-Clinical Artifact Names Complete list of Non-Clinical artifacts defined inthe Artifact Name column on the Non-Clinicaldomain tab of the DIA EDM reference modelspreadsheet.

Non-Clinical Literature References ArtifactNames

List of artifacts in the Literature Referencesgroup on the Non-Clinical tab of the DIA EDMreference model spreadsheet.

Non-Clinical Report Component Artifact Names List of artifacts defined on the Non-ClinicalReport Components tab of the DIA EDMreference model spreadsheet.

Non-Clinical Study Durations List of values that can be selected for theduration of a particular non-clinical study.

Non-Clinical Study Management Artifacts List of document types defined on theNon-Clinical tab of the DIA EDM referencemodel spreadsheet that can be createdmy members of the Non-Clinical StudyManagement group.

Non-Clinical Summaries Artifact Names List of artifacts in the Summaries group on theNon-Clinical tab of the DIA EDM referencemodel spreadsheet.

Non-Clinical Test Facility Locations. List of artifacts in the Non-Clinical group onthe Non-Clinical tab of the DIA EDM referencemodel spreadsheet. It is the list of locations thatprovide test facilities for non-clinical studies.

360


Table 28. Quality domain dictionaries


Quality Groups List of values in the Group column on theQuality domain tab of the DIA EDM referencemodel spreadsheet. These values are the logicalgroupings in the Quality domain.

Quality Subgroups List of values in the Subgroup column on theQuality domain tab of the DIA EDM referencemodel spreadsheet. Within the Quality domain,categories of documents within a group.

Quality Artifact Names List of values in the Artifact column on theQuality domain tab of the DIA EDM referencemodel spreadsheet. List the various kinds ofdocuments in the Quality domain.

Quality Adventitious Agents Artifact Names List of values in the Artifact column on theQuality domain tab of the DIA EDM referencemodel spreadsheet. These are the artifact namesfor Domain: Quality and Group: AdventitiousAgents.

Quality Drug Product Artifact Names List of values in the Artifact column on theQuality domain tab of the DIA EDM referencemodel spreadsheet. These are artifact names forDomain: Quality and Group: Drug Product.

Quality Drug Substance Artifacts Names List of values in the Artifact column on theQuality domain tab of the DIA EDM referencemodel spreadsheet. These are artifact names forDomain: Quality and Group: Drug Substance.

Quality Facility Artifact Names List of values in the Artifact column on theQuality domain tab of the DIA EDM referencemodel spreadsheet. These are artifact names forDomain: Quality and Group: Facility.

Quality Information Artifact Names List of values in the Artifact column on theQuality domain tab of the DIA EDM referencemodel spreadsheet. These are artifact namesfor Domain: Quality and Group: QualityInformation.

Quality Literature Reference Artifact Names List of values in the Artifact column on theQuality domain tab of the DIA EDM referencemodel spreadsheet. These are artifact namesfor Domain: Quality and Group: LiteratureReference.

Quality Medical Device Artifact Names List of values in the Artifact column on theQuality domain tab of the DIA EDM referencemodel spreadsheet. These are artifact names forDomain: Quality and Group: Medical Device.

361



Quality Overall Summary Drug Product ArtifactNames

List of values in the Artifact column on theQuality domain tab of the DIA EDM referencemodel spreadsheet. These are artifact names forDomain: Quality and Group: Quality OverallSummary Drug Product.

Quality Overall Summary Drug SubstanceArtifact Names

List of values in the Artifact column on theQuality domain tab of the DIA EDM referencemodel spreadsheet. These are artifact names forDomain: Quality and Group: Quality OverallSummary Drug Substance

Quality Project Management Artifacts Defines the document types that can be createdby members of the Quality Project Managementgroup.

Table 29. Regulatory-Admin domain dictionaries


Regulatory-Admin Artifact Single dictionary that lists values of theRegulatory Administrative domain tab of theDIA EDM reference model spreadsheet. It holdsa key with a syntax "<artifact_name>|<region>".There is a alias created for each value that variesfor each artifact (for example, Group, Subgroup,Region, and so on).

Regulatory-Admin Management Artifacts Defines the document types that can becreated by members of the Regulatory-AdminManagement group.

Table 30. TMF dictionaries


TMF Models Name and version of the TMF reference modelthat is supported as listed in the DIA TMFreference model spreadsheet. Defines the TrialMaster File schemas supported. Each schema(model) can have its own access control rules fortrial participants.

362





363


364

Appendix D

Visual Representation of AttributeCascading in Life Sciences

During document creation or import, a document inherits a set of attributes from a correspondingregistration form. For example, if you create a non-clinical document, the system requires you toassociate the document to a Non-clinical Study Registration Form. The individual document inheritsa set of product and study information from the registration form.

The following diagrams represent how information is cascaded from the registration forms to theindividual documents in each of the solutions.

Legend:

• TXT — Free Form Text Entry

• DQL — DQL-based set used for the drop-down list

• DQL-prod — DQL-based set tempered by selected product to be used for the drop-down list

• DICT — Dictionary-based set used for the drop-down list

• DICT+FREE — Dictionary-based set used for the drop-down list; unlisted values accepted

• DICT-DQL-prod — Dictionary-based value set through DQL tempered by the selected product

• RO — Read only value; set earlier

• DQL-RO — Read-only value set through a DQL query on another field

• DQL-Dep — DQL-based set tempered by the first value in the set

• DQL-Dep-RO — Read-only value set through DQL tempered by the first value in the set

• DQL-Dep-Free — DQL-based set tempered by the first value in the set; unlisted values accepted

365

Visual Representation of Attribute Cascading in Life Sciences

Figure 1. Product and Project Registration Form Attributes

Figure 2. Cascading of Attributes in the Clinical Domain

366


Figure 3. Cascading of Attributes in the Non-clinical Domain

367


Figure 4. Cascading of Attributes in the Regulatory Domain

368


Figure 5. Cascading of Attributes in the Safety and Quality Domain

369


370

Appendix E

D2 Configurations

The following table lists the D2 configuration elements that are used by the Life Sciences solutions.When customizing the D2 configurations to address customer-specific business requirements,these D2 configurations must not be renamed or removed from the Life Sciences system. Theseconfigurations are used by the Life Sciences Server Methods internally to address specific andrespective business operations.

Configuration Category Configuration Name

Creation Profiles Submission Elements

TMF Documents by TMF Unique Artifacts

Default Value Templates Clinical Trial Country Registration Form Default Values

Clinical Trial Registration Form Default Values

Clinical Trial Site Registration Form Default Values

Non-Clinical Study Registration Form Default Values

Product Registration Form Default Values

Quality Project Registration Form Default Values

Regulatory Submission Registration Form Default Values

Regulatory-Administrative Registration Form Default Values

TMF Placeholder Defaults

TMF Template Default Values

371

D2 Configurations


Dictionary Clinical Study Phases

Clinical Trial Control Types

Geographic Regions

GMP Artifacts

Object Type to Taxonomy mapping

Regulatory-Admin Artifact

Route of Administration List

States of America

Submission Element Types

Submission Filestores

Submission Regional Metadata Conversions

System Parameters

TMF Artifact Scopes

TMF Artifact Scopes for Bulk Upload Spreadsheets

TMF Artifact Scopes for Individual Documents

TMF Countries

TMF Document Roles

TMF External Contributor Roles

TMF Folder Groups

TMF Geographic Regions

TMF Lifecycle States for Bulk Upload Spreadsheets

TMF Models

TMF Unique Artifact Names 2.0

TMF Unique Artifact Names 3.0

TMF Site Facility Types

wf_rule_attributes

Extended Creation Profile TMF Documents by TMF Unique Artifacts

Lifecycle Config TMF Document Indexing Lifecycle

372

D2 Configurations


D2 mailing config Send Contributor Change Notification

Send user index notification

Registered Table Config notify_message

tmf_progress_history

D2 Taxonomy Clinical Classification by Group

GMP Artifacts

GMP Artifacts by Group

Non-Clinical Classification by Group

Promotional Materials Classification by Group

Quality Classification by Group

Regulatory Correspondence Classification by Group

Regulatory Labeling Classification by Group

Safety Classification by Group

TMF Geographic Regions

373

D2 Configurations

374

Index

Aaccess control

role-based, 166adding role example

external trial participants, 247ApplyD2Configurations, 319artifact-based attributes, 115artifact-based autonaming, 115

configuring existing dictionaries, 116attribute rules

auto-inherited, 91configuring, 92

audit events, 234audit trail, 234auto-inheritance rules

support auditing, 125

Bbulk import-export, 239

CC2 View configuration

PDF, 82cascading attribute rules, 91

configuring, 98preconfigured, 117support auditing, 125

cat 1–3ownership, 167

CDFsecurity model, 159

CDF methodscontext user argument, 109

change requestconfiguring, 201configuring properties, 202disable, 201

Change RequestCURRENT binding rule, 204

configure rolesQ&M, 53

configuringaudit events, 234D2 mailing configuration, 229modifying messages, 143search criteria, 236

configuring roles and permissionsexternal participants, 242

content server settingsJBOSS access log, 337JMS, 337scheduled jobs, 336server.ini, 337

control categories, 45assign, 164ownership, 167

control categorydefinition, 76

controlled printconfiguring, 207configuring auto-recall, 213cover page configuration, 207creating the overlay template, 210creating the print profile, 210mapping the contexts, 212overlay configuration, 207print reasons, 212setting up printers, 212

Convert to Virtual Document optionenabling, 255

creation profile, 73add artifacts, 79change, 79customize, 78new, 78remove, 80remove artifacts, 80

custom attribute inheritance rule, 122custom reference model

dictionary, 72

375

Index

implement, 72custom roles

create, 52property page, 52workflow, 53

DD2 client configurations

D2 GUI, 339document preview widget

configuration, 339D2 configuration elements

hard-coded, 371D2 configuration migration, 319

configure, 321install, 320

D2 core methodsenabling trace level, 255

D2 mailing configurationmessage configuration, 231task variables, 229

D2 mailing configurations, 227D2 URL, 256, 304D2–based solution, 47

base configuration, 48base solution contexts, 48best practices, 52custom application, 47extend, 47 to 48merging, 51team development, 52

dashboardsviewing, 200

data model, 55database settings

SQL Server, 335debugging

enable, 349default values template, 76dictionary

extend, 71display label, 194distributed processing

enabling, 251 to 252document creation profile, 74document domains, 16document permissions

external trial participants, 246document_id, 81

EeCTD, 261

M1 regional XML files, 279new XML formats, 263non-standard XML files, 276regional XML file, 261standard XML files, 273xsl style sheet, 261

EDM reference modelimplementation, 59updated implementation, 69

email notificationdisabling, 233

enablingdistributed processing, 251 to 252

eTMFcustom reference model, 72file plan, 72file plan template, 72standard reference model, 71

eventsaudit, 233

extended attribute expressions, 104extended base configurations

reconcile, 50solution upgrades, 50

external participantsconfiguring roles and permissions, 242

external trial participantsadding role example, 247define permissions, 246define roles, 243user groups, 33user roles, 32

external user, 326external users

security, 323external widget

configure, 199

Ffile names, 81for collaborative editing, 130

Hhard delete

configure, 237

376

Index

Iinheritance, 91Internet Explorer

browser settings, 334

LLife Sciences

fundamental concepts, 15lifecycle, 145

document, 145normal states, 157pseudo states, 157

lifecycle actionscustom business logic, 158

lifecycle configurationcreate, 157modify, 157

lifecycle state transitionuniqueness check, 156

lifecycle statescontrol categories 1–3, 148control category 4, 148

log files, 345logging

enable, 349

Mmailing configurations, 227management creation profile, 73multi-threaded processing, 321myInsight, 32, 37, 41, 44myInsight agent job

deactivate, 333myInsight reports

external widget, 199report generation process, 199widgets, 198

Nnative annotation, 81NeeS, 303

OO2 configuration, 81overview, 15

Pparallel processing, 321

CFD methods, 254disable, 254

PDF annotation, 81PDF rendition, 83PDF renditions

electronic signatures, 83overlays, 84page size, 84signature page, 84

PDF to Excelconfigure, 236

performanceconfigurations, 333content server settings, 336D2 client configurations, 338database settings, 335file import, 334submission import, 334TMF trial activation, 334web server settings, 337

performance improvement, 333permissions, 159

change requests, 161country and site registration forms, 160GMP documents, 161product registration form, 160R&D documents, 163registration forms, 163trial master file document, 160trial registration form, 160

planningchecklist, 341

previewingmedia files, 235

QQ&M reports, 200

RR&D reports, 200recall document, 134reference model

corporate document, 68general, 68manufacturing, 68

reference models, 59

377

Index

registration form, 87custom types, 89types, 87

Regulatory domainupdated implementation, 69

regulatory submissions, 259Release Pending

configuring as final state, 202roles, 18, 29

administrators, 20approvers, 20auditors, 21authors, 22contributors, 23controlled printers, 28coordinators, 24custom, 52extend, 52external trial participants, 243global external participants, 28inspectors, 29investigators, 29managers, 27QO approvers, 25quality check, 29readers, 25reviewers, 26

RSA security providersdisable, 333myInsight reports, 333

SSDK

DFS, 329Java Client Library, 330overview, 329web services integration, 329

search criteria, 236security, 159

folder, 168granular, 170regulatory activity package, 173regulatory application registration

form, 171regulatory submissions, 170submission document, 175submission folders, 174submission registration form, 172submission subfolders, 174

servicesrequired, 355

solution typesadd, 57create, 58modify, 57

special naming conventions, 115SSV reports, 200standard reference model

extend, 71submission

filestore, 303submission history XML file, 262submissions

granular security, 170submit change request for approval, 136

Ttmf

dynamic access control, 168external user registration, 169role-based, 168

TMF access control groups, 326TMF admin tool, 322

delete, 327examine, 323external users, 323install, 323purge, 327refresh, 326repair, 323

TMF reference modelimplementation, 66

TMF reports, 200to be read recipients, 133tracing

enable, 349troubleshooting, 345, 355

Uunderstanding

user roles, 29US regional 2.3 eCTD format

extending SSV, 290user groups

cross functional, 36, 41, 44cross-functional, 31external trial participants, 33

378

Index

Reporting, 32, 37, 41, 44User Groups

correspondence, 43user roles

external trial participants, 32utility

integrity check, 319migration, 319

Vviewer widget URLs

configuring, 305viewing dashboards, 200virtual documents

configuring, 215creating, 218CSR copy, 220D2 configurations, 216installing, 215review and approval, 221template approval, 217versioning, 222

Wweb server settings

D2 caching, 338JMS configuration, 338

welcome page, 194workflow, 129

attributes, 143configure, 141diagrams, 129roles, 129

workflowscontent template, 140expiry review (control category 2), 139for collaborative editing, 130

modifying messages, 143periodic review (control category

1), 132recall, 134send to TBR distribution, 133submit change request for

approval, 136submit change request for review and

approval, 135submit for approval (control category

1), 131submit for approval (control category

2), 138submit for delegated approval (control

category 3), 140submit for review (control category

3), 139submit for review and approve (control

category 1), 130submit for review and approve (control

category 2), 136submit for review-format approval

(control category 2), 137withdraw document (control category

1), 133workspace, 177

tasks, 177views, 177

workspace groups, 181workspace views

workspace roles, 189

XXML metadata extraction, 281

value-mapping, 289XML viewer

update, 313

379

OpenText Documentum for LifeSciences...LegalNotice...

Documents

Transcript of OpenText Documentum for LifeSciences...LegalNotice...