Enhancing Workflow Automation in Insurance Underwriting Processes
with Web Services and Alerts
Raymond C.M. Lee, Kai Pan Mark, and Dickson K.W. Chiu, Senior Member, IEEE
Department of Computing, The Hong Kong Polytechnic University
email: 04739356g@polyu.edu.hk, csmarkkp@comp.polyu.edu.hk, dicksonchiu@ieee.org
Abstract
Underwriting is one of the important processes in insurance operations. The applicant's information, including
various kinds of medical information, must be evaluated
before the insurance company can decide to accept the
application. These activities are usually supported by process automation facility. However, the support of exception handling mechanism and the monitoring of turnaround time in those process automation solutions are usually inadequate. This results in a low efficiency of the underwriting operations or even loss of business opportunities. To address the problem, this paper presents an Alertenhanced Underwriting System (AUS), which handles the
exception events and monitors the turnaround time with
the concept of alerts. We further illustrate how Web services facilitate workflow integration and process communications.
1. Introduction
Life insurance provides protection against the economic loss caused by the death of the person whose life is insured [1]. Because of its popularity, it is a business where
many insurance companies allocate many resources in
order to gain more market share. A life insurance policy
defines the terms and conditions for the prospective client,
particularly the situations under which the insurance company promises to pay a benefit upon death [2]. Since life
insurance products can provide a stable “cash inflow” for
an insurance company, there is a trend that insurance
companies market various life products, such as investment-linked life products, savings life products and critical
illness protection, in order to attract more customers with
different needs.
Although life insurance business can generate financial
benefits to the insurance company, the company still needs
to bear financial responsibility to pay the insured under
some agreed conditions, e.g., the insured dies during a
specified period. The insurance will face the consequence
of financial loss if the company accepts prospective clients,
who present extremely high risks and when some of these
insured persons die soon after policy issuance. High quali-
ty processes are necessary to assess the degree of risks
associated with each application of life insurance. Underwriting (which is also known as “new business”) is a process of assessing and classifying the degree of risk represented by a prospective client and making a decision to
accept or decline the insured.
The world of electronic collaboration is developing
rapidly, introducing new technology and new ways of collaboration. The success of collaboration often depends on
the ability of a corporation not only to make sure that their
applications are dynamic, but also to maintain a high degree of interoperability with collaboration partners.
In this paper, we present an Alert-enhanced Underwriting System (AUS) as a collaboration platform for streamlining the workflow of insurance underwriting processes.
AUS makes use of an Event-Condition-Action (ECA) collaboration model [13] to manage event handling, process
integration, and alert/exception management for the process flow of the underwriting operations.
The rest of the paper is organized as follows. Section 2
discusses some related work and background requirements.
Section 3 describes system design and implementation for
our AUS. Section 4 concludes our paper with our continue
research work that look forwards to possible enhancements.
2. Background and Related Work
Electronic Data Interchange (EDI) essentially defined
the technology of electronic collaboration in the past.
However, EDI is an expensive solution, due to its high
cost of network infrastructure and system integration. In
addition, security issues of EDI also limited corporations
from directly accessing the computing resources of its
trading partners, which used "firewall-unfriendly" protocols. Therefore, developers start to find other technologies
which have a low cost, flexible software solution that allows corporations to build new applications in response to
changing business needs while adhering to a defined electronic business standard [10].
Recently, numerous vendors have offered solutions to
support both XML (eXtensible Markup Language) and
EDI formats for collaboration. One of the solutions is the
transformation of information between companies: XML-
to-EDI. Transformation is critical to an "edge" integration
strategy that brings together B2B collaboration and enterprise application at the boundary of an enterprise in order
to enable the back-end connectivity and workflow required to support a complete business process [11].
In the XML world, e-Business XML (ebXML) [12] is
a modular suite of specifications which are initiatively
designed for electronic interoperability. The strength of
the ebXML architecture is that it provides a framework for
electronic business collaboration. The architecture enables
businesses to work together to specify business process,
discover one another, negotiate collaboration agreements,
and execute business processes. However, although
ebXML implementations are already being announced, the
rate of deployment of ebXML is not quickly accelerated.
Many companies are taking a "wait-and-see" approach
until ebXML becomes a mainstream in the market.
2.1. Key Processes and Integration
Branch/Zone Offices
Head Office
Policy Dispatch
Docs
Print Server
Agent
Cashier
Approved
Cases
Data Entry
Import
Workflow Engine
Transfer Module
Scanning
warehouse
Index & QC
Case
Assignment
File Server
Workstations
Workstations
Workstations
Figure 1. A typical underwriting process
Figure 1 illustrates a typical underwriting process,
which usually consists of the following four key activities:
A. Performing field underwriting,
B. Reviewing the application for insurance,
C. Gathering additional information to make a
sound decision, and
D. Making an underwriting decision on the case [3]
However, before a new case is sent to an underwriter
for processing, there are other activities involved:
1. Packing application forms and other documents from
the agent
2. Initial premium payment through the cashier entry
system
3. Data entry of new application in a branch or zone
office
4. Scanning documents into images for workflow pro-
5.
6.
cessing
Quality Check (QC) and Indexing on the scanned
documents
Release of the validated and scanned documents images into workflow engine for further processing
In the traditional way of performing the activities 1 to
5 without any automation processes, it incurs high cost in
human resource, storage cost, and paper work, together
with a high turnaround time. That means it causes the underwriter to spend a long time to handle a new application.
This affects the insurance company’s reputation and may
further induces financial losses or even legal penalties.
With the advent of information technology, most of the
above activities are linked together to streamline the workflow for processing a new business, starting from receiving documents from an agent, ending at the underwriter
getting the case from workflow system and issuing new
policy if approved.
Some benefits accrued to the business for automating
the entire underwriting processes:
 Improvement of the service quality (such as turnaround time)
 Reduce of the risk of losing submitted documents
