The need for life sciences companies to collaborate with external partners, whether it’s Legal Counsel, Contract Research Organizations (CRO’s), Manufacturers or Joint Venture partners, has become a daily occurrence. Documents such as Contracts, Informed Content and Protocols require authoring, review and approval from individuals both inside and outside the company. This trend will continue as life sciences companies increase outsourcing efforts at the same time the amount of unstructured content generated each year skyrockets.1

There are many different use cases in the clinical trial process that require the need for this type of data exchange. For example, Investigator’s Brochures (IB) are exchanged between study sponsors, investigators and Institutional Review Boards (IRB). These are not static documents thus requiring collaboration as updates are needed whenever new relevant information is found during a trial. Creating, reviewing and approving Informed Consent language requires a collaborative process that involves input from investigators and IRBs. Investigators are required to complete a Form 1572 along with a summary of their qualifications (typically a CV) and provide it to the sponsor before participating in a trial.

Documents such as these are vital to the safety and efficient operation of a clinical study. Failure to have a reliable, consistent and compliant approach to document exchange and collaboration with relevant parties can result in unnecessary delays and additional costs

Challenges with Common Document Sharing Methods

Many CROs and life sciences companies today collaborate and exchange content either through email, fax, File Transfer Protocol (FTP) or hosted third-party solutions. Each of these methods has its disadvantages in terms of security, document versioning, cost, efficiencies and information loss.

Email

For example, email may be easy to use, and is by far the most widely used communication mechanism in the corporate world. However, sending attachments through email is typically not secure because most of us aren’t encrypting attachments. Attachments also cause our mailboxes to quickly exceed their quota. More troublesome is the fact that there is often confusion about which version of the attachment is the latest—a problem that is exacerbated as the number of collaborating users increases. The end result is a time-consuming, frustrating and error-prone process of manually merging multiple documents to ensure the latest edits and comments are incorporated into a single document.

Fax

Like email, facsimile technologies are commonplace in the workplace. Most fax solutions today convert incoming faxes to digital format and email the document to the recipient. This may be sufficient if the receiver does not need to modify the document. However, in a collaborative environment—where both the sender and receiver must author or edit the document—the resulting PDF or TIFF file is not an editable document and is unsuitable for this purpose.

FTP

FTP collaboration, while not as commonly used as email or fax, has a long history of providing a secure means of exchanging files. However, these solutions require more advanced technical knowledge, are cumbersome to use and typically require IT involvement to initially set up and configure permissions and access. Security aside, the lack of version management is as much a problem with FTP as it is with email.

Third-Party Solutions

Some hosted third-party ("on-demand") solutions solve some of the problems of email and fax by providing a common repository for all parties so there should be no question about which version of the document is the latest. Features such as document version control are useful in that you can go back to an old version of a particular document and have greater insight into how the document has changed throughout the collaborative process. However, not all on-demand solutions offer versioning features, including one of the leading solutions on the market. Some on-demand solutions do provide audit capabilities. This provides for better compliancy by tracking the user, date and time for each document change.

On-demand solutions have a potentially large cost downside, however. These services typically charge by the number of documents or the amount of storage space consumed. As such, they can quickly become expensive. In addition, these solutions require a username and password to connect, which is typically not synchronized with the user’s network username and password. This requires users to remember yet another username and password. This in turn leads to security and compliance issues—for example, users have been known to write passwords on a sticky note and keep it under their keyboard.

Peer-to-Peer Data Sharing: The Ideal Solution

The drawbacks associated with all of these methods—some of which are quite serious—has escalated the need to find a more secure, cost-effective and user-friendly way to manage documents. The solution at hand is peer-to-peer data sharing, one of the most effective content delivery methods available today. Peer-to-peer is an approach to computer networking where all computers share equivalent responsibility for processing data.

Of course, there is one critical consideration to make when selecting a document exchange and collaboration solution: Above all, it must be easy for the end-user to use. This speeds adoption of the new process, avoids costly upfront and ongoing training costs and eliminates the all-too-common scenario where end-users revert back to using email to share documents.

Lower Cost, Improved Performance

Peer-to-peer networking (also known simply as peer networking) differs from client-server networking, where certain devices have responsibility for "serving" the data and other devices consume or otherwise act as "clients" of those servers.

Peer networking significantly reduces technology costs for file sharing while dramatically improving the performance and scalability of the document creation, maintenance and review process. It allows organizations to seamlessly add speed and efficiency for content collaboration, while requiring no changes to the business's current technology infrastructure. This greatly improves the end-user experience and securely speeds up the process of document collaboration for both internal and external parties.

In a peer networking solution, desktop computers can easily be configured to allow sharing of files, printers and other resources across all connected devices, allowing data to be shared easily in both directions—whether downloads to or uploads from your computer. Peer networking can also handle a very high volume of file sharing traffic because the load is distributed across many computers.

Improved Security

