Legacy claims systems pose substantial challenges for health plans who wish to get control of their provider data. It’s important to know what those challenges are and implement appropriate mitigations.
When we say “legacy claims systems”, we are generally talking about software that is no longer actively supported by the original manufacturer. That is not to say that modern systems don’t pose their own challenges. But systems that are out of commercial support may require different approaches.
Let’s talk about some specific challenges these legacy systems pose and what can be done to offset them.
#1 – Data Structures Are Not Conducive to Best Practices
Keep in mind that the goal for most claims systems is to pay claims as quickly and accurately as possible. Provider data is an important element in that goal but still represents just one component. As such, provider data structures in these systems are often overly simplistic. They generally lack the flexibility that today’s health plans need to represent their provider relationships.
A common issue is the lack of ability to correctly represent relationships between vendors, providers, and locations. In systems where the provider’s location is stored at the provider level, you can end up with multiple provider records. Each one may have a unique internal identifier that doesn’t relate to the other records for the same provider. This can make things like checking for duplicative or incorrect NPI entries a challenge.
Further, these systems may not fully represent where the provider practices and under which vendors they practice. In our complex healthcare landscape, providers may work under many “vendors”. They may also work in private practice. Each vendor may have different physical locations. In order to support accurate claims matching and payment, the claims system needs the ability to capture these relationships.
Other challenges are experienced when it comes to identifying parent organizations for providers. Large health networks may operate dozens of different legal entities. Each of those legal entities may have its own tax ID. Further, each of those legal entities may have multiple organizational NPI numbers. Going another level down, each of those legal entities may have multiple physical locations and providers that practice in one or more of those locations.
Many legacy systems require customization or hacks to adequately represent this type of hierarchy. Even then, it may still be a challenge to “group” all the legal entities under a single umbrella. This can make it difficult to ensure that providers are paid according to master contracts. It can also complicate efforts to adequately administer and analyze the financials of any given contract. And it can make it particularly difficult to migrate your provider data to a new claims system.
Mitigating the Data Structure Problem
Because the data structure is often foundational to the application, this problem is hard to solve. To start with, determine what options you have within the legacy system. If you can add to the structure, you may consider some carefully designed fields to capture important data elements. You may use these fields to uniquely identify a provider across multiple records. Or you can capture a parent organization identifier that will allow for ease of reporting.
You will need to rely heavily on external reporting and analysis. This involves creating internal reports or using an off-the-shelf package. You’ll extract data from your claims system and use these tools to analyze it. You may create dashboards to summarize the data. But just as importantly, you should be able to create “work queues” that identify issues for correction and track the status. This would include identifying missing or incorrect data elements.
Finally, you should consider using an external system to manage provider data. This system should have the ability to structure provider data based on best practices. It should also give you access to the raw data. This will allow you to feed your claims systems from a known-good source.
#2 – Lack of Key Data Elements & Validations
Health plans today must capture tremendous amounts of data about their providers. As discussed earlier, claims systems are built to pay claims efficiently. There are certain data elements that are simply not as important for that purpose. Therefore, claims systems often pay only lip service to this data. When they do, it’s generally in the form of a lightweight “provider directory” module that feels like an afterthought.
Many plans have customized their legacy systems heavily. This often includes the addition of data elements needed for reporting and provider directory support. However, it may be virtually impossible to validate these data elements adequately. This can be especially true of data elements that need to span vendor and provider relationships.
Solving for Missing Data Elements
This is again a good use case for an external provider data management (PDM) system. The external PDM system should give you configurability that allows for the extension of the data you collect. This should include both simple structures such as single fields. But it should also give you the ability to build more complex customizable structures.
You should ensure that you’re able to apply appropriate validation to any extended data elements that you collect. The system should require data to be correct before storing it. Finally, the system should allow all data elements to be accessed as raw data and through APIs. This will support the type of deep integration that health plans have become accustomed to.
#3 – Lax Enforcement of Relationships
We touched on this previously regarding the data structure. This topic is related but worth discussing on its own. Relationships between vendors, providers, and locations are critical to accurate claims payment. They also influence provider directory accuracy and other reporting. Claims systems that don’t validate these relationships can lead to ripples throughout the organization. Finance, provider operations, enrollment, regulatory compliance, and utilization management teams may all be impacted.
For example, when a medical group is out of network but relationships within that group are flagged as in-network, this has significant downstream consequences. In-network contracts may be used to pay different rates than non-participating providers should get. Likewise, this can impact member experience. If a provider appears in the directory as in-network, members will rightfully assume that they can go to that provider. If the claim is subsequently denied or if the member gets a bill for Out of Network costs, this can lead to grievances and appeals.
Validating Relationships
Health plans must get regular roster updates from contracted medical groups and facilities. These requirements should be agreed upon within the provider contract. These updates should be processed in a timely manner. Validations should be applied to ensure that accurate data is presented. This includes the identification of providers who have been added or removed from the medical group’s roster. Health plans should also encourage providers to review and update NPPES entries on a regular basis. This can help in validating data provided on rosters.
Additionally, using external reporting and validation can help to identify incorrect data. Determining when a provider is on a different contract from the medical group can be one indicator that something is amiss. Mismatched participating indicators can help identify these as well. Any issues identified should be quickly corrected in the claims systems directly. Any other systems that use that data should likewise be updated.
A PDM system can assist with this type of validation as well. The system should be capable of identifying anomalies in the relationships between providers. These may often require manual intervention by the Provider Operations or Network Management teams to ensure the data is correct. Monitoring on an ongoing basis is critical since this data changes regularly.
Mitigating Legacy Claims Systems Challenges
These are just a few challenges that health plans can experience with legacy claims systems. Implementing an external PDM system built for modern health plans can address many of these. It will still require diligence on the part of the health plan. The only certain thing in the life of a health plan is change. That is especially true with provider data.
If you’re struggling with your legacy systems, there are options available. Maven One can help you to understand and correct your provider data. Our Maven One Rules Engine gives you insight into where your challenges are. Its built-in Smart Fix technology can help correct common problems. This frees up your team to address the more difficult challenges. The Maven One Streamline module gives you the ability to configure and validate data elements and structures, coupled with powerful workflow tools to collect and manage that data. Connect with us today to get expert provider data help!