Insurance systems need to talk to each other. They must be able to store, share, retrieve and use the same data. Data should flow unimpeded from the first collection of information, from a prospect or census, through underwriting to policy administration to claims. Failure to integrate data adds cost and complexity and introduces errors. These errors can slow everything down, potentially leading to loss of business in an increasingly competitive environment for employee and voluntary benefits.
Integration with many other systems is a must. Insurers often have a variety of best-of-breed systems: sales/underwriting, CRM, policy administration, claims, enrollment systems, risk and lead scores and self-built software. No one wants to re-enter data. Everyone requires an automated streamlined solution.
Systems today often still can’t use the same data for a variety of reasons.
Legacy systems for employee benefits may still be great workhorses, but they are less flexible. It takes extra work to get them to communicate with other systems. Insurers that have gone through a merger may have two sets of systems and often find their systems are incompatible. This means data must be re-entered multiple times.
Even if carriers decide to implement their own integration, the dynamic nature of the group insurance market can quickly make a recent system integration obsolete. For example, carriers may be forced to consider a new insurance product or to retrofit old ones to meet the market demands. Usually, such changes will trigger a cascade of updates for many, or sometimes all, integrated endpoints. Micro-services can alleviate this kind of problem. Breaking down software into smaller components can lead to better modularity, which in turn may reduce the implementation effort because smaller portions of the system have to be changed.
Sometimes even micro-services are not enough – many carriers have implemented complicated data pipelines with complex business logic. Changing or updating a single stage in this pipeline can thus have dramatic consequences on any downstream endpoint.
This is where an exchanger platform can be really helpful: Instead of software updates and changes in micro-service application programming interface (API), exchanger software lets carriers easily change or update the data structure that flows through the pipeline.
See also: 3 Phases to Digital Transformation
Exchanger software must be designed with compatibility in mind: both backward compatibility (compatible with data structures produced by any older version) as well as external compatibility.
Managing data flow is a growing priority for both IT and business users. And each of those groups of users has specific requirements and constraints. IT users are focused on data formats, data security and system performance, while business users are more focused on business rules and data validation.
Each of these aspects must be configurable in the exchanger platform. One particular characteristic of integration systems for group insurance systems is the size of data that often flows between endpoints. For very large groups with a complex insurance product structure, the amount of exchanged data is very large. For this reason, the exchanger software can operate in both synchronous and asynchronous mode with built-in protection against system overload. Data flowing through the transformation pipe can be formatted in either XML or JSON and can be restricted to certain users, based on their authorization level.
The exchanger platform offers a powerful tool to build more specialized applications that fit more specific needs. Many carriers are now embracing cloud solutions like Salesforce or Amazon Web Services (AWS). Although in the long run this reduces IT operating costs, it still requires integrations with existing systems that are not yet deployed in cloud-like policy administration, claims, payroll and archive.
For all these endpoints, insurance carriers should now be able to use one of the many connectors built on top of the exchanger platform. Connectors are specialized applications ready to be deployed and integrated with a specific endpoint. For example, the Salesforce connector allows bi-directional communications with Salesforce cloud applications. Salesforce users can leverage a Salesforce connector to initiate "ratable quotes" and receive final rates whenever these are made available by the carrier rating system.
Data-exchange standards should encompass data aggregation, format and translation and frequency of delivery.
Without standards, chaos can develop, and costs can ratchet up. Unfortunately, data-exchange standards have not become universal. Industry groups such as LIMRA, CLIEDIS and ACORD are trying.
See also: Beyond the Digital Transformation Hype
One encouraging sign of progress: In 2019, LIMRA launched the prototype of the LIMRA Workplace Benefits Electronic Data Exchange Standards. This is something we look forward to seeing develop as we enter the next decade.
Reprinted with permission from the Jan. 16, 2020, issue of www.propertycasualty360.com ©2020 ALM Media Properties, LLC. All rights reserved.
