Papyrus for Healthcare Insurance Correspondence Transforming the claims process to maximize customer service INSIDE Case Study: Major US Healthcare Provider streamlines its claims operations E Migrating legacy host claims letter generation systems DCF/ASF, Napersoft and Xerox DJDE. E Eliminating manual processes E Applying new logic and layouts, changes for logos and branding in record time 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: a Claims Entry: Batch letters b Claims Processing: Online letters c Customer Service: User interactive letters a Claims Entry: Batch letters This is a batch mainframe process where letters were merged with different images and bar-coded for automated mailings. N 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 J 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. J 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. J 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. J 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. J 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. J 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. N 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 b Claims Processing: Online letters This is a batch mainframe online process where replication of text was eliminated and bar-coding was added. N 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 J 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. N 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 c Customer Service: User interactive letters A client/server based system where improvements were made in speed, accuracy and aesthetics. N 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 N 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. J Nodes were created for: The Domain Controller, printers, developers, administrators, users and the MQ receiver J Each department (group) created: • Distribution queue • Inboxes & inbox control • Completed queue • Quality Control Queue • Error queue J 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. J 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 J Built methods Determined what actions would be required and allowed for each object used. J 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 J 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 N 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. N 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. N 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 MOTIVATIONS for INNOVATIONS Motivation: Wasting time and money due to inflexibility and manual processes Innovation: Transforming the legacy mainframe system with a Client/Server based System gaining speed, accuracy and aesthetics Solution: Papyrus became the generic Enterprise Application Integration solution for batch, online and user interactive claims documents PAPYRUS PRODUCTS in use Papyrus Designer Package on Windows WYSIWYG dynamic document design Papyrus DocEXEC on z/OS High speed document formatting engine Papyrus WebRepository on Windows Document resource management Papyrus Postprocessing/PrintPool Image merging and barcode processing Papyrus Adapter/MQ Series Interfacing with messaging system Papyrus Client (1500 concurrent users) Interactive, ad-hoc letter generation 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. N 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. N 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. N 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. N 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 N ‘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