Spotlight on 4th Generation Electronic Document Management (EDM) Systems

October 1, 2005
Daniel Hahn

BioPharm International, BioPharm International-10-01-2005, Volume 18, Issue 10

...each day a product is delayed is estimated to cost upwards of $1 million to $100 million.

The "vision" to implement compliant electronic document management (EDM) systems — with process facilitating and monitoring functionality such as template-based authoring, fully automated work flow, electronic signatures, submission-status portals, and filing through fully digital backbones — has existed for decades.

Daniel Hahn

Until recently, the combination of vague regulatory agency guidance and fragmented technology has prevented both large and small pharmaceutical companies from fully achieving the vision. Yet many companies have invested millions of dollars and years of manpower to implement marginally successful, compliant EDM solutions.

To successfully achieve the vision and effectively manage EDM projects, first categorize the current state of your EDM system, then build a road map with manageable phases to reach the desired end state.

The goal of this article is to provide: (1) real-world examples of valuing EDM projects; (2) methods for categorizing a required solution; and (3) useful guidelines and rules of thumb for building a road map after the solution has been categorized.


Building a road map is a natural starting point for any well-managed project. With EDM projects, visioning and road map activities become especially important for several reasons:

  • There are likely many EDM projects within the organization

  • The purpose of various projects may be convergent or divergent

  • Managing expectations of the various constituencies is extra-ordinarily difficult with the potential functional solutions that EDM can provide

  • Achieving any specific value, either business functionality or financial, is particularly difficult if a company attempts to do everything simultaneously

  • Compliance and coordination issues associated with multiple projects and poor project mapping can cause a budget to balloon by more than 100 percent.

By way of narrative example, the clinical operations function at most life sciences companies produces documentation to effectively manage ongoing trials, monitoring documentation such as visitation reports, protocols, and amendments; investigator's curriculum vitae and licenses and general correspondence. Additionally, medical writing groups typically develop clinical study reports and other final documents that appear in US Food and Drug Administration (FDA) submissions.

Categorizing EDM Projects

Electronic trial master file (eTMF) systems differ substantially from submissions management systems in that eTMF systems control, organize, and share study-related information within the clinical operations group. A submissions management system, on the other hand, controls inter-functional processes — among groups such as regulatory affairs, quality assurance, and clinical operations — of published content in individual leaf documents (such as FDA's 1572 clinical investigator form; or FDA's chemistry, manufacturing, and control [CMC] document) related to an investigational new drug (IND) or new drug application (NDA).

In addition, the method of valuing a submissions management system is often different from that of valuing an eTMF system. For instance, a mid-sized contract research organization (CRO) recently estimated the cost savings — due to case-report-form sharing, site-closeout efficiencies, and general site-level administration — from implementing a compliant eTMF system could approach $900,000 per year, while several top-tier pharmaceutical companies spend well over $3 million per year in submissions support alone. The submissions support expense justification is often a time-to-market argument, in which each day a product is delayed is estimated to cost upwards of $1 million to $100 million. (This figure is based on a daily revenue estimate achieved by dividing yearly revenue from a moderately successful to blockbuster product — approximately $360 million to $4 billon dollars annually — by 365 days, assuming that one extra day of revenue falls almost directly to the bottom line when a drug is covered by patent, and that all other factors are held equal; the author does not necessarily subscribe to this method of value estimation.) The improvements in time-to-market, driven by a submissions system, are often attributed to electronically facilitated work flows, pre-defined and streamlined approval processes, electronic signatures, and highly automated submissions construction.

These distinctly different purposes have distinctly different values. How, then, does a company separate, prioritize, manage, and achieve the value for an enterprise EDM project (especially when the cost of margin functionality increases rapidly beyond rudimentary systems)? Can value even be achieved? The answer to both questions is "Yes."


A solid conceptual starting point involves categorizing document management solutions into four maturity states based on functionality: (1) open information-sharing intranets; (2) controlled electronic filing cabinets; (3) compliant EDM solutions; and (4) highly automated content publishing solutions. It is this categorization that forms the foundation for the desired end state of a solution — and begins the road map for any EDM implementation and validation.

