For many health plans, payment integrity is able to influence the bottom line in powerful ways. For payment integrity organizations (sometimes called cost containment), the new year is the perfect time to evaluate what has been working well and what can be done better and more efficiently. And often payment integrity technology is one of the areas that could use improvement. Payment integrity is traditionally a lower priority for IT support than core groups like Claims and Finance and as a result technology challenges arise including multiple sources of data, conflicting or inaccurate data, data integration challenges, manual workflows, multiple reporting systems, and on and on.

But creating a technology environment that can support payment integrity functions, whether that is claims recovery, subrogation, coordination of benefits, DRG, or others can bring IT and business managers together in their thinking. I recommend 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.

In a later piece I will describe this architecture more in-depth, but as you reconsider your technology environment and consider adopting a new Payment Integrity Reference Architecture, you will see  four specific layers of payment integrity technology emerge: Payment Integrity Services, Data and Analytics Services, Database Management Services, and Infrastructure Services.

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.

The next layer of our recommended Payment Integrity Reference Architecture is 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 and Analytics Services follows Database Management Services and refers to the technologies that help analyze, share, and report data. Within this layer are the analytics used to identify potential overpayments, duplicate payments, other party liability, other health insurance, etc. – 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 should also have reporting functionality.

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.

Throughout the evaluation process, keep in mind that your enterprise payment integrity efforts will benefit from technologies that can be used across payment integrity functions. For example, most payment integrity activities hinge on member eligibility information.  The goal should be to capture this information once and use it across all areas of payment integrity (and even with other areas, such as Claims and Finance). Likewise, a single Case Management tool should be able to service coordination of benefits as well as subrogation and any other area of payment integrity, so there is no sense in building or buying multiple versions of this functionality. For more detailed information, watch for my next published article, “Enterprise Approach to Payment Integrity Technology: Reference Architecture.”  Additionally, if you would like to gauge where your organization falls on the technology and data maturity model, see our blog “Enterprise Approach to Payment Integrity Technology: Using A Payment Integrity Maturity Model.”