Implementing Successful Health Care Payer Core Claims System Conversions

Over the span of my career, I have led or been involved in numerous system installations and conversions. It seems like each project involves an out of date or unsupported primary/legacy system that needs to be replaced, which means that a new and exciting system is waiting out there to improve the client’s productivity.

As Director of Product Integration at HCIM, it is one of my primary job functions to implement new product installations and conversions, but I also get to lead and consult on projects for existing and new clients on core system conversions. About five years ago I was a primary influence in the conversion of providers, contracts, claims, auths, and members for a large client that was converting from Amisys C/S to Facets. I was involved in the data conversion mapping for all major modules and directly mapped much of the data myself. This included both the field level mapping from and to the legacy and new systems as well as conditional field and lookup table designs. I was a key member of the team, deciding what fields could be carried directly from system to system and what needed to be mapped to new values, in addition to what couldn’t be converted due to system limitations, changed workflow, or configuration design and needed to be fully recreated from scratch.

I recently led two historical data conversion projects for clients converting to ikaSystems’ ikaClaims and other ikaEnterprise modules. My team and I worked together to design a proprietary platform that imports legacy data, maps or converts it to the new database import schema, and validates each data field against individual field types, relational lookup values, industry standards, and system requirements. This process produced a clean file in the ikaSystems’ standard format. ikaSystems’ platform is flexible enough to allow for customization to accommodate each individual client’s business rules and policies so the converted data is both technically accurate and operationally functional for historical reference.

For the ikaSystems conversion we were called upon to convert historical system data for the member, provider, authorization, claims, payment, benefit plans, and accumulators. The task demanded a thorough understanding of business processes, system functionality, and technical rules to successfully accomplish an undertaking of this magnitude. It also required a good team and LOTS of communication in all directions.

If your organization is due for a new claims system and is looking for help selecting a new core claims transaction system or needs assistance with the historical data conversion or data clean up (i.e. duplicate provider or vendor records), contact me at 888-454-0202, option 5. I look forward to hearing from you.

Author: Gregory K. Merica
About: Director, Product Management Integration at HCIM
Posted: January 3, 2011

2 Responses to “Implementing Successful Health Care Payer Core Claims System Conversions”

  1. Greg Merica says:

    Mr. Kinloch,

    Thanks for your question. While we know that there is no “perfect” system at any price, ikaSystem’s platform is very robust in its price range. The Provider Contracts module is flexible and was able to accommodate much of the unique pricing we encountered and the Benefits module was similarly accommodating. All of the EDI transactions are very strong and work very well. There are other systems that I have worked with that seem more full-featured in certain areas, however these are also several times more expensive and do not necessarily scale down well.

    The project and implementation managers at ikaSystems were very knowledgeable of the system and were able to help the implementation along, finding answers promptly to all questions and providing advice on the best practice configuration options. The first ika conversion I was involved in was a complete historical transition from a TPA to an in-house system in a very tight timeframe (i.e. less than 3 months). Due to the timeline and a hard go-live date, there were several corners cut in configuration that were very expensive in the long term. These were known risks that we were forced to accept due to the hard date in this case. The second conversion was a more traditional approach where we converted various LOB in a phased approach and the outcome was obviously much better.

    Greg Merica

  2. TK says:

    Mr. Merica,

    While you indicate you did work on the IkaSystems conversion, you do not coment on the system implementation or the system itself. Any thoughts?

Leave a Comment.