XML, Insurers’ Ultimate Plug-in?

Recently there has been a noticeable increase in activity as insurers move forward to “web enable” their legacy computer applications. Rather than spending money replacing legacy applications, companies are finding it more economically viable to modernize them, thus preserving legacy investments, and opening up insurance information to the Internet.

Building new web-based components that integrate with existing legacy applications is a good place to begin. Further steps can be taken to re-use applications by migrating legacy functions to modern platforms and expose the function through web or message-based services. If legacy applications are of good quality, even further transformation of a legacy application can be a feasible option. Re-implementing applications on new platforms can reduce operational costs. The additional capabilities of new technologies can provide access to valuable tools such as XML classes and web services can be managed in integrated development environments (IDE).

Web-based products, such as CGI’s “SMART Insurance Technology”, not only automate the claims adjusting process with external vendors, but also facilitate the first notice of loss with the claimant via the web. At a technical level, a claims front end such as SMART IT uses XML (extensible markup language) to increase business value. XML is the standard data transfer language for its messaging. Messages are transferred using industry standard message transfer software such as IBM’s “MQSeries” and with the TCP/IP protocol underlying the process. This is a great leap forward from the days when every vendor had incompatible fixed message formats sent over private networks.

WEB BASICS

When you view an Internet website, the basic code used to display this page is called “HTML” (hyper-text markup language) which uses predefined “tag names”. XML is derived from HTML as a language specific to the task of defining complex data messages between software systems.

HTML is for formatting data, whereas XML is for structure and reference. XML tag names, and the attributes of the tag, are defined by the creators of a message or data block to provide a standard means of describing data. Tags are defined as required for invoking a particular application service and retrieving the answers the service provides. XML can deal with almost any kind of data that lies between the tags, not just web-related data. Although simple in concept, XML provides a powerful framework for interoperability between different computer platforms.

XML is a messaging standard between customers and service providers and has led to the use of web services which is ideally suited for transactional applications such as CGI’s “claims history” products such as “AutoPlus” and “HITS”. Web services are published so the client only needs to know the input and output parameters and how to find the service. The client will send a message to the service in XML format and receive, usually instantly, an XML encoded reply with the requested data. The exchange of data is ‘loosely coupled’ unlike hard-coded flat file layouts. The rules for tag names and their ordering must be followed, but the data between them can be almost any length or type. The only assumption is that the two communicating partners understand the messages received. XML provides both content and context to facilitate the meaning of the messages even if the contained data is a legacy fixed format message.

Programs written in any language, using any component model and running on any operating system can access the XML web service provided. The transport mechanism for the data is decided between the parties involved, usually TCP/IP, but can as easily be a legacy protocol. The only requirement is that the client application must be able to send, receive and process messages to and from the XML-based web service.

BINDING CODE

If there is a service that your business could use, such as externalizing “rating rules”, you want to be able to interface in a timely fashion. In the past, due to a lack of standardization, it may have been too costly or impossible for your system to ‘talk’ to this service or even to know this service was offered. There may have been a service or function you knew a vendor offered, but the code to do it was embedded as part of an entire system so it was a case of “all” or “nothing”.

The functionality within legacy systems may have to be reengineered or wrapped into reusable or modularized services. This modularity gives clients the freedom to choose the best cost/quality for a particular service. Perhaps you want to buy an auto policy application from one vendor, a property policy application from someone else, and while at the same time use a standard accounting system to tie them together. XML creates the opportunity to expose code and functionality and the “glue” to bind them together.

Interoperability opens up the possibility for automating a business workflow that may have previously required manual intervention. For example, when you order a motor vehicle report (MVR), the information should be returned to you in standard XML. You can immediately view the information at no cost by using a web-browser since it understands XML. Any post-processing to be performed would have to be written to handle XML as the input. Not only does this give the client the freedom to choose from many vendors, but also opens up the possibility of direct third-party integration services such as printing. All documents or reports, such as “dec pages”, could be sent directly for processing instead of requiring a manual interpretation process before the document is ready. If you think of XML as simply the plug or connection between the output of an engine and the input to some device, the engine can now be used to drive many devices.

XML is accepted as the standard for structuring content when conducting business over the Internet. It is a natural extension to assume that even non-Internet based applications will use this as the standard interface mechanism. Whether the request to an XML web service is coming from a web application or a legacy system is irrelevant since they both access the service through a standard interface. Various systems can now work together as never before. The possibilities for leveraging existing computing technology are endless. In the end, clients receive improved customer service, more accurate information, track claims, and bind and quote coverage online more quickly from anywhere at the touch of a button.