Seven lessons for transaction system replacements

You can’t engineer yourself out of strategic gaps.

The healthcare industry faces transformational change, and the claims systems of the recent past cannot keep up with this pace of change. Insurance companies, integrated delivery systems and state governments all require new approaches to claims payment, benefit design, contract management, clinical intervention, member enrollment and fulfillment, and customer service. Additionally, ongoing changes to regulation, such as Medical Loss Ratios (MLRs) and ICD-10, the need for increased transparency and the ability to reduce manual processes require the deployment of a modern claims transaction system.

Granted, it’s a daunting task. Replacing a transaction system with this many critical parts can be an expensive, time consuming proposition. Medium sized health plans (100,000 to 250,000 insured members; or clinical delivery systems with 300,000 to 800,000 active patient charts) can spend three years and millions of dollars acquiring or replacing systems. How do I know? I’ve done it. 

What I learned is that the investment of time and money can be optimized for a successful outcome by remembering and employing seven key lessons for change. In numerous transaction system projects over the past 35 years, strategic organizing principles and the discipline to maintain them are essential to successful scope, budget and schedule. 

1 Change your frame of reference. Transaction system changes should energize business process improvements and measurable gains in product cycle time, claim accuracy, customer relationship management, and other key business model domains. Too often, the organization quickly dives to the technical level of configuration and database design, without examining the drivers in the new business model that required the claims system replacement project. The result can be expensive effort to reproduce obsolete results. 

At one health plan this resulted in a $58 million project that could not go live because technical detail did not roll up to measurable business value. In contrast, a large state Medicaid transaction system I worked with was replaced with greatly improved functionality and lower cost per transaction largely due to key organizing principles that emphasized this change in frame of reference.

2 Business model strategy must be explicitly selected, clearly defined, and relentlessly communicated. First map IT to strategy, not functionality. Senior management will often spend significant time and energy selecting and validating a business strategy, yet fail to drive its implications into the daily operating processes. Middle management must receive explicit and continuing communication to manage change in business process and to develop the reports and indicators that will measure performance against the new business requirements. 

During the merger period among HMOs in the mid-90s, more than one integration between health plans-which should be a smaller and less complex effort than total replacement-ran dramatically over budget and underdelivered because no clear consensus around IT functionality for business strategy drove decision making. The result was duplication of each feature in each system creating inefficiency and processing conflicts. We subsequently changed the approach to define IT capability in order to support specific business strategy. Everything else was optional. 

3 Recognize and adopt to the pace of change. Requirements research, solution design, decision making, validation, and feedback must occur at much faster cycles of development. Failure to maintain appropriate cadence across all aspects of project design and construction shrinks time necessary for testing, quality assurance and reporting domains, with severe cost and performance implications. In my experience, IT departments with software development life cycles closely tied to annual budget parameters are particularly fragile with this change of pace. 

In one project, key vendor software of the wrong version was acquired and installed because of difference in cadence between the project and acquisition of that product, resulting in incomplete functionality and a substantial negative impact to the cost and scope of the project. The project moves at one pace but the vetting and acquisition of software happens at a different pace. Everyone has to work at the same cadence. This can become a particular issue with vendor management-they have their own time cycles and we have ours. Vendor relationship managers aren’t always closely attached to the project and may not understand the pace of requirements delivery. In my experience, one successful approach is to subsume vendor acquisition and management within a project management stream. This can create other tensions within the larger (and historic/pre-project) management structure of the organization.

4 Know who is in charge. Everyone’s responsibilities, performance, and job outcomes are affected by system change of this magnitude. Staff productivity and morale move in inverse proportion to time spent in inconclusive meetings. A subtle but significant driver of project failure is the inability of key managers to recognize and accept that their role and responsibility may change. People avoid uncertainty, especially if it affects their job function. 

However a greater risk is the resistance to loss of control: people aren’t resistant to change, they are resistant to being changed. In my experience, health insurance companies with significant claims volume are very resistant to process changes required by altered business models. In one recent project, claims managers left the organization rather than change expectations. 

5 Seek alignment around key intersections of value. The list of potential improvements is infinite. The urge to load this freight into the project is strong.  Experienced insurance plans attempting to install proven technology can spin into budget fiasco because every process becomes a major point of negotiation around improvement. A few key value intersections must be selected and used to contain scope and manage to schedule. You have to decide what you want it to work for. Leadership must clearly communicate to project owners what key attributes must work and what is merely absence of failure. 

Customer service and claims cycle time will inevitably degrade immediately after conversion. This happened while I was working at one of the top consumer rated health plans for customer service. They had to accept a period of degraded service standards; the cost of maintaining standards immediately after go live was simply too high. Build expectation to the reattainment of goals within an acceptable time frame rather than attempting to engineer to retain these goals at go-live. 

6 Realign filters, checkpoints, and governance. A successful project is as much about deconstructing the old as creating the new. The desire to achieve both is costly, unrealistic and contributes to strategic uncertainty within the middle management who must drive the project. This realignment requires the willingness to accept failure or incomplete results in lower priorities. This requires clear accountability and substantial change management at the individual department level. 

A rapidly growing health insurance company struggled to manage new customer needs when they failed to change management structures in order to efficiently enable technology capabilities they had purchased. While largely successful, they could not significantly address their defect list. The new system functioned to design, but processes had not sufficiently changed. Most importantly, they had not altered management structure to efficiently address the newly presented issues. 

7 Process and discipline are necessary but not sufficient. Extensive literature describes project management, change management, corporate communication, strategic planning and operations execution. Selecting and adhering to a discipline among these practices is critically important. Managing a claims transaction system replacement within an active project portfolio can be extremely challenging. However the best discipline will create the opportunity, not the certainty, of success. Senior leaders must still communicate and execute a vision of change in which the claims system is only one component.  

Technology improvements allow today’s claims transaction systems the flexibility and performance to address the transformation in healthcare. However absent the recognition of other key lessons outlined above, large claims system replacement projects will continue to create cost and scheduling challenges while under delivering results. 

Bill Jollie, Senior Vice President for Professional Services with HealthEdge, with 36 years in the health delivery and financing industry, including eight claims systems replacement projects as Chief Operating Officer for several insurance companies.