Print to Repository – OpenContent Print Driver Support

TSG has been working with a client recently that needs the ability to print directly to the repository.  This post will present both the old way of printing to the repository as well as our new OpenContent Print Driver to allow printing to the repository with a consistent web-based indexing user experience.

Print to Repository – What are the requirements?

Often times, a user is looking at a web page or document on their desktop, iPad or other device that the user would like to quickly add that to the repository.  Examples could include a picture of a map from a Google Map search, a single page or two in a long document, a view from a third party web application or any other number of viewers that don’t translate easily into documents that could be easily uploaded.

A common work around is to initiate “Print to PDF” and save a PDF file to the device and then manually upload the document to the repository.  In this manner, just the page of the long document or whatever is being displayed from the browser can be captured.  Some issues with this approach including:

• Process flow – In the Print to PDF scenario, the user needs to print to PDF, save the document on the desktop or device and then manually upload the document.  This can result in lots of clicks to find and upload.
• Security – Since the file is being saved to the desktop or other file storage, the user needs to remember to delete the document (more clicks) once successfully uploaded.

Legacy ECM Print Driver Approaches

Many of the legacy ECM approaches provide a print driver with indexing capabilities to avoid the Print to PDF issues above.  In this approach, the print driver includes ECM capabilities and indexing in the driver itself.  In adding print driver support, TSG looked at this approach but we were concerned about the following issues:

• Consistent Indexing – Clients have been asking for more and more machine learning and other capabilities in indexing.  Having more than one way to index documents creates issues with consistency across indexing approaches, particularly when it comes to index logic with lookups.  (example – Vendor Name/Number, Claim Number…).
• Additional Indexing – Users have to enter all the index information about the document.  In a Case Management scenario, this would include case number (ex: claim number, vendor number) as well as other case-related metadata.  These items are typically searched for in the repository and then confirmed in the manual “Print to PDF” scenario.  Keying manually can result in error and lost documents.
• Confirming the upload – With a print driver, once the print is complete, the driver returns to the application.  When indexing is in the print driver, the user isn’t necessarily given feedback that the document has been placed in the right folder or index values as they would have to go to the repository to verify.  Any error in indexing would essentially lose the document (for example a mistype in the claim number in an insurance scenario)
• View and Index – As a best practice for indexing, OpenContent provides a view of the document while indexing to allow for a better quality index as well as selecting fields from the document itself.  Putting indexing in the print driver requires the print driver to appear and for the majority of applications reduce the users’ ability to see what they are printing.

OpenContent Print Driver Support

The OpenContent Print Driver reduces the clicks and provides consistent indexing through both a simple print driver as well as an easy and consistent user experience.  Rather than add all the document attribute indexing in the print driver, the OpenContent Print driver can queue the document directly into the OpenContent Management Suite importing screen.  Rather than save the document on the desktop or file system, the document is immediately saved in the repository.  Once in the repository, the document is available from the standard indexing screen for import for only that user.  Index values can be added or inherited from the case with the document displayed when adding these values. 

Walking through the scenario from a typical auto insurance claim:

1. The Claims adjuster is working on a claim in the repository and looking at a police report.  The adjuster would like to add a small map from Google Maps to the claim file of where the accident took place.
2. The adjuster goes to another tab on their browser brings up Google Maps, finds the intersection and selects Print and the OpenContent Print Driver. 
3. The adjuster goes back to the tab for the claim and selects “Add Document” – the recently added Map is available for the adjuster to add to the claim.  The adjuster can verify the map, annotate the specific intersection and add the map to the repository.

To illustrate the above process, see a quick video demonstration below:

Summary

Printing directly to the repository can efficiently add web pages or other types of documents that are hard to directly upload but can lack indexing consistency and quality.  The OpenContent Print Driver solves the consistency and quality problems by providing a single, consistent indexing interface.

Let us know your thoughts below.