Because trial-related documents contain proprietary information and/or sensitive patient data, improved security is a must. For example, if a CRO is working with three separate life sciences companies, it is important, from both a compliance and contractual standpoint, to have three separate workspaces to reduce the risk that a confidential document from Life Sciences Company A is not seen by Life Sciences Company B. Peer networking documents that are exchanged between any two parties are stored within their own individual workspace.

An effective peer network also automatically encrypts and replicates data among users, allowing every user to have constant access to the latest shared documents—even if they are not online. It is also important for the solution to encompass built-in disaster recovery by having the data stored in at least two separate locations.

Accurate Version Control and Tracking

Peer networking should allow CROs to track and manage documents in several ways, including version control and status change notifications via email or text. Additionally, automatic status update indicators should be displayed to alert users of new updates within the application interface. This allows for real-time interaction and updates among users, ensuring a more efficient and accurate collaboration process.

Cost-Effective Infrastructure

One of the most important benefits of a peer networking solution is the elimination of the storage and file-transfer costs typically associated with on-demand services. The ideal peer networking solution requires minimal end-user training and greatly reduces administration, resources and maintenance from a central IT infrastructure, lowering overall costs and accelerating the investment payback.

Integration with Existing Document Management Systems

An exchange and collaboration solution should allow for integration with an existing document management system. For example, take the scenario where an Investigator’s Brochures (IB) is initially created. The authoring and review should happen in a collaborative workspace but, once complete, it should be moved seamlessly into a document management system (DMS) such as Documentum or SharePoint where it can go through a formal approval process with electronic signatures. When the IB needs to be modified at a later date, a change request should be submitted, and once approved, the IB should seamlessly be copied back into the collaborative workspace. Then the IB can be modified by all relevant parties. After the IB is revised, it should be moved or published back into the DMS.

Universal Platform Support

As the Apple Mac is gaining popularity in the corporate world, any peer networking solution should be innately compatible with both Windows and Mac computers.

Conclusion

The most common methods of document sharing and collaboration in use today—predominantly email, fax and FTP—are inadequate and insecure. Expensive managed third-party solutions may also be insufficient, particularly for highly regulated life sciences needs.

A good peer networking solution, on the other hand, will allow life science companies and CROs to balance multiple factors such as total cost of ownership (TCO), ease of use, robust version control capabilities, auditing and integration into a true document management system. The end result: a comprehensive solution with improved workflow, 21 CFR Part 11 compliant electronic signatures, change management and records retention capabilities.

Life sciences companies that adopt peer networking will experience improved document exchange and collaboration processes with external business partners. This reduces risk, compliance and security issues, while at the same time promoting efficiencies and cost savings. CROs that offer robust exchange and collaboration solutions using peer networking also stand to gain a competitive advantage while providing benefit back to their life sciences customers. In turn, these customers will be able to launch products faster because the document-intensive clinical trial and submission management processes are streamlined and made more secure.

1 J. Malek, Transforming Life Sciences: The Connected Life Sciences Company,

Cisco Internet Business Solutions Group (IBSG), July 2009

2 Peer-to-Peer, Harnessing the Power of Disruptive Technologies, March 2001

Dan Wheeler is a managing partner and co-founder of Sitrof Technologies, 700 Alexander Park, Princeton, NJ 08540

The Challenge

Most petitions or submissions received by the Agency arrive through regular mail and are manually routed to various departments. The balance of submissions are received as attachments to email. This creates a number of inefficiencies such as duplication of documents, the inability to know where various submissions are within the process, as well as the inability to provide feedback to petitioners on the status of the submission. The Agency was searching for an electronic document management system, to alleviate the identified issues within the current paper process and increase the efficiency of the state agency. It was imperative that the electronic process closely mimic the one currently followed.

The Solution

The Agency hired Sitrof Technologies of Princeton, NJ to design and implement a document management system and workflows based on Microsoft SharePoint 2010. First the team developed a process requiring all submissions, regardless of their origin and how they were received, be converted into electronic form and then sent to SharePoint for tracking and storage. The format of the document, physical or electronic, dictates the next step in the process. If the document received is in paper form it must be scanned into PDF format, utilizing the existing Xerox multifunction devices with are Extensible Interface Platform (EIP) enabled to streamline and customize the process.

If the document received is already in electronic format it will be uploaded directly to SharePoint to a specific folder related to the submission for further processing.

The ScanFlowStore converts the scanned paper document to a text searchable PDF and place it on the file system. ScanFlowStore is utilized to break apart batches of submissions so that the mail room can scan multiple documents at the same time enabling them to improve efficiency.

The Sitrof Ingester takes the output from ScanFlowStore and routes to SharePoint 2010. Knowledge workers in the mail room use an indexing screen to define the type of submission which then automatically distributes the submission to the appropriate division(s) within the Agency. Once the document has been indexed, a set of validations execute to ensure that the data the user entered matches the rules set in the system for submission properties and starts the appropriate actions. Newly indexed documents are automatically routed to the appropriate folder within SharePoint 2010.

