A core claims and adjudication system that was no longer delivering on its promise, was the main reason a large East Coast health plan decided to replace its technology in 2016. It needed to have a system that was easy to configure, and would help the health plan move forward with its business goals.

With internal and external health insurance and market pressures forcing the health plan to find another way to process and adjudicate claims, developers no longer had to pull customized code out of the legacy system to reconfigure it.

The replacement of its core system was at the forefront, yet it involved much more than merely swapping out an old system for a new one. Core system replacements are often the largest technology initiative a health plan undertakes in terms of the project’s scope, the amount of money spent, and the time to complete.

An aging legacy system

As the health plan’s legacy technology continued to age, it became apparent that it was getting more difficult to support its lines of business. There were issues with the plan’s administrative cost margins, the setup of new products and self-funded groups was cumbersome, and the health plan was having difficulty keeping up with regulations on commercial and government products.

Some of the biggest challenges with the legacy system was that it used older programming language, such as C#, that required more individual programming to maintain the aging technology. And, it was getting more and more difficult to integrate older technology with newer solutions coming to market. The health plan regularly saw low claims adjudication rates, as well as high pend claims that sat in the queue for a long time.

Because the legacy system was hard-coded, any time a change needed to be made, the health plan’s technology team had to pull the code, make the coding changes in the older COBOL or JCL languages outside the system. And, with fewer people who know COBOL and JCL, the cost was increasing with each system change.

System configuration changes are best explained by using the idea of a room with four walls, such as health insurance policies, deductible changes, individual vs. family plans. With new technology, the configuration team is able to manage the changes, seamlessly, within the four walls of the room. Whereas, in the legacy environment, any configuration changes had to be made outside the four walls. To expedite its processes, the health plan needed to find a solution where changes could be made inside the system, and quickly.

Health plan goals

The health plan’s goals were to implement an enterprise system that would support regulatory compliance and other external market demands, streamlining processes, increasing efficiencies, and reducing or eliminating manual processes, which would reduce the likelihood of errors occurring.

The health plan wanted to align its processes and systems with these long-term, strategic goals:

• To better serve its members.
• To be among the top 10 percent of health plan brands nationally based on a member’s willingness to recommend the plan to others.
• Achieve the highest quality through 5-star CMS and NCQA ratings for a number of different product lines.
• Manage the cost of care by achieving a two percent total cost of care margin for all lines of business.

New system requirements

The new technology needed to allow for configuration coding changes within the .Net framework and configuration shell.

A system replacement has the potential to include the following strategic benefits and opportunities, risks, and assumptions:

• Identify and align the health plan’s strategic direction with corresponding operation requirements
• Aligning the business. The health plan’s IT staff worked closely with HighPoint on its software sprints, setting timelines for when work would be completed and when testing would start, capturing system requirements, and developing and delivering technology solutions. HighPoint worked alongside the health plan to ensure that what was being developed and delivered achieved 100 percent of the health plan’s requirements.
• Documenting forward-looking business transformation opportunities and expectations
• The legacy technology was limited in its configuration capabilities and was using older technology, which limited what the health plan could do with its system.

The system replacement confirmed the health plan’s need for a new, forward-looking application blueprint for both internal applications and utilities, and integration requirements for full automation.

The health plan’s leadership and HighPoint developed a roadmap to guide the overall success of the project, ensuring the project stayed on track, on time, and on budget. HighPoint assessed staff roles and responsibilities, as well as the organizational structure, and the affect this initiative would have on the organization once the project was completed.

Project specific requirements

The success of the project would be determined by the health plan’s ability to process its claims and support core business functions, such as member enrollments, provider encounters, and billing. The project also had to support the integration with third-party entities already on the legacy system.

The health plan also had to comply with state and federal requirements, had to have the flexibility to effectively integrate for CMS reporting and ensure that the migration to the new system would keep the health plan compliant into the future. The health plan also needed to generate reports and correspondence, and streamline processes by automating current manual processes (e.g., use of workflow, integration with providers).

Replacing the system

The health plan finalized its decision in early 2016 to replace its legacy system. The implementation deliverables were rolled out during these phases:

• Phase 1 – Medicaid
• Phase 2* – Commercial, TPA/Self-funded, Children’s Health Insurance Plan (CHIP)
• Phase 3* – Exchange/Medicare

The health plan used two different development methodologies: Waterfall and Agile. An Agile methodology was used for developing interfaces, claim extracts and customized integrations, which were rolled out in three-week sprints. Using a blended methodology approach gave the project flexibility and was best for the health plan and its overall ability to adapt to the changes.

Agile development allowed for sprints toward application development. Several sprints can be run simultaneously to quickly develop and test the new applications.

Building the strategies for success

Built into the project were some assumptions that would lead to the health plan’s success.

This included having a solution that would be able to handle more than 1 million members. The project cutovers were designed to fall on appropriate billing cycles rather than random dates. This was outlined in all phases that required billing cycles.

HighPoint and the health plan also managed multiple strategies that would lead to success throughout the project lifecycle. The health plan developed strategies for:

• Migrating and managing providers
• Migrating and managing accumulators
• Managing data that was held in external, non-legacy vendor custom tables
• Establishing a way to migrate employer group data (e.g., groups, subgroups, class, plan, etc.)
• Migrating membership for fee schedules, members, and providers
• Retroactively managing the billing cycle

Potential risks

The health plan identified the following risks prior to the project launch:

• Depending on health plan’s resources and schedule to build the technology environment, some of the work would be prioritized and positioned in a queue. The health plan was cautioned by HighPoint that this may not necessarily align with its schedule and, therefore, could potentially lead to delays. The legacy system was highly customized, which meant that there may be some requirements that the health plan had not accounted for, some requirements could be missed, and this could negatively affect the project.
• Many operational processes were affected and the work required to mitigate this were not known at the time (e.g., ID cards, etc.). If HighPoint and the health plan had not accounted for all of the processes that were changing, there may have been gaps in business readiness.
• An Operational Data Store (ODS) was brought online and was important to the project’s success. The ODS was used primarily for containing and producing claim extracts, reports, and handling the movement of outbound data from the legacy system.
• Integration activity was complex, and with limited documentation for the legacy system, it was not known what customizations or extensions might be needed.

The cutover

To ensure its success, the health plan took a Date of Service approach when it cutover from the legacy system to the new technology. Any claims with a date of service greater than or equal to the go-live date would be processed on the new system. Any claims with a date of service before the go-live date would be processed on the legacy system.

There were a few exceptions to this, including:

• Inpatient hospital claims were paid based on the admission date. If the admission date was before go-live, and the discharge date was after go-live, then the claim would be processed in the legacy system. If the admission date was the go-live date or later, the claim would be processed in the new system.
• Inpatient Professional and Ancillary claims were paid based on their date of service. The claims with inpatient professional or ancillary claim data with admission or discharge dates before or after the go-live date would need special processing.

Identified deliverables

HighPoint and the health plan decided that the four lines of business would process Medical claims on the new system. This included:

• Medicaid
• Commercial 
• Commercial
• Self-Funded
• CHIP
• Exchange
• Medicare 
• Medicare Advantage
• Medicare Supplement

Wrap up

To date, the health plan is now better positioned to be more efficient, automated, and responsive to its customers.

HighPoint led the configuration and application development. A third-party vendor led the software testing. And, HighPoint provided overall project management expertise.

Projects of this size tend to experience deadline slippage or missed deadlines; however, HighPoint has not missed a deadline for this project. Deadlines may have been pushed back by mutual agreement, but HighPoint has not missed an actual deadline — something that is unique in IT.