Users Requirements Document - · PDF filePocket EDMS© - Pocket eTMF© Requirements Document Page 3 of 43 © 2017 Drug Information Association All Rights Reserved 1. Document Introduction

Pocket EDMS© - Pocket eTMF© Requirements Document

Page 1 of 43

© 2017 Drug Information Association All Rights Reserved

URS Users, System and Regulatory Requirements

Specifications Document

Date: 11 May, 2017

Revision History

Version Date Author(s) Description

Version 1.0 01-Feb-2016 Dimitri Stamatiadis

Steve Scribner

Draft

Version 2.0 03-Feb-2016 Dimitri Stamatiadis

Steve Scribner

For comments

Version 3.0 07-Mar-2016 Dimitri Stamatiadis

Steve Scribner

Incorporates user's comments


Steve Scribner

Incorporates user's comments from round 2

Version 5.0 21-Sep-2016 Dimitri Stamatiadis

Steve Scribner

Incorporates user's comments


Steve Scribner

Scientific Archivists Group (SAG): http://www.sagroup.org.uk/

GCP special interest groups (SIGs): http://www.sagroup.org.uk/sighome/sig-gcp

Addition of the eTMF section

Version 7.0 11-May-2017 Dimitri Stamatiadis

Steve Scribner

Reorder items (mandatory /optional)

http://www.sagroup.org.uk/

http://www.sagroup.org.uk/sighome/sig-gcp


Page 2 of 43


Table of Contents 1. Document Introduction ....................................................................................................... 3 2. Requirements ..................................................................................................................... 3

2.1 Legal and Regulated Environment .......................................................................... 4 2.2 EDM User Requirements ........................................................................................ 4

2.2.1 Document Repository ............................................................................... 4 2.2.2 Document Creation/Modification ............................................................... 6 2.2.3 Management of Complex Documents ....................................................... 8 2.2.4 Document Lifecycles and Lifecycle Configurations ................................... 9 2.2.5 User Role Functionality .......................................................................... 11 2.2.6 External Partner (e.g. CRO/CMO) Access .............................................. 11 2.2.7 Electronic Signature Configuration (if used) ............................................ 12 2.2.8 GMP Documents Management (if used) ................................................. 12 2.2.9 System Requirements ............................................................................ 14

2.3 eTMF Requirements (extension of the model) ...................................................... 15 2.3.1 eTMF-Access ......................................................................................... 15 2.3.2 eTMF-Architecture .................................................................................. 15 2.3.3 eTMF-Document Lifecycle ...................................................................... 16 2.3.4 eTMF-Integration .................................................................................... 16 2.3.5 eTMF-Metadata ...................................................................................... 16 2.3.6 eTMF-Permissions ................................................................................. 17 2.3.7 eTMF-Reports ........................................................................................ 19 2.3.8 eTMF-System ......................................................................................... 20 2.3.9 eTMF-Validation ..................................................................................... 21 2.3.10 eTMF-Workflow ...................................................................................... 21

2.4 Implementation, Validation, and Use of the System .............................................. 24 2.4.1 Data Migration Requirements ................................................................. 24 2.4.2 Quality/Regulatory Requirements ........................................................... 25 2.4.3 Security requirements............................................................................. 28 2.4.4 User Training .......................................................................................... 29

3. References ....................................................................................................................... 30 4. Appendix A ― EDMS Roles ............................................................................................. 31 5. Appendix B – Monitor document status and information ................................................... 33 6. Appendix D - Workflow types............................................................................................ 34 7. Appendix E - Document Process (Examples) ................................................................... 35

7.1 Document Authoring workflow .............................................................................. 36 7.2 Review / Approval workflow .................................................................................. 37 7.3 Status Change workflow ....................................................................................... 38

8. Appendix F ― Lifecycle Specifics ..................................................................................... 39 8.1 Lifecycle................................................................................................................ 39

9. Appendix G – Glossary..................................................................................................... 41


Page 3 of 43


1. Document Introduction

This document provides detailed user, system, and quality/regulatory requirements for implementing a compliant EDMS for small organizations and, as such, serves as a baseline for setting up a "turnkey" system that can be implemented requiring no further changes by small size companies12.

Many commercially available software packages may be able to fulfill and surpass the Pocket EDMS requirements described in this document. We recognize that most companies will want to realize additional advantages that may be considered less tangible, such as ease of use, effort for implementation or flexibility. However, we have chosen the requirements in this URS as necessary for the intended purpose. Each vendor may want to demonstrate their solution and show their desirable characteristics, but we do not require these features because they are difficult to measure or compare except by individual perception. Cost is a key element for small size companies and is a very tangible factor. It is highly recommended that vendors price the packages based on the elemental needs of the sponsor as defined by these requirements as critical to the sponsor’s objectives.

2. Requirements

Areas of requirements are separately addressed in the sections to follow.

Requirements comply with the following principles:

Technical requirements are testable and verifiable.

Procedural requirements will necessitate the development of procedures to be used for implementation and adoption, and will be adapted by each company separately. Nevertheless, they will be required for successful implementation.

All requirements are clear enough for immediate implementation.

Each requirement is relevant to the business problems.

The collective requirements are complete in the sense that if the product satisfies the requirements, it will be acceptable as a commercially available solution for immediate implementation.

Section 2.2 applies to functionality in EDM software packages. Those packages that fulfill all the mandatory requirements in this section will qualify for Pocket EDMS specifications.

Section 2.3 is dedicated to Trial Master File functionality. Those packages that fulfill all the mandatory requirements in this section will qualify for Pocket eTMF specifications.

Section 2.4 contains a mix of system and procedural requirements ensuring regulatory and security compliance to the system leading to the full implementation of a validated EDMS based on Pocket EDMS specifications.


Page 4 of 43


2.1 Legal and Regulated Environment

The system must be set up and operated in such a way that it meets all current GxP, 21 CFR part 113 and eCTD requirements.

2.2 EDM User Requirements

The following sections detail the user requirements for EDMS. Other functions such as publishing, eCTD compilation or RIM are outside of the scope of this document.

Note: Mandatory requirements are numbered bold and optional ones are italics. Requirements that are optional for TMF repositories are marked.

2.2.1 Document Repository

ID No. Description

Mandatory

EDM-1.1 The system shall require minimal to no client specific deployment and provide real time online electronic access for internal and approved external users

EDM-1.2 The repository shall store and retrieve objects, which may be any container of content (e.g. documents, visuals, sound, or multimedia)

EDM-1.3 Objects in the repository shall be characterized by attributes (properties about the document, also known as "metadata")4. Whenever applicable, the system must have the ability to verify attribute values against controlled vocabularies (internal authoritative sources or external standards).

EDM-1.4 Remote access must provide full systems functionality irrespective of nature and performance of connection.

EDM-1.5 The system must control access by uniquely identifying authorized users by password or biometric identification.

EDM-1.6 A user must be able to navigate and locate documents with the use of any method such as filtering, sorting and searching on attributes and full-text content or by a visual representation of the repository (e.g. cabinet/ folder hierarchy).

EDM-1.7 The user's local date and time must be displayed. Date display format must be configurable by the users.

EDM-1.8 When browsing, the system shall display a document’s current lifecycle state. A user with access to a document must have the ability to view the following information about this document: status, versions, relationships, content, audit trail, messages, permissions and available renditions and other properties such as location if available (see also Appendix B).