For example, if supporting documentation is required before a submission can be approved, the workflow will enter a paused state until additional support documentation is received. Once a supporting document is received, the workflow will continue allowing the knowledge worker to determine if the additional documentation is sufficient to continue the process or if more documentation is required.

Two submission workflows were created in SharePoint 2010 for the business process related to non-delegated and delegated submissions.

Delegated Submission

After a delegated submission is assigned by the department admin and email is automatically generated to the assigned knowledge worker notifying them of a task within SharePoint. Once within SharePoint they have access to all the available information about the submission from a single screen as well as the original submission and any supporting documentation which is related to the specific submission. The knowledge worker has an option to Approve, Reject, Request Information or escalate as a Non Delegated Authority Process. The knowledge worker would also have an option to reassign the task.

Non-Delegated Submissions

Non-delegated Authority Submissions are submissions that require a public hearing. These submissions go to a number of distribution groups and require a number of different reviews before a decision is made by the Commissioners at the Public Hearing. The specific groups which receive the submission are dictated by the type of submission received. All of the different groups review and provide various comments on the submission. General Counsel can annotate the submission. After all knowledge worker reviews are completed, General Counsel prepares an opinion document that takes the reviews into consideration and is used by the Commissioners for the public hearing. General Counsel may also redact portions of content related to the submission.

Similar to the delegated workflow, the non-delegated submission is indexed by the mailroom clerk and then distributed to the relevant department administrators in the respective divisions that will review the submission. The department admin would then assign reviewers who would have the ability to comment on the submission. Apart from assigning reviewers, the admin would also click on the hyperlink to open the submission in Adobe Acrobat and invite reviewers to gather the comment.

Shared Review, Comments and Tracking Submissions

The department admin enters the email address of all the reviewers who are to participate in the workflow, automatically generating an email notification inviting them to review the submission. The reviewers then comment on the submission, which are all tracked in the system. Pre-determined due dates are set for tasks automatically generating a reminder email to the reviewers.

Once all the reviewers complete their tasks, a new task is created for a pre-assigned user to prepare the memo/opinion for the submission. This user views all the review comments and has to write up an opinion based on the comments. After the memo is prepared, the clerk is then notified to update the action date on the submission. This action date is the actual date of public hearing.

Following the public hearing, the clerk updates the status of the submission depending on the decision made by the commissioners. The clerk also uploads any documents from the public hearing to the ‘Submissions Drop Box’ with the appropriate index values related to the submission.

The Results

As common with every state in the Union, budget cuts have necessitated deep personnel cuts. The old adage ‘Do more with less’ is actually true with the Sitrof/SharePoint solution.

• Reduced Paper: Routing and reviewing petitions electronically to multiple people greatly reduced the need to print duplicate copies which also reduced the printer costs.
• Improved Productivity: Entire staff ranging from Clerks to General Counsel spent far less time in document routing, petition reviewing and searching, and scheduling Public Hearings.
• Petition Tracking: SharePoint Workflow reports and logs meant every petition filed could be tracked at a granular level which was very important due to the time sensitive nature of the petitions.
• Improved Compliance: All petitions are now processed within the time deadlines specified by the legislation.

Next Steps

The State has several initiatives to implement SharePoint 2010 document management and collaboration workflows in various departments and divisions across the State.

A major pharmaceutical company, and long standing Sitrof client, used a very highly customized Documentum WDK Application for content authoring and submission management. While this system served the company well for many years, it ran counter to the company’s IT philosophy of moving to commercial off-the- shelf solutions.

Computer Science Corporation (CSC) was contracted to gather application requirements, perform production configuration and installation. Sitrof was engaged to gather the extensive document, user, configuration and customization migration requirements as well as to perform the design and execution.

This case study discusses the unique challenges such a migration and upgrade effort presents, including:

• Key factors influencing the migration approach ( rolling  vs. an in-place “all-at-once” migration)
• Porting customizations from the legacy system to the upgraded system
• Ensuring external systems that interfaced with the legacy system continued to work with the new system

Migration Approaches

Two Migration Approaches were considered and reviewed for the migration effort:

Rolling Migration

A rolling migration is broken up over time to facilitate a gradual, incremental migration. The migration is divided into distinct chunks using business specific criteria. Documents are migrated from the legacy system on a department- or product-level basis to the new system.

For such an approach, the configurations and customizations to support the entire migration effort over its entire timeline are installed in the new system before any actual content is migrated. This ensures that all the functionality is always available as soon as the content is.

The following diagram illustrates such an effort:

Often the different departments slated to use the new system convert their business processes at non-coinciding times in support of the migration. If this had been a limiting factor, then a rolling migration approach would be the only possible approach. However, this was not the case in this project, which allowed us to explore following migration approach.

In-Place “All-At-Once” Migration

An “all-at-once” migration is where all the documents, users, configurations and customizations necessary for a complete migration are done in a single chunk, usually over an extended weekend.

