Papyrus for Insurance Correspondence
Transforming the claims process to maximize customer service

INSIDE

Case Study: Insurance corporations streamline their claims operations

View in pdf format: English, German, Italian, French

E-mail us for a printed copy...

Major US Healthcare Provider streamlines its claims operations

Recognizing a need:
• The mainframe system was hard to maintain and caused numerous errors
• Changing logos and branding required a better way to apply new logic
• Too much time and money was being wasted on manual processes

Three different transition processes were needed:
1.) Claims Entry: Batch letters
2.) Claims Processing: Online letters
3.) Customer Service: User interactive letters

Claims Entry: Batch letters
This is a batch mainframe process where letters were merged with different images and bar-coded for automated mailings.

• Prior to Papyrus

• The letter process took 3 days from data entry to mailing
• Expensive preprinted letterhead was used
• Required manual process of merging letters and claim images
• Required manual sorting of letters for enveloping and mailing

• The claims entry process:
In case there is not enough information on the form to process the claim, the data entry person enters a code representing the missing information. The codes are then translated to paragraphs for a cover letter that explains what is missing.

• The printing:
Prior to Papyrus the codes and data were gathered and sent in a file to the mainframe for merging. Letters were printed on preprinted letterhead with one logo, address and phone number. Then the letters were hand carried to the service area for sorting.

• Image Processing:
The images were retrieved separately from an image server and sent to a network printer. 2000 to 3000 images per day were printed on an HP laser printer onto letters in the order they were requested.

• Merging letters and Images:
This was done manually and matched to the balancing report. This process took an entire day to complete. 1800 letters a day were processed.

• Sorting:
Letters were manually sorted by number of pages. Any combination over 6 pages were hand inserted into large envelopes which were individually addressed and mailed. Letters under 6 pages were carried by hand back to the mail room.

• Enveloping and Metering:
Stacks were fed into an envelope folder/inserter and each stack was handled separately, 2, 3, 4, 5 and 6 page combinations of letters and images. Letters were metered and mailed 3 days after the letter codes were entered.

• How they improved the process
The graphical Papyrus Designer tools are used to define logic for the letterhead giving better accuracy and enabling printing on plain paper. Indexes are defined and AFP output is sent to an existing printing and archiving system. The ­Papyrus PrintPool and Postprocessing functions on z/OS are used to merge images with letters and apply barcodes.
Images are retrieved and sent by MQ Series to the server and then to the mainframe VSAM file for merging. Data is sent to the Papyrus DocEXEC formatter on z/OS where letters are formatted and merged with the images. The letters are then printed on plain paper with the already merged images and barcodes for automatic enveloping.
The DocEXEC generated letters are sorted using Papyrus Postprocessing functions and the output is split into separate files by logo and number of pages. Folding and inserting of letters into envelopes is done on one machine and instead of taking 3 days, letters are ready for mailing less than 24 hours after data entry.

Gains achieved
• Letter process time was reduced from 3 days to 24 hours
• Huge savings by eliminating preprinted forms
• Manual merging of letters with images was automated

Claims Processing: Online letters
This is a batch mainframe online process where replication of text was eliminated and bar-coding was added.

• Letter creation prior to Papyrus

• 3000 letters and 850 letterheads had to be maintained
• There was no flexibility for adding logic
• No online viewing
• All changes and tests required printing
• All logos and signatures needed to be loaded to the printers on cartridges and were difficult to align with text

• Test shells & Letterhead
There were 3000 different letter shells and text had to be repeated over multiple letters because of letterhead and signature placements. There were over 850 different letterheads in DJDE code and because each letterhead had some difference such as PO Box, Phone number or placement of the signature individual forms had to be loaded onto a cartridge and into the printers to be called at print time. Forms were only viewable by printing and often signatures were not aligned with the text.

• How they improved the process
Conditional logic was used to reuse text elements, which reduced the number of text blocks from 2900 to 125. Variables were used to make sure the signature was always aligned with the text and fonts were updated with cleaner, more aesthetically pleasing character sets. Printer independence was achieved by eliminating DJDE code and AFP output was added to the existing printing and archive system they were already using. Postprocessing functions were used to bundle letters to one recipient in one envelope.

Gains achieved
• Text blocks were reduced from 2900 to 125 by reusing elements
• Eliminating Xerox DJDE controls provided printer independence
• Bundling of all letters to one receipt in one envelope