Page 5 of 43


ID No. Description

EDM-1.9 The system must have the ability to display the audit trail for a document upon request. The audit trail must display system date and time (UTC, see also SYS-3), be immutable, human readable, and exportable (PDF, excel or text file).

EDM-1-10 In compound documents, and in published output stored in the repository, hyperlinks may be used to connect or relate one document to another. These hyperlinks must be preserved and remain functional within the repository.

EDM-1.11 The system must be able to generate watermarks displaying information about the document (e.g. date printed)

EDM-1.12 Optional for TMF

A web-link (a hyperlink sent from one user to another that opens a document) must allow access to the document’s current version (default), contingent on the user's privileges.

EDM-1.13

Optional for TMF

The system must be able to create and retain relationships as needed between documents as - "Related To" (e.g. translations).

EDM-1.14

Optional for TMF

The system must be able to create PDF renditions that meet PDF standards required by agencies around the world (e.g. see eCTD guidance, April 2003 and FDA PDF Specifications, September 2014)5

EDM-1.15

Optional for TMF

The rendering engine must embed all fonts used in the editable document. If a Word document contains fonts that are not available during PDF rendering, the system must generate an error message rather than substitute fonts.

Optional

EDM-1.16 The architecture of the repository should follow the EDM Reference Models including submissions, GMP, Labeling and TMF. QMS documentation and SOPs should be structured according to company policies.

EDM-1.17 Access using a mobile device should have full systems functionality.

EDM-1.18 The system should automate the maintenance of access control and groups.

EDM-1.19 The system should provide full-text search capability.

EDM-1.20 The login page should be able to display important system messages (e.g., if the system goes down).

EDM-1.21 The system should have the capacity to send notifications via email. A user may configure the types of notifications to receive (e.g. for review, approval or status change).


Page 6 of 43


2.2.2 Document Creation/Modification

ID No. Description

Mandatory

EDM-2.1 Users shall be defined as performing one or more roles with the same User ID and in a single login session (Appendix A for definitions of roles)

EDM-2.2 Users in applicable roles shall be able to create or import documents.

EDM-2.3 Users shall be able to import or export documents either individually or in a batch.

EDM-2.4 The system must be able to store templates. When creating a document, the user will be able to:

Start with a blank document

Select a template from a dropdown list or

Use an approved document as a starting template.

EDM-2.5 When creating or importing a document, some attributes may be automatically populated based on pre-defined rules. A user with applicable permissions must be able to access document attributes and enter/modify attribute values, except for auto-generated numbers.

EDM-2.6 For entering an attribute that uses values provided by an authoritative source (see EDM-1.3), a search option must be provided (e.g. drop-down list).


Page 7 of 43


ID No. Description

Optional

EDM-2.7

For TMF repositories see section 2.3

For EDM Reference Model repository: When creating or importing documents, users must classify the documents according to a domain (e.g. Clinical), group (e.g. summaries), sub-group (e.g. Clinical Summaries) and artifact name (e.g. Summary of Clinical Efficacy). These four elements define a document type in the EDM reference model (an extract of the model is shown below).

(not applicable for stand-alone eTMF systems)

EDM-2.8 The user should be able to access a definition of the available selections using the Help function.

EDM-2.9 The system should be able to auto-classify documents based on attribute values. The attributes are specific to each document type.

EDM-2.10 The system should support collaborative authoring either intrinsically or through secure link to third-party tools (e.g. Please Review)

Domain

Group

Subgroup

Artifact

Group

Artifact Artifact

Subgroup


Page 8 of 43


2.2.3 Management of Complex Documents

Complex document features are not mandatory for stand-alone eTMF solutions.

ID No. Description

EDM-3.1 The system must be able to handle complex documents. Complex documents are defined as an outline with nodes that link to individual documents and/or other complex documents. When published, all nodes in the outline will be populated using the linked content.

EDM-3.2 The complex document outline must support nodes that have not yet been linked (placeholders). Published output will identify the placeholder.

EDM-3.3 Complex documents must be managed in the same way as simple documents (with metadata, lifecycle, workflows, versioning etc.)

EDM-3.4 Complex documents may contain elements nested to any depth.


Page 9 of 43


2.2.4 Document Lifecycles and Lifecycle Configurations

See section 2.3.10 for specific authoring and lifecycle rules for TMF.

ID No. Description

Mandatory

EDM-4.1 After a document is created or imported, the document will enter and progress through a lifecycle, which may vary depending on document type. The system must have the flexibility to define multiple life cycles and/or workflows based upon business needs. A lifecycle can be managed either by the system or by procedures except when e-signature is involved. The lifecycle depicted here is a typical example.

EDM-4.2 A new document created in the system will always start as a minor version of 0.1. The system must ensure incremental creation of versions each time the document is saved in the system (check-in).

EDM-4.3 The user must not be able to save a document as the same version.

EDM-4.4 The owner may set the status of an imported document depending on company rules (e.g. import as status = "For Approval"). In this case, scanned documents will require a QC before being promoted to “Approved”.

EDM-4.5 If all required Approvers of a document approve the document, the system will automatically promote the document from the "For Approval" state to the "Approved" state and transfer ownership of the document to the system.

EDM-4.6 A document will advance to a major version (for example, 1.0) upon entering the "Approved" state.

DRAFT

OBSOLETE CANCELLED

APPROVED

SUPERSEDED

Status Changed manually

(Change Status)

DRAFT

Edit

Workflow

For Edit

REVIEWED

Status Changed automatically

(Workflows)

Approval / eSignature

Workflow

For Approval For eSignature

Review

Workflow

For Review

REVIEWED

EFFECTIVE

ARCHIVED


Page 10 of 43


ID No. Description

EDM-4.7 An option must exist for all previous minor versions and review annotations to be deleted based upon a configurable trigger (e.g. promotion to the Approved state). This option must be selectable by document type.

EDM-4.8 Even in case of system-controlled lifecycles, a Document Coordinator must have the ability to “Power-Promote” a document through more than one lifecycle step at a time (e.g. promote a document directly from draft to effective).

EDM-4.9 The change of a document from one lifecycle state to another must be

tracked in the audit trail.

Optional

EDM-4.10 When using system-controlled workflows, the system should automatically verify that all properties required by company rules are populated as entry criteria to the "For Approval" state.

EDM-4.11 After a document has reached the "For Approval" state and Approvers have been selected, all selected Approvers should receive a task to either approve or reject the document. If applicable, each Approver will be required to provide an electronic signature (see section 2.4.2 for details on e-signatures). An option must be available for the first available Approver to fulfill the action and the task be deleted from other recipients.

DRAFT

OBSOLETE CANCELLED

APPROVED

SUPERSEDED

Status changed manually

(Change Status)

DRAFT

REVIEWED

Review

Workflow

For Review

Edit

Workflow

For Edit

Approval / eSignature

Workflow

For Approval For eSignature

Status changed automatically

(Workflows)

EFFECTIVE


Page 11 of 43


2.2.5 User Role Functionality

The use of all the roles described below is not mandatory. A company may choose to only use some of them or to merge several roles into one depending on company size and internal processes.

ID No. Description