An in-place upgrade is one where an upgrade to the existing software is done instead of migration to a new system with the new software. An advantage of this approach from a Documentum perspective is that the unique object identifiers are left intact whereas a rolling migration requires that the object identifiers change. This was the main driving factor for the selection of this migration approach, because the business used a submission publishing system that stored these identifiers. Updating the object identifiers in the publishing system would have added increased project complexity and extended project timelines.

The following high-level process was followed in order to move the legacy system to a new FirstDoc Research & Development (FDRD) environment:

1.      Clone the existing docbase (database + content) to new target hardware and perform an in-place Documentum upgrade

2.      Install FDRD into the upgraded docbase

3.      Convert all documents to FirstDoc aware objects (i.e. change the documents’ object types to the FirstDoc specific object types)

4.      Call the FirstDoc SetACL and SetLink routines to ensure that the documents’ permissions and folder locations are set to business requirements

These steps are illustrated in more detail below:

Configurations & Customizations

Because migration involved moving from a legacy Documentum System to a FirstDoc FDRD system, it was necessary to convert all documents to FirstDoc objects.  Sitrof interacted closely with the client Subject Matter Experts (SMEs) to determine the FirstDoc type/subtype/units for all the existing documents. In cases where documents could not map to existing document inventory, Sitrof worked with CSC in order to have new types/subtypes/units added to the system.

The client also had WDK Customizations in the legacy systems, which Sitrof helped port over to the FDRD system by merging this functionality into the FDRD UI where possible.

Secure Login

The client’s IT security policy dictated that all passwords traveling on their networks be encrypted. However, using network sniffers, it was found that passwords were being passed from the WebTop/FirstDoc login screen in the application server to the Content Server in clear text.  Sitrof customized the WebTop/FirstDoc login component to encrypt the passwords passed to the Content Server.

Remote Import

A customization of the legacy system was the ability to import documents from a list of pre-defined FTP servers directly into the Documentum repository. Sitrof merged this functionality into the FirstDoc Bulk Import function so that document import from FTP Servers is treated in an identical manner to the documents imported from the File System.

Product Dictionary Loader

The client had an existing data warehouse that contained product, regulatory, clinical and nonclinical information, and did not want to manually maintain these dictionaries within FDRD.  Sitrof developed a series of custom jobs that queried the data warehouse on a daily basis and automatically created the appropriate FirstDoc Product dictionaries within FDRD whenever new data appeared in the data warehouse.

Architecture Sizing / Performance Testing

Because this was a mission-critical system, the client wanted to ensure that it was properly sized to handle current and future volume.  Sitrof worked with the client’s internal testing and infrastructure teams to develop performance tests to stress all individual components of the system. The joint team also stress-tested the overall system itself by designing “day in the life” scripts.

External Systems

Special attention was paid to all external systems that interfaced with the legacy system to ensure that the interfaces would work after migration. If a modification to the interface was needed, Sitrof made this change.

Trackwise Integration

The existing legacy system was integrated with Trackwise, allowing users to view content residing in Documentum from a Trackwise screen.  Sitrof ported this customization to work with the latest version of Documentum and FirstDoc.  Sitrof also customized FirstDoc to write the unique Documentum identifier to Trackwise any time a health authority correspondence document was approved within FirstDoc.

Conclusion

Sitrof was involved from inception to the finish of the project, and oversaw a large part of the development and migration efforts that were required for a successful completion of the project. The client was able to decommission their legacy solution shortly after going live with the FDRD solution.

Background

A large generic pharmaceutical manufacturer needed to migrate a subset of documents from their legacy GxPharma solution to a FirstDoc FDQM 5.0 system. Sitrof is a vendor neutral integrator, always looking for the best approach for individual customers.  We also believe in building on past successes.

After much research and consideration with a previous customer (See previous case study), we decided to build a custom migration utility rather than use an off the shelf product like Buldoser or FME’s migration-center.  That approach proved to be successful and we had envisioned using this custom utility for future migrations.

This particular client preferred to use CSC Configuration Management Utility (CMU) to perform the migration.  They had confidence in CMU and had performed a similar migration several years ago.  They were looking to adopt a consistent migration approach and toolkit to perform the FDQM migration along with any other migrations needed in the future.  While Sitrof had experience using the CMU to move FirstDoc configurations from environment to environment, we had never used the tool to perform a migration to or from a repository outside of FirstDoc.

The FirstDoc solution was already in production, presenting an interesting set of circumstances.  Other complicating factors were the GxPharma system was running Documentum version 4.2.8 while the FDQM system was running Documentum version 6.0 SP1 as illustrated below.

The Sitrof Approach

We had hoped to use CMU 5.0 to perform the entire migration.  However, CMU 5.0, which uses DFC 6.0 SP1, cannot connect to a 4.2.8 repository.   We worked around this issue by using CMU 4.2 to perform the export while using CMU 5.0 to perform the import and any post import processing steps.

