This Insurance Company is one of the largest Property & Casualty (P&C) insurers that operates in all areas of Canada as well as in the States of California and Oregon in the US. The Insurance Company’s insurance products are distributed by over 1,300 independent insurance brokers.
To modernize the application systems supporting its P&C operations, the insurance company embarked on a major, multi-year initiative—its Enterprise Systems Renewal Strategy—that has already seen the introduction of a new Broker Transaction Portal and a new Claims Processing system. Ultimately, the program will also see the company completely revamp its existing Policy Administration system and the ERP system used for managing financial processes.
The firm’s Claims Processing system, for example, for which there was a separate instance installed in each of the company’s nine regions across Canada, was very old, offered only limited functionality and was very difficult to extract information from. As the result of an RFP exercise, the insurance company chose to implement Guidewire’s ClaimCenter®, a Web-based claims system built specifically for the P&C industry.
A single, centralized instance of ClaimCenter® was installed in the company’s headquarters data center, giving the company’s 1,200 claims users an advanced system capable of workflow, more functionality and better reporting. This includes support for document composition and document management, for which the legacy system offered little or no capability.
When insurance claims are settled, ClaimCenter® users create Remittance Packages containing documents such as cover letters, signoff forms, payout cheques and numerous others that are sent to the claimants. A big feature of ClaimCenter® is the ability to compose documents and have them easily customized by these users, based on the circumstances associated with the claims being processed.
With over 1,000 custom document templates loaded into the system, a user simply selects the desired template and the system automatically populates the template with data from the claims database, performs a ‘mail merge’ with the claimant’s information and displays the completed draft document on the user’s screen. Once the user indicates that the document is ‘final’ and has either mailed or e-mailed it out, for example, ClaimCenter® then moves the document into the IBM® FileNet® system the company chose as its Enterprise Content Management repository.
According to the Director of Architecture & IS Risk, the company uses FileNet® primarily for Document Management—they need to store many documents for decades to meet business and regulatory requirements. However, they were concerned about storing documents for long periods of time in their native document formats, such as Microsoft® Word® or Excel, for example, because they would be subject to ongoing changes/upgrades Microsoft® Office®.
The decision left the insurance company’s team needing to find a PDF rendering tool to integrate with ClaimCenter® and FileNet® that could provide the required document conversion from other file types into PDF format.
Extensive research and testing of numerous PDF rendering tools available on the market enabled the insurance company’s team to develop a clear understanding of their requirements and define product selection priorities, the first of which was the ability to faithfully render all types of documents into PDF, with 100% fidelity.
“We found that full PDF rendering fidelity was not such a simple requirement, and many of the tools we tested were not capable of faithfully converting specific content within our test files,” reports the Director of Architecture & IS Risk. He goes on to say that the second critical decision factor, equally as important as the first, was that the chosen tool needs to be compatible with their integration strategy and work seamlessly with ClaimCenter®, FileNet® and their claims processing workflow. The new claims processing environment had been architected based on a ‘service bus’ approach to integration, with ClaimCenter® at the core and supporting systems, such as FileNet®, connecting to it via a common connection pathway.
“When we looked at the native PDF rendition engine within FileNet®, for example, which is an embedded third-party product, we found it met some but not all of integration requirements—the rendering takes place after the fact, rather than within the workflow,” states the Director of Architecture & IS Risk. He also points out that the PDF rendering capability within FileNet® was that it was difficult to find any information about the product. One of the technical people from a third-party firm helping the company with the ClaimCenter® deployment did some research on his own and recommended they consider the Adlib PDF rendering solution.
“We had actually been going down a different path based on a tool one of my own architects discovered, but after extensive testing, we found it didn’t meet our rendition fidelity requirements, so we gave up on it,” says the Director of Architecture & IS Risk who was quick to add that after a short look at Adlib, on the other hand, including some initial lab testing, “We very quickly realized that Adlib was the right tool for us—it was the only PDF rendition product out of the seven or eight we looked at that met our requirements for 100% fidelity and integration.”
The insurance company’s IT team made the decision to move forward with Adlib, purchasing an initial four Adlib server licenses to meet production requirements and integrating the Adlib rendition functionality into the ClaimCenter® service bus and claims processing workflow.
Although the insurance company’s team did the initial integration of Adlib with FileNet®, using java code within their Enterprise Service Bus, Adlib subsequently developed its own robust FileNet® integration, which has been incorporated into the product as part of ongoing enhancement efforts.
The Adlib technical people who worked with the insurance company’s team to implement Adlib also suggested that instead of converting documents into PDF format, they use Adlib’s additional ability to convert them into the ISO-standard PDF/A file format, a derivative of PDF that has established itself as the de facto document format for high-fidelity, long-term digital archiving. Although many insurance company’s use TIFF file format to meet regulatory archival requirements, this format increases storage costs and is not fully text-searchable.
“Adlib’s PDF/A capability is ideally suited to us because of the length of time we are required to store documents,” points out he Director of Architecture & IS Risk, explaining how the PDF/A format retains all the metadata-like formatting information necessary to read a PDF document, even many years later, without having to rely on any type of external application, such as Word or Excel, that might have been used to create the document originally.
The Adlib implementation began with Proof of Concept, Performance and Quality Assurance testing. Although most testing was conducted in the insurance company’s Development & Test lab, Acceptance Testing involved a few claims processors from each of the company’s regional branch offices who were given access to a separate system environment where they could test the overall document creation and storage workflow. The use of Adlib is transparent to the users— they do not actually invoke a PDF/A rendition, but rather it occurs automatically within the overall ClaimCenter® document management workflow when the user indicates that a document is final. The workflow calls for the rendition and then moves the resulting PDF/A file into the FileNet® repository.
Adlib has a unique rules engine for configuring automated, metadata-driven document workflows using document properties and information about the document to initiate the transformation rules. This allowed the insurance company to achieve the automation they needed.
Only two challenges of any significance were encountered during Adlib implementation. The first was some initial incompatibility between Adlib and the IBM® AIX® UNIX server on which the ClaimCenter® application runs. To resolve this challenge, a small piece of specialized Windows software called “Services for UNIX” was added to the Adlib servers, allowing them to read the AIX files.
In the second case, some initial performance issues that may have been the result of incorrect option selection and configuration during installation were resolved by an Adlib professional services consultant tuning the Adlib environment.
“We underestimated the number of documents we would need to render daily, so we added three additional licenses while we were still in the early stages of implementation, giving us a current total of seven Adlib production servers and three development servers,” says the Director of Architecture & IS Risk. “As a result of Adlib’s consultant’s effort, our Adlib environment performed much better, processing anywhere from 2,600 to 4,000 documents per day — averaging about 3,500—with an average conversion time of 11 seconds.”
The Adlib component of the ClaimCenter® system has been in production use for several years and is used every day as an integral part of the insurance company’s infrastructure and claims processing workflow. Adlib’s unique metadata rules engine, which uses various properties of the document to initiate the PDF conversion, was instrumental in allowing the insurance company to achieve the level of automation they needed.
By way of example, he cites the fact they are already implementing another business application for which Adlib will also render PDF files, this time involving a third-party, Web-portal-delivered appraisal system for automobile insurance claims—the widely used Mitchell Appraisal System—which creates reports on auto damage, including photos. The insurance company has integrated ClaimCenter® with the Mitchell portal so that when the report package has been created, the report file is pulled into ClaimCenter®, where Adlib converts the report file into PDF/A and combines this file with other PDF/A files to create a single claimant file that is archived in the FileNet® repository.