Tag Archives: Insurance Claims

Putting Puzzle Pieces Together and the Challenge of Creating a New Claims System

Posted on by
1

Creating a new claims system should be easy with no legacy, right? Not so fast!

One of the great things about going to work for a start-up insurance company with a lot of venture money is the idea that you can build everything from scratch. No legacy of losses, a clean balance sheet, and no system constraints. The problem was the company did so well right from the start that policies were being written as fast as they could print the paper. The company had made the initial decision to buy an old established (green screen) application to handle back office processing. The thought was it was the most robust system on the market and as such should be able to handle multiple lines of business. Nice thought but we were a specialty lines operation and the thing just couldn’t do everything that it needed to do. Individual departments knew this and started to build their own mini-systems to get the work done. Suddenly the clean legacy free environment developed a legacy problem.

So where did this leave us in claims?

Unlike underwriting or finance, we did not have to worry about a huge influx of claims from the start so time was on our side. Despite the time we had, we were not involved in the underwriting system initiative early on. We would later learn what impact this would have on everyone. There is more to this story, but needless to say involving all key stakeholders potentially impacted by a system implementation is critical early in the design process. Nonetheless, we had a handful of claims and time to decide what type of claims system we were going to use.

Option 1 – License a System From Our Vendors – Sounds like a good idea?

The first suggested claims system solution was that building a system would be too costly and we should just “rent” a system from one of our Third Party Administrators. Another nice idea in principal that proved to be a not so nice in practice. While everything seemed usable during the demo and initial discussion phases, it was not until we started to actually get down to trying to integrate the application that problems arose. The system was really designed for a TPA and not for a carrier. The meant it did not handle policy data well and in turn would be difficult to adopt. At every turn the so called “customizable” options were leading us to create work-around after work-around. Unless we wanted to pay for fields to be customized, this option was not going to work.

Option 1 – Scrapped.

Option 2 – Buy a Comprehensive System – Another nice idea that was not going to happen

Simply put, this option was way to expensive, and with no true policy system in place, an implementation was going to be even more difficult than “renting” a system. Additionally, at the time, robust claims systems did not exist on the market as much as they do now and the ones that did were an all or nothing approach. We had a half a dozen claims and buying a system that could handle more than we would could have needed for lines of business we were never going to write didn’t make any sense either. So, needless to say –

Option 2 – Scrapped.

Option 3 – Build Your Own – more a decision by accident than by design

Now time was not longer on our side. Claims were coming in and we needed to do something. Ah the wonders of excel. With a spreadsheet all we could do was keep a record of claims and money spent, but in no way provide a claims management system. The controls, and making sure various required financial reports could be provided, was a continual problem that got worse the more claims and transactions we had. Like other departments in the organization I decided to build my own system out of necessity. This began with my limited skills in MS Access and then continued with the hiring of a an actual Access developer.  I was off to the races now and the claims department could build something it could actually use.

Option 3 – I think we’re on to something…

So now let’s build – It’s time for reality, a plan and a process

Developing is very simple when you have no rules, no team and no plan. It was me and a developer. I told him what I wanted to see and he built it. Life was good.  Now claims were coming in faster and we had more users on the system and people now wanted my data. Developing this way was not going to work and I was in for a rude awakening with the assignment of a business analyst. This was all new to me at the time and my days of walking over to the developer’s cubical and telling him to stop what he was doing to add a new feature were over.  In walked much needed process and structure. The reality was I did not really think we were going to build a system from scratch – I thought I was building a stop-gap measure. The stop-gap was over and the system was now going to have to go to an entirely new level.

With structure came direction and a strategic plan was developed. We had to get the basics taken care of which included a more stable database that could handle multiple users, and a new front end that would allow us to make changes quickly as well create new features and connections to various parts of the organization. A development plan emerged and a procedure for enhancements, development, testing, and implementation took shape. The system was no longer a department database, but a corporate application.

I had to come up with a name for our new application and so the Claims Processing Administrations System, cPAS, was born. The puzzle pieces were beginning to fit.

With old claims systems come old claims processes – You can’t change one without the other!

Posted on by
2

So you need a new claims system

You know the darn thing doesn’t work or do what you want it to do so what’s next?

You can’t just go out and buy a new system without understanding what your current process looks like. Over the years you have adopted your operation to your existing technology.  However, with older technology comes outdated and sometimes ineffectual processes. Extra steps and workarounds were common ways you dealt with the inadequate technology, but updating the system alone will not get rid of those extra spreadsheets and additional paper. Those steps have become part of your organization and its “processing culture” and as you know – old habits are hard to break. A detailed assessment as to what is really going on must happen before you spend a dime on new technology.  Not doing a process assessment will make your expensive new solution function just as poorly as the old.

As recently reported in Claims Magazine, transforming your technology is more than just buying a new system. The authors of The Claim Transformation Journey correctly understand that:

Because of the age of many legacy systems, over the years, carriers have often adopted business practices that were built around their claim system’s limited capabilities and increasing shortcomings. As a result, the entire claim operation must be reevaluated. Changing the system without examining directly and indirectly related business processes, the interaction with claimants, and how data is managed would be akin to driving a sports car the same way great grandpa drove his Model-T: You’ll not only have a serious crash, but you’ll also do so much faster.

Even new systems can feel old when existing processes are not updated

While working for a client and performing an end-to-end process evaluation I learned how important the need for a pre-implementation assessment was. This firm had adopted new technology five years prior to my retention. They previously had a basic program to capture transactions but no real claims management system. In adopting their new claims system they continued managing files the same old way. Instead of feeling more organized and efficient, claim handlers now felt they had even “more work to do.”  In evaluating their process I found out that they were only using a fraction of their claim system’s capabilities. They had, however, created nine spreadsheets to track multiple versions of similar information and duplicated their work, time and time again. Had they assessed their operation prior to buying the system and changed not only their technology, but the way they were going to use it, they would have save hundreds of thousands of dollars.

Lessons learned

  • Before you assume your current technology is failing you – check your current processes and business rules against the systems capabilities
  • Create an end-to-end map of how things are being done and see if any tasks were created solely to fit into your technology
  • If tasks were created to ram a square peg into a round hole your claims solution may not be adequate
  • Make sure a new solution can reduce or eliminate old problems and not create new ones
  • Buying a new system will not improve efficiencies unless you understand how your current work flows function versus how you want them to function

So this is claims – hey this job is pretty interesting!

Posted on by
Reply

Welcome to the world of property and casualty claims management. I learned quickly to sit down and avoid the speakerphone. I also learned how to reserve files and negotiate settlements. I managed defense counsel and working with senior management to ensure underwriters, actuarial and finance, were aware of the impact of my work on the business. I found everyday to be a new opportunity to help protect the assets of the company while fairly resolving claims to a prompt evaluation, reserve, and resolution. Along the way I watched Juries defy logic and award verdicts beyond belief. I saw sadness in the faces of family members trying to understand what happened to their loved one and desperately looking to my clients to “pay” for the outcome. I met plaintiff’s attorneys who truly believed in what they were doing and stood up for their clients, but also saw fraudulent claims and plaintiff’s counsel who truly cared little about their clients.

One became slightly detached from the claims themselves and the losses suffered. Brain damaged infants, a parent having to bury a child killed because of a worksite accident, a grandfather and his grandchildren struck by a train at a rail crossing, it was my job to value lives that clearly could not be valued by all the money in the world. I used to tell claimants that unfortunately I had to put a dollar value on the life of their son, daughter, mother or father. That was the nature of claims and it was hard with a desk of 150 matters to always keep that in perspective.