Mitigating Provider Implementation Issues
You’ve done an extensive amount of work over the previous year mapping provider data from your legacy payer system to your shiny new payer system. You’ve tested your conversion logic repeatedly and you are now confident that your provider conversion into the new system works flawlessly. The records ‘look’ perfect in the new system. It’s the first week of go-live and nothing about the configuration of the provider records is working!! What happened??? Now you have the technical team pointing fingers at the configuration team and vice versa.
Provider conversion seems to consistently be one of the most difficult parts of any new implementation. The vendor will tell you at the beginning of the project that provider conversion is simple, it’s just data. They may even provide tools you can use to streamline the process. What you may not realize is that every payer system stores and utilizes provider data very differently, and can potentially be one of the most complex modules during conversion.
It’s not enough to just map data elements from the legacy system to the new system. You must also have a thorough understanding of the functionality of each system and how the data elements are actually utilized. How are the providers in each system interrelated to each other (i.e. individual provider is part of a group or a network or both)? How are contracts attached to the provider record? How do you handle providers that may have more than one taxonomy? What is your inbound 837 EDI process looking for to match to provider records in the new system?
There are several different things you can do to mitigate provider issues prior to go-live:
- Clean up you legacy provider data. This means finding and removing duplicate records. Validating provider interrelationships. Validating key provider data elements like NPI and TaxIDs to name a few.
- Acquiring DBAs who are familiar with the database schemas for both payer systems. Try to avoid hiring or contracting DBAs with no payer system experience at all. The time it takes them to understand the table relationships is precious time away from completing the conversion tasks and increases the possibility that crucial data will be missed in conversion.
- The conversion team needs to consist of a project manager, DBAs as mentioned above, a health plan representative familiar with how provider and contracting business is conducted and also configuration analysts that have a thorough understanding of the functionality of the provider areas in each of the respective payer systems. The ideal configuration SME would also have an understanding of the database schema. The configuration analysts are key to bridging the gap between the DBAs, the functionality of the system with regard to how the data is utilized and the health plan and their requirements.
Conversion of provider data from a legacy payer system to a new payer system may seem straight forward and simple on the surface but there is more to the successful conversion than just mapping data elements. How the payer system utilizes those data elements must be clearly understood, the data coming over from the legacy system must be clean and the conversion team must consist of knowledgeable team members familiar with both systems.