EDM-5.1 For each document lifecycle state, user functionality must be limited by user role. The following roles must be supported by the system (see Appendix A ― EDMS Roles for details).

Structural roles

Systems Administrator (IT): Can make system changes under change control with the business

Business Administrator: Can apply changes in the system

Document Coordinator: Has enhanced control over documents

Author/Contributor: Has read/write access to documents

Consumer/Reader: Has read access only to approved documents

Auditor/Inspector: Has read access only to specific approved documents (TMF-specific role)

Procedural roles (during workflows)

Owner: Has control of own documents until the documents reach the "Approved" state

Reviewer: Has only read and review and annotate access to a document

Approver: Has only read and approve / reject access to a document

External partner: Has role-based access to specific documents

2.2.6 External Partner (e.g. CRO/CMO) Access

ID No. Description

EDM-6.1 An external partner must have access to only certain documents. The system must allow the configuration of external partner access individually or by groups.

EDM-6.2 The functionality available to an external partner must be role-based.

EDM-6.3 For documents that an external partner creates, an attribute of Partner ID should be automatically populated with the applicable value.


Page 12 of 43


2.2.7 Electronic Signature Configuration (if used)

ID No. Description

EDM-7.1 e-Signatures must be immutably linked to the signed document (see section 2.4.2).

EDM-7.2 If used, e-Signatures must be applied at the "For Approval" state in a Lifecycle.

EDM-7.3 User authentication must be done at the time of signing even though the user is already logged in the system in one of the following ways:

By entering the user ID and password or

By entering the user ID and a biometric authentication, if available (e.g. mobile devices).

EDM-7.4 e-Signature must display a justification prior to signing (text options will be configurable)

EDM-7-5 A physical manifestation of the e-Signature must be generated by the system for each approver and added to the document (signature page, see also P11-17)

EDM 7-6 Electronic signatures must be unique to each signer and may not be reassigned.

2.2.8 GMP Documents Management (if used)

These features are not applicable for stand-alone eTMF solutions.

ID No. Description

GMP Document Lifecycle

EDM-8.1 For various GMP document types, the lifecycle will include an additional step (after "Approved") leading to "Effective". Upon entering the "Effective" state, this version number will not change.

EDM-8.2 For a GMP document in the "Draft" state, an author will be able to set the Effective Date.

EDM-8.3 For a GMP document in the "Approved" state, a Document Coordinator will be able to modify/set the Effective Date.

EDM-8.4 GMP document types may be configured for periodic review as required by each company's policies.

EDM-8.5 A log of all controlled-print documents, including the person requesting them, will be maintained and updated as the printed batch is retired or destroyed.


Page 13 of 43


ID No. Description

Change Request and Change Notice

EDM-8.6 For a document in the Approved or Effective state, any Author can create a Change Request.

Change Requests will be automatically numbered as CR-# where # has no limit.

An Approved or Effective document can optionally be associated with a Change Request via a Change Request Relationship.

A Change Request may cover multiple documents and a relationship would be created to each.

Any Author (or higher) will be able to assign approvers and initiate the approval process.

The assigned approver(s) will be able to approve or to reject the Change Request.

EDM-8.7 For an Approved or Effective document, any Author can create a Change Notice.

Change Notices will be automatically numbered as CN-# where # has no limit.

A new version of the Approved or Effective document(s) can optionally be associated with a Change Notice.

Any Author (or higher) will be able to assign approvers and initiate the approval process.

The assigned approver(s) will be able to approve or reject the Change Notice.

If a Change Notice has attached documents, those documents will also move to the "Approved" state when the Change Notice is approved.

Change Request and Change Notice

EDM-8.8 For certain GMP document types (e.g. SOP) in the Effective state, the system must generate a printing watermark that will contain “Only Valid on DD-MMM-YYYY”, which is the current date.

EDM-8.9 Print-controlled documents (GMP) that are in a state other than “effective” will be printed with the current state watermarked across the page.

EDM-8.10 Print-controlled documents (GMP) will be printed with a date range in the margin, as specified by procedures.


Page 14 of 43


2.2.9 System Requirements

ID No. Description

EDM-9.1 Processes and procedures will be in place to ensure that system recovery from a disaster can occur. The system must be able to recover from a failure within a reasonable time to preserve business continuity.

EDM-9.2 The system vendor shall provide a complete disaster recovery plan including recovery point and recovery time objectives (RTO/RPO)

EDM-9.3 System performance must be trackable and not exceed reasonable limits for specific functions that have a major impact on usability. Specific tolerances are not suggested here but should be determined by the business organization of the sponsor.

EDM-9.4 Coordinated Universal Time (UTC) is the recommended global time standard in a format of HH:MM:SS. For the date format, see EDM-1.6.

EDM-9.5 The system will be able to accommodate a minimum of 20 concurrent users to address the needs of very small Pharma. For larger organizations, the sponsor may require greater capacity and scalability.

EDM-9.6 The system must provide capabilities (APIs) for integration with external applications.

EDM-9.7 The system shall ensure that documents can be readily recovered from failed or interrupted processes without loss of integrity

EDM-9.8 The system shall provide high availability and fail over for business continuity


Page 15 of 43


2.3 eTMF Requirements (extension of the model)

This section details user requirements that are specific to eTMF managing systems. In the event of a combined implementation of Regulatory and eTMF management systems, the eTMF portion shall comply with the requirements listed in this section, above and beyond the ones listed in section 2.2.

2.3.1 eTMF-Access

ID No. Description

TMF-1.1 The eTMF shall require minimal to no client specific deployment and provide real time online electronic access for approved third party users6

Optional

TMF-1.2 The eTMF must be suitable for use by a person with red/green color blindness

TMF-1.3 The eTMF shall provide a preview of each document in a viewing pane

2.3.2 eTMF-Architecture

ID No. Description

Mandatory

TMF-2.1 The eTMF shall allow additional sites to be added once a study is underway

TMF-2.2 The eTMF system shall provide a complete TMF structure based on the TMF reference model

NOTE: If TMF alone, this supersedes EDM-1.3.

TMF-2.3 The eTMF shall provide a mechanism for modifying the out-of-the-box TMF structures/templates via configuration

Optional

TMF-2.4 The eTMF shall allow to enter a link to a document existing in another source. When selecting the link from within the eTMF the document will open from the source system.

NOTE: if archiving occurs to a specific archive system the linked content should also be archived with the study TMF.

TMF-2.5 The eTMF shall allow storing above-study level content and allow this content to be associated to multiple studies.

NOTE: if archiving occurs to a specific archive system a copy of the shared content should also be archived with the study TMF.

TMF-2.6 The eTMF shall allow for multiple vendors to be designated at the study, country and site levels


Page 16 of 43


ID No. Description

TMF-2.7 The eTMF shall allow the ability to provide for expected content in a template; this expected content can then be applied to the eTMF based on business requirements (e.g. based on country/local/phase/therapeutic area requirements)

TMF-2.8 The eTMF shall be flexible enough to accommodate disparate TMF structures that are used by different Sponsors or CROs

2.3.3 eTMF-Document Lifecycle

ID No. Description

TMF-3.1 The eTMF shall allow for specific business rules to be created at each lifecycle level

TMF-3.2 The eTMF shall enable the capture of custody information for documents transferred outside the system

Optional

TMF-3.3 The eTMF shall allow studies and sites to be marked as active or inactive

