Nothing is more impactful, engaging and notorious for a Health Insurance Payor than the replacement of their Claims platform or consolidation of many into one. For those contemplating such a move or already in the throes of one, here are some thoughts around “Best Practices” to make the effort successful.
Data Repository
To facilitate the transformation of claims from one platform to another, a data repository should be used. This provides for the establishment of a common information model and layer of abstraction between the source and the target. This allows for ETL logic to be developed for each source and the target platform just once. The use of a repository provides the opportunity for the development and application of the complex transformation logic and business rules required to convert the claim history and other information to something consumable by the target. In terms of volume, claims history is the largest data set. Typically 12 to 18 months of history is migrated, primarily to provide for duplication identification and allow for adjustments. As one system will record the adjudication results differently than the other, for example key reference data, such as providers, eligibility, networks, plans and group structures, logic is leveraged to translate the history to conform to the design and function of the target platform. The use of the repository provides for a more efficient, iterative effort as the transformation logic and business rules are developed and tested.
Phased Client/Product “Conversion”
It’s very difficult to migrate every client and product offering all at once. Ideally, the incoming claim volumes would be segmented in a way that provides for a challenging, yet achievable monthly migration schedule, typically focusing on blocks of business. These blocks could be product or customer related. Start small and ramp up as the first month or two will allow for refinement of the process such that succeeding months will go more smoothly. The timing allows for vetting the extracted source data into the repository, applying all transformation rules and logic, and then reviewing/dealing with kickouts, group building, plan building, billing, training and appropriate communication. It is suggested that you allow for up to two weeks for the first couple of months, moving to one week going forward. Operations will be required to pay down all open claims for each block of business targeted to move that month, eliminating any backlog. The week provides time to perform all the activities related to migrating that block of business and allowing for resolution of any issues. While each block is migrated, during the week of downtime, a portion of the existing Operations folks would undertake orientation, training and made ready for life with the new platform. Particularly early on, there will need to be some staff augmentation in Operations to support the migration.
Reference Data
If not already in place, it is recommended that the management of Provider and Eligibility information be done on a platform separate from the claims processing system. These two sets of data are key to the processing of claims and their accuracy, which is critical to turn-around, throughput and quality. By managing this information off-line, you can institute appropriate controls and quality review procedures. On a regular basis, updates would be released to any target claims platform. During a claims migration or consolidation of an acquisition, being able to handle and manage these two sets offline allows for a smoother transition, as management is done centrally and updates can be pushed out to the old and new claim platform concurrently.
Cohesive, Company-wide Effort
The Migration plan should take into account and provide for all activities related to the effort, including, but not limited to Technology, Operations, Account Management, Compliance, Provider Management and vendor relationships. The technology is the easy part, operationalization, execution and management of the change from an overall business perspective will be difficult. To ensure the short and long term success of the effort, look at backfilling key individuals from the various parts of the organization and putting them on the project team full-time.
Long-term benefits to the organization
Acquisition Consolidation
The block-by-block of business approach provides for the creation of a template or repeatable process. Doing so not only helps to ensure the success of the current migration, but provides the foundation for and capability to more easily consolidate acquisitions. The tools, mechanisms, procedures, rules and information model created can be re-used. Most importantly, the folks that were assigned to the original migration effort are now back in their respective areas and are familiar with template.
Data Warehousing
Leverage the work done in building the repository to help drive the establishment of an Enterprise Data Warehouse. The movement of data into and out of the new Target platform is reusable in an on-going basis for the ETL’ing of data for Business Intelligence. As new Standard Operating Procedures, User Reference Manuals and other processes are being defined, develop the new workflows in a way that allow for easier monitoring through the movement of operational data to the new EDW for Throughput, Backlog, Exception and Productivity reporting. Further analytics around topic areas such as Population Health, product design and quality can be supported.
Data Repository/Data Integration Service (SOA)
The repository can become a foundational component for data integration services that enable the organization to easily source and exchange data across the various application platforms and use cases internally, as well as with external partners. The repository can provide for a level of abstraction, allowing each platform to be connected once, then accessible to all as required by the business.