during delivery
 Transfer of applications to the next step of the process
immediately
 Better control of risk management such that some
cases (i.e., excess of coverage limit) can only be approved by senior underwriters
The key integration of the processes between the
agents and the underwriters are as follows.
Images and Data Transfer Process – This activity is
an automated process and does not involve any manual
operation unless the sub-system is down or errors / inconsistency occurred during the transfer. The purpose of this
process is to transfer the scanned images and indexed data
from a branch or zone office to the central office for importing into the workflow system. If the network linkage
between a branch or zone office and the central office is a
private connection (i.e., leased line), the operation is just a
simple transfer of document images into the file server in
the central office with an XML file including all the indexed data. If the network connection between both sides
is public (i.e., the Internet) and it is not a Virtual Private
Network (VPN) connection, then the interactions require
other security measures as described in later sections.
Import Robot and Workflow Engine – They are located at the central office of an insurance company. The
engine waits for the image files and XML data to be uploaded from the branch or zone office and verify the XML
data integrity with the appropriate XML Schema. The imported document images and indexed data are installed
into the existing workflow routing engine for case assignment to appropriate underwriters for further case approval.
2.2. Requirements Overview of Stakeholders
In automated underwriting processes architecture, a
workflow engine (e.g., eistream [9]) is deployed at the
central office. This engine can efficiently route job assignments to appropriate underwriters. The processing
performed with the workflow engine is usually referred to
as post-processing of the workflow. There are many preprocessing activities, which must be completed before
those new insurance applications can be imported into the
workflow engine for further underwriting. Figure 2 depicts
a use case diagram of the underwriting process. The key
stakeholders involved are discussed as follows.
Issue
Pending
Records
Submit
Docs/Payment
Agent
Issue Policy
Premium
Payment
Underwriters
Decline
Application
Cashier
filing
application
Check
Missing Docs
Data Entry
Assign jobs to
work queues
Input
Application
Scanning Officer
Check
scanned
image quality
Scan
document
into system
Index Officer
Check Batch
Problems
Approve
document
images for
upload
Verify Upload
Batch
Workflow Engine
QC Officer
Import data and
images into
workflow engine
Upload data
and images to
file server
Transfer Module
MIS Staff
Check index
accuracy
Index
document
images
Import Robot
Figure 2. Use Case diagram for the underwriting workflow processes
Agent – He/she is an authorized representative to sell
insurance products on behalf of an insurance company.
The agents have the responsibilities to perform a simple
check first by gathering initial information about prospective clients and screening applications who have requested
coverage [4]. They have to gather required documents
(such as health certificate) from the prospective client in
order to speed up the underwriting process. Email access
or Internet portal are the prompt means for agents to
communicate with an insurance company.
Cashier Entry – For a new application of life insurance, the prospect client is required to pay the initial premium in the form of cash or check. The amount of premium is also dependent on the payment mode of the proposed policy. The agent has to submit the initial premium
with the application. The cashier entry will collect the
initial premium and put a premium receipt record in a
“Premium Collection System.” The Cashier Entry also
files the application forms and documents for data entry.
Data Entry – A user in branch/zone office enters the
information recorded on the application form, such as the
policy owner information, proposed insured information
or medical information, etc., into the underwriting frontend input system.
Scanning Officer – When a scanning officer receives
the documents, including application form, from an agent,
he/she will try to sort and classify the documents into different document types (such as health certificates, identity
proofs), and then scan them into images for auditable
backup as well as indexing and quality check (QC). The
application form is scanned just for auditable backup because the data has already been entered.
Index and QC Officer – After the submitted documents have been scanned into images, the index and QC
officers (it may involve two individuals) will try to index
the fields on several regions of a scanned image and save
the indexed data into the database, so that the indexed data
can be adhered with the corresponding images and imported into the workflow system. If the index officer discovers
that the image quality of scanned document is not good,
the document must be rescanned until the image quality of
the document is acceptable for indexing.
Underwriter – An underwriter is assigned with a case
(new or pending case) by the workflow engine. The underwriter carries out an assessment process by considering
the submitted documentations, medical information, other
personal factors like age, driving history, tobacco use,
career nature, and financial factors of the potential client,
etc. Then, the underwriter will determine whether the application is approved, pended for additional proofs or documentation, counter-offered to the applicant, or rejected.
2.3. Alert and Exception Handling
Although most of the activities starting from submitting documents in branch or zone office to the back-end
underwriting processes are automated, there are still many
events, both business-oriented and technology-oriented,
must be handled in order to streamline and speed up the
entire underwriting process.
Exceptions are events that can drive not only reactions
performed by business parties [6], but also information
exchanged within an organization, across physical boundaries (e.g., departments located in different geographical
areas) or within (e.g., underwriting department and printing service department located in the same building) individual organizational boundary. In order to handle the
exceptions and monitor the exception handling process,
(especially those important and / or with urgency requirements), Chiu et al. [6] proposed the use of alerts to model
and implement this. The key differences between alerts
and exceptions are that alerts represents messages sent to a
target, usually with time and urgency constraints, and that
alerts are monitored and tracked. That means, to handle an
exception, an Alert Management System (AMS) sends an
alert message to a handler (human or system) and keeps
track of the process until the handling job is finished.
In this application, the main objective of applying
alerts is the concern about the turnaround time in the insurance application process. Some key exceptions and
alerts generated by the main stakeholders are listed as follows.
Agent – Cancellation of an insurance application can
trigger an alert to the central office so that the workflow
system can change the application status (if it has been
imported into workflow engine) into pending status and no
more human resource will be wasted on this application.
The application will ultimately be cancelled after the cancellation form is scanned and imported into the workflow
system. The AMS can therefore make sure that the case is
closed within a reasonable time limit.
Cashier Entry – An alert can be generated when the
agent submits an initial premium payment for the new
applicant but only part of initial premium has been settled.
The alert can notify the central office underwriter to solve
the application case if the case has been pended for the
reason of insufficient premium.
Scanning Officer – Exceptions can be generated if the
agent submits unknown type of documents or forms. If the
workflow automation system does not know how to handle the unknown type documents or forms, then “unknown
document” alert can notify the corresponding agent about
this issue and urge him/her to fix this within a certain period.
Index and QC Officer – A “Document Rescan” alert
can be generated to the scanning officer if the index officer finds the document image quality is too poor to be
indexed. A QC officer can also generate a “Reindex” alert
if he/she found that an index officer did not correctly index the fields on document images. QC officer can also
trigger “Document Rescan” alert if he/she found the quality of document image is unacceptable even the index officer has accepted the quality of document image.
Underwriter – An “Insufficient Initial Premium” alert
can be generated so that the agent can be notified that the
initial premium must be settled before the policy can be
issued even all the underwriting checks are passed for the
case. This situation may occur when the client paid the
initial premium with check but the check could not be
cleared.
On the other hand, exceptions and alerts can be generated by automated processes, such as the following:
Images and Data Transfer Process – A “Transfer”
exception can be triggered if the transfer process of images and XML data to the central office file server is not
completed or failed/aborted at some points (because of the
stability of network connection). An alert can then notify
the MIS staff in the branch or zone office to investigate
the root cause of transfer failure and resume the transfer
process as soon as possible. An alert can be triggered after
the transfer process of the branch or zone office is completed successfully, so that the import robot resided on the
workflow engine can start the data verification process and
import the images and data into workflow system. This
helps to shorten the total time for processing of new applications and monitor pending cases.
Import Robot and Workflow Engine – A “Data Inconsistency” alert is sent to the agent if the import robot
checks that the XML data uploaded from the branch or
zone office contains inconsistency after validating with
XML schema. This alert urges the agent to repeat or fix
the images and data upload process.
Workflow Engine - An “Application Pending” alert is
triggered to the agent who submitted an application for
his/her client when the underwriter changes the new application status to “pending” because additional documentation is required. This alert urges the agent to contact its
customer for the relevant documents before he receives an
official “document request” letter from the insurance
company, as applicants may need time to present documents, like health certificates or financial statements issued by banks.
2.4. Relationship management requirements
Alerts and exceptions are not only dedicated to handling abnormal or unexpected events. These can be used to
enhance the relationship between insurance company and
potential customers (B2C). For example:
Applicants can be notified by email with the progress
of its life insurance application. On the other hand, the
agent can contact his applicants promptly after he receives
an acknowledgement email. Reminder alerts can be sent to
the agent in the form of SMS to remind him/her to contact
his/her applicant to collect required additional documents
to process a “pending” application. This helps reduce the
risk of insurance application being cancelled after an application has been pending for some time. This is because
the customer may not know that insurance company requests more additional documents from him in case the
agent does not contact him. This also reduces the chance
of giving a negative image to the potential customers of
poor services.
Agent
Desktop
MIS Staff
Mobile
Scanning
System
Index &
QC
Transfer
Module
SMS/Email
Adaptor
XSLT Processor Agent
MSMQ
Message
SOAP
SOAP
SOAP
Web Services Agent
Cashier
Entry
Clients
Firewall
Branch /
Zone
Offices
Cashier/
Scan Officer/
Index Officer/
QC Officer
PDA
MSMQ
Message
SOAP
Head
Office
MSMQ
Message
MSMQ
Message
Message Server
(MSMQ)
Alert
Management
System
ECA rules
Event Repository
Event Subscribers List
Business Entities
MSMQ
Message
Existing Enterprise Systems and Workflow Engine
Data and
Image Import
Robot
Underwriting
System
Printing
System
Servers
Other
Enterprise
Systems
Firewall
Figure 3. System Architecture for AUS
3. System Design and Implementation
In this section, we present the system design and implementation for our AUS, which includes the system architecture, various system components, Web services security, and an example scenario.
3.1. System Architecture
Figure 3 shows the overall system architecture for our
AUS. We add on top of the existing enterprise information
systems four main components in the backend AUS: Web
Services Agent, Message Server, Alert Management System (AMS), and Event-Condition-Action (ECA) rules
database that defines the actions to be triggered under
some predefined conditions. We discuss the functionalities
of these components in the following subsections.
One of the main problems in the current process automation is the effectiveness of communication among different stakeholders and systems involved in the entire process of underwriting. Based on the above discussions, we
design an AUS based on exceptions and alerts as the unifying communication platform within the entire underwriting processes. On this platform, we choose to use Web
Services with SOAP protocol for the communication and
Message Server (such as Microsoft MSMQ [8]) for the
underlying message (exceptions and alerts) processing.
The reasons why we choose Web services with SOAP
protocol in our platform are as follows:
 Web services can be invoked over the Internet or in-




