EXPERT PAGES

Bill Fleming graduated from Northwest Missouri State University in 1979 with a Bachelor in Business/Industrial Technology and joined Sig Manufacturing, Montezuma, Iowa, designing and testing model airplanes. This included drafting, graphic arts, photography, building, flying, and work in the machine shop where he designed and built a foam wing cutting machine. He later moved to the corporate office, where he streamlined the computerized order entry and picking system. Bill has over 20 years in insurance computer operations with American Income Life and American Amicable Life, separate companies in Waco, Texas, as an applications software programmer and as the systems programmer. Bill wears many hats. He currently maintains the IBM mainframe operating system, writes program interfaces for mainframe and network, and helps maintain the local network. He also writes applications for mainframe, PC,and Web based systems.

Q. Bill, to start off with your Efile, let’s go where it all starts, the scanning of the application in the field. You built a program for a standard inexpensive scanner which guides the agent through scanning the application and all the associated paperwork in the right sets, so it made sense to the home office when it came in over the internet. Will you summarize that program?

The program provides an icon on the PC screen for each step. An "application" includes the app and all supporting documents. An app "set" includes all applications that you need to keep together, i.e. apps on the same person or family. So the first icon starts a set, the second icon scans more pages of the app, the third starts a new app in the set (if there are any), and the first starts a new set again. I also included icons for sending the data, and for deleting data. We provided detailed instructions, with screen prints, for the agents on the company web site.

Q. When the documents have been transmitted, how do they queue up to be submitted? How does the submit clerk know there is one waiting? Do the images go anywhere first, and require any processing, before being submitted? If the clerk can select among the queue, how is that done?

The documents are transmitted into a "RECV" queue on a server. A program on that server wakes up and processes the images. It opens a package file that tells it what was delivered. This keeps the "sets" or families of apps together. Each set is then placed in the "INBOX" queue ready for a clerk to work. A clerk runs an image viewing program called "Appview". This program looks in the INBOX and shows the clerk what , if any, they already have in progress. When they are ready to start another "app set" they request "next" and the program grabs the next one and tags it as theirs. There is no picking and choosing, they get the next one in the queue. If for some reason they cannot work it they can leave it as "In process" and request next for the next app set.
"Appwait" can be put into "Sleep mode" where it is minimized and goes to sleep until new apps appear in the "INBOX" for a clerk to work. It then pops up and ask them if they want to do some work.

Q. After some experimentation, it was decided to give the submit operator two monitors, one for the image of the app, the other to use to submit the information. How does the image of the app get the assigned policy number associated with it, and into the Efile for that policy number? Since the application never is reduced to paper, how do you obtain process control so everything goes to the right place for the rest of the process?

The operator submits by viewing the image in "APPVIEW" and submitting thru "PCSUBMIT". When the completed submit is entered, PCSUBMIT puts the policy number in the clipboard. The operator switches to the APPVIEW screen and pastes the number in one of the policy number slots. We have 5 slots in case it is a combo app. When they are finished submitting policies from the image they click on "FILE" in APPVIEW and it assigns the number to the image, files it in Efile, and creates an email with a link that is sent to the PI Checking operators. An MIB request is automatically generated. The PI Checking operator opens the email, clicks the link which takes them to EFile for that policy. They review the checking sheet against the image. If all is OK and there is no MIB hit they can issue the policy. Otherwise they forward the email to an underwriter for additional follow up, adding any information that is appropriate.

Q. You note that the MIB is automatically requested. You did not elect to use the more expensive on line program that would have allowed mainframe to mainframe communication with MIB, so how do you get the request to the MIB PC? Is that a manual process? Also, when you get a positive response, how does that come to the attention of the underwriter?

The submit transaction is a mainframe program, and upon submit the request for a MIB is sent by the mainframe to the network via a CGI web page. It is done automatically by a program that acts like a web browser. The request is then manually imported by a clerk 3 or 4 times a day to the MIB machine and transmitted to MIB.

Q. Once you have the application and the underwriting documents in Efile, you want all of the other items that go into a file so you never create a paper file for that policy. You have items coming from the mainframe, such as outgoing letters from the correspondence system, manually scanned incoming correspondence and documents, emails, and outgoing letters created in Word and manually printed and mailed. How do you get all that into the folder for that policy number so everything can be viewed in a web page?