A typical E-T-L (extract, transport, load) model for this type of migration would be to export the content, apply metadata transformation rules and then import into the FirstDoc repository.  With past migrations, we exported the metadata into database tables which provides an efficient and convenient way to update metadata values based on migration rules (e.g. existing documents with r_object_type of sop will have a document_type value of Standard Operating Procedure).

CMU does not provide a way to write metadata to a database but instead, writes it to an XML file.  Fortunately, rather than having to modify values within the XML export file, the CMU provides a means to transform values during the export itself so that the metadata in the resultant XML already has the transformed value.  Using the ‘transform’ attribute in the CMU ObjectExporter allows you to call your own JavaScript code where more advanced transformation rules can be applied.  Many of our transformation rules were handled in JavaScript code where either the rule was hard coded or read in from spreadsheets that contained the mapping rules.

Once the export was complete, the exported metadata resided in XML and the content resided on a file system.  The import process was very straightforward; we just used the CMU ObjectImporter to import the exported XML files.  The ObjectImporter provided a handy “save_object_id_map” feature that produced a CSV file that created a map of the old r_object_id to the new r_object_id.  This map can be useful if you wish to import audit trail values but need to update the old object Id to the new object Id.

Once the documents were imported, there were several post import steps that had to be performed.  These tasks included creating FirstDoc relationships between documents (e.g. an SOP related to a Form), calling the FirstDoc methods AutoNumber (to assign a new document number), SetACL (to apply the appropriate document security based on the document’s type and subtype) and SetLinks (to link the document to the correct folder location).  The CMU TaskManager was used to call a series of JavaScript programs to perform these tasks.

Observations

We were pleasantly surprised by the number of CMU options available to facilitate a migration.  For this particular migration, 40,000 documents (all versions) and tens of thousands of audit trail records were migrated.  While the performance was adequate for a migration of this size, the CMU would not be our tool of choice for a larger scale migration.  Also, the CMU would not be a viable option if there was a need to migrate from a non-Documentum based source system.  Nonetheless, since most FirstDoc customers already own the CMU it should be considered as an option for your next migration.

Background

Copernicus Group IRB (CGIRB), with assistance from Sitrof and employee-driven change management, was able to transform from an entirely paper-reliant company with millions of pages of legacy documentation into a completely digital paperless organization in less than two years. As a result, the company dramatically reduced expenses and created a truly “green” work environment by nearly eliminating paper, printing, storage, shipping and other hard document handling costs.

With a three-phase implementation approach, employee-led review and oversight committees, CGIRB fostered a positive, productive atmosphere for long-term change management. CGIRB gained competitive advantage and improved service to pharmaceutical clients by becoming more efficient in review and approval process—thus enabling clients to accelerate their study start up and increase the speed in getting drugs approved and into the market.

The Challenge

In the fall of 2006, CGIRB sought a document management solution to handle incoming electronic documents so they did not have to be printed and circulated in hard copy. It approached Sitrof Technologies, a company specializing in unstructured document management with extensive experience Part 11 compliance. CGIRB wanted to install a 21 CRF Part 11 compliant document management system with workflow, version control and electronic signatures to handle incoming documents.

CGIRB is an IRB which under FDA regulations means it’s an appropriately constituted group that has been formally designated to review and monitor biomedical research involving human subjects. Running the day-to-day business at an IRB is incredibly paper intensive and requires a great deal of internal and external collaboration. But by 2006, 96% of incoming documents to CGIRB were received electronically via digital fax, portals and email—and then printed out because CGIRB did not have a FDA 21 CFR Part 11 certified process for electronic document handling.

CGIRB knew something had to change in this process and set to work with Sitrof to implement a solution to becoming paperless.

Initially, CGIRB only sought a way to handle incoming electronic documents, and nothing more. However, early in the investigation process, CGIRB realized it was entirely possible to become a completely paperless company and so established a very aggressive goal of doing so. This paperless evolution would involve a massive legacy document scanning operation, including 1.5 million legacy documents totaling 5 million pages, as well as all internal documents and all inbound paper and electronic documents.

The project also required extensive system integration with CGIRB’s internal Protocol Tracking Systems and its customer-facing portal, Connexus. It also necessitated reengineering and converting of the company’s existing paper processes and workflows—which in turn necessitated a critically important cultural/change management solution for CGIRB employees.

Objectives included:

• To install a 21 CRF Part 11 compliant document management system with workflow, version control and electronic signatures to handle incoming documents.
• To improve efficiency, reduce the need for paper (cost, storage and environmental reasons) and most of all, improve their competitive advantage.
• Overall objective was for CGIRB to become a paperless company.

The Solution

To transform CGIRB into a paperless company, Sitrof undertook a massive legacy document scanning operation, including 1.5 million legacy documents totaling 5 million pages, as well as all internal documents and all inbound paper and electronic documents. Due to the requirements of 21CFR Part 11, CGIRB must validate all regulated systems. Each of these phases included documentation and validation effort to ensure CGIRB systems remained in an appropriately validated state.