Maturity State 1: Open Information-Sharing Intranets

Information-sharing intranets are portal-style applications for sharing documentation. The sites are often open to general access and may house documents relative to one specific topic or multiple topics. These solutions can be elaborate and homegrown, using tools such as BEA Systems' WebLogic Portal, IBM's WebSphere Portal, or Oracle Corporation's Oracle Portal. Alternatively, they may be as simple as EMC Corporation's eRoom or Microsoft Sharepoint Team Services. Functionality is normally fairly static in these environments. However, common capabilities include: uploading and downloading of documents; creating new sites or folders for new topics; adding, removing, and re-arranging gadgets; and manually controlling document versions.

These intranets typically do not facilitate the production or approval of documents. Controlling versions on these types of sites often proves challenging. Movement of documents among folders and different sites can prove difficult too because loaded content remains in the same location. Finally, the proliferation of the created sites is often uncontrollable and results in an environment that is hard-to-search. This type of environment is almost certainly not meant to be validated or provide enterprise business efficiency (although it can add some project document sharing efficiency).

Maturity State 2: Controlled Electronic Filing Cabinets

Controlled electronic filing cabinets provide deeper document management functionality and typically focus solely on controlling documents being placed into well-structured files. Controlled solutions normally contain relatively well-structured proprietary, confidential, or regulated documentation. Examples of business functions that may use controlled electronic filing cabinets are: (1) intellectual property and litigation teams; (2) sales, franchise, and real estate administration groups; (3) regulatory affairs teams; and (4) pharmaceutical clinical operations groups.

Collaboration capability, partially automated versioning, document-level access control, rapid document retrieval, and reporting capabilities are the primary benefits of the controlled electronic filing cabinet. These filing cabinet solutions usually do not provide the capability to create documents in a controlled manner; instead, they provide a controlled environment for sharing and retrieval.

The technology tools used to implement controlled electronic filing cabinets are often enterprise document management systems — such as the standard eContent Server from EMC Documentum, LiveLink ECM from Open Text Corporation, or ECM solutions from Hummingbird, Ltd. — or are point solutions offered by specialty contract research organizations such as ClinPhone Group Ltd. or Quintiles Transnational Corp. The solutions can range in complexity from configured, out-of-the-box software to systems with heavy customization that facilitate document bar coding, user-friendly document importing, scanning, and quality assurance measures. The normal precursor to a controlled filing cabinet EDM system is a set of shared drives on a network — a solution that is often difficult to scale and control.

In this controlled-filing-cabinet state, solutions are often implemented in conjunction with scanning environments — such as those offered by Captiva Software Corporation or Kofax Image Products, Inc. — and frequently augment a paper-based system of record. Even if paper remains the official record, the system is invaluable for its ability to enable users to: (1) create reconciliation reports based on document metadata; (2) retrieve documents without leaving a computer; (3) search for documents based on the text; (4) check status to ensure documents have been submitted or completed; and (5) allow multiple role-players to view the document at the same time. Maturity state 2 is normally a relatively rapid implementation with quick value — systems typically can be implemented in a validated manner within four months.

The controlled electronic filing cabinet is a solid step in moving up the maturity cycle. The ability to view content is usually assigned on the document level or content level, providing role-facilitating capability and alleviating the need to travel, photocopy, and carry large volumes of paper — in processes where multiple groups need access to a document at one time or where manual paper movement is absolutely required for record-verification purposes. Most importantly, it helps system users and administrators to start thinking in "document management" terms.

Maturity State 3: Compliant EDM Solutions

Compliant EDM solutions are systems that build on controlling access to final documents by controlling their creation, review, and approval. Further, they enable documents to be placed into retired or obsolete life cycle states. Hallmarks of compliant document management are well-defined document life cycles; unique groupings of mandatory attributes around document types; specification of role-players in the form of authors, reviewers, and approvers; controlled change requests; version and printing control; electronic signatures and promotion; and finally, full audit trails.