The mainframe is sending material generated by CICS programs, batch programs, and from the print queue. We have programs that convert from EBCDIC to ASCII as necessary, and the items are sent down by policy number and doc ID. The actual filing is done by a PC program.

The scanned images are TIFF group 4 which compress smaller than jpg. The Image is scanned by our EFileScan program. The clerk enters the policy number and selects a description, then clicks file. The program then files the image into EFile. Emails that arrive are answered back by email and to an Email robot. The subject line contains "pol=1234567.docdescription" which is used by the Email robot to file the email in EFile. Word documents are handled the same way just as attachments. The clerk can also add free form notes to Efile as a separate document.

Workflow is handled by email, containing links to the efile. Routing can be to specific individuals or to groups of clerks.

Q. One huge benefit of storing items in web pages on your server is the ability to let the policyholder see, and copy, any of the items you choose to put in that category. A good example is the actual policy issued. Policyholders will request a duplicate policy rather than look through their records for the original. With your system, not only can the home office print a duplicate, with the exact forms and data, but you can make that available to the policyholder on your web site. The policyholder can print his own policy, as many times as he wants. And you can let him see prior correspondence and any other item he is entitled to get a copy of.

Yes, this can really resolve the duplicate policy problem. We do not actually store an image of the policy, but rather build a PDF on the fly for each request. I capture for Efile the variable data and the identity of all of the forms from policy print, as the original policy is printed on the mainframe printer. The requester is not actually looking at any portion of Efile, but rather a construct by a program on the server using the parameters obtained from Efile. We do not currently make any of the images in Efile directly available to the policyholder on our site, but there is no reason we can't, once we sort out the practical issues of what to make available.

Q. What about storage issues. You are keeping everything on your servers, and you have big hard drives. But you are going to have a lot of folders. Is this going to be a problem?

As efile gets larger things like backup can get very time consuming. I use a 3 terminal digit filing to keep an even spread over the hard drive. Still, it is going to get to the point where we spread over two or more hard drives. We aren't there yet.

Q. You have also created separate efile systems so that all documents, regardless of the department that will eventually use them, can be scanned in the agency offices in the same way they can be in the home office, and transmitted electronically. How does that work?

This is the general procedure for scanning documents other than applications. First the document is scanned. If there are multiple pages to the document you continue scanning. When complete you "File" it to your local system. After Filing all documents you "Send" them to the Home Office along with a package file that will be used to know what arrived. When they arrive at the Home Office they are processed by an automated program. This program looks first at the package file to see what to process. Each file is then filed to it's respective file system. We have a Policy Owner efile and an Agency efile area (items like contracts and licenses) the home office was already scanning documents to. Now it doesn't matter where the document is scanned, it works the same. Each has its on rules. Based upon what came in, a notification is sent to the clerk(s) who will handle the document.

The POS Efile front end is all web based. It has security on it. Each document has a security key and if a user has that level of security they can view the document. If not, the document description shows as an item that they cannot view. Examples are medical information and death claims. Only an underwriter can see the medical, but the clerk can see the description so that she will know that medical information has been received.

Q. I see where you are headed. Once you work with all documents scanned, you might as well get them scanned at the earliest possible point, which right now is the agency office. You save everyone time and postage. With scanners now becoming ubiquitous, good ones available at less than $100, the next step might be direct transmission from the policyholder. The challenge of course is how to get the scan without having your special programs on their machines. Perhaps by filling out a web page and emailing from it with the scan attached. Of course, a bigger question is how long it will take the industry to just catch up to where you are, scanning apps from the field.

COMMENT: When a company first eliminates paper, it is easy to forget that in the previous systems steps were driven by the arrival and presence of paper documents. If you don't create alternative systems, you will start losing things. Previously underwriting knew it had an application because a piece of paper came, and if it wasn't moved to the next station you had a STACK. When things are images stored on servers, there are no stacks to warn you if you forget to process what the system delivered to your screen. The email that the clerk received when the document first came in will not show whether the clerk acted on the document. Applications are perhaps the easiest, since once submitted there is a pending master file which can be regularly queried to spot items that have been there too long. With agent licensing material and policyholder requests there is no preexisting pending file, so a similar pending device has to be created. In some instances it can be as simple as not moving an email to a completed folder unless it has a reply or forwarding email with it.