Imagine you're driving and the car's fuel light comes on, warning that you are low on gas. You pull into a gas station, pay in advance as required, pick up the nozzle and only then realize that it does not fit your car. Nozzles in this particular gas station only fit a certain brand of car, not including yours. Instead of pumping the gas directly into your car as originally planned, you pump gas into a can and use a funnel to get it into your gas tank. You later learn that more of these brand-specific gas stations--where you don't learn whether your car's model is served until after you pay--are being planned.
In the real world, motorists wouldn't stand for this. But the software industry somehow expects claims managers to accept a similar situation in insurance. Fortunately, the brand-specific scenario is about to end for the claims industry.
The gas that powers the insurance industry is the flow of data and business processes. Without an uninterrupted flow of data through business processes, workflows come to a halt, especially as one business entity interacts with another. An insurer is all too familiar with having to create a data file or fax reports to an independent adjuster, who then must rekey the claim into their systems. The claim is then processed in the independent adjuster's system, and the results are rekeyed into the carrier's system.
Using our analogy, the adjuster's gas nozzle does not fit the carrier's vehicle, and multiple cans are used to fill the tank, forcing the question: Can't there be a "super nozzle" that can enable communication across business partners in the claims industry?
Service-oriented architecture is it. SOA is the latest technology that enables multiple business partners (such as attorneys, adjusters, health-care providers and insurers) to interact with each other and exchange business-process information to keep the workflow moving seamlessly.
As you'll see, each component of SOA fits our automobile analogy. Various business partners, such as insurers, third-party administrators and claims service providers, are the equivalent of car models. The "request" Web services that transmit data in a specified format are similar to drivers requesting gas. The recipient Web services that receive and interpret this data and then perform value-added activity are like gas-pump operators. And, finally, the Web services that send feedback from the pump operators to the drivers are like gas hoses.
Better yet, let's illustrate service-oriented architecture with some practical examples in the world of the claims manager.
THE FIRST NOTICE OF LOSS
Imagine that you pull up at a "gas station" again--but this time it's on the Internet. You need to send an electronic data interchange transaction via the Internet to a state insurance department for a first notice of loss for a worker's compensation claim.
Assume that this particular state wants the EDI transaction to be submitted in the International Association of Industrial Accident Boards and Commissions' Release III format--a common format that enables easy interaction between the states and any other partner in the insurance chain.
Your SOA claims system "low gas light" is on; in other words, the system knows the triggering events that require a first notice to be filed, either via EDI, e-mail, paper or fax. The system automatically creates a document of the necessary format with the information needed to file a first report of injury or a subsequent report of injury.
A nightly (or hourly, as required) batch process sends this file to the Web service, and the file format complies with the input format of the Web service--hence our super nozzle. The Web service next interprets the incoming file and validates that all the necessary fields are present for Release III. If there are any exceptions, the outliers are flagged. The complete records are submitted directly to the state regulators by using yet another Web service.
What really happened at our Internet gas station is that multiple Web services cooperated with each other to automate the business process seamlessly. The insurer used a request Web service to call the FROI service provider. The FROI service provider sent a response indicating whether the information provided was adequate.
Even as exceptions were communicated, the FROI service provider communicated with the state's Web service to submit the transaction and obtain confirmation that the transaction was successful.
Web services also deliver several efficient avenues to detect and address fraud. Similar to our FROI/SROI example, there are fraud-service providers that use sophisticated algorithms to detect fraud based on insurer data.
These service providers accept a data feed from the claims system based on selected triggers. For instance, all claims involving health-care providers deemed suspicious may automatically be sent for fraud-verification services. This business process--automatically detecting suspicious health-care providers--can be handled by another Web service.
Once the suitable data feed for fraud-scoring has been identified, the rest is seamless. The system can, in many cases in real time, send the necessary information to the fraud Web service. The Web service accepts the data, validates it and requests additional data if all information is not present.
The data is then scored for the possibility of fraud and the results, including a fraud score for each claim, are returned. The claims system takes this score and displays this along with the claim. Claims that scored above a certain threshold may be flagged in the adjuster's diary, and some may automatically be routed to the special investigations unit.
Once again, this process involves an integration of Web services, workflow, rules engines and, best of all, a team of people who understand both technology and the business processes--all made possible by SOA technology.
Requesting accident reports no longer has to involve spending more money to send a check to a sheriff's department than the actual check itself. The SOA claims system can create a request for a police report containing all the necessary information. Missing information will be captured by the requesting services and provided by the responding Web services.
The service provider will then contact the various sheriff offices, police stations and others around the country. The digitized reports will be sent via another Web service to the insurer's system. The data stream is picked up and, again, a diary or a note can remind the adjuster of the list of accident reports that were obtained the previous day. The super nozzle has come to our aid again.
Technology developers have traditionally differentiated themselves by creating proprietary interfaces, but now we have come full circle with multiple technology vendors working together to create a common method of communication. There is reason to believe that the super nozzle will be around for a long time to come to deliver business benefits. With SOA it won't matter the make and model of your "car," or data.
is vice president of claims strategy and business development for Insurity Inc., a ChoicePoint company.
March 1, 2006
Copyright 2006© LRP Publications