These solutions are most likely built on enterprise-class EDM solutions such as Documentum's eContent Server with Documentum Compliance Manager, or Open Text's Livelink for Regulated Documents. When considering controlled documents — either once controlled filing cabinets are implemented or, more importantly, when implementing a compliant document management solution — it is critical to begin considering new software tools to add functionality (e.g., hot back-ups, fail-over, and disaster recovery; EDM and enterprise portal integration; compliant document management package; or records management).

For hot back-up — back-up performed on a regular basis without bringing the system down — "cover-your-assets" products serve as a good example. Clustering services from VERITAS Software or BEA Systems are examples of disaster recovery and fail-over tools through their ability to cluster servers. Both Documentum and Open Text (Livelink) offer a host of gadgets to integrate document management "in-boxes" with enterprise portals.

When it comes to compliant document management packages, Documentum Compliance Manager (DCM 5) serves as a good example of a partially configured tool that can provide substantial functionality toward a compliant document management solution without the need to expend large sums of money. The integration of some important records management functionality into the Documentum 5.3 eContent Server provides a highly configurable and integrated content control platform that can be upgraded with minimal technical or validation effort.

Other solutions such as Adobe Systems' intelligent forms, Acrobat, and Reader should be considered here for obtaining e-signatures from external resources; providing cursory annotation services; and controlling access to original content.

Equally important as the chosen tool is the time required to define the life cycles, functional groups, role-players, document types, metadata, and more. This need to effectively manage the investment often results in time-boxed projects and, therefore, functionally "siloed" solutions. Because the EDM tool becomes process facilitating, and likely the system of record, there are enormous standard operating procedure (SOP) implications and validation issues.

It is these SOP and validation issues that require substantial consideration in laying out the EDM road map.

Compliant document management is used most frequently by quality assurance groups for controlling SOPs or by regulatory affairs groups to ensure the control of documents for regulatory submissions.

Process efficiencies are moderate for compliant document management, but high levels of document-handling and content-creation compliance can be achieved. The cost of noncompliance, measured by lost revenue from stalled operations and labor required to resolve FDA citations, is the primary driver of compliant document management.

Electronic signatures and process automating electronic work flows reduce circulation and document approval efforts. In conjunction with a process-harmonization effort, these systems include templates with common nomenclature and structural standards specific to each document type. It is the structure and automation that lead to high-quality audit trails, complete document histories, and compliance-related reporting capabilities.

Maturity State 4: Highly Automated Publishing Solutions

"Templatization" and their electronic management lead to an acceptable level of preparedness for highly automated publishing solutions. Highly automated publishing solutions require that documents have appropriate metadata — to accurately and electronically locate the documents — and that they contain the appropriate tagging to locate content within the document. This ability to locate a document, and "chunks" of content within a document, enables the division and distribution of content for multiple uses and in multiple locations. It is the first step of transitioning to an XML backbone for publishing.

Highly automated publishing solutions integrate compliant document management to enable automated publishing of documents and their more granular chunks of content. The automated publishing may be performed in electronic form — such as via templated web publishing or an XML backbone. Alternatively, the publishing may be done on paper or in a file, such as an Adobe PDF, that represents paper.

Submission software is the cornerstone for most publishing systems because submissions publishing is the bulk of the publishing performed by pharmaceutical companies. The most prevalent companies providing publishing solutions are Image Solutions, Inc. and Liquent, Inc. Their tools serve to map compliant leaf documents into submissions using the structures specified by various government regulatory agencies.

Substantial effort goes into generating persistent bookmarks, hyperlinks, and tables of contents for any submission, even with a submissions tool. The output of these tools is a submission in the form of printed paper, electronic files on a CD-ROM or DVD, or document content placed in an XML backbone, representing a submission. Eventually, documents and content will be placed in an XML backbone where updates are automatically transmitted to regulatory agencies in a controlled manner. It is up to the publishing system to capture a snapshot of the virtual documents submitted.

Very few companies, if any, have achieved fully automated publishing and submissions. However, this is a vision, or endpoint, that will be attained in the near future. The challenge is the implementation steps.


