Thursday, September 8, 2016

Implementing ESB for Insurance Solutions

Raman Singh

Implementing Enterprise Service Bus (ESB) is crucial game when it comes to complex working model of Insurance sector. A key part of the ESB is to leverage the SOA framework and implement a set of services that connect with cloud and on-premise applications. This becomes more critical when linkage is between various businessprocessesof the insurance domain.

The ESB Services Layer consists of a set of common services that connect and access data spread across enterprise systems and provide the data in a format that the end-users are able to consume as part of their business functions.

As a leader in B2B integration, Adeptia has gained expertise in implementing ESB for Insurance companies. Here’s a high-level diagram that shows how an Adeptia ESB service layer interacts with the business process and the underlying systems.

How it Works

The process begins by calling a context-specific API or Business Process Service (the ESB framework allows for many different methods of initialization whether it be batch jobs kicked off during another process, timed events, or manual requests) and passing the appropriate data elements (for that specific service), once the request is received the service layer parses the request and determines the appropriate actions to take such as: which system to query, what query to use, which mapping process to use and how to send the data back. Next the data is gathered from the appropriate data source and mapped to the Insurance Company’s standard (or “base”) format, business rules are applied to the data (if the requesting process has defined any) and the data is returned in the predefined way.

In the following example, we would setup a service with two methods that provides Policy and Policy summary to a HealthCare Claims system. In this use case, a claim’s handler is reviewing a new claim application. On the Claim Management System, reviewer clicks on a button called “Find Policy Information” by policy number among other required values. The service (API) response brings up the policy details of the insured and displays it in the Claims system next to the claim application. The information helps the claim reviewer with the relevant data needed to process the claim.

Now let’s look at the ESB implementation examples in detail.

Claims Web Service

There are two methods exposed in the following Claims API:

Sample endpoint: https://IPaddress/wsx/services/getPolicy?wsdl

Method 1: getPolicy

Method 2: getPolicySummaries

Method 1: getPolicy

Method getPolicy request (see Appendix D) contains the following fields:

Field Comments FullPolicyNumber Optional PolicyPrefix Required PolicyNumber Required PolicySuffix Optional LineOfBusiness Required (example WC) EffDate Required (yyyy-mm-dd) ExpDate Required (yyyy-mm-dd) LossDate Optional (yyyy-mm-dd) OriginatingSystem Required (values can be PNT, CSC, PHX) RequestSystem Required (such as ClaimPlus)

The response message structure for this request is mentioned in Appendix B. For more information on the response message please refer to the ‘Returning Data’ section.

Method 2: getPolicySummaries

Method getPolicySummaries request (see Appendix C) contains the following fields:

Field Comments FullPolicyNumber Required. Supports wild card * PolicyPrefix Optional. Supports wild card * PolicyNumber Optional. Supports wild card * PolicySuffix Optional. Supports wild card * LineOfBusiness Required (example WC) EffDate Optional ExpDate Optional LossDate Required. (yyyy-mm-dd) InsuredName Optional. Supports wild card * InsuredTaxID Optional. Supports wild card * City Optional. Supports wild card * State Optional. Supports wild card * PostalCode Optional. Supports wild card * PolicyStatusCD Optional. Supports wild card * PEOClientName Optional. Supports wild card * PolicyStatusCD Optional. Supports wild card * OriginatingSystem Optional (example value is OneSource) RequestSystem Optional (example ClaimPlus)

The response message structure for this request is mentioned in Appendix A. For more information on the response message please refer to the ‘Returning Data’ section.

Data Mapping

Data element maps are created in the service layer that corresponds to the standard or base mapping for each policy system data source and line of business that is needed. This allows the framework to be standardized across multiple systems and reduce or eliminate the system specific knowledge that is needed to not only map but also extract data from any given system. The concept is to write an extraction process once for every system and LOB then reuse and expand the mapping to accommodate the next project that needs data from any given source.

Returning Data

One of the major benefits to the SOA approach is to reduce the complexity of data mapping from project to project and to be able to reuse these mappings over and over. Another area of opportunity is reducing the complexity and standardization of the data elements themselves into easily understandable names and meanings. Your company can standardize on XML or JSON constructs that are easily expandable for future projects and all Lines of Business. This does not mean that XML or JSON is the only way to receive data; it is only one of many. If your application needs data delivered in some other format or written to a database this framework would be able to deliver that as well.

The returning response structure itself is comprised of elements or nodes that are hierarchical in nature. The first node at the top of the structure is the “COMPANY” node. Under this node you can have a Policy node. The Policy node contains elements that all Policies have regardless of the business line, examples are: PolicyNumber, EffDate, LineOfBusiness and many others. If the LOB node is populated as “WC” then there will be node named “WorkersCompensation” at that level. This node will contain all the policy detail information for that Workers Comp policy.

Here is a portion of the xml:

<?xml version=”1.0″?>

<Error>

</Error>

</ReturnStatus>

</CancelDate>

</ReinstatedDate>

</Policy>

</COMPANY>

Please see the table below and the appendixes’ of this document for further description of the returned XML.

Below is a list of existing response types:

TYPE NAME Response Type Specifications XML Policy Header XML – Standard Appendix A XML Policy Header and Workers Compensation XML – Standard Appendix B

Requesting Data

In this section, we describe each of the existing interfaces and the general idea behind each one. The tables at the end of the section will point you to more detailed information in the appendixes.