Sitrof worked with CGIRB to create an efficient and successful implementation process using a three-phase approach.

• Phase One: Using DocuShare out of the box.
• Phase Two: Scanning and uploading 5 million legacy pages to an e-file room for viewing purposes only.
• Phase Three: Adding Sitrof’s Compliance Module to DocuShare to automate the workflow and decision process for electronic records while maintaining Part 11 compliance.

Phase One:

From the very start, CGIRB improved employee adoption and buy-in immeasurably by creating subcommittees, focus groups, team meetings and best-practices teams from lines of business and IT. In mid-2008 Sitrof installed Xerox DocuShare software for use with CGIRB’s non-regulated documents, such as vacation requests, business development information, training information, PowerPoint presentations, spreadsheets, status reports, RFIs and contracts. Employees quickly became familiar with the DocuShare interface, easing them out of their comfort zone in a non-threatening, time-relaxed manner.

Subcommittees, focus groups, team meetings and best practices teams involved as many staff members as possible. Phase One also allowed CGIRB and Sitrof to fine-tune processes and customize the software before launch, again minimizing risk before full implementation.

Phase Two:

To become truly paperless, a major legacy scanning operation was necessary. CGIRB commissioned a local established outsource firm, SCDATA, Inc., to work on-site, scanning, indexing and archiving 5 million pages of legacy documents (more than 200,000 pages scanned per month). Proper check-in/check-out of these live paper documents was essential throughout the conversion process, because at any point in time, CGIRB had to be able to locate any specific document—even if it had already been pulled for scanning.

Initially, the scanned documents were available through a DocuShare e-file room for “read only” purpose. This allowed users to become familiar with the system and working with electronic records. However, because the system was not yet Part 11 compliant for decision-making, the original paper was still routed to board members. Thus by the end of phase two, and before full launch, users already had nearly a year’s worth of hands-on experience with the system.

In addition to making a certified and trustworthy duplicate through scanning, Optical Character Recognition (OCR) was applied to each page, converting it to digital text and allowing full text search of all 5 million pages of documentation. Adding OCR and full text search was very forward thinking on part of the team and resulted in further streamlining of the clinical research process. Each document was also compressed to within 5% of its original size. The OCR and compression process continues today for all newly entered hardcopy and electronic documents.

Phase Three:

Both CGIRB and Sitrof knew from the start that Xerox DocuShare alone would not meet all functional requirements for a new paperless system, including Part 11 compliance. Yet, by design, it wasn’t until a full year later—after thorough testing with non-regulated documents, working through process changes and getting buy-in—that Sitrof installed its Compliance Module to ensure 21 CFR Part 11 compliance. Until that point the mission critical documents were still being handled in paper.

DocuShare, when combined with the Sitrof Compliance Module, is a robust document management collaboration tool supporting CGIRB’s mission critical function.

The Results

CGIRB’s award-winning paperless evolution is green, efficient, cost-effective, compliant and competitive. With over 96% of documents received electronically at CGIRB, eliminating the need to print documents reduced cost and allowed for a green work environment. An ROI of 51% represents the implementation of CGIRB’s DocuShare paperless environment.

By scanning and performing OCR all the 1.5 million documents in the legacy repository can now be searched in a Google-style manner by the DocuShare software. This enables board members to quickly find the right passage in typically 200-page long protocols and investigative brochures. In addition to the time savings, the risk of missing something is virtually eliminated.

In the past, thousands of approval documents and correspondence were shipped out to sites and clients each day. Now, with updated SOPs and the technology in place to exchange electronic documents, paper is conserved, shipping costs are reduced and approval documents can be accessed instantly.

Because study documents are dynamic documents that are never fully retired, they can be in use for more than ten years. Converting all paper to digital dramatically expedited the retrieval process of these valuable documents and nearly eliminated hard storage costs. CGIRB no longer risks losing paper documents, and a single document can easily and securely be shared among numerous board members.

A global pharmaceutical company and Sitrof client uses FirstDoc R&D for managing their FDA submission content.  After acquiring another life sciences company that were left with submission content in three disparate content repositories; one in FirstDoc and the other two lightly customized versions of Documentum. The company tasked Sitrof with defining the migration mapping requirements, evaluating configurations and customizations in the source system and implementing a technical solution in order to migrate this mission critical  content and metadata.

Key points to consider when performing such a migration include:

• FirstDoc Object Model
• Migration of FirstDoc Configurations
• FirstDoc API
• FirstDoc Migration

FirstDoc Object Model

When performing a migration from one FirstDoc system to another, it is important to remember that FirstDoc interfaces rely on the FirstDoc object model to function correctly. The FirstDoc object model for the FDRD module is reproduced below:

All objects that extend from the fdk_document type are recognized by the FirstDoc interface to be FirstDoc documents. If types are to be mapped from one FirstDoc system to another, this is important since mapping to a type that does not extend from fdk_document will cause the document to become a normal non-FirstDoc document.