Building the implementation road map for an EDM project requires both a top-down and bottom-up planning approach. The top-down approach provides implementation teams with a charter. This charter normally includes critical sponsor-related planning elements such as the desired end state, prioritized business requirements, and the business justification. The top-down elements cascade to the bottom-up planning by helping the implementation teams understand how many maturity states they must work through, the combinations of functionality that will maximize value through each maturity state, and the tools that will best scale to the desired end state.

The remainder of this article focuses on guidelines for transitioning from the conceptual top-down EDM project chartering to the tactical bottom-up project planning. First, five guidelines are provided for project planning. Subsequently, four validation guidelines and one change control guideline are presented.

Not all systems need to be fully automated publishing systems; controlled filing cabinet functionality may be the desired endpoint for an application. As with any system, the endpoint should be commensurate with the value that a system — and its users — can achieve. Second, and only marginally less important, is that maturity states 2, 3, and 4 build on one another — each is a logical, stepwise progression through the implementation process.

EDM Project Planning Guidelines

Many business project sponsors argue for skipping the controlled electronic filing cabinet state to achieve artificial deadlines or because the real value is perceived to come from controlled document management. However, it is this controlled electronic filing cabinet that usually focuses the users on folder structures that suit their business needs. This focus on business needs and structure normally leads to the comfortable identification of document types and subtypes. Once the document types and subtypes have been selected, the list of metadata associated with each document type can be more easily generated. However, generating the list of metadata for each document type frequently proves to be one of the most arduous activities in specifying a system — an activity that can derail a project if a project is over-scoped.

Build your road map so that each state in the maturity cycle is independently achieved. These maturity states can become high-level milestones on the planning horizon.

Project Planning Guideline 1 Apply proven rules of thumb to estimate the project effort. Perform a check with the business sponsor to ensure that effort does not exceed business value.

For a non-validated implementation of out-of-the-box EDM tools, such as Documentum eContent Server, requirements should consume about 33 percent of the overall project time, design and configuration should consume 33 percent, and testing and training should consume 33 percent. For a validated solution, applying a moderately rigorous validation procedure, the total hours allocated for requirements through training could be multiplied by 125 percent and 133 percent; the cost of validation (or "validation uplift") often proves to be at least 25 to 33 percent of the total implementation cost of the solution.

Based on maturity state and organizational knowledge, estimate the requirements gathering effort, then apply a 1/3-1/3-1/3 rule of thumb to estimate the overall effort. Finally, work hard to define your organization's validation uplift, and apply this uplift to the effort estimated with the above rule of thumb. The estimates can be refined as the project moves forward, but these initial estimates are a great reality check to determine if the business value articulated in the charter exceeds the effort required.

Project Planning Guideline 2 Plan in 16-week time periods. Schedule logical project plan updates (called "stage gates") within the 16 weeks to ensure that estimates are revised and that the project sponsor has full visibility for the effort and budget.

For a single group implementing a compliant document management solution using a package such as DCM, validated implementations with a full out-of-the-box life cycle and having a limited number of document types can be performed in four months by implementation teams as small as four people.

As with any estimate or forecast, accuracy increases as more information is known and as one moves closer to the time period in question. Choosing manageable planning horizons will aid in connecting a company's current state with the desired end state. It is advisable to use 16-week time periods to manage implementations. A 16-week time frame is sufficient to implement a controlled filing cabinet and, usually, a modest compliant document management solution for one business function.

Within the 16 weeks, and especially if a full implementation will be completed within that timeframe, schedule stage gates between requirements, design and configuration, and testing and training. The stage gates can be used for reevaluation of and adjustments to the project plan. Once the adjustments are made, an interim "go/no-go" decision can be made.

Project Planning Guideline 3 Use a waterfall systems development life cycle to align the development life cycle with the project governance needs required for a validated EDM system.

Regardless of the desired end state, it should be considered compulsory to manage validated EDM projects using a waterfall systems development life cycle. EDM applications have many changing values — users and groups, roles, metadata values, folder structures, and so forth. Likewise, many changes can occur in work flows and life cycles as projects move closer to implementation (not necessarily because business analysis is bad, but because the combination of requirements, design approaches, and product functionality cannot perfectly align).