2.3.4 eTMF-Integration

ID No. Description

TMF-4.1 The eTMF shall allow documents to be dragged and dropped to pre-create document placeholders

TMF-4.2 The eTMF shall allow for the addition and maintenance of investigator sites within the eTMF to be managed from an integrated Clinical Trial Management System (CTMS)

TMF-4.3 The eTMF shall allow for the importation of data from a CTMS pertaining to studies, sites, investigators, milestones

TMF-4.4 The eTMF shall provide capability for integration with the Microsoft Office suite of programs (e.g. MS Word, MS Excel, MS PowerPoint and MS Outlook etc.)

2.3.5 eTMF-Metadata

ID No. Description

Mandatory

TMF-5.1 The eTMF shall allow documents to be marked as reconciled as per company standards

TMF-5.2 The eTMF shall display site identifiers that include country, site ID and principal investigator name for easy identification


Page 17 of 43


ID No. Description

TMF-5.3 The eTMF shall enforce use of a fixed metadata schema that cannot be altered except by an authorized systems administrator7

TMF-5.4 The eTMF shall enable investigator sites to be linked to a specific study and multiple studies to be linked to a specific investigator8

TMF-5.5 The eTMF shall present content and metadata side-by-side for document indexing

TMF-5.6 The eTMF shall have the ability to utilize a standard library of metadata values based on pre-defined client-maintained data dictionaries

Optional

TMF-5.7 The eTMF should allow members of the study team to view annotations created by other members, based on role-based security and permissions granted per company standards8

TMF-5.8 The eTMF should have the ability to capture integrity and technical characteristics of documents based on their type and name each document according to approved company standards, so that documents can be accessed, reviewed, manipulated, re-used and approved in native format

TMF-5.9 The eTMF should have the ability to display information about a document's status, including workflow task and recipient(s), whenever the document is displayed

TMF-5.10 The eTMF should link classification metadata to retention criteria8

2.3.6 eTMF-Permissions

ID No. Description

Mandatory

TMF-6.1 The eTMF must provide the ability to host unblinded data with proper security and controls in place

TMF-6.2 The eTMF must allow only the authorized users access to content and/or folders within their functional area based on the associated document's metadata

TMF-6.3 The eTMF must allow only authorized users access to content and/or folders within their functional area based on study, country and site level

TMF-6.4 The eTMF must allow only an authorized user to delete documents

TMF-6.5 The eTMF must allow only authorized users to edit the security matrix


Page 18 of 43


ID No. Description

TMF-6.6 The eTMF must limit all export mechanisms to specific authorized users\ to perform them

TMF-6.7 The eTMF must limit the information that the auditor/inspector can see to that required for inspection purposes

TMF-6.8 The eTMF must not delegate any task to a user who does not have the authority to complete it

TMF-6.9 The eTMF must prevent modifications to study documents once the study is locked

TMF-6.10 The eTMF must prevent multiple members of the study team from editing document content concurrently e.g. check-in/check-out

TMF-6.11 The eTMF must provide an out of the box auditor/inspector role

TMF-6.12 The eTMF must restrict access to the Archivist for studies that have been archived

TMF-6.13 The eTMF must restrict who can create content at the doc type level

TMF-6.14 The eTMF must set access rules at the document type level7

Optional

TMF-6.15 The eTMF should allow a user to view documents that have and have not been reconciled for a specific site

TMF-6.16 The eTMF should allow a user to view summary information, including coming due and past due documents, for their favorite and recent sites

TMF-6.17 The eTMF should allow an authorized user (including any workflow participant) to view the list of workflow participants and their status (whether they have completed their task)

TMF-6.18 The eTMF should allow authorized users to create and view study level announcements

TMF-6.19 The eTMF should allow a user to delete a document uploaded erroneously prior to sending to its next lifecycle state

TMF-6.20 The eTMF should allow all roles to see but not modify or delete other users annotations to documents

TMF-6.21 The eTMF should allow Authors / Contributors to append annotations to documents

TMF-6.22 The eTMF should provide a mechanism for reviewing the documents accessed by an authority during an inspection


Page 19 of 43


2.3.7 eTMF-Reports

ID No. Description

Mandatory

TMF-7.1 The eTMF shall allow multiple values to be chosen for report criteria e.g. Phase II and III studies, multiple countries

TMF-7.2 The eTMF shall ensure that access controls and security requirements are met through the employment of reporting tools

TMF-7.3 The eTMF shall ensure that workflow management can be monitored through the employment of appropriate reporting tools

TMF-7.4 The eTMF shall provide the ability to report on the quality of an ongoing or completed trial, or on quality across trials

TMF-7.5 The eTMF shall provide the ability to report on the timeliness of processing within the eTMF

TMF-7.6 The eTMF shall report on specific quality defects encountered based on quality issues reported during the QC process

Optional

TMF-7.7 The eTMF should allow users to save and re-use facet values across studies e.g. create and save a filter for missing, overdue 1572s

TMF-7.8 The eTMF should allow an organization to set target thresholds for key performance indicators such as completeness, timeliness, and quality

TMF-7.9 The eTMF should allow authorized users to create reports based on user-selectable report criteria

TMF-7.10 The eTMF should allow drilldown to explore potential issues and problems related to key performance indicators

TMF-7.11 The eTMF should allow members of the study team to easily export reports to CSV and Excel files

TMF-7.12 The eTMF should allow results to be filtered or grouped by CRO partner.

TMF-7.13 The eTMF should allow results to be grouped based on important metadata e.g. study, country, site, zone, etc.

TMF-7.14 The eTMF should allow users to save report criteria for re-use

TMF-7.15 The eTMF should have the ability to report on expiration dates e.g. CVs

TMF-7.16 The eTMF should have the ability to track documents not yet received by investigator sites e.g. planned vs. actual for study start-up progress


Page 20 of 43


ID No. Description

TMF-7.17 The eTMF should have the ability to track on quality control efforts e.g. which documents have (not) been subject to QC

TMF-7.18 The eTMF should produce impact analysis reports based on document relationships e.g. which documents are associated to other documents

TMF-7.19 The eTMF should produce reports that include details about the report criteria e.g. who ran the report and when, the criteria used to create the report

TMF-7.20 The eTMF should provide a home page for each study provided to summarize status, details and activities related to the study

TMF-7.21 The eTMF should provide a report that summarizes the documents that are coming due or past due based on a specific date, which can be used to prepare for an inspection or audit

TMF-7.22 The eTMF should provide functionality to determine when a study is ready to lock e.g. draft documents, no active workflows, no missing essential documents

TMF-7.23 The eTMF should provide the user with information on study and site milestones

TMF-7.24 The eTMF should produce real time status reports

TMF-7.25 The eTMF should provide reports to allow the draft manifest of documents to be reviewed before placeholders are created

2.3.8 eTMF-System

ID No. Description

Mandatory

TMF-8.1 The eTMF shall have the ability to render documents within the system in non-modifiable PDF or PDF/A format

TMF-8.2 The eTMF shall permit business and operations scalability by being flexible with but not limited to amount of users, structure, integrations with other systems, and not impacting performance

TMF-8.3 The eTMF shall provide for the application of event-based retention trigger dates at appropriate times and in accordance with company retention policies3

Optional