Searching for Policies

Your company may have several varying systems and one of the challenges for SOA strategy is to verify policy accuracy before performing an action on a given policy. The getSummaries Web Service method can be created to offer policy searching and verification capability to applications or processes that may need it.

Guidelines/Information:

1.Data is returned as a repeating Policy node of the Standard XML file.
2.Service returns from 0 to 25 policy header summaries (The limit can be set at 25 due to the vast amount of policies that your company may have and a determination can be made that anything over 25 returned records would require more information from the user or system.)
3.Wildcard is * and is accepted in all field in the request
4.Return Codes and Error Messages are populated in the returned XML.
5.Fields that can be searched by are as follows: PolicyPrefix, PolicyNumber, PolicySuffix, LineOfBusiness, EffDate, ExpDate, LossDate, InsuredName, InsuredTaxID, City, State, PostalCode, PolicyStatusCD, PEOClientName, OriginatingSystem, and RequestSystem
6.Originating System identifies the underlying system that stores the policy. This is needed in case when Insurance Company manages multiple policy systems and the return code helps identify the source of the data.
7.Defining Public vs Private services. Maintain a higher level of separation between context-specific services and reusable “loosely coupled” services. The point here is that your data translations, business rules validations can be decoupled from an abstract service that simply provides the information to your main service which executes the task of converting the data into a canonical format that your backend systems can process.

Policy Detail

The getPolicy Web Service is created to provide policy detail information, for any line of business, in a standard format.

Guidelines/Information:

1.Data is returned as a single Policy node of the Standard XML file.
2.Service will return a customized XML file that is tailored to the specific line of business of the Policy requested.
3.This request must correspond to only one record in the source system.
4.Return Codes and Error Messages are populated in the returned XML.

Below is a list of existing interfaces:

TYPE NAME Response Type LOB Data Source Specifications Web Service getSummaries XML – Standard Policy Header ALL OneSource Reference Appendix C Web Service get Policy XML – Standard Policy Detail WC Data Mirrors: Point8, PointIN, Phoenix Appendix D

API Library consists of services that get data from following systems:

Point8
PointIN
Vantage
Phoenix
Insurity
WPC
Coverall
MRS database
Guidewire
Duckcreek
and other systems

API can also use Mapping (data transformation rules) to convert data, such as:

Legacy to HIPAA, HL7 or ACORD XML maps
HIPAA, HL7 or ACORD XML to Insurance Company systems
ACORD AL3 conversion to canonical format
EDI to SAP
HIPAA to Database
HL7 to a common format
and many others

Appendix

Appendix A – Policy Header Return XML

<?xml version=”1.0″?>

<Error>

<ErrorMessage>No Policy Found</ErrorMessage>

</Error>

</ReturnStatus>

<PolicyStatusCd>ACTIVE</PolicyStatusCd>

</CancelDate>

</ReinstatedDate>

</AdditionalInterest>

</AdditionalInterest>

<AddrTypeCd>MailingAddress</AddrTypeCd>

<Addr1>404 Avenue Of The Americas</Addr1>

<Addr2>

</Addr2>

<Addr3>

</Addr3>

</Address>

<OperationsDesc>Nature of Business</OperationsDesc>

</BusinessInfo>

<Email>insured@hotmail.com</Email>

</ContactInfo>

<CommercialName>NY Test Class Specfic Questions-9074 red</CommercialName>

</CommlName>

<NonTaxIdTypeCd>StateBureau</NonTaxIdTypeCd>

</NonTaxIdentity>

</TaxIdentity>

</NameInfo>

</InsuredOrPrincipal>

<ProducerName>Producer Name</ProducerName>

</ProducerInfo>

<ProducerName>Producer Name</ProducerName>

</SubProducerInfo>

</Producer>

</Policy>

</COMPANY>

Appendix B – WorkersCompensation Return XML

</LargeDeductible>

</LargeDeductibleALAE>

</AdditionalInterest>

<LocationDesc>NY Test Class Specfic Questions</LocationDesc>

<Addr1>404 Avenue Of The Americas</Addr1>

<Addr2>

</Addr2>

<Addr3>

</Addr3>

</Address>

</AdditionalInterest>

</CommlName>

</NameInfo>

<PremiumBasisCd>PAYRL</PremiumBasisCd>

<RatingClassificationDesc>TAVERN</RatingClassificationDesc>

</CurrentTermAmt>

</WorkCompRateClass>

</WorkCompLocInfo>

</Deductible>

<Limit>

<LimitAppliesToCd>PerAcc</LimitAppliesToCd>

</Limit>

<Limit>

<LimitAppliesToCd>DisEachEmpl</LimitAppliesToCd>

</Limit>

<Limit>

Platform

Connection

Mapping & Alignment

Workflows & Orchestration

Monitoring & Management

By Industry

By Initiative

By Capability

By Application

Resources

Support

Welcome to a New Era of Adeptia Connect

What is Data Mapping?

Company

Legal

Implementing ESB for Insurance Solutions

How it Works

Method 2: getPolicySummaries

Data Mapping

Returning Data

Requesting Data

Searching for Policies

Policy Detail

Appendix

Appendix A – Policy Header Return XML

Appendix B – WorkersCompensation Return XML

Platform

Connection

Capabilities

Solutions by Industry

Solutions by Capability

Solutions by Initative

Solutions by Application

Resources

Company