In the three previous articles of this series we have revealed several architectural advantages to leveraging the data. We started by looking at the importance of understanding the data -- not from a technical perspective, but from a business perspective. Next, we looked at the leverage gained by establishing a single source of truth for the data. This eliminates confusion, promotes consistency, and simplifies maintenance. After that, we focused on the idea of data contracts. Having well defined data contracts provides flexible integration points to help us respond to ever-changing requirements.
Up to this point we have looked at an index data example that examines a solution space from the perspective of the data and then looked at some of the key underlying architecture principles that are satisfied by this approach. In this final article we’ll look at another example to solidify these concepts. The example involves exposing data from one system into another system.
To understand the example, a few more details about the insurance company operating environment are needed. The core application used to manage claims is Guidewire’s ClaimCenter product. ClaimCenter runs on IBM’s WebSphere Application Server against an Oracle back end. Several years were spent developing a data warehouse. The initial effort focused on the data from the claims and policy systems. In this process, much attention and rigor was used to analyze and understand the data. Rules were developed and consistently applied, and SAP’s Data Services was used to extract, transform, and load (ETL) the data to ensure the right data was captured and presented, that lineage of the data was clearly understood and captured, and that a high degree of data integrity was maintained.
Once this effort was complete, the same process was applied to the medical data. Medical and pharmacy information about the claims is loaded from flat files delivered by the billing vendor into a medical database. ETL processes were developed to move this medical data into a conformed staging area and on into the enterprise data warehouse. Oracle Business Intelligence Enterprise Edition (OBIEE) is used to present the enterprise data warehouse information to end-users. This arrangement is shown below.
Part of the claims handling process requires an evaluation of the medications that have been prescribed to a claimant. A change request came through the IT department requesting the addition of medication/pharmacy information to the ClaimCenter application to help inform claim decisions. The request was to take the data from the medical database associated with the claim and copy it into the ClaimCenter database so it could be accessed by the application.
All information system changes for the company are subject to a review by the architecture team to ensure alignment with both business and technical direction. During this review it was recognized that the pharmacy data being requested was already available as an OBIEE report. Both ClaimCenter and OBIEE are web-based products. The architecture review revealed the opportunity to leverage all the work that had gone into developing the rules to conform and validate the enterprise medical data rather than copying a redundant data set into the claim database and reapplying all the ETL rules in ClaimCenter. When the medical data was incorporated into the data warehouse, careful attention was given to it so the right data was structured the right way to be meaningful to the business user. The last mile of presenting this data in the moment of decision-making was next.
A ClaimCenter web page was designed to contain a web page, or I-Frame, of an OBIEE page showing the desired pharma report. This provided several advantages. First, it minimized the footprint in the Claim Center application. Instead of bringing all this data into the Claim enter database, recreating rules to apply to the data, developing a UI that read the data, and maintaining the custom code through upgrades, the I-Frame utilized a simple URL call to the OBIEE application from within a ClaimCenter page. This allows the end-user to see the pharmacy data in the context of the claim information within the ClaimCenter application.
Second, leveraging the fact that both ClaimCenter and OBIEE are running on WebSphere Application Server, SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) could be used to help servers share authentication information. In this case it was used to authenticate the ClaimCenter user to the OBIEE server providing secure seamless integration between the two applications without requiring another login by the user.
Third, the strengths of ClaimCenter and OBIEE could be leveraged through the architectural alignment of the data and the infrastructure. The rigor used to transform and load the current and historical medical data in the data warehouse could be leveraged from within the ClaimCenter application. There was no need to copy these rules and try to keep the multiple rule sets in sync. Lastly, rather than just exposing the data within a custom ClaimCenter table, the medical data was exposed with OBIEE functionality to include tabular data presentation, timeline views, bar chart graphs, sorting, filtering, and drill-down capability. All of these tools are inherent within the OBIEE product and did not require any additional development time. The screen captures below show the types of views available from within the ClaimCenter application. Below, you can see what the user sees: The claim context is in the header and sidebar information from ClaimCenter, and the timeline/tabular/bar chart history of medications used is seen within the OBIEE I-Frame.
In conclusion, effectively leveraging the data can provide great returns to an insurer. Stepping back from the hardware and software view of the infrastructure and understanding what data is needed and how it is used to run the business presents a number of advantages to all levels of the organization. This provides the necessary information at the time it is needed to make quality business decisions. In the case of the pharmacy data described, the pharmacy information that used to take hours of research to discover and assemble is now available in real-time while the claimant is on the phone with the customer, making the claims examiner brilliant in the moment when the decision of how to proceed is needed. We did this at Montana State Fund and won a Guidewire Innovation Award in 2013 as a result. This does not just happen. Rather it comes from a thorough understanding of the data, a well designed infrastructure, and the discipline to implement and maintain the data structures to capitalize on and leverage opportunities as they arise.
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