TMF-8.4 The eTMF should include an integrated scanning mechanism or the ability to add an integrated scanning mechanism

TMF-8.5 The eTMF should enable hyperlinked notification of specified events including documents required for specified milestones e.g. due, overdue, "regulatory green light", drug shipment


Page 21 of 43


ID No. Description

TMF-8.6 The eTMF should only allow locking of a study when all designated lock requirements have been met.

TMF-8.7 The eTMF should provide the ability to identify anticipated documents related to a milestone or event and produce a report of what documents will be required in eTMF as of the milestone/event (i.e. inspection date (a future date) to assist in preparing for inspection)

TMF-8.8 The eTMF should provide for the generation of transmittals/cover sheets for use in scanning

TMF-8.9 The eTMF should provide functionality to manage replacement documents upon expiration of a previous version.

TMF-8.10 The eTMF should support the large scale import and classification of scanned documents

2.3.9 eTMF-Validation

ID No. Description

TMF-9.1 The eTMF shall be developed and supported as a quality system (including software development life cycle documentation) available for audit by the customers at any time

2.3.10 eTMF-Workflow

ID No. Description

Mandatory

TMF-10.1 The eTMF shall prevent overwriting of documents, but enable users to contribute to the document collaboratively

TMF-10.2 The eTMF shall allow a user performing QC to correct metadata on a document and re-submit the document for additional QC

TMF-10.3 The eTMF shall allow a user performing QC to return a document that does not pass QC to the originator or other qualified user

TMF-10.4 The eTMF shall allow a workflow initiator to disallow delegation or automatically assign if recipient is out of the office

TMF-10.5 The eTMF shall allow an expiry date to be assigned to a document if the document type has been configured as expiring

TMF-10.6 The eTMF shall allow comments / annotations to be attached to documents, digital images and video files contemporaneously by auditors/inspectors during an audit/inspection without changing document content7


Page 22 of 43


ID No. Description

TMF-10.7 The eTMF shall allow document metadata to be assigned to content8

TMF-10.8 The eTMF shall allow for the assignment of unique document metadata based upon the type of content created7

TMF-10.9 The eTMF shall allow internal and external members of the study team to apply annotations to a final document

TMF-10.10 The eTMF shall automatically assign each document with a unique document identifier on CREATION, capture or ingestion7

TMF-10.11 The eTMF shall automatically assign each document with metadata inherited from the hierarchical eTMF structure on capture or ingestion7

TMF-10.12 The eTMF shall ensure that each revision of a document is automatically saved as a new version8

TMF-10.13 The eTMF shall ensure the signature page includes the full name of each approver, meaning of signature, and date and time of signature3

TMF-10.14 The eTMF shall prevent the upload of password protected files3

Optional

TMF-10.15 The eTMF should alert a user if unprocessed tasks have been present in his or her inbox for more than a user defined period

TMF-10.16 The eTMF should allow a single-instance document to be saved against multiple placeholders e.g. Investigator Brochure7

TMF-10.17 The eTMF should allow a user to view the progress of documents in a workflow

TMF-10.18 The eTMF should allow an authorized user to mark a final document as not viewable for Inspectors due to the document needing to be obsoleted because of being uploaded incorrectly

TMF-10.19 The eTMF should allow authorized users to recall or terminate a workflow and associated tasks

TMF-10.20 The eTMF should disallow comments / annotations to be attached to documents, digital images and video files contemporaneously by general users

TMF-10.21 The eTMF should allow document checkout to be cancelled by an authorised user

TMF-10.22 The eTMF should allow document metadata to be changed during content editing, versioning and annotation

TMF-10.23 The eTMF should allow documents be checked-out and authored by internal and external members of the study team


Page 23 of 43


ID No. Description

TMF-10.24 The eTMF should allow for roles be configured within workflows in order to drive business rules e.g. review/approval

TMF-10.25 The eTMF should allow internal and external members of the study team to review, edit, reply and resolve edits/revisions

TMF-10.26 The eTMF should allow reviewers to enter free text comments when completing a review task

TMF-10.27 The eTMF should allow study, country and site metadata to be assigned to bulk uploaded documents

TMF-10.28 The eTMF should allow the ability to set default reviewers/approvers based on applied business rules

TMF-10.29 The eTMF should allow the delegation of workflow tasks unless the workflow initiator disallowed delegation

TMF-10.30 The eTMF should allow the placement of content packages/binders within an existing content package/binder (nested binders)7

TMF-10.31 The eTMF should display the user's meaning associated with the signature for a task and require the entry of a valid user name and password for approval3

TMF-10.32 The eTMF should enable manual workflow initiation for specified documents

TMF-10.33 The eTMF should ensure if a document is finalized that has an earlier final version, that version shall become superseded and be potentially identified as obsolete

TMF-10.34 The eTMF should properly handle imported document versions that are received "out of order" (i.e., a later version is uploaded before an earlier version) by ensuring that the version with the latest document date is considered the current version

TMF-10.35 The eTMF should provide a group inbox for role / department based tasks (e.g. QC) and direct all tasks to the group inbox rather than requiring a specific task recipient to be named

TMF-10.36 The eTMF should provide a workflow initiator to select from preconfigured parallel or serial workflow processes that apply to the document

TMF-10.37 The eTMF should provide the ability for a user to set an out-of-office for workflow assignments to be re-routed in their absence. A Business Administrator also can manage the out-of-office mechanism.


Page 24 of 43


ID No. Description

TMF-10.38 The eTMF should provide each user with a mechanism to allow them to see details of tasks in their inbox, e.g., summary of the number and description of tasks in their inbox, containing hyperlinks to each task.

TMF-10.39 The eTMF should provide a way to identify anticipated documents on a study-by-study basis for all levels of content. This will need to be managed on an ongoing basis and have the ability to be modified depending on study events.

TMF-10.40 The eTMF should provide for both individual and group inboxes which allow searching and sorting

TMF-10.41 The eTMF should require a user to choose one or more failure codes (e.g. rejection reasons) for any document requiring rework

2.4 Implementation, Validation, and Use of the System

The following sections are related to the implementation, validation, and use of the system. They do not only constitute requirements for the software vendors but have been included in the present document in order to provide a complete set of requirements for the successful implementation of a "Pocket EDMS" by any small sized organization.

2.4.1 Data Migration Requirements

The term "Data Migration" applies to an automated or semi-automated transfer of records from a previously used and validated EDMS into the current system. Data may not be automatically transferred from a non-validated system into the EDMS without confirmation of the records by a trained user of the system (validation rules). For non-validated sources, the import function must be associated with a QC step.

ID No. Description

MIG-1 Document content and their associated attributes (metadata) must be able to be moved from other source repositories to EDMS.

MIG-2 All versions of a document must be able to be migrated. A configurable option to migrate only selected version should also be available. It may be desirable for TMF-only solutions to only migrate the final version of each document, if an authoring process is not supported.

MIG-3 If existing, a document’s audit trails will be migrated from its source system and will be available for viewing in EDMS.

MIG-4 Source document state will be converted to target document state according to a map (by source repository).


Page 25 of 43


ID No. Description

Optional

MIG-5 Migrated documents should be deposited into a location determined by the attributes. If attributes do not exist or are of insufficient quality for the record, manual mapping may be required.

MIG-6 If applicable, during migration, it should be possible to populate a table that maps legacy object ID to new object ID.