The business sponsor and functional teams should understand that their functional requirements must be finalized and signed prior to moving into design. The sponsor and functional teams should also go through the same finalization process prior to moving from design and configuration to testing and other aspects of the overall plan. The alternative is massive change control to validation documents, which often delays the project more than changes to true application functionality. The waterfall methodology aligns the development life cycle with the project governance needs of validated EDM.

Project Planning Guideline 4 Complete one successful compliant document management solution to establish your organization's guidelines before trying to run additional projects in parallel.

In many cases there is a tendency to attempt to run 16-week projects in parallel. Consider this only after successfully implementing the compliant document management solution. By then, the effort, rules of thumb, and pitfalls will have been identified, and you can determine if performing parallel projects is prudent. Most organizations find parallel implementations very difficult to manage unless there are completely separate teams. The amount of information sharing and team coordination required for parallel projects often increases the project effort by 25 percent or more.

Project Planning Guideline 5 Mitigation of high validation costs start with understanding answers to at least three sets of questions:

1. Was your validation strategy written for data acquisition and management systems (as many have been for organizations starting as research and development companies)? Does it provide some measure of flexibility for process facilitating systems?

2. Does your company have part of the infrastructure for your EDM solutions installed and validated (e.g., application servers, database servers, server hardware, or document management software)?

3. Does your company's template for the validation master plan and the quality assurance group allow for frequently changing values such as user lists and groups, attribute values, and service packs to be documented and managed via the administrator's SOP?

With timelines and rules of thumb for effort in mind, the number of people involved in compliance document review, the prescriptive nature of the templates used for the validation documentation, and the number of review cycles are just a few of the primary drivers for the amount of time required for validation. In worst-case scenarios, the 25 to 33 percent rule of thumb can turn into 100% or more.

EDM Validation Guidelines

FDA's website defines "PQ" as "performance qualification," "process qualification," or "product qualification." Validation strategies oriented for data-acquisition software often apply the "performance qualification" definition, which often translates into problems for testing a process facilitating tool such as EDM.

In a data acquisition-orientated operation qualification (OQ), there are usually straightforward tests to prove that the software is functioning out-of-the-box, as it should; there are often few changes to the real functionality of the application. In this case, the performance qualification can focus on the repeated successful performance of: (1) configured business rules; (2) extract-transfer-load procedures; (3) integration reliability with other systems; and (4) such things as fail-over and back-up procedures.

In the case of compliant document management solutions, an application is much more like a manufacturing system: the application is responsible for controlling and producing a document. The PQ definition of process qualification often fits better than performance qualification.

Under this scenario, discrete functions of the EDM application are checked by the OQ scripts to ensure proper application function: document import, document check-in and check-out, attribute input and validation, and more.

The process qualification is used to test the application from the role-based perspective of such steps as: the author generates a document for review, and the reviewer completes the review cycle. These types of tests involve testing sets of disparate functionality in a sequence that matches how the role-players will actually use the application. For business users, this approach appears to be similar to user-acceptance testing. For administrators, this approach provides tangible examples of the functions they will be asked to serve almost immediately after "go-live."

Validation Guideline 1 It is important to validate EDM infrastructure hardware and software well in advance of application deployment.

If your validation strategy calls for an approach more in line with performance qualification, and your EDM application's purpose is compliant document management, work with your QA department to write a variance or amendment to the validation strategy. The validation strategy for compliant document management systems should include a process qualification

Validation of an EDM system is not limited to the application created within the EDM tool. The entire hardware and software stack — the physical server hardware and operating systems, database servers, application servers, EDM applications, and EDM support software — should be validated. If your company has installation and operational qualification (IOQ) protocols for validating these components — and the IOQ protocols can simply be updated to suit your environment — then some of the validation risk and effort has been mitigated.

Ensuring that test and production hardware are delivered early; resources are available to execute the protocols; and hardware, operating system, and database servers are validated well in advance of the planned date for setting up the test environment, additional validation risk is mitigated.

