In more and more health plans, payment integrity is being recognized for the powerful influence it can have on the bottom line. For payment integrity organizations (sometimes called cost containment), this is an opportunity to shine. It's the perfect time to evaluate what has been working well and what has been holding you back. If technology is one of the factors holding you back, then you're in good company. In many health plan organizations, payment integrity is traditionally a lower priority for IT support than core groups like Claims and Finance. As a result, you may experience technology challenges that include multiple sources of data, conflicting or inaccurate data, data integration challenges, manual workflows, multiple reporting systems, and on and on. Sounds familiar?
Part of the challenge is envisioning the technology environment that can support payment integrity functions, whether that is claims recovery, subrogation, coordination of benefits, DRG, or others. It can help to have a diagram that brings IT and business managers together in their thinking. We've developed a “Payment Integrity Reference Architecture” that shows how payment integrity systems (such as recovery, case management, and reporting tools) integrate with enterprise IT to provide the backbone of a technology-enabled, data-driven payment integrity organization.
This architecture describes four specific layers of technology: Payment Integrity Services, Data and Analytics Services, Database Management Services, and Infrastructure Services. It is essentially a map that shows how payment integrity-specific technology integrates with enterprise technology to deliver information and analytics that elevate the efficiency and outcomes of payment integrity functions. This could include more automated integration of partner and plan data, more accurate and complete case identification, improved staff productivity, and automated reporting and tracking, among others.
We will concentrate on the first three layers, but understand that the “Infrastructure Services” layer consists of foundational technology components that support all areas of the business and that are managed by corporate IT (includes networking, security, archiving, storage, and more). It’s important that this layer exists, but it is not directly relevant to the payment integrity discussion
DATABASE MANAGEMENT SERVICES
In the Payment Integrity Reference Architecture, Database Management Services is where data resides; Payment Integrity Services is where the data becomes useful; and Data and Analytics Services is where the data is enabled to flow between the two systems.
Let’s start with the Database Management Services layer. This layer contains data from internal groups and external partners—data that payment integrity groups need to use for their business processes. Some of this data will reside in core health plan systems, such as Finance, Claims, Enrollment, Pharmacy, and others. This layer usually consists of a corporate data warehouse that makes this core data available for all areas of the enterprise. From there, the data may flow into functional data marts, which allow for more flexibility to slice and dice data for functional analyses. As payment integrity functions mature within some plans, this layer may also include a Payment Integrity Hub, which establishes a system to coordinate recovery services across internal departments and external vendors in real-time. The hub also provides visibility into work-in-progress for operations and forecasting.
• Data Exchange
When you have data coming from so many sources (state, CMS, partners, and more), the data exchange function is critical. And challenges mount with the constant sending and receiving of files. That said, the data exchange function must be (1) secure and (2) have data loss and data corruption protection.
• Core Systems
Core systems data usually includes data from claims, enrollment, finance, providers, member eligibility, pharmacy data management, and others. The data may reside in multiple departments and is spread across sources. But this is where you will find the information you need to learn about your members, so you need to start thinking about how that data will flow to the data warehouse.
• Data Warehouse
A data warehouse should be a necessity for most health plans—primarily because you may have more than one system/vendor/product for your core systems. The data warehouse is where all of that data can be integrated and made useful. Just as in business intelligence architectures, ETL happens here and plays a significant part. It’s a place where the data can be brought together to support analytics that may require ac¬cess to lots of historical data to identify new cost containment opportunities.
• Data Mart
The data mart has to serve two purposes—a place to track results over time for metrics and a reporting source to measure success and performance management among departments, vendors, and others. Here is where you can start to identify swings in the volume of claims data, look at recoveries as a ratio, and make data available for other analysis.
• Payment Integrity Hub
The payment integrity hub is necessary for supporting real-time coordination of recovery efforts in your payment integrity system. It pulls from the data mart and runs analytics against it to give you only and exactly what you need. For plans that use multiple payment integrity vendors, this offers a way to coordinate activities among vendors and provides visibility into the payment integrity pipeline for work in progress and forecasting
DATA AND ANALYTICS SERVICES:
Data and Analytics Services refers to the technologies that help analyze, share, and report data. It’s about:
1. Taking data from the Database Management Services layer and making it useful for Payment Integrity Services.
2. Sharing data (such as eligibility updates or payment adjustments) from the Payment Integrity Services layer with other areas of the health plan and updating systems in the Database Management Services layer.
3. Reporting data from Payment Integrity Services layer, such as cost, performance, and trends.
Within this layer, you have the analytics used to identify potential overpayments, duplicate payments, other party liability, and other health insurance—opportunities to avoid or recover costs. In more mature organizations, this will include advanced analytic tools that look across diagnosis codes, dollar amounts, member histories, and many other data points to identify more potential recovery and savings opportunities. This layer also has reporting functionality to pull together data across recovery teams, vendors, and functions to analyze costs, recoveries, vendor performance, trends, and quality metrics.
For many plans, this layer of the reference architecture is managed manually. And when data is coming in from multiple outside sources such as CMS, Medicaid/states, vendors, and other partners, it is incredibly important to make sure that data is consistent, accurate, and timely as it is matched against member data. And for most, that just isn’t happening right now. This often results in processes taking longer, cases getting overlooked, inaccuracies slipping through, and revenue opportunities being missed.
PAYMENT INTEGRITY SERVICES
The Payment Integrity Services layer includes the technologies that are specific to payment integrity functions. Ideally, these tools should be relevant and useful across any area of payment integrity, whether coordination of benefits, subrogation, overpayment recovery, or others. These are the tools that help automate some of the tedious or difficult tasks involved in payment integrity (for example, case identification, work assignments, work prioritization, and letter generation). They bring the automation, consistency, efficiency, and transparency that are cornerstones of a mature payment integrity function.