tranet, within or outside the firewall. For example,
some processes like document scanning or image indexing may be located in the central office or outsourced to other service providers.
Less development time is required to deploy Web
service features from existing application, especially
with the tools and libraries provided.
It supports synchronous (RPC) and asynchronous
messaging.
SOAP has been implemented on many different
hardware and software platforms.
SOAP can be protected under the Web Service security [7] standard.
3.2. Web Services Agent
In our system, Web services technology is chosen to
support the communication between the AUS backend
systems and other front-end, sub-systems in branches and
zone offices, as well as external agents and clients. The
Web Services Agent transforms the incoming messages,
which are in the form of XML data embedded in SOAP
(Simple Object Access Protocol) [14], into native message
formats that can be sent into the queues of the central message server. The Web Services Agent also transforms the
alerts and exceptions from the form of native message
format into the XML/SOAP format and uses HTTP protocol to send the XML message to the branch/zone offices
systems through respective Web services.
A sample SOAP messages from a client system is
shown in Figure 4. This message describes the indexed
data and images to be uploaded to the file server in the
insurance headquarter after scanning operations have been
performed on the submitted documents in branch and zone
offices. Figure 5 shows a response message from the AUS
that describes an alert from the Transfer Module in a
branch or zone office and notifies the MIS staff to handle
the exception.
Request SOAP Message
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body xmlns:m="http://www.insurance123.com/imaging">
<m:System SYSID="TRANSFER_MODULE" FUNCID="UPLOAD">
<m:TotalCases>100</m:TotalCases>
<m:Policy>
<m:PolicyNo>B100000101</m:PolicyNo>
<m:DocumentID DocID="F10001">
<m:ImageFilename>B100000101_1.TIF</m:ImageFilename>
<m:ImagePages>4</m:ImagePages>
<m:IndexField FieldID="OWNER">JOHN LEE</m:IndexField>
<m:IndexField FieldID="INSURED">MARY CHAN</m:IndexField>
<m:SignatureFilename>B100000101_SIG.TIF</m:SignatureFilename>
</m:DocumentID>
</m:Policy>
<m:Policy>
.......
</m:Policy>
</m:System>
</soap:Body>
</soap:Envelope>
Figure 4. Request SOAP Message
Response SOAP message
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body xmlns:m="http://www.insurance123.com/imaging">
<m:System SYSID="AUS" FUNCID="EXCEPTION"
SOURCE_SYSID="TRANSFER_MODULE">
<m:ErrorCode>9001</m:ErrorCode>
<m:ErrorMsg>Upload Batch 10A was rejected because the missing files
found in the following policy images. Please upload the batch again.
<m:/ErrorMsg>
<m:ErrorMsg>B100000101_1.TIF was missing in file server.<m:/ErrorMsg>
......
</m:System>
</soap:Body>
Figure 5. Response SOAP Message
3.3. Message Server
The message server comprises of application queues
and system queues and the server manages the received
data (i.e., incoming XML/SOAP messages, internal
MSMQ messages from other enterprise systems, and alert
messages from the AMS and routes the messages to the
target (subscribed) parties. For example, when the Transfer Module sends a Web service message to the AUS, the
message is put into two waiting queues: one for the Import
Robot and another for the AMS (so that the AMS can
monitor the progress of the Import Robot). When the Import Robot has verified the integrity of uploaded data and
images, it sends a message to inform the AMS of job
completion, or a “Data Inconsistency” alert in case of data
inconsistency. These messages triggers events so that the
AMS issues new alert/exception messages upon on the
conditions in the event repository database to related parties for further actions (as discussed in Section 2.3)
based on the ECA rules defined by the administrators.
The reasons why we choose the Message Server as a
core component in managing data communication are as
follows:
 Most of the message servers support Web service
functionality.
 Message servers support guaranteed message delivery.
 Asynchronous message communication as well as
publish-and-subscribe can be supported.
3.4. Alert Management System (AMS)
The main role of the AMS is to manage the alerts. It
also captures the events and exceptions (i.e., MSMQ native message format) submitted by other parties. Alerts are
generated based on the ECA rules specified in database to
the appropriate parties. It further transforms the alerts into
a MSMQ message and put it on the waiting queue for Web
Services Agent for the delivery. Further details of the
mechanism of the AMS, including descriptions of the
ECA rules, can be found in our earlier paper [6]. We apply
the same AMS module except that we include a message
server component to further increase the messaging reliability.
3.5. Example Scenario
In this subsection, we use a scenario to illustrate the
system flow in our AUS. Figure 6 depicts the process flow
for this scenario. First, a Scan Station prepares a XML
data file which contains the policy number and other indexed data for the scanned documents. When the XML
file is ready, the Transfer Module uploads the XML file
and document image files into the central file server. Upon
completion, the Transfer Module generates a SOAP message, which details the uploaded data to Web Services
Agent in order to notify the Import Robot to verify the
integrity of uploaded data and images.
After the verification, the Import Robot generates the
verification result event and the AMS captures the “data
uploaded” event from the Transfer Module together with
the event generated by the Import Robot, and returns the
appropriate events back to the Scan Station and Scan Officer based on ECA rules processing.
Scan Station generates XML data for upload process
Start
Upload XML data and Image files into File Server
Generate SOAP Message to Web Service Agent
Import Robot verifies the data and images
AMS captures event
Generate Verification event
AMS analyzes and generate response message
<soap:Envelope soap:xmlsn="http://www.w3.org/2002/12/soap-envelope">
<soap:Header>
...
</soap:Header>
<soap:Body>
...
<x:Policy PolicyNo="B100000200" x:xmlns="http://www.insurance.com/payment">
<x:Payment Type="CreditCard">
<x:CreditCard Type="Visa">
<x:CardNumber>4404119200931293</CardNumber>
<x:ExperationDate>200710</ExperationDate>
<x:PaymentMode>ANNUAL</x:PaymentMode>
<x:Amount>1200.00</x:Amount>
<x:Currency>HKD</x:Currency>
</x:CreditCard>
</x:Payment>
</x:Policy>
...
</soap:Body>
</soap:Envelope>
Figure 7. Unprotected SOAP Message
Web Servies Agent transfers the message into SOAP message
Send SOAP Message to Scan Station
Generate SMS/Email
Send SMS/Email to Scan Officer/MIS Staff
Upload XML data and image again
Figure 6. Activity flow between Transfer Module and
Import Module
3.6. Web Service Security
Web services integrate applications inside and outside
the organization. However, distributed computing always
has a challenging set of security issues. Identities and messages are two of the greatest security challenges brought
on by Web services. Web services transport potential unknown entities into your organization and messages are
transported from one place to another place through an
unsecured channel, the Internet. Therefore, actions must
be taken to safeguard the information exchanged among
the authenticated parties. XML Encryption and XML Signature are used to address the protection of sensitive data
and the identification of identity of data sender respectively [15]. Figure 7 shows an unprotected SOAP message
that contains payment information for an insurance policy.
Figure 8 shows how encrypted messages and signature are
put in a SOAP envelop.
<soap:Envelope soap:xmlsn="http://www.w3.org/2002/12/soap-envelope"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:xsig="http://www.w3.org/2000/09/xmldsig#"
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext">
<soap:Header>
<wsse:Security>
<xenc:ReferenceList>
<xenc:DataReference URI="#PaymentID"/>
</xenc:ReferenceList>
</wsse:Security> ...
</soap:Header>
<soap:Body>
...
<xenc:EncryptedData Id="PaymentID">
<xenc:EncryptionMethod
Algorithm= "http://www.w3.org/2001/04/xmlenc#tripledes-cbc"
<xsig:KeyInfo>
…..
</xsig:KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>...</CipherValue>
</xenc:CipherData>
</xenc:EncryptedData>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
.......
</SignedInfo>
<SignatureValue>
Y4MhHzBYz+CBdAz1LhAFjy6QxQoKJoA7l2eG45QV0hDIJrmXwLEG
</SignatureValue>
<KeyInfo>
.....
</KeyInfo>
</Signature>
...
</soap:Body>
</soap:Envelope>
Figure 8. Encrypted SOAP Message
The <EncryptedData> element block contains the encrypted form of payment information. The <Signature>
element contains the XML signature for payment data. In
general, a shared key must be provided so that receiver of
the messages can decrypt the protected data. However, it
is a bad idea to include the key in the SOAP message (i.e.,
the <KeyInfo> element block) because unauthorized parties could just get the key and decrypt the protected data.
AgreementMethod is a protocol for safely communicating
a secret key. This key agreement protocol, like the SSL
secret key agreement protocol, is used to generate the encryption key along with the key material necessary to repeat the encryption key generation on the recipient’s side
[15].
4. Discussion and Summary
Process automation by integrating existing enterprise
information systems with workflow software has proved
to increase the staff productivity, thus turns out to generate
more business values in terms of more revenue and less
expenditure. However, if the process flow within a business workflow from one step to next step is not smoothly
executed (e.g., failure of transferring complete XML data
to workflow engine and servers but no further “resend”
action is done), then the next step may not be able to proceed until the problem is detected and fixed. This kind of
situations significantly wastes human resource and time
and should are not expected to occur in automated processes. Therefore, by integrating the AUS with the existing workflow infra-structures can bring the workflow automation into full play because the errors or unexpected
events can be detected and relevant parties or processes
are notified with alerts to rectify the problems. The following tangible benefits can be achieved with the AUS, mainly through the enhanced monitoring and tracking through
the AMS with a service-oriented architecture.
For example, the turnaround time taken to rescan documents, which have been identified as poorly scanned, is
shortened. If the scanning officer is not notified properly,
the poorly scanned document will probably be rescanned
after the scanning officer triggers to print out a report on
listing those document rescan requests, thus resulting in
longer processing time in some cases. This benefit is also
applicable to the process of “Document Reindex” for the
index officers.
Moreover, the AUS helps maintain data integrity in
uploading data into the centralized file server. If the XML
data is inconsistent and the import robot still proceeds to
import the inconsistent data into workflow engine, it will
result in unexpected or serious consequences. The consequences may be a delay in processing applications or even
a wrongly underwritten insurance application that could
put financial risk to insurance company.
On the other hand, more attributes can be added to
measure staff performance. Since the alerts generated to
officers and agents are monitored by the AMS, the time
spent on handling the exceptions and alerts can be calculated based on the time recorded in database. For example,
if a scanning officer receives a “document rescan” alert,
then he must rescan the requested documents and relevant
records within the “document update time.” The performance is logged into database and reports for staff can
include this kind of attributes to measure the staff performance. So, the workload on investigating problems related
to the entire operation flow can be reduced as detailed
information about the problems can be found from the
exceptions and alerts well managed by the AMS of the
AUS.
In addition, the following intangible benefit can be
achieved with the AUS. Customer satisfaction can be improved. The document processing and flow are smoothly
controlled and executed. This can shorten the entire processing time for new case applications and thus result in
issuing and sending policy to policy owner within a shorter period of time. This can enhance the insurance company’s professional image as well because the short processing time of new insurance application can impress its
customers and improve the customers’ confidence in insurance company. This might led to more business opportunities in the future.
This paper has presented an overview of underwriting
process in an insurance company and the automated facilities incorporated into the underwriting process to drive the
entire underwriting. A Web-service based alert-enhanced
underwriting system has been presented in this paper to
overcome most of the existing problems of the underwriting process workflow implementation. We expect this
approach is suitable to other business processes that involve human approval together with the need for maintaining documents for auditing and legal purposes, such as
loan and credit card approval.
After finishing the AUS platform prototype, we shall
then proceed to study the benefits of adopting the platform
in existing workflow infra-structures in the insurance
company’s perspective through questionnaires to collect
user feedback. Although the proposed platform obviously
facilitates the handling of most problems or events in the
process flow of underwriting, there are still some unexpected events that are hardly to be detected or tracked.
Further studies should be carried out on this topic. Future
works include the extension of AUS platform to support
artificial intelligence in handling the exception events as
well as agent-based assistance to internal staff and external
users. We are also interested in empirical measurements of
the improvement of staff performance and customer satisfaction.
Order Received
Begin
Enquiry
Received
Check
System
Config
Prepare
Quotation
Send
Quotation
Req
Extra
Info
Send
Extra Info
Deliver &
Install
Install
Software
Test
System
Payment
Received
End
Request
Extra
Info
Sell Integrated System
References
Order
Missing
Parts
Begin
Assemble
System
[1] Miriam Orsina, Gene Stone, “Insurance Company Operations” (2nd Prepare
Ed), pp.3,
LOMA, 1999
Service
System
[2] Harriett E. Jones, Dani L. Long, "Principles of Insurance:
Integrator
Life, Health and Annuities" (2nd Ed), pp. 8, LOMA, 1999
Update
[3] Jane Lightcap Begin
Brown, KristenCatalog
L. Falk, "Insurance
End Administration", (2nd Ed), pp. 22, LOMA, 2002
[4] Jane Lightcap
Brown, Kristen L. Falk, "Insurance AdminReceive Part Info Updates
istration", (2nd Ed), pp. 67, LOMA, 2002
[5] Miriam Orsina, Gene Stone, “Insurance Company Operations” (2nd Ed), pp.243, LOMA, 1999
[6] D.K.W. Chiu, Benny Kwok, Ray Wong, E. Kafeza, and S.C.
Cheung, “Alert Driven E-Services Management,” HICSS37,
IEEE Computer Society press, CDROM, 10 pages, Jan 2004
(Best Paper Award, Decision Technologies track).
[7] OASIS, Web Services Security Core Specification 1.1,
http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=wss, 2004
[8] Microsoft
Message
Queuing
MSMQ,
http://www.microsoft.com/windowsserver2003/techno
logies/msmq/default.mspx
[9] Global 360, http://www.global360.com
[10] Dynamic
e-business
using
Web
service
workflow,
http://searchwebservices.techtarget.com
[11] EDI
Prepare
Service
and
XML
Solutions
-
iWay
Software,
http://www.iwaysoftware.com/products/edi.html
[12] ebXML
-
Enabling
a
global
electronic
market,
http://www.ebxml.org
[13] D.K.W. Chiu, S.C. Cheung, E. Kafeza, and H.F. Leung, “A
Three-Tier View Methodology for adapting M-services,”
IEEE TSMC, Part A, 33(6):725-741, Nov 2003.
[14] SOAP
(Simple
Object
Access
Protocol),
http://www.w3.org/TR/SOAP
[15] Jothy Rosenberg, David L. Remy, “Securing Web Services
with WS-Security”, pp 222-230, SAMS, 2004
End