Validation Guideline 2 Do not forget about the impact of your EDM system on the desktop image. New applications may need to be installed and qualified even for web-based applications.

A related risk is the qualification procedure for the desktop image (the set of desktop software approved by QA to work effectively and reliably together). If your company has created a qualified desktop-software image, ensure that your EDM administrator works with the desktop-application administrator to understand the tools that will be installed on the desktop in conjunction with the EDM implementation.

Some examples of EDM support software that should be checked are applets and Java run-time environments for the EDM; versions of viewers required (e.g., Adobe Reader and WinZip) on the desktop to support the EDM usage; and compatibility of all desktop tools with the EDM stack being implemented. Changes to the image may require the desktop image to be requalified, a time-consuming process that can cause major project delays in cases where several tools need to be changed, updated, or uploaded.

Finally, consider licensing implications of changing any desktop components, support software, or components of the EDM stack.

Validation Guideline 3 Set up "test" and "integration test" environments to promote early identification and rapid resolutions of bugs and other issues.

Consider implementing four environments when performing a ground-up implementation: development, test, integration test, and production. The integration testing environment allows the EDM application to be tested with other applications, such as scanning environments or desktop applications. The test environment should allow the EDM application to be tested in isolation. The two together provide an opportunity to view what has changed during integration efforts, thereby allowing early identification and rapid resolution of bugs and other issues.

Validation Guideline 4 Fully understand the scope of the validation effort. The amount of documentation and supporting software and the number of review cycles and architectural components can all cause the scope of validation to balloon out of control. EDM solutions are often more complex to validate than originally expected.

Change Control Rules of Thumb

EDM solutions have many values that change on a regular basis: users, groups, metadata values, folder structures, service packs, and so on. While the requirements for these values should be identified during the requirements gathering process — and documented in detail during design — the maintenance of actual values is often better managed by an administrative SOP. The design document can reference the SOP and actual values as a starting point. Value changes should be governed by an administrative change that does not require the entire system to be revalidated and does not require documents contained in the validation package to come under change control.

Change Control Guideline An administrative SOP and change procedure should govern frequently changing values. If you leave the sole documentation of the values within the requirements or design documentation, the application will need full revalidation when these values change (to maintain compliance).


Understanding the business charter of an EDM implementation will most likely lead the team fluidly to the envisioned end state of the project. For example, a project charter with a stated purpose of "increasing and automating the creation of compliance documents" leads to maturity state 3 as an endpoint, while a project charter that simply specifies "sharing less-sensitive project documents among team members" is likely to indicate maturity state 1. Once the end state is known — once you have your vision — the functionality necessary to achieve that vision is relatively clear. Transitioning to bottom-up planning requires some EDM project planning knowledge as well as application of proven guidelines.

Work from the vision or end state backward to decompose the project for bottom-up planning purposes. Start the decomposition using the planning guidelines above. When executing the project, work in a stepwise manner — achieving high levels of success, one maturity state at a time, before moving to the next maturity state. On the first project, apply loose effort estimates initially. Learn from the projects by tracking effort for each phase of the development life cycle, and calculate more precise guidelines for your organization as more projects are implemented. Applying consistent methodologies and using similar project governance techniques will enable best practices.

Planning a validated project requires substantially more time and coordination than an un-validated project. Knowing the pitfalls of managing validated projects, and then taking action at the inception of a project by applying the validation guidelines, will help to mitigate the largest project risk: delays in the project due to documentation rework rather than actual system quality. The guidelines in this article allow you to benefit from other organizations' best practices.

Last, but certainly not least, governing EDM implementations through short planning horizons strongly encourages prioritization of user requirements. Effective prioritization coupled with well-aligned development and validation methodologies will enable you to consistently manage sponsors' expectations. Positively and effectively managing the sponsors' expectations will build "apostles" for the EDM system — the best practice for achieving the desired value from an EDM system

Daniel Hahn aniel Hahn is engagement director, Life Sciences Division, Ness Technologies, 3 University Plaza Drive, Hackensack, NJ 07601, 201.488.7222, ext. 415, Fax: 862.596.0178;