Executive Summary / Abstract
The objective of the project was to implement a process-oriented architecture including the standardization and improvement of user interface ergonomics. The goal was to raise the degree of automation in claims processing to absorb an annual increase in gross revenue by 10-15 percent with an equal increase in claims, as well as to relieve clerks of simple routine tasks.
The annual increase in gross revenue could be absorbed by automated claims processes, which meant that the number of experts needed for processing was almost stable. This is an equivalent of € 0.75 million in cost savings per year and rising. In addition, the implementation of a rules engine for regulatory rules resulted in an increase of one percent in claims rejection or over € 1.65 million per year and growing. Claims processing time could be reduced from an average two weeks in the past to a few hours. The new automated process frees claims experts from routine tasks and lets them work on unclear or complex cases. On the other hand, simple tasks as obtaining missing data or correcting errors can now easily be diverted to less qualified personnel.
The German HanseMerkur Insurance Group, based in Hamburg, offers a wide range of insurance products, e. g. health and life insurance, car insurance, property insurance etc. The independent company is also the second largest travel insurer in Germany and the second oldest mutual health insurance company in Germany (established in 1875). Over the last decade HanseMerkur has more than doubled its total premium income and tripled the gross premium written in mutual health insurance. This had serious impact on their backend processes as well as the technical infrastructure.
The “KOMPASS” project to introduce automated claims processing in supplementary health insurance is a first step in implementing a new architecture concept.
Currently mainframe computers and sparsely standardized applications (known as contract management systems) dominate insurance companies’ IT landscapes – and the HanseMerkur insurance company is no exception. The expectation from introducing a BPM platform to control all business processes was an increase in software development efficiency as well as more flexibility regarding business application modifications. A business rules management system (BRMS) complements the process management platform, thus constituting an important part of concept.
A vital element during the initiation phase of the project has been the proof of concept to the members of the board in order for them to approve of the necessary budget. Besides the corporate management, the insurance clerks affected by the change and the workers council also had to be very closely involved in the planning.
One of the enhancements the project provided was to enable the operating department to define business rules for process control in a graphical way themselves, so that they could be automatically applied to process execution afterwards.
Besides introducing a complete new architecture (SOA and process-orientation), the project organization was also changed completely as SCRUM was introduced. Furthermore, a complete development paradigm was created, covering all stages from functional analysis through two-step process modeling, object modeling and final implementation in an iterative way.
At present, around 25 percent of all claims in health insurance are processed fully automatically without user interaction. Of the remaining batches, around 60 percent are preprocessed and need no further inspection. This enables HanseMerkur to handle its growth in portfolio without adding personnel.
The technical platform created together with the new development paradigm is now used in almost every new project at HanseMerkur.
Claims processing in private health care used to be a highly manual process. The customer sent his or her claim on paper to the insurance company via standard mail. This document was then passed through different departments within the insurance company, until finally a letter was sent and the money transferred.
Each step in this process was individual in that the experts had to decide which amount could be refunded and which had to be refused, which meant that the process was very expensive in terms of human resources. Turn-around time for this process was at least 14 days.
The motivation for this project sprang from the huge growth HanseMerkur was experiencing. With attractive products and clever marketing, new products could successfully be placed in the market thus considerably increasing the customer and contract portfolio. The aim was to handle the additional claims settlement processes with the existing work force at even higher quality. This required automation of as many process steps as possible, such as verifications against the portfolio management system to ensure coverage.
The Key Innovations
First of all, the impact of the project on the customer was transparent, i.e. the customer did not experience any changes in the claims process. With the improvements made possible by the new architecture however, the changes are vast.
Turnaround time for claims processing was reduced from around 2 weeks in the past to a possible 1 day today and may even be reduced further in the future.
Furthermore, the new architecture enabled HanseMerkur to introduce new process steps such as online retrieval of claims data (see 4.3), thus minimizing errors, additional data input channels such as mobile devices, uniform settlements due to the introduction of business rule-based services for fee regulations and, soon to come, provision of tracking information for the claims process.
The claims process used to be a highly manual process. The following picture provides an overview of this process.
A customer usually collects doctor’s bills and prescriptions for some time, and then sends them to the insurance company by mail. Here the data is either entered manually or scanned, and runs through character recognition software with optional manual post-processing of errors. Afterwards, the document is processed by several experts working on different aspects, checking different regulations or cases within a claims system until finally a settlement letter is sent to the customer and a payment is authorized. No documentation existed for this process.
Domains, Services, and Processes
Click for Larger Image
To develop an automated process from this starting point required several changes in the way software is developed. One major change is that processes are now modeled within the department itself. As the first step in achieving this, the whole business had to be segmented into functional domains. Within these functional domains there are domain services, on which basis business services are created. These business services comprise the building blocks from which the processes are made. See below for a model of domains, services and processes.
A process architect within the department or from a central service department (the organization’s development department) then models the process in BPMN language or applies changes if required. This modeling capability is provided by the process engine, thus ensuring that there is always a connection between the functional model and technical implementation. The process model, in conjunction with subsequent object models, also provides a thorough documentation of process and service components. The resulting models look much more complex than the original ones, but also provide a much deeper insight into the process flow itself, showing exactly what needs to be adjusted in order to improve the process.
An automated process designed using these principles is shown below:
Today, the customer either sends the claims documents by mail in the usual manner or sends them directly as an iPhone-generated photo. However, this photo does not include the whole document, but rather the contents of a data matrix on the document by which the detailed data in it can be retrieved electronically from a data hub for private medical care clearing centers. (These clearing centers collect and process billing information from certain doctors working for the private medical care sector. They print invoices including the data matrix and send these to the patients. The data hub then in turn collects this data from the clearing centers and, if certain authentication requirements are met, sends this data to insurance companies on request.) By the same means, the data on the documents sent by mail can be retrieved without the need for data capturing.
The data from the documents is then sent to various automated processing channels depending on the type of document. For example, prescriptions are processed differently to bills for outpatient treatment or bills for hospital treatment. The allocation to these channels is accomplished using decision components based on a BRMS. Human intervention is only necessary if data is missing or unclear.
After these channels of regulatory business rules, the results may or may not be collected for the next processing step – again based on business rules. In either case the next step is the application of tariff rules and finally the same post-processing as in the original process with the option to send the settlement report electronically.
Due to the component services, architecture changes to this process are very fast. For instance the adaptation required for the new pharmaceuticals realignment law requires a couple of days (mostly taken up by optical recognition of a pharmaceutics code and process of transferring data to the pharmaceutical industry), whereas without this architecture it would have taken hundreds of days.
The new automated process frees the claims experts from routine tasks and lets them work on unclear or complex cases. On the other hand simple tasks such as obtaining missing data or correcting input errors can now easily be diverted to less qualified personnel. This leads to more distinctly differentiated job descriptions. There is no such thing as a claims expert any more.
Furthermore, a special group of the claims experts have been trained to work in process analysis and modeling. This is now a highly qualified group within the claims department which also acts as a link between the claims experts and the IT. These specialists are not likely to go back to their prior positions, however.
In the organization’s development department, a new role of business process owner has been established. Here, all processes spanning several departments are accounted for. They also administer the central repository of business services from a functional point of view.
Within the software development department, the traditional branch-specific segmentation of developers is slowly dissolving as more and more services emerge that span the responsibility of several departments or branches. This leads to a disassociation between administrational leadership and functional leadership within the IT organization and management.
Because taking a service-oriented view of processes was completely new to the members of the board and the next level of management, and also because introducing the architecture would cost a lot of money with no immediate benefit (i.e. in the first year or two), it took a great deal of marketing effort to make them believe in these principles. Once they were convinced that the approach was feasible, “only” results had to follow.
It was very helpful during the early stages to recruit external consultants who could report success stories of the architecture, albeit in other industries.
The next major step then was the going-live of an initial process with maximum gain. This demonstrated that it was possible to develop and install the architecture within a given time frame and afterwards to set up efficient processes in a very short period of time.
Another obstacle turned out to be the introduction of agile project methods (SCRUM), which resulted in an immediate loss of direct control from second level management over “their” employees. Only by redefining management roles by involving management in functional ways was this method and hence the project accepted.
Fortunately the project posed no problem to business at all, because during development it had no effect on business and customer service subsequently improved.
At least three different parts of the organization were directly affected by the project: the department of the claims experts, IT and the department for organizational development, which had to adopt the role of process owners, especially for trans-departmental processes.
For the claims department, the whole method of operation changed. Whereas previously, they worked with a pull-principle by pulling jobs out of a workflow task list, with the new process it became push, where the clerk registered with a queue and then had his jobs allocated. Also the claims department was afraid that jobs would be cut. Both anxieties where smoothed by constant dialogue and early involvement in the project. In fact, a group of claims experts became central stakeholders within the project. Of course, the growth of the workload also helped as no layoffs were necessary.
For the IT department, the entire architecture changed, as did the software development process. This required a very steep learning curve for developers and architects. To introduce these new paradigms it was very helpful to have constant coaching in methodology from experienced consultants. The change in IT organization resulting from the SOA approach is an ongoing struggle and is being supported by the IT management.
Because the new processes span departments, it also became necessary to have process owners looking at the whole process. This role was adopted at an early stage by the department for organizational development. They became the drivers for process design and subsequent improvements. Without this new and crucial role, the whole project would not have been possible, because department leaders tend to optimize their own small areas without looking at the whole picture.
Number of Claims Per Year
Click for Larger Image
Although gross revenue increased by 10-15 percent each year, resulting in an equal increase in claims, the capacity of claims experts remained almost constant. The growth in claims was also amplified by another phenomenon: in 2005, 5 years prior to the going-live of the automated process, HanseMerkur became very successful in the market of supplementary dental insurance. The nature of these insurance policies is an annual increase in maximum refunds. This maximum becomes unlimited after 5 years, resulting in an increase in claims submissions after these 5 years.
Both effects could be absorbed by the automatic process, which meant that the number of experts needed for p ocessing was almost stable. This is an equivalent of € 0.75 million in cost savings per year and rising.
A third factor for recent cost savings has been a BRMS for regulatory business rules, which resulted in an increase of 1 percent in claims rejections or over € 1.65 million per year and growing.
With all these savings taken into account, the ROI will reach break-even after 5 years in 2013 and be increasingly positive afterwards.
Claims processing time (counted from the claim being issued by the customer to the customer receiving the result) could be reduced from an average 2 weeks in the past to a few hours (with the help of an iPhone App). Without the host system (which is currently being replaced by a new settlements component) processing times can be reduced even further to a few minutes.
This project has not affected revenue so far, but will do so indirectly due to the increase in customer satisfaction as well as the possibility for faster product time-to-market (see 8).
Average Number of Cases per Clerk per Day
Click for Larger Image
Although automation favors simple cases, hence the more complex cases are left to the experts and one would expect a decrease in productivity, in fact productivity has risen considerably.
Note that the first automation step took place in December 2009, followed by a major additional step in May 2011.
This improvement can be attributed to the fact that as a result of the service-oriented architecture, process steps can be routed according to skills, which means the experts can better focus on specialized tasks.
Best Practices, Learning Points and Pitfalls
Best Practices and Learning Points
- Ensure support of all parties involved up front. An SOA project is lengthy and costly and you do not want to alienate any party during the process. Constant marketing and persuasion is required.
- An SOA Implementation should be accompanied by agile project technology. When you enter unknown territory you have to explore where to go. There is no such thing as a recipe for SOA: you have to find your own model. Agile technologies best fit this approach.
- Use a sufficiently small goal with maximum gain for the first step. This usually ensures support from the board, but also boosts motivation within the team.
- Process orientation requires constant and close collaboration between functional departments and IT. The role of process owner has to be filled as early as possible.
- Try to avoid dogma in applying SOA architecture and agile methods. Both have to be adapted to a company’s existing architecture and culture.
- Prepare to have to defend the new approach. Classical architecture and development paradigms will seem faster and less expensive initially. Hence there is a trend in people to fall back to the “old ways”. The expected gain has to be made plausible again and again, for example by successful extensions of the initial process.
Automation Rate Process Improvements
Click for Larger Image
With a 25 percent automation rate (i.e. full automation plus 60 percent partial automation of the rest) HanseMerkur has a leading position among German private health insurers. This automation rate provides not just for cost-quota savings, but also enables highly standardized claims settlements, thus increasing customer satisfaction twofold by reducing the turn-around while making highly reproducible settlement reports possible. The following chart demonstrates the continual increase of the automation rate process improvements:
The underlying architecture also allows for rapid addition of innovative customer services such as the new claims app for iPhone.
Future plans include replacing the host based settlements core with a new one which can run fully automatically, based on product definitions from the policy module. This will further increase the automation rate, but will also provide for much more processing information, enabling for instance seamless process tracking for the customer as well as the HanseMerkur back office. Furthermore, this connection between policies and claims will allow for very high flexibility in product definition (an extremely short time to create and implement new products), which is a major competitive advantage in this time of rapid regulatory changes.
By introducing a service- and process-oriented platform, HanseMerkur achieved a broad range of goals. First and foremost, the SCOUT platform raises the efficiency of software development by introducing a unified architecture concept for all applications built on this platform.
The core of this application platform is a custom-made component / service architecture built on the JBoss application server. Standard JBoss features have been enhanced by concepts for hot deployment and multi-version support for services through a concept of class separation. Both features are necessary as processes with long durations are expected.
Process orchestration and execution are achieved using the inubit Process Engine as part of the inubit Business Process Management Suite. In this case the process engine was successfully tuned to high throughput in complex processes.
The inubit Process Engine calls services deployed into the component registry within the JBoss application Server. It is also used in the modeling process where the claims experts design the processes, and provides a link between functional process models and technical process models.
Usually, process flows are either batch or interactive (workflows). In this case a special requirement was the use of hybrid workflows, i.e. flows that contain process flows interspersed with human interaction.
This could successfully be built into the process engine by designing means for suspending and waking a process.
One central set of services – known as decision components – are created by the BRMS (Business Rules Management System) Visual Rules from Bosch Software Innovations. The use of these components helps to homogenize validation and control rules. The model-based approach of Visual Rules displays the business logic graphically as rule flows or as decision tables. This helps to separate rules development from classical software development cycles and enables claims specialists to directly change, test and implement their rules.
The platform also includes the Eclipse RCP based Open Source project Riena as an application framework. Riena provides a clear navigation concept and ergonomic standardization of user interfaces. It also enables the user interface to operate like a service from the platform point of view.
Last but not least the technology stack is rounded off by the FIT framework for testing. This perfectly complements the built-in testing capabilities of the inubit process engine and Visual Rules, and the JUnit method within Java, thus providing a complete test suite from unit to system, integration and regression testing.
The Technology and Service Providers
inubit AG (www.inubit.com), now a member of Bosch Group, provided the process engine of inubit Suite.
The inubit Suite 6 is inubit’s core product. It is a comprehensive standard product for holistic BPM and is based on Java and XML technology. It supports all phases of processes management, from modeling in BPMN 2.0, simulation, pattern-based generation of executable processes, easy integration with legacy via more than 70 connectors, a full SOA foundation, business rules support, task handling, human workflow, portal integration based on the portlet standard and real-time monitoring with processes KPIs, dashboards and reporting. This is accomplished by a large set of enterprise and system management features including versioning, tagging, SNMP-alerting, monitoring of consumed server resources, multi-level staging and deployment plus support for clustering and high availability.
The inubit Suite is compliant with over 200 IT-standards and follows an open architecture principle in order to operate on multiple operating systems, databases, application servers, portal servers, and service registries. By default, inubit makes use of widely accepted open source components such as Tomcat, JBoss, and Liferay but is also prepared to run in commercial components such as Websphere and SAP Portal. This makes inubit very flexible in integrating with existing customer environments or operating as a stand-alone implementation.
inubit consultants helped in installing and optimizing its configuration.
Bosch Software Innovations (www.bosch-si.com) is a leader in Business Rules Management Systems and offers software and systems solutions for the financial services industry, eMobility, as well as companies in various industries.
The Visual Rules Suite offers proven tools and platforms, designed for technical and business software applications and completely scalable to meet customers’ performance and agility needs. The rule-based integration concept establishes rules and rule modeling instead of programming as core elements of software applications. Rules define the business logic of applications, control internal workflows, and promptly react to defined events within the system environment. Rules are also used to integrate applications into heterogeneous and distributed system landscapes. Under this approach, sophisticated concepts come together with components based on mature technology and industry standards.
Holisticon AG (www.holisticon.de) is a management and IT consulting company from Hamburg, Germany. Based on a holistic consulting approach they assist customers in development projects on all technical, tactical as well as strategic levels.
At HanseMerkur, Holisticon consultants have contributed their core areas of expertise in Business Process Management (BPM), Enterprise Architecture and Agile Software Development (Scrum) to build a new service-oriented application platform, implement the first automated business processes on top of it, and establish a new paradigm of process-oriented, agile software development.
compeople (www.compeople.de) is an innovative IT-Service-provider. Their core competence is supplying modern, user-friendly IT-systems. compeople offers a complete range of services, focussing on software development, technology and architecture consultancy as well as consultancy on agile project methods.
As a solution member of the Eclipse Foundation, compeople have not only initiated the Eclipse RT project “Riena”, but also lead the project within the Eclipse Community. “Riena” is a platform for developing user-friendly, multi-tier enterprise applications. Core to Riena is an OSGi-based Remote Services component that allows developers to easily create distributed client/server applications. Furthermore Riena provides an enhanced navigation concept for business applications with a focus on end-user usability. Typical users of Riena are companies which are interested in realizing complex enterprise applications and by doing so, attach great importance to a high usability of their applications.
Copyright: This case study was originally published in the Excellence in Practice series in the book entitled “Delivering Competitive Advantage” published by Future Strategies Inc. ©