MIG-7 Optionally, documents from source repositories that have not been enriched and mapped to EDMS may be assigned to the document group "Legacy".

2.4.2 Quality/Regulatory Requirements

The following requirements not only concern the software system but also the way it is implemented in an organization and were taken from applicable sections9 of the “21 CFR Part 11 Requirements”, hence the “P11-“ designation. It is the responsibility of the sponsor company to ensure the full validation of the system. The software vendor should be able to provide validation-ready documentation (see below P11-01).

ID No. Description

Electronic Record Requirements – System

P11-01 The system must be validated against a documented System Development Lifecycle before being used or after a change that has potential regulatory impact. This must include:

(a) Requirements Specification

(b) Design Document

(c) Testing Documentation

(d) Operating Procedures

The validation should include the following documentation:

(a) Project (Validation) Plan

(b) Risk assessment

(c) Project Summary (Validation) Report

(d) Training Documentation

(e) Change Control Procedure

(f) Data Conversion

(g) Support Plan

(h) Vendor Audit

(i) Traceability Matrix

(j) Installation Qualification (IQ)

(k) Output Qualification (OQ)

(l) Performance Qualification (PQ)

(m) User Acceptance Testing (UAT)

Change requests for the system must be adequately documented via a change request process.


Page 26 of 43


ID No. Description

P11-02 The system must be capable of maintaining accurate records, protecting them from unauthorized deletion, and retrieving them in a timely manner10,11. (For retrieving a document, see SYS-2 (2).)

P11-03 The system must be capable of generating accurate and complete copies of records, to both paper and electronic media, for viewing, copying, or inspection. The system will remain the authoritative source12.

P11-04 The system must include automatic, secure audit trails:

(a) Must be computer-generated, human readable and be immutable

(b) Must include user ID and name

(c) Must include a UTC-based date and time stamp

(d) Must include all user entries/actions that create, modify, or delete electronic records. It may also be desirable to track ‘view’ access.

(e) Must not obscure previously recorded information

(f) Must be retained throughout the e-record life

(g) Should log system administrator activities

(h) Should monitor DBA activities

P11-05 The system must be capable of generating accurate, complete and human readable copies of the audit trail in both paper and non-electronic media.

P11-06 The system must prevent the Audit Trail from being disabled or turned off.

P11-07 The time source should be derived from a reference source for UTC.

P11-08 The system must allow for maintaining historical user access lists.

P11-09 The system must prevent unauthorized users from accessing the system, accessing electronic records, altering an electronic record or electronically signing an electronic record.

P11-10 The system should include a configurable capability of locking out access after a specified time has elapsed. For example, the system will lockout access (timeout) after 60 minutes of inactivity have elapsed.

P11-11 A capacity analysis should be performed to ensure that the system (this includes the software, hardware and operating system) could accommodate any projected record volume.

Electronic Record Requirements – Procedures

P11-12 A written electronic record retention policy must be in place that meets the minimum regulatory or legal requirements.

P11-13 A procedure for maintaining data integrity in case of disaster must be in place (backup and restore).

P11-14 Data archiving and retrieval procedures must be in place.

P11-15 An account management procedure must be in place and include the process for granting, maintaining and removing privileges.

P11-16 Procedures must be in place for how to export records upon Agency request.

P11-17 There must be evidence that persons developing, maintaining and using the system are qualified to do so. Training records for users must be available.


Page 27 of 43


ID No. Description

Electronic and Handwritten Signature Requirements – System

P11-18 The signature must be part of any human-readable manifestation of the e-record.

P11-19 The signature manifestation must be under the same controls as the e-record.

P11-20 Signed electronic records must

(a) Include the printed name of the signer.

(b) Include the date and the time of the signing.

(c) Include the meaning of the signature.

P11-21 Signatures (handwritten and electronic) must be linked to their electronic records. The link between signature (handwritten and electronic) and e-record must break if the e-record changes.

For handwritten signatures, there must be a procedure ensuring that this signature remains valid. For electronic signatures, this should be built into the system.

P11-22 Signatures (handwritten and electronic) must not be deleted, copied or transferred to another document.

P11-23 e-Signatures must employ a minimum of two distinct identification components (e.g. User ID and password).

P11-24 Passwords should be encrypted and unavailable to persons other than their originator.

P11-25 When a series of signings are executed during a single, continuous period of controlled system access, the first signature must include both components; subsequent signatures may include only one.

When a series of signings are not executed during a single, continuous period of controlled system access, every signature must include both components.

Electronic and Handwritten Signature Requirements – Procedures

P11-26 The organization must acknowledge and ensure its understanding that an electronic signature is the legally binding equivalent of a handwritten signature. These are demonstrated by

(a) A procedure acknowledging the legal equivalency of e-signatures

(b) Submission of a Certification letter to the appropriate regulatory authority

(c) Documentation of periodic e-signature training

P11-27 An electronic record procedure must be in place. That procedure must detail the process for delegating electronic signature authority.

P11-28 The company must verify the identity of individuals before assigning electronic signatures. Electronic signatures must be unique to each signer. e-Signatures must be used only by their genuine owners. Electronic signatures must not be reused or reassigned.


Page 28 of 43


2.4.3 Security requirements

The requirements below ensure adequate data security from both a system and a procedural perspective.

ID No. Description

Security Requirements – System

S-01 All data must be handled in the system in accordance to the European Directive 95/46/EC and the decisions of the working party outlined in article 29 of this directive13.

S-02 All computer systems handling regulated information must securely log and retain all security relevant events for as long as the underlying regulated records are retained/archived.

S-03 User IDs must uniquely identify users, and passwords must be maintained by the system as secret information.

S-04

The system must require strong passwords and may display information about the password strength (e.g. color code).

The system must be able to enforce periodic password change as set by company rules. Applications that can accept network authentication can do so (e.g., single sign on).

S-05 The system must use transaction safeguards to prevent unauthorized use of ID/Password.

The system must automatically detect, log, and report unauthorized ID/Password use.

S-06

Information and programs communicated via an untrusted, external network (e.g. the Internet, third-party networks, etc.) should be adequately protected from modification and disclosure (e.g. encryption, digital signatures, checksums/hash totals, etc.).

Security Requirements – Procedures

S-07 Application access levels must be reassessed for appropriateness when job functions change (e.g. transfers) or during organizational changes (e.g., creation or merger of units, departments, etc.).

S-08 Activities of privileged accounts must be logged and reviewed on a periodic basis.

S-09 User IDs must not be shared by users. User IDs used as server-level service accounts are exempt from this control; however, reasonable compensating controls (e.g., such as strong passwords) should be implemented.

S-10 ID/Password combinations must be periodically reviewed, revised, or recalled. User accounts must be disabled upon termination/suspension of the user.

S-11 Where governmental regulations require, written policies and/or procedures must be in place to hold individuals accountable and responsible for actions initiated under their ID or electronic signatures.


Page 29 of 43


ID No. Description

S-12

Users of computerized systems that are supporting regulated applications must have documented education, training, and experience (e.g. college education, professional and internal technical and user-level certifications, etc.) to perform their assigned tasks.

Security Requirements – External Partner Management

S-13