Customer Service: User interactive letters
A client/server based system where improvements were made in speed, accuracy and aesthetics.

• Letter creation prior to Papyrus

• They were using a mainframe CICS system with Napersoft as a text system
• The PF key invoked the letter system
• Mainframe printer ID and shell document name was limited to 10 characters and had to be known
• Formatting was not consistent and there was no choice of fonts nor any ability to view the whole letter
• Any format changes were difficult to achieve
• No logo could be applied and expensive preprinted letterhead was required
• Variables needed to be typed over and very limited search capabilities where available
• Since there was no online quality control or print previewing all letters were printed
• All printed letters were saved to history and on average they were printed twice per letter sent
• There were no levels for supervisor, administrator or controls for accessing letter shells
• Neither were there restrictions for printing or editing

• How they improved the process
They implemented Papyrus Objects as a Client/Server application using Papyrus Client and Desktop and the Papyrus ­WebRepository. The delivered object oriented correspondence framework was customized to meet the customers requirements on document processes. Standard network printers and plain paper is used for printing all letters and AFP output was added to the already existing print and archive system.

• Nodes were created for:
The Domain Controller, printers, developers, administrators, users and the MQ receiver

• Each department (group) created:
• Distribution queue
• Inboxes & inbox control
• Completed queue
• Quality Control Queue
• Error queue

• Agents and queues were defined for moving tasks
Agents move tasks when a letter is put into a certain state by the user’s actions.

• Papyrus Adapter interfaces with the MQ messaging system
Data is received from the mainframe by MQ queues:
• Each user’s inbox is referenced in the MQ Receiver
• Each inbox is matched to their Windows Logon
• The task always goes to the person who requested it

• Built methods
Determined what actions would be required and allowed for each object used.

• User Authorization
Roles were built for users to manage access, abilities and some variables used in letters:
• Introduced three levels of users
• References their inbox
• Contains variables that help determine addressee and return address
• Allows updates by group administrators
J Letter templates are built using the Papyrus Client and Desktop
• Letter templates contain objects corresponding to includes in the document definition
• Designed to use drop down menus
• Description field is used to preview text
• Variables are checked to verify if a prompt is needed

• Papyrus Designer is used to build logic elements and the data interface
• Logic is imbedded into includes for addressee, return address, etc.
• AFP Designer is used to design overlays to apply logos and attachments

• User experience
The user double clicks an icon on their desktop to start the kernel and Papyrus Desktop. This displays the Inbox and letter folder and allows for the use of macros to drop tasks into the inquiry or claims inbox they are working on. The user then selects a letter template to merge the data with by dragging and dropping the template onto the MQ data.

Then the Client plug-in launches and prompts users for missing information. This allows for text to be edited just like in Word with spell checking and hyphenation. When the user then clicks ‘generate’, ­Client closes and a ‘Send to Quality Control’ button appears. Once clicked, the letter leaves the inbox and the Supervisor or Administrator can see it in the Quality Control Queue and review the letter for sign-off.
N Employee satisfaction, productivity and ­accuracy

Even though some of the employees were initially skeptical, everyone has really enjoyed the transition. The software is not only efficient it is also accurate. Among the benefits is the fact that Papyrus guides the user through the process and prompts the user for missing information. The system manages the employee workflow and tracks all of the steps and compliance dates.

• Usage
An average of 1800 front-end letters are sent per day that are merged with 2000 images along with an average of 2000 claims letters that are generated. Over 3,000 users from 35 departments create an average of 3000 on-demand letters per day and almost 2,000,000 documents will be produced using Papyrus software in 2006.

• Leverage Software for additional applications
Papyrus was chosen as the letter writing system for a new patient care tracking system in the first quarter of 2006 with many new requirements. The ISIS AFP Designer will be used to convert old PMF forms to PPFA to allow for development offshore.

Gains achieved
• Substantial cost savings by eliminating preprinted forms and by printing all letters only once
• Faster completion of letters and greater user satisfaction due to superb WYSIWYG functionality
• Rigorous document control due to sign off processes
• Security requirements can be achieved by restricting printing and editing

TECHNOLOGY SUMMARY

Correspondence:
The Opportunity In Speeding Claims to Closure

The ability to communicate with insureds swiftly and accurately plays a key role in closing more claims in a shorter amount of time. In this report you will learn how insurers are successfully automating this process for reduced risk and better results using Papyrus‘ end-to-end integrated document solution for communications with their clients.