Properties of the fdk_document in all FirstDoc:

FirstDoc extends the Documentum Type architecture to Subtype, Unit, and Subunit. Thus, a mapping of the Types, Subtypes, Units and Subunits is required from one system to the other. This is usually achieved in the requirements gathering phase, after mapping has been decided upon. Furthermore, each FirstDoc module has other special mapping requirements which are unique to each module. For example, in the FDRD module, all FirstDoc documents extend from the r_and_d_document type which has the required attribute ‘product’. Each unique product is associated with a Product Dictionary in the FDRD system.

When migrating from one repository which has a different set of products to another, all product dictionaries must be created from the source system in the target one. Products may also be mapped from the source system to the target one in which case a new product dictionary does not need to be created. This is illustrated below:

For a successful migration of all documents, all products must be completely mapped or created in the target system since the FDRD module will not allow documents to have products which do not have a Product Dictionary.

Migration of FirstDoc Configurations

FirstDoc is a client-driven enforcement of server-side configurations, meaning that all FirstDoc rules and security are enforced at the Web layer. The rules are implemented and stored in the Content Server. Every FirstDoc configuration is associated with at the minimum a Type and a Subtype and at maximum the Unit and Subunit.

During migration, this presents us with two scenarios:

• All Types and Subtypes are mapped completely from the Source System to the Target System. In this case, migration of FirstDoc configurations might not be necessary--unless the configurations from the Source System to the Target system are in conflict with each other. In this case, the business owners of the source system and the target system must decide which configurations to keep.
• Some Types and Subtypes from the Source system are created as new Types and Subtypes in the Target System. In this case, the configurations associated with these type-subtypes might have to be migrated to the Target System. These new type-subtypes must also be added to the FirstDoc Dictionary of the Target System. To assist in the migration of the configurations, the FirstDoc CMU Tool could be employed.

FirstDoc API

FirstDoc provides developers with an extensive set of JAVA API to perform many of the server-side functions that are executed upon user-interaction. For the purposes of migration, only the API related to the following two functions are important:

• Refoldering API: Documents in FirstDoc are foldered according to their Type and Subtype. This is stored in a FirstDoc configuration. During import of the documents, one must run the Refoldering API so that the documents are foldered at the right place.
• Security API: Documents in FirstDoc inherit their ACL according to their Type and Subtype. This is also stored in a FirstDoc configuration and during import of the documents, one must run the Security API so that documents attain the correct ACL according to the FirstDoc rules.

The flow of the Import program is thus illustrated as below:

FirstDoc Migration

This section summarizes all the above points and provides a visual for the overall FirstDoc Migration:

Background

Founded in 1882, our client is a leading provider of commercial, specialty and personal insurance to customers worldwide. Our client ranks among the Top 10 publicly traded insurance organizations, based on revenues, in the United States. With more than 10,000 employees throughout North America, Europe, South America and the Pacific Rim, our client serves property and casualty customers from more than 132 offices in 33 countries. Our client works closely with 5,000 independent agents and brokers worldwide.

Business Challenge

The insurance industry is currently undergoing a high degree of change. Carriers are challenged to post an Underwriting profit. Government deregulation is enabling new competition from traditional Financial Services companies, who are now able to market products to their customers which in the past, had only been available from Insurance companies.

Fierce competition, product commoditization and catastrophic losses are increasing pressure on eroding margins. Leading companies are exiting unprofitable business lines and streamlining expenses. At the same time, agents, brokers and consumers are demanding specialized products, high quality services and access to information from any location, using any medium at any time. Accordingly, carriers are leveraging information technology to:

• Reduce costs because the bottom-line counts now more than ever
• Increase efficiency by streamlining and automating manual processes
• Improving productivity
• Create new demand for products
• Enhance services to keep one step ahead of the intensifying competition

Objectives

Our client needed to integrate existing fax servers so that all incoming faxes would be received and routed to a centralized document management repository. Furthermore, our client needed to have the fax index information automatically stored on the document when it was filed. In addition, our client required a robust Lotus Notes integration to allow users to add incoming and outgoing email to the document management system. Finally, our client also had the need to implement a distributed and easy to use imaging solution.

Technical Solutions

Sitrof Technologies, Inc. was able to build a system that met all of the user requirements. The system consisted of a .NET architecture with HTML/LotusScript, and Visual Basic user interface. The applications connected to and retrieved the documents from a newly implemented document management repository. Faxes came in through their Zetafax Fax Gateway Server and routed to the inbox in Lotus Notes. Users were able to select one or more e-mails/faxes from a desired folder. The users select an integrated menu option, prompting with an input screen. The screen is used to classify (document type) the emails/faxes and enter any relevant metadata required from the document management server. Sitrof also customized and implemented their scanning solution and integrated a document classification/acl schema to the chosen document management server in accordance with the user and functional requirements specification.

Results