Data confidentiality, integrity, and availability controls must be specifically defined in contracts with third parties. Controls will cover all appropriate physical, personnel, and logical information protection risks based on risk levels. In addition, controls will take into account all prevailing statutory and regulatory requirements.

S-14

Contractual agreements will grant the contracting organization the right to audit the relevant systems within third parties and/or the third parties will commit to having independent, periodic audits performed which the contracting organization will have the right to review.

S-15 Third-party agreements must include a provision for adherence to requisite policies of the contracting organization.

S-16 Third parties must notify the contracting organization of all personnel changes affecting contracting organization.

S-17 Third-party controls must specify roles and responsibilities for destruction or disposal of contracting organization data in accordance with contracting organization’s policy and risk of loss.

S-18 External third parties must have a defined process to issue and respond to intrusion alerts. Provision must be made for notification to the contracting organization for high-risk intrusions/alerts.

S-19

For all external connections, network-monitoring systems should be implemented to monitor changes to critical system files, and to provide detection and alerts of unauthorized file changes (e.g., Tripwire, RealSecure, etc.).

S-20 Personnel other than those employed by the contracting organization must be restricted to the information required to complete the contracted work (e.g. specific products and / or domains).

S-21 Procedures should be in place to verify and document external partner signatures.

S-22 All personnel not employed by the contracting organization who require access to contracting organization’s information resources must have sponsorship from an authorized contracting organization employee.

S-23 Personnel other than those employed by the contracting organization (e.g. vendors, consultants, and contractors) must have at least the same access restrictions to which an internal user is subject.

1

2.4.4 User Training

In order for such system to be validated, appropriate training of the users must be conducted and documented. Training specifics will be captured in a Training Plan.


Page 30 of 43


3. References

1 A Robust Methodological Approach for Replacing Global Electronic Document Management. D. Stamatiadis and S. Scribner. Therapeutic Innovation & Regulatory Science May 2009 vol. 43 no. 3 243-251.

2 NARA, https://www.archives.gov/research/alic/reference/archives-resources/terminology.html

3 Title 21, Food and Drugs Chapter I, Food and Drug Administration Department of Health and Human Services Subchapter A, General Part 11 Electronic Records, Electronic Signatures.

4 Klingler EC, Arizona declares metadata is fair game for open records requests, Litigation News, 29 December 2009

5 eCTD guidance, April 2003 and FDA PDF Specifications, September 2014

6 UK SI 2006:1928 The Medicines for Human Use (Clinical Trials) Amendment Regulations 2006

7 MHRA Grey Guide 2012

8 EU Directive 2005/28/EC

9 Guidance for Industry Part 11, Electronic Records; Electronic Signatures — Scope and Application. August 2003

10 Digital archiving in the pharmaceutical industry, Stamatiadis D, IMJ: pp54-59, July 2005

11 Electronic archiving: a new paradigm, Stamatiadis D, APR 8:5 pp10-16

12 Information Nation, seven keys to information management compliance. R.A. Kahn, Esq and B.T. Blair, AIIM publications, 2004

13 Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data. This directive will be superseded on May 25, 2018 according to the EU General Data Protection Regulation 2016.

https://www.archives.gov/research/alic/reference/archives-resources/terminology.html


Page 31 of 43


4. Appendix A ― EDMS Roles

Structural Roles

Role Functionality

System Administrator

(IT), under change

control from business

1. Create, modify, and delete Dictionary entries.

2. Change owners.

3. Unlock a document.

Business

Administrator

Has enhanced system

access and can set up

the system according to

business needs

1. Create, modify, and delete groups.

2. Create, modify, and delete user accounts.

3. Create, modify, and delete dictionary entries. Includes

permission to create new product-specific entries.

4. Create, modify, and delete templates.

5. Create, modify, and delete workflows.

6. Start, track, redirect, and stop a workflow.

7. Create, modify, and delete ACLs.

8. Manually promote or demote a document.

9. Change document attributes.

10. Create a new draft version from an Approved or Effective

document.


12. Print controlled copies.

13. Reassign a document to a different document type.

14. Create a relationship between any two documents.

Document Coordinator

Coordinates the

management of specific

documents to facilitate

teamwork

1. Manually promote or demote a document.

2. Start, track, redirect, and stop a workflow.

3. Change document attributes.

4. Create, modify, and delete placeholders.

5. Create new draft version from an Approved or Effective

document.


7. Change owner (if current state is Draft, In Review, or For

Approval).


9. Reassign a document to a different document type.


Author / Contributor

Any of the contributing

authors.

1. Create a Change Request.

2. Create a document. Create by using templates or another

approved or effective document as a template.

3. Modify a draft document.

4. Assign attributes.

5. Delete a Draft document.


Page 32 of 43


6. Link a document.

7. Export a document.

8. Import a document.



Consumer

Accesses approved and

effective documents for

business uses

1. Browse documents.

2. View (read) / print Approved or Effective documents.

3. Print controlled copies using approved procedures

External Partner

CRO / CMO

1. Perform all functionality defined by role limited to specific

documents (e.g. by product, study and so on).

Procedural Roles

Role Functionality

Owner

By default the principal

author until the

document reaches the

status of "Approved"

when ownership is

transferred to the

system.

1. Change owner (on own documents only).

2. Initiate a workflow.

3. Promote a document from draft.

4. Create a Change Request.

5. Create and modify a document.

6. Assign attributes.

7. Delete a Draft document.

8. Link a document.

9. Export a document.

10. Import a document.

11. Print controlled copies

Reviewer 1. Review and annotate a document.

Approver

1. Approve a document.

2. Apply electronic signature.

3. Approve a Change Request.

Note: It is desirable that Business Administrator and the Systems Administrator (with the direction from the business) can add users to multiple groups.


Page 33 of 43


5. Appendix B – Monitor document status and information

Description

Each document is associated to a number of Attributes (properties) of which some are system generated and others are linked to business rules.

A user with access to a document must have the ability to view the following information about this document: Properties, status, versions, relationships, content, audit trail, messages, permissions and available renditions. Location is optional based on implementation.

CONTENT

Document properties System Properties

Authors, name of the document, type …

Creation date, object identification, …

View PROPERTIES

View STATUS View RENDITIONS

View CONTENT

View PERMISSIONS

View RELATIONSHIPS

View AUDIT TRAIL View LOCATION View MESSAGES

View VERSIONS

0.1 0.2 1.0 1.1 0.x

Pocket EDMS© Requirements Document

Page 34 of 43


The following appendices are educational and may be used for configuration for implementation as well as for training of users.

6. Appendix D - Workflow types

Workflow Name

Status after Accept

Status after Reject

Document Format circulated

Possible Use

Edit DRAFT DRAFT Native Document Format Used to co-author documents

Review REVIEWED DRAFT Native Format or PDF Used to collect feedback on documents

Periodic Review

APPROVED (EFFECTIVE)

DRAFT PDF Used to assess applicability, decide on the need to update and set next review date

Approval APPROVED DRAFT PDF Used to approve a document when an electronic signature is not needed

e-Signature APPROVED DRAFT PDF Used to approve a document when an electronic signature is needed


Page 35 of 43


7. Appendix E - Document Process (Examples)


Page 36 of 43


7.1 Document Authoring workflow


Page 37 of 43


7.2 Review / Approval workflow


Page 38 of 43


7.3 Status Change workflow


Page 39 of 43


