|
||||||||||||
|
||||||||||||
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. |
||||||||||||
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. |
||||||||||||
|