Creating a Data Contract for Insurance

Establishing a data contract requires stepping back and looking at all use cases for the data.

The first two articles of this series focused on understanding insurance data and the importance of having a single source of truth. By implementing a well defined indexing data structure, we can be assured of consistent, accurate indexing data across all document images. We saw that having a single source of truth for the data requires only one integration point with the imaging system. This significantly reduces the number of integration licenses required. In the previous article, we also mentioned another key concept: the architectural principle, Separation of Concerns.

One of the difficulties with the original index arrangement was that each interface was coded independently, and data from the image system was being stored in the core applications. Because each of the core systems contained image system code and data, the systems were tightly coupled. A vendor change to the image system would likely require a change to the core systems, because in this case the core systems were tightly integrated. 

This idea of separation of concerns, or de-coupling as it is commonly called, has been around for some time. When we look at it through the lens of leveraging the data, we leave the application perspective and view de-coupling from a business perspective. Because we now understand how the business uses the index data and developed a data structure providing a single source of truth, we are ready to expose that to the rest of the enterprise as a data contract.

[The Need for an Intelligent Quote Engine in Life Insurance]

The data contract is a formal way of defining the data structure required to integrate with the indexing data. There are several advantages to defining this data contract:

• Establishing a data contract requires stepping back and looking at all use cases for the data. This broad perspective allows the design to focus on what data is needed for indexing and not just the data needed by a particular application. The data becomes closely aligned with the business need. 
• A programmer can design interfaces to the specifications of the contract. There is no longer a need for every developer to understand the code used by the image system and how to form an index record. As long as the data is supplied to satisfy the contract, the document will be imaged and indexed.
• Maintenance is less involved. As long as the contract remains intact, changes can be made upstream and downstream of the contract without having to worry about the effects to the systems on the other side of the contract.

Other architecture principles such as ease of use, innovation, agility, and flexibility fall out directly from this approach.

With this data structure identified, a service can now be created that accepts this data structured by the contract. In this example, representational state transfer (REST) services were used to interface with the imaging system. Other applications can interface with the indexing system by means of calling this service using this data contract as shown in today's diagram. Remember, the initial reason for looking at the indexing data was part of the enterprise document generation implementation. The data contract defines the data needed to add a document image to the imaging system. Because adding this image is using a well defined data contract and associated service, it has a much greater utility. Now, any application that is able to call the service and supply the data required by the contract can add a document image to the imaging system. The beauty of this is that no knowledge of the underlying system is required by the programmer. It looks like this:

 

Remember, the data contract was designed to not only index the document images, but looking forward it would have the ability to index any item including document images, voice recordings, company badges, etc. This level of flexibility was obtained by focusing on the data needed and important to the function of indexing, rather than focusing on what the application needed to integrate with the imaging system. This shift in perspective from an application-centric perspective to a data-centric perspective is the seed to developing a flexible, responsive infrastructure to meet business needs.

It wasn’t long after the indexing component was implemented when the flexibility was demonstrated. In the insurance business, it is a common practice to record key phone calls with claimants. These phone calls become part of the official claim file. Up to this point, there was no integration between the claims system and the call recording system. When a user wanted to see if a recorded call existed he would log into the call recording system and search on the claim number. From the data perspective of the indexing system, the structure developed does not care if it is indexing a document or a voice recording. The voice recording meta-data was added to the indexing system, and a backend integration was made to the call recording system. This allowed both the call recordings and document images to be exposed to the claims system so the claim examiner can now see all the documents and recorded calls from one place within the claim application. In fact, by making this change, the call recordings are now available to all the applications that use the indexing system.

Through the diligence of understanding the data and implementing an indexing component based on this data, the addition of another dataset like voice recordings almost appears trivial, yielding great flexibility towards adapting to business needs. The flexibility for the solution to expose the index information for any future dataset that may include images or videos, for example, becomes obvious.

Andy Metroka is the Director of IT Architecture responsible for systems, application, and database architecture at Montana State Fund, which provides workers compensation insurance for Montana businesses. Prior to that Andy was a software consultant where he designed and ... View Full Bio