8. Appendix F ― Lifecycle Specifics

8.1 Lifecycle

Definitions of Lifecycle states are provided below. Details on these states are specified in the table that follows.

Draft: Document state and security are set to allow editing, versioning, viewing, and deletion by owner.

For Review: Document is routed for review using ad-hoc or proscribed workflows. Reviewer may annotate the document and continue the routing. Several users may perform the review concurrently. The document is locked during review.

For Approval: The document is ready for its primary purpose, and formal approval is requested. Purpose of this state is to collect signatures (electronic or paper). The document is read-only.

Approved: The document has completed its formal approval process. A GMP document should progress to the "Effective" state through a notification process, except when a delay is required to allow time for training.

Effective (GMP): The document is approved and in force. Once Effective, the document remains Effective until it is superseded, obsolete, or replaced by a new and Effective version of the same document. All Effective versions of a document must be retained in compliance with the company’s Record Management policy.

Superseded: The document has been replaced by new document, which is in effect.

Obsolete: The document is no longer used for any business purpose.

Archive: This state is in preparation for long-term archival.

Document Lifecycle State

Business Rules Draft In Review For Approval Approved Effective Superseded Obsolete Archive

1 The document may be edited? Yes No No No No No No No

2 The document may edited to become next minor version?

No No No No No No No No

3 The document may be annotated?

No Yes No No No No No No

4 A Change Request may be issued on the document?

No No No Yes Yes No No No

5

A notification may be issued on the document?

No No No Yes Yes No No No


Page 40 of 43


Document Lifecycle State

Business Rules Draft In Review For Approval Approved Effective Superseded Obsolete Archive

6 The document may be exported from the repository as a stand-alone file?

Yes Yes Yes Yes Yes No No No

7 The "Current" version of the document may be printed by EDMS?

Yes Yes Yes Yes Yes Yes Yes No

8 The document will display or print with a watermark?

Yes Yes Yes Yes Yes Yes Yes N/A

9 The document may be demoted in its lifecycle?

No Yes Yes No No No No No

10 A new version of a document already in the repository may be created by importing a version created outside of the repository?

Yes Yes Yes No No No No No

11 A new PDF file may be generated from the "Current" version of the document?

Yes Yes Yes No No No No No

12 The document may be superseded?

N/A N/A N/A N/A Yes N/A N/A N/A


Page 41 of 43


9. Appendix G – Glossary

Term Abbrev. Meaning Access Control List ACL Lists of groups of people that fit a particular role or permission. These

lists are used to govern access and rights to modify content.

Application Programming Interface API Exposed call or programming link through which various systems may be integrated.

Artifact A specific type of document or object.

Attribute Attribute = Property = Metadata. Assigned to a record that describes or identifies it. Used for search or selection criteria.

Authoritative source A designation given by companies on an information source that states that these value(s) are correct. Governance of this data has been agreed. Applications that need to use this information can assume it to be correct. If the source is outside tof the organization, then it is coming from a government or governing body that is accepted by the company.

Biometric (identification) Identification of an individual that is based on physical properties. E.g. fingerprint, iris pattern, etc. When using mobile devices, the dominant method today is fingerprint.

Contract Manufacturing Organization

CMO Many Pharma companies can do adequate early-stage development but need to partner with an outsourcing organization with greater capabilities to manufacture product for distribution.

Change Notice CN When the controlled document has been modified and made Effective, a Change Notice is issued to advise users that the updated document is available for action. Typical action will be “To Be Read & understood (TBR)”.

Collaborative authoring The process of authoring or creating an object with more than one author, concurrently. Each of the authors need immediate and simultaneous access and modification rights.

Complex document Complex documents are defined as an outline with nodes that link to individual documents and/or other complex documents

Change Request CR A Change Request is initiated and routed for approval when controlled documents need to be created or modified. This CR asks for permission to create/update the controlled document.

Clinical Research Organization CRO Outsourcing of either specific tasks in Clinical or more often the entire process of conducting Clinical trials for a sponsor. The sponsor retains overall responsibility.

Common Technical Document CTD The official format for content that must be included in a submission for approval of a drug. This outline of information was created by the ICH and approved internationally.

Controlled Vocabularies CV Lists of possible values that may be applied to an attribute. It is controlled when there is an authoritative or external source for the values and an Administrator assures that the correct values are available.

Common Technical Document (electronic)

eCTD The specification for submitting CTD applications electronically.

Electronic Document Management System

EDMS Document or content management solutions that follow a specific information architecture and business rules of access and change.


Page 42 of 43


Term Abbrev. Meaning Electronic Signatures eSig The application of an electronic stamp that represents the official

approval of an object or a process.

Trial Master File (electronic) eTMF Electronic management of Clinical Trial documentation that is required according to GCP.

Food and Drug Administration FDA US government organization that oversees the proper regulation and approval of medicinal products. This agency is the official unit that accepts and approves applications for new medicines.

Good Manufacturing Practice GMP A good manufacturing practice (GMP) is a production and testing practice that helps to ensure a quality product.

Good Practices GxP The 'x' denotes multiple domains of application where Good Practices are followed. E.g. Clinical, Manufacturing, Regulatory, Systems, etc.

Information Technology IT The branch of engineering that deals with the use of computers and telecommunications to retrieve and store and transmit information

Lifecycle The steps that an object moves through in creation, editing and finalization of a record.

Metadata Data that describes the content of a record. Used for searching.

21 Code of Federal Regulations, Part 11

Part 11 US regulation concerning electronic records.

Portable Document Format PDF A document format created by Adobe that is used to combine document objects that have been created with different source applications. This format is being used to bridge the usefulness of document output across generations of applications. Largely used as an archiving format.

Placeholder When a complex document or outline of a document that is fulfilled by other documents, a placeholder may be created to show the dependency even though the actual content of the object may not be yet available. When the object has been created and approved ready to use, it can be linked to the placeholder and show it is ready for use.

Pocket Designed for use in small-sized Pharma. May also apply to larger sized companies. The URS is designed to be a minimum set of requirements to achieve compliance across any sized company.

Property Another word for an attribute of a record

Quality Control QC The process to verify the contents of an object or element of information that it is correct.

Quality Management System QMS A quality management system (QMS) can be expressed as the organizational structure, procedures, processes and resources needed to implement quality management.

Standard Operating Procedure SOP A document of instructions on how to perform a specific process. In Pharmaceutical GxP, specific SOPs must be created and followed in the performance of any repeatable process.

Trial Master File TMF GxP dictates that any documentation that is necessary to prove that a Clinical trial has been performed according to Good Practices and will substantiate the conformance to those principles. GCP is not specific to the actual required documents. Nevertheless, a TMF Reference Model has been created within the industry where many Pharmaceutical companies have contributed and verified the inclusion of each artifact.


Page 43 of 43


Term Abbrev. Meaning Coordinated Universal Time UTC Greenwich Mean Time is considered the universal time zone for UTC. It

is the basis for civil time. Local time can be derived based on the local difference in time zones to GMT. Using UTC allows all transactions in a system to be tracked irrespective to the multiple locations participating in the process.

Validation For systems, checking that a software system meets the specifications and fulfills its intended purpose. Also applies to validation of processes.

Workflow The navigation or routing of a document object (or collection of objects) to people for the specific purpose of review and approval.