Our client is now able to eliminate most of the paper documents in their process and have web-based access to all their documents on time and without problems. What used to take minutes or hours now takes seconds. They are now confident that all the documents are sent to their customers and if any problems do arise, they can respond in minutes as opposed to hours and days. The project was completed on time and within budget.

Background

The Public Employees' Retirement System was established in 1955. The Division of Pensions and Benefits is assigned all administrative functions of the retirement system for investment.

Business Challenge

To redesign and develop a workflow system to be used by the Division of Pensions and Benefits to process the purchasing of retirement time. The original system had become old and outdated and was no longer going to be supported by FileNET. This system, originally developed using the FileNET WorkForce Desktop 4.0 scripting language, needed to be rewritten to use the latest FileNET Visual WorkFlo.

Objectives

• Redesign and develop a workflow system to manage the retirement process of municipal and state employees.
• The new system required a tight integration to the IBM Mainframe, Oracle Databases, and UNIX FileNET imaging repositories.
• A sophisticated automated letter creation module was required for correspondence to state employees.
• The new system had to be Y2K compliant.

Technical Solutions

Used FileNET Panagon to develop a client-server based solution.

Application

Customized application interface containing all of the needed information for the Purchasing group to process their work. It included imaging which allowed the user to access documents scanned in as well as storing correspondence printed from the custom letter generation service. The applicant would start the process by submitting an application which would generate a work object. As the work object traveled through the workflow, different users would interact with the data. In the event of certain flags produced by that interaction, the system would automatically generate correspondence which was printed on a nightly batch process server. Once the applicant was approved a form was generated and sent to the payroll department so that they could begin deducting the agreed amount from the applicants biweekly or monthly pay checks.

Tools

Visual Basic for customized components. FileNET's IDM Desktop API's and Visual WorkFlo.

Results

• Applicants are now reviewed and approved 50% faster.
• Fewer mistakes are made during the process.
• The administrator now has the ability to reassign workload to different users decreasing the bottleneck when someone is out on sick leave or vacation
• Users now have timely access to the documents needed to process the work.
• Pre-defined from letters can be pre-populated from the applicant's information as stored in the FileNET System.

Background

Our client is a major international consumer products company. They worked with an Application Service Provider (ASP) who contracted with them to hold and supply all of their MSDS documents. Due to poor service from the ASP they wanted to create a custom system allowing them to manage their own access to the MSDS documents.

Business Challenge

Our client wanted to leverage their existing Documentum repository where the MSDS documents already existed. In addition they wanted to create a Web-Based application for their users to access the documents. The site needed to be able to print, fax, or email large amounts of documents as well as track each request.

Objectives

• Deploy application in Piscataway, New Jersey for use by the Consumer Affairs division located in New York City, New York.
• Leverage the existing Documentum DocBase located in Piscataway, New Jersey.
• Build a Web-Based Architecture with a consistent user interface across all desktops.

Technical Solutions

Sitrof Technologies, Inc. was able to build a system that met all of the user requirements. The system consisted of an ASP/COM+ architecture with HTML/JavaScript user interface. The application connected to, and retrieved the documents from their existing Documentum DocBase and handled all of the reporting requirements.

Results

Our client is now able to access the MSDS documents on time and without problems. What used to take minutes or hours now takes seconds. They are now confident that all the documents are sent to their customers and if any problems do arise; they can respond in minutes as opposed to hours and days. The project was completed on time and within budget. In addition, the project won a company award for the Best Managed Project of the Year.

Background

Our client is a pharmaceutical business unit of Akzo Nobel NV, a multinational company based in the Netherlands. Today, our client has nearly 10,000 employees and is active in more than 100 countries.

Business Challenge

Our client's West Orange, NJ, facility faced a growing challenge of managing their Standard Operating Procedure (SOP) documents. With the volume of documents increasing at 20% per year, their paper-based approach was very labor-intensive, expensive and error prone.

Objectives

Create an electronic document management system that will accomplish the following:

• Decrease review and approval times
• Reduce copying and shipping costs
• Provide better reporting capabilities.

Technical Solutions

Sitrof Technologies, Inc. used Documentum 4i server with customized Desktop Client (DTC) front-end.

Application

Customized DTC components such as Check-In, Properties, and Task Manager. New DTC components such as Reassign Tasks, Pull Reviewer Tasks, and Submit Change Request.

Tools

Visual Basic for customized DTC components. Active Server Pages and XML for web based workflow reports.

Results

• Documents are now reviewed and approved 50% faster.
• Thousands of dollars a year have been saved in photocopy and shipping charges.
• Web-based workflow status reports eliminate the need to track down who is currently working on a document and gives the Document Administrator the control to improve productivity.
• Electronic sticky notes make it easier for document authors to read reviewer comments.
• Electronic backups reduce the amount of storage space needed SOPs available to all users via the company Intranet.

Closing Statement

Sitrof built a custom electronic SOP system that has greatly reduced the amount of time spent reviewing and approving documents. This has allowed our client to re-deploy resources that were previously dedicated to make photocopies and collecting hand signatures.