• Papyrus Document Integration
Papyrus Objects was designed for managing business documents and their business data links in a distributed corporate environment. Because most such documents are the carrier of the corporate business process, they are also mapped to the lifeblood of IT, the business data. Papyrus is a generic system that makes the linking of documents to business data simple, whilst also enabling the management of the related business process.

• Interfacing with legacy Systems
The developer can define true business objects such as customer, address, warehouse, account, item, account transaction, phone call, fax, incoming mail, insurance offer, policy, claim, claim settlement and so on. An adapter or type manager supplied by ISIS is used to define how data from an existing database is mapped into the attributes of a business object. 

Adapters linked to messaging systems such as MQ-Series interface with e-mail and workflow systems and have definitions that react to these events. In many applications, it is necessary to call the letter generator from the host application manually. The adapter, however, is a message translator that waits for events to take place.

• Document Process Integration
The adapter and Typemanager interfaces with the core claims system then the business case-type selects the process and data is passed to the document. Additional data is reloaded on demand and control information along with a document ID is returned.

• Document Process Management by Business Rules.
Examples:
•  WHEN CUSTOMER AGE is greater than 18 THEN INSERT ‘Car Brochure’ in ENVELOPE ‘Monthly Statement’
•  WHEN PARAGRAPH ‘A’ USED THEN ALSO USE ‘B’
•  WHEN STATE EQUALS ‘error’ THEN MOVE to ErrorQueue

• Professional Strength’ Correspondence Systems
• Enables the free definition of letter elements (Document Framework)
• Implements the data, user and process control interfaces
• Defines user authorization with roles and privileges (i.e. LDAP)
• Provides the infrastructure for resource distribution in the network
•  Defines the letter process
•         Enables the infrastructure for printing, faxing, e-mailing and archiving

USER INTERFACE

Papyrus WebPortal
More than just a pretty user interface.

The Papyrus WebPortal is a part of Repository’s functionality that offers Web-based CRM applications to streamline your business.  All information related to the web user, business data and document type and layout are stored in the WebRepository.

The Web browser functions are a multipurpose GUI that enables the customer or end user to view and interact with the business’ communication of virtually any type or format.  Each end user’s experience is tailored to his or her role, enabling extensive flexibility either through the viewing of documents or interacting  with them by filling in text and data.  Document security, versioning and reconciling different taxonomies is taken care of by WebRepository.

Setting up a Papyrus WebPortal is easier than you think.  The portal roles you create for one user can be applied to other users across the company, cutting down on implementation time and costs.  Papyrus also delivers HTTPs server functions and integrates with third party HTTP servers. The full Papyrus Client text editing functions are available as a plug-in in the browser and all document formatting is performed centrally on the fly and are shown in PDF format in the browser.  

• Document Framework Development
Graphical design of document resources. All resources, classes, versions, variants, jobs, etc. are stored in a central Repository. An integrated authorization system based on roles and policies eliminates unauthorized access and offers change management for document flow and sign-off. Features such as version and variant control, along with audit trailing, monitors changes in the document and keeps track of letters produced by a variety of users. 

• Business Application Data 
The business application data can be directly read by ­Papyrus in any format, such as XML, ASCII and EBCDIC. Papyrus offers several standard data interfaces: Flat files, SQL queries, Adapters (i.e. MQ Series), HTTP, TypeManagers for DB/2 and Oracle. Data preparation or data tagging is not required.
N  Process Link                    
The process link is used to request documents from the server, which then manages the completely independent document process. Upon completion, a status is returned.

• The Central Production Server
A central PC or UNIX server receives data from Web users via HTTP. It interfaces with data from the business application and collects document resources and layout definitions from the central Repository. The e-document is generated on the fly and sent to the user in PDF format for viewing and local printing.

• Central Server Printing, Pooling and Archiving
All Web-generated documents can be automatically archived, viewed, searched, and printed locally or centrally from virtually any platform and printer. Pages retain their original look and feel, complete with text, graphics, photos, and color and documents remain available for as long as they serve a useful purpose or legal requirement. These rules also govern the removal of documents when they have outlived their usefulness.    

Benefits/Gains to be achieved
• A unified document interface and a single point of entry
• Java coding not required
• Seamlessly integrated Web-based e-document solution where data, documents and applications interact within the portal process definition