Our scenario is based on the merger of two insurance companies:
- Lord General Insurance (LGI), a general insurance company, is a large enterprise with over five million policy holders, looking to boost its auto insurance business and requiring a quick entry to the e-business direct insurance market. LGI has a large legacy IT infrastructure based on S/390 and CICS.
- DirectCar.com (DC) is a modern dot.com auto insurance company that sells insurance through the Internet and has less than one million policy holders. It has an e-business focused infrastructure based on WebSphere Application Servers, Oracle databases, and TXSeries.
The scenario focuses on the merger, and has the following requirements:
- Improve the company's profitability by reducing administration costs overall, with an immediate focus on claims administration for existing products.
- Create an automated claims system for the joint customer base that connects the existing external services.
- Satisfy service level agreements as defined in customer requirements (performance and security guidelines, for example).
In this article, the claims system refers to the combination of processes and IT systems that are used in the processing of a claim raised by a client. As part of the merger of LGI and DC, a consolidation of the individual claims systems is essential. During an evaluation of the two claims systems, three requirements for merging the systems, improving claims administration, and reducing cost were highlighted. They are:
- Reengineer the business by combining the claims departments and creating a single claims process.
- Improve claims process management.
- Extend process management to include service provider and agent activities.
These requirements direct all implementation and improvements in creating the merged claims system. The merged claims system is not a brand new implementation, but an evolution of the existing claims system.
The claims system for DC is based around a three-tiered net-centric architecture that lets clients register claims online and receive updates on the status of their claims through e-mail or traditional mail. The IT infrastructure that supports the claims processing consists of a cluster of application servers that handle both the transformation and collation of data provided by the client, and sends this data in the form of requests to an off-the-shelf claims application in the back-end system. Replies from the back-end applications are sent to the application servers, where they are presented dynamically to the client as Web pages. Other processing is performed manually or in the back-end system.
LGI has a legacy infrastructure with all client applications sending requests to a central message hub that handles the transformation and routing to the required back-end applications or workflow systems. All replies from the applications are sent to the message hub for transformation and routing for the required client application. The client registers a claim by contacting the call center where the claim handler collects the required information over the phone. As with DC, all other processing is done manually, or through dedicated client applications accessible by the claims handler and claims supervisor. LGI provides channels for business partners into the message broker. The existing claims system for LGI and DC can be divided into four business processes:
- Register claim
- The client, in the case of LGI, contacts the call center, where accident details are recorded by a claims handler who completes the required forms and enters required information in the claims database. The claims handler then gives the client a claim number for reference. In the case of DC, the client logs on to the DC Web site and is able to register claims online. The claim reference is presented to the client online once the required processing is completed.
- Validate claim
- The raised claim is authenticated to confirm that the client's policy is valid and not expired, that the driver is insured on the policy, and that the details provided are accurate.
- Investigate claim
- The claim is investigated by requesting and acquiring the police and medical reports from the authorities. At this stage, the assessment company is contacted to perform an assessment of the damage and to make recommendations on how to proceed.
- Judge claim
- Based on all the information provided, the claims handler or claims supervisor makes a decision on whether the car is to be fixed or replaced, or the claim rejected.
In the existing system, while certain technologies are used for storing data and tracking claims status, these systems are disparate. Much of the interaction with the client and between departments is performed manually, on paper, using the mail or fax.
The main requirement of the merged claims system is that a common front-end be created for the merged company. As part of merging the claims systems, a consolidation of the IT infrastructure to leverage the best of both systems is crucial, and where possible, reuse of technologies and skills advised. One of the biggest challenges in the merger is the legal requirement that the data for the two companies must not be merged. This means that the DC and LGI back-end systems must be kept separate, and access to these back-end systems restricted so an employee can have access to either DC or LGI client data but not both. To this effect, the transformation and routing engine is central for data and message transformation, and routing of requests and replies to and from the relevant back-end systems. Merging the security policies of the two companies also influences some of the changes to be made to the business processes.
The improvements and implementation required to create the merged claims system are described below:
- Register claim
- The register claim process is automated by creating an online common Web interface for the joint customer base. Clients are able to raise claims online and get their claim references. The system is capable of connecting to existing external services. The common front end authenticates the users against the merged secured user directory, and provides a customized user interface for the internal users.
- Validate claim
- The validation of claims is automated by developing business process flows that represent the validation process and deploying them in a workflow engine.
- Investigate claim
- The investigation process is automated with integrated access to the assessment companies and other business partners. Using workflow technologies, the claims handler and supervisors have access to the different claims and are able to make decisions or correct errors where required.
- Judge claim
- This process is automated and linked to the other processes and services for access to any data that might be needed to help make a judgement.
In this section, we describe the architecture of the environment that supports the existing claims system and also supports the new merged claims system. We also describe the interactions, which are divided between users and components, and between the components and any other remaining components.
Figure 1 below shows the architecture for the claims system. This is a three-tiered architecture with the middleware and business process management (BPM) engines contained in the second tier. The third tier shows the servers and data stores that manage the client, policy, and claims data for LGI and DC. The first tier presents the client side of the system that provides customers with the ability to interact with the system over the Web. Internal users (claims handlers and claims supervisors) can access data through intranet Web applications and through the rich-client branch office application. Business partners use WebSphere Data Interchange (WDI) client applications.
Figure 1: The claims system architecture
Web users (clients, claims handlers, claims supervisors) access the index page where they are prompted for a user reference and password. Logic in the application server authenticates the users against a directory of registered users using the Lightweight Directory Access Protocol (LDAP), and the users subsequently get an option to confirm that their details are correct before being prompted to enter the information for their claim.
Once submitted, the data is sent as XML to the transformation and routing engine using messaging technologies. The transformation and routing engine checks if the client who raised the claim, or had the claim raised on their behalf, is an LGI or DC customer. Based on this information, the data is transformed to the required format and routed to the required back-end system. The DC system requires an in-house XML format, whereas the LGI system requires a legacy format. The back-end system, on receiving the data, stores it and generates a claim ID, which is sent back to the transformation and routing engine where transformation of the reply is done before it is sent to the application server to be presented to the user. At the same time, the claim ID and claim details are passed to the business process manager (BPM) for further processing.
Users of the rich-client branch office application interact with the system in the same way as Web users but bypass the application server and interact directly with the transformation and routing engine. Authentication of the user is performed against the same LDAP directory but directly from the client, and is implemented using Java SWING.
Business partners send and receive data using WDI. The data sent from the business partner is sent to the WDI Gateway where the required transformation is done for the data to be passed on the transformation and routing engine. Replies from the transformation and routing engine are sent through the WDI gateway back to the business partner. All other interactions remain the same.
All successfully registered claims are transferred to the validate business process.
On receipt of the claim ID and claim details, the BPM starts the validate business process, which sets the claim stage to "Validate." The inputted information is passed to the transformation and routing engine where transformation of the data for the required back end is performed. Subsequently, the data is routed to the back-end program where the verification of the inputted data is performed. For example, verification is done against the back-end data stores to ensure that the policy is not out of date. Based on the result of the verifications performed, the BPM sets the claim status to "Valid" or "Invalid."
The claim handler can log on to the system to view all invalid claims, and contacts the client to rectify the problem. For instance, if the data was entered incorrectly, it is corrected and the process is restarted, or else relevant action is taken that might involve canceling the claim.
When all validation and verification steps have been completed successfully, data is sent to the BPM indicating that the status of the claim should be set to "Valid." A valid claim is automatically passed on to the investigate business process.
When the validated claim data has been received, a notification detailing the status of the claim is sent to the client using their preferred method of contact (e-mail, fax, or mail). All valid claims in the investigate process are presented on the claim handler's work list. The claim handler, after authentication, can view the details of a claim and any related data, which helps decide what external reports are required. The options available are:
- Medical report
- Police report
- Vehicle assessment report.
The reports request is sent from the BPM to the transformation and routing engine, where the data is transformed to the required internal and external systems using messaging and Web services technologies.
Upon receipt of all requested reports, the claim handler is notified and a work item appears on their work list. The claim handler updates the claim with the relevant information from the reports. On submission of the updated claim, the claim status is updated to "All Assessments Received" and the claim data is passed to the judge process. At the same time, data is passed to the transformation and routing engine for transformation and routing to the relevant back-end systems for storage.
In the judge process, the claim handler or claim supervisor can view all claims with status set to "All Assessments Received" on their work list, and are able to retrieve the claim details and other relevant data required to make a judgement. The decision at the end of the judgement could be:
- Repair
- Payment
- Combination of repair and payment
- Reject claim
When a decision has been made by the claims handler or claims supervisor, the work item is updated with the required data and completed. If the decision was payment, the required information is sent to the payment systems by the transformation and routing engine. Similarly, with a repair decision, an approved garage is contacted with the required information and instructed to commence repairs. Depending on the garage used, the communication could be done manually over the phone, or as an external service through the transformation and routing engine. On completion, the broker sends the claim data and judgement to the relevant back end system for storage, and then a notification of the decision is sent to the client.
Implementing the merged claims system
This section explains the products and technologies used to implement each of the claim system components, as shown in Figure 2.
Figure 2: Products used to implement the claims system architecture
The merged company wanted to reduce costs and time to production by reusing as much of the existing infrastructure and applications as possible. Another key requirement is to use the skills and experience of the company's staff. This will reduce the need for retraining by using products and technologies they are familiar with, and will ensure that familiar existing user interfaces are maintained.
It was decided to retain the existing WebSphere MQ (MQ) infrastructure of the LGI Company and extend it to incorporate the new common front-end Web application and existing DC back-end systems. The MQ infrastructure consists of multiple MQ clusters configured to transfer data among the different application components running in different products on various operating systems. This takes advantage of MQ's assured delivery mechanisms and its wide platform coverage.
Each component displayed in Figure 2 is described in more detail below.
User interfaces include the Internet, intranet, branch offices, and business partners.
- Runtime
-
Product Platform Version Java runtime engine (JRE) Microsoft Windows 2000 1.3 Web browser to view Web pages (JavaServer Pages (JSP) pages and HTML) Windows 2000 N/A WebSphere Data Interchange (Data Interchange) Windows 2000 3.2.1 WebSphere MQ (MQ) Client Linux, Windows 2000 5.3 - Tools
-
Product Platform Version WebSphere Studio Application Developer (Application Developer) Linux 5.0.x Usage: For application development of Java Swing user interface - Description
- Provides a user interface to register an auto insurance claim in the form of:
- An intranet Web interface for DC customers.
- A Java Swing application for the LGI branch offices and call centers. The application uses MQ clients to transmit the information to and from the transformation and routing engine.
- An EDIFACT interface for business partners. The application sends EDI 835 data to the Data Interchange gateway.
- Reason for choice
- Existing interfaces used by DC customers, LGI call center, business partners, and branch offices must be retained unchanged.
Our middleware includes LGDirect Application Server and Data Interchange Gateway.
- Runtime
-
Product Platform Version IBM HTTP Server (IHS) AIX, Solaris, Windows 2000 1.3.x, 2.0 WebSphere Application Server (Application Server) AIX, Solaris, Windows 2000 5.0.x WebSphere Application Server Network Deployment (Network Deployment) AIX 5.0.x WebSphere Data Interchange (Data Interchange) Gateway Windows 2000 3.2.1 WebSphere MQ (MQ) AIX, Windows 2000 5.3 - Tools
-
Product Platform Version WebSphere Studio Application Developer (Application Developer) Windows 2000 5.0.x Usage: For application development of servlets and Enterprise JavaBeans (EJB) components WebSphere Studio Site Developer (Site Developer) Windows 2000 5.0.x Usage: For application development of HTML and JSP pages - Description
-
- Provides a new consolidated internet Web site for DC and LGI policy holders to register an auto insurance claim, based on the existing DC applications. Uses the HTTP server to host static HTML pages with the Application Server servers hosting JSP pages, servlets, and EJB components. The EJB components have been modified to issue JMS API calls to pass requests to and from the transformation and routing engine.
- Provides an intranet Web site for the company's claims handlers using HTTP server and Application Server to interact with the process manager.
- Edge Server components of Network Deployment are used for load balancing across multiple Application Server nodes to provide a scalable solution with failover capabilities.
- The Data Interchange gateway puts the EDI 835 data it receives from the business partner onto a MQ queue, where it is consumed by the transformation and routing engine.
- Reason for choice
- Application Server allows the merged company to expand into J2EE technologies, using the skills and technology possessed by the DC Company. In addition to supporting MQ as a JMS provider, Application Server meets the company's quality of service requirements. As stated, Data Interchange is required for the continued support of the business partners' channels.
We have a transformation and routing engine.
- Runtime
-
Product Platform Version WebSphere MQ Integrator (MQ Integrator) AIX, Solaris, Windows 2000, z/OS 2.1.x WebSphere Business Integration Message Broker (Message Broker) Windows 2000 5.0.x - Tools
-
Product Platform Version MQ Integrator Control Center Windows 2000 2.1.x Usage: For application development of message flows Message Broker Eclipse-based application development tool Windows 2000 5.0.x Usage: For application development of message flows - Description
- MQ Integrator and Message Broker transform the data received from the application servers or process manager in one XML format, and transform it to either another XML format required by the DC company's existing back end claims application, or to a legacy communication area (COMMAREA) format as used by the LGI company's systems. (A COMMAREA is a CICS area that's used to pass data between tasks that communicate with a given terminal. The area can also be used to pass data between programs within a task.) Once the data has been transformed, it is routed to the appropriate back end system based on the content of the MQ message received. In the case of requests from business partners, the EDIFACT data is converted into XML using a DTD imported as a message set.
The MQ Integrator brokers are configured in a domain for handling large workloads and providing fail-over support.
- Reason for choice
- Continued support of the messaging infrastructure and reuse of the existing MQ Integrator infrastructure, which was already used to expose LGI's back-end systems. Supports all the data formats required by the applications: XML, COMMAREAS, and EDIFACT data and the multiple operating systems used by the merged company.
This section describes the process managers in our scenario.
- Runtime
-
Product Platform Version WebSphere MQ Workflow (MQ Workflow) AIX, Windows 2000 3.4 - Tools
-
Product Platform Version WBI Modeler (WBI Workbench) Windows 2000 4.2 Usage: For application development of business process flows MQ Workflow Build Time Windows 2000 3.4 Usage: For application development of business process flows - Description
-
- Controls processing of claims through the validate, investigate, and judge stages calling the back end systems, where appropriate, through an MQ message to the transformation and routing engine.
- Allows conditional staff intervention based on certain criteria being met. Investigate process allows manual intervention to process claim.
- Reason for choice
- Builds on the existing skills and products already in use by the LGI company. MQ Workflow provides support for role-based staff activities in long running interruptible flows. The tooling provides the ability to rapidly modify or redevelop new business process flows.
Back-end transaction servers and data
This section covers the DC application server and data center.
- Runtime
-
Product Platform Version DB2 Windows 2000 7.2 Oracle Windows 2000 9.1 TXSeries Windows 2000 5.0.x Application Server Windows 2000 5.0.x MQ Windows 2000 5.3 - Tools
-
Product Platform Version VisualAge for COBOL Windows 2000 3.6 WebSphere Studio Application Developer (Application Developer) Windows 2000 5.0.x Usage: For application development of session and entity beans WebSphere Studio Application Developer Integrated Edition (Application Developer Integrated Edition) Windows 2000 5.0.x Usage: For application development of Java Connection Architecture (JCA) EJB components - Description
-
- Application Server configured to use MQ as a JMS provider. Message Driven Beans (MDBs) were developed to consume messages from an MQ queue using a message selector and then invoke the appropriate existing session beans (EJB components). The session beans call entity beans to access an Oracle database.
- During claim validation, checks are performed against the policy details held in the database. In this case, the session beans use an RMI-IIOP call to an EJB interface that uses JCA services to route requests to TXSeries via the CICS Transaction Gateway (CTG). CICS COBOL applications within TXSeries access DB2 where the policies are held.
- Secure connections using the Secure Sockets Layer (SSL) protocol over MQ links have been established between LGI and DC.
- Reason for choice
- Reuse of existing systems leaving working applications unchanged. TxSeries and DB2 were part of an "off-the-shelf" insurance policy management application. The DC company had chosen J2EE technologies with Application Server to develop their own claims handling system in conjunction with an Oracle database. The only new addition here was MQ to integrate with the consolidated system.
This section describes the LGI data center.
- Runtime
-
Product Platform Version CICS Transaction Server for z/OS (CICS) z/OS 2.2 DB2 z/OS 7.2 MQ z/OS 5.3 - Tools
-
Product Platform Version WebSphere Studio Enterprise Developer (Enterprise Developer) Windows 2000, z/OS 5.0.x Usage: For application development of CICS COBOL programs - Description
- MQ messages are transferred through the MQ-CICS bridge that invokes CICS COBOL applications. These issue SQL statements to access the DB2 databases containing the customer's policy and claims information.
- Reason for choice
- Reuse of existing systems leaving working applications unchanged. The MQ-CICS bridge is used as the interface between the wider MQ infrastructure and the CICS system.
The merged company achieved its goals of reducing costs and administrative overheads by developing a consolidated claims system and using the skills and investment already made in WebSphere Application Server and Web technologies by the DC company to provide an internet claims registration facility for both DC and LGI customers. Support for the existing branch office and business partner interfaces was also continued. The new merged claims system leverages Message Broker as a transformation and routing engine, and MQ Workflow as a business process engine, to provide a single claims process for both DC and LGI claims.
Through the use of the merged claims system, extensions and new functions that could increase the efficiency of the claims process were identified. One of these extensions is the assessor automation system. Look for details about the design of an external assessors solution in an upcoming article.
- Read the first article in this series, Merging disparate IT systems, Part 1 -- Introduction and overview, for an overview of a mergers and acquisitions solution.
- Visit WebSphere Business Integration on the WebSphere section of developerWorks.
- Find out more about WebSphere Business Integration on IBM Software.
- Check out IBM WebSphere Business Integration for Insurance solutions.
- "Business processes and workflow in the Web services world" (developerWorks, January 2003) explains how a workflow is only as good as the business process underneath it.
- Learn about IBM WebSphere MQ Workflow.
- Learn about IBM WebSphere Business Integration Message Broker.
- See an example Web application that uses WebSphere Portal for the Web front end, WebSphere Application Server as the application server, and WebSphere MQ for the messaging layer to an enterprise back-end system in "Configuring your solution with WebSphere Portal, WebSphere Application Server, and WebSphere MQ" (developerWorks, January 2004).
Larry Yusuf is a Solution Test Specialist with IBM. For the past two years he has been actively involved with developing and designing solutions for integrating disparate systems. Larry works for the WebSphere Platform System House and can be reached at yusuf@uk.ibm.com.
Sue Bayliss is a Solution Test Specialist with IBM. For the past four years Sue has been a technical leader in the Hursley Solution Test team with expertise in CICS, z/OS, and Software Testing. Sue can be contacted at sue_bayliss@uk.ibm.com.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags