Reduce Medical Loss Ratio by Straight-Through-Processing with Oracle Health Insurance Components ORACLE WHITE PAPER JULY 2015

Transcription

1 Reduce Medical Loss Ratio by Straight-Through-Processing with Oracle Health Insurance Components ORACLE WHITE PAPER JULY 2015

2 Table of Contents Introduction 1 Business Agility 2 Risk-Based Intervention 3 Oracle Health Insurance Components 3 Integration 4 Coordination 4 Auto-adjudication 4 Pend Only What You Need To Pend 5 Conclusion 6 REDUCE MEDICAL LOSS RATIO BY STRAIGHT-THROUGH-PROCESSING WITH ORACLE HEALTH INSURANCE COMPONENTS

3 Introduction With the steady increase of healthcare costs, health insurance payers are challenged to find new ways to reduce cost. As a payer, you have three ways to achieve this: reduce reimbursement, reduce coverage or reduce the cost of running your business. The first two options shift the cost towards providers and members and are not viable in a competitive marketplace. Making the third option reducing the medical loss ratio an attractive choice. Any payer strives towards a claims administration where straight-through-processing is the norm. Yet, not many payers get to boast auto-adjudication rates higher than 95%. In fact, many payers do not even come close. And given the volume of claims in health insurance, even if you achieve an autoadjudication rate as high as 95%, that still means you have to deal with (tens of) thousands of claims that can t be processed without some kind of intervention. In other words, the goal is clear getting there is the challenge. There are three typical obstacles on the road to running an efficient claims shop.» Inherent Complexity: Processing a claim is a complicated process. It includes determining the appropriate provider contract, agreed reimbursement, the member s benefit plan, authorization requirements and the appropriate cost-share with the member. And this list is far from complete. All this inherent complexity makes it hard to define a universal set of system rules to achieve automation.» Collaboration, Mergers and Legacy Systems: Mature health care markets invariably see a considerable number of payer mergers and payer collaborations. The result is that many payers have a mix of parallel and overlapping systems that have to work together. Legacy systems are invariably designed as business-in-a-box applications. This means that information has to be shared between systems that have never been designed to integrate with each other. At best, connecting these systems means (yet another) custom development project. The worst case scenario is that you ll have to implement a manual processes in which a user reads information from one system and keys it into the next.» Evolving Benefit Plans: Payers are constantly experimenting with new types of plans, catering to market demand. Some examples are layered benefits, different accumulation scenarios, tiered provider networks and customized coverage rules. While these constructs might be attractive to the market, they can be nightmares for your claims shop. If the configuration of your automated claims administration process cannot match the pace of the new plans, mandates and benefits that you offer, it may be incomplete, directly impacting your ability to achieve a high rate of auto-adjudication. 1 REDUCE MEDICAL LOSS RATIO BY STRAIGHT-THROUGH-PROCESSING WITH ORACLE HEALTH INSURANCE COMPONENTS

4 Business Agility For a claims administration system, straight-through-processing is the ability to take the incoming claim in the local EDI format, process the claim without manual intervention and provide payment information to the payment system. The concept itself is simple enough, so why is it so hard to achieve? The two main sources of disruption to straight-through-processing is the payer s own provider contracting department and business administration department. For competitive reasons, a payer is compelled to deviate from standard reimbursement agreements with the provider and offer highly customized benefit plans to their key accounts. Without a doubt, reducing variation in the plans and reimbursement schedules that you offer, as a payer, will simplify your back-office and eventually lead to operational cost reduction. But, while standardizing your reimbursement and plan offerings definitely benefits your ability to achieve straight-through-processing, it also inhibits your ability to do business. The only alternative is that you make sure that your back office is flexible and agile enough to follow the business, wherever it may go. After all, isn t the purpose of enterprise software to make business easier? While the answer is obviously yes, this does not mean that the solution is simple. There are three aspects to straight-through-processing in a componentized architecture: integration, coordination and auto-adjudication.» Integration: The first aspect is the interoperability between different applications. End-to-end claims processing typically means that claim information is passed from one system to the next: you need a way to connect these systems into a robust process chain. That means you require the applications that make up the process chain to have standard access points that allow you to connect them together. It also means that these access points need to have a measure of flexibility, because you need all applications in the chain to be aligned on the data elements that they are passing along. This flexibility needs to be inherent in the access points, to prevent you from having to update all of the connecting interfaces every time you add a new data element to the payload.» Coordination: Unfortunately, claims processing is not always a straight line. In fact, in some markets a straight processing flow is the exception. The path that a claim traverses often has loops and junctions. This means processing requires a certain degree of coordination. To illustrate this scenario, consider the following pricing scenario. Suppose that there is business rule that says that only priced claims can go through clinical editing, as the price is one of the data elements that determines the whether the claim is edited. But if the clinical edit then results in new information on the claim, such as a new procedure code, then the claim has to be repriced.» Auto-adjudication: The third aspect is the level of automation within an application, i.e., auto-adjudication with accurate results. Within the context of configuration, health insurance is very different from other types of insurance. Where other consumer insurance products are typically quite static (e.g. life, car, home), the configuration for health insurance operational processes are highly volatile. Members constantly switch between plans and the sheer volume of claims is greater than any other insurance business. In other words, for a healthcare payer, configuration is an ongoing process. An application s ability to auto-adjudicate is about finding the sweet spot in the spectrum of flexibility versus maintainability. On the one end you will find systems that offer flexible configuration rules that are sophisticated enough to automate any business rule, but require steep investment of skilled resources to implement and maintain (i.e., code it yourself). So even if you can automate any rule, the combination of the implementation complexity and the relentless influx of new rules to configure, requires such effort that once you ve got your system set up, the business requirements will have changed. Your configuration simply can t keep up with the pace, so it becomes tempting to pend and push the claims downstream manually. The results are reduced accuracy and increased operational cost. 2 REDUCE MEDICAL LOSS RATIO BY STRAIGHT-THROUGH-PROCESSING WITH ORACLE HEALTH INSURANCE COMPONENTS

5 On the other end you will find robust, rules-driven systems that are easier to configure, but ultimately lack the flexibility you need to automate the myriad of benefit plans in your portfolio. This is a typical challenge for legacy systems; they were built to be fit-for-purpose so they have been designed for the health insurance business user. But some of the contemporary benefit designs could not have been imagined when these systems were first implemented, often more than a decade ago. For example, the design of a legacy system typically assumes that each claim line has only a single procedure code that is relevant for adjudication, while contemporary facility claims often use combinations of medical codes to identify the rendered service. Some of these assumptions are so embedded in the system s logic, that even custom extensions to the system won t work; and manual adjudication is the only way to adjudicate. The results are increased operational cost and increased claim turnaround times. Finding the optimal balance between flexibility and agility is paramount for running an efficient claims shop. Risk-Based Intervention The ultimate goal for a claims shop is 100% auto-adjudication with a processing and financial accuracy that also converge towards 100%. However, there is always a subset of claims that you do not want to auto-adjudicate. Typical reasons are fraud detection, extra controls around high dollar claims or a business requirement to stray from the system s configured adjudication rules. This means that you require your operational systems to detect when a claim should be pended and, if the claim requires manual work, send out an event to a human workflow system. It also ties back into the aspect of coordination. If an operator manually edits data elements on a pended claim, i.e., change the servicing provider, that claim will have to repeat a number of steps in the process chain, such as contract selection and reimbursement. Oracle Health Insurance Components Oracle Health Insurance Components are state-of-the-art applications built specifically for the health insurance business. Each of the OHI Components focuses on a single core process, e.g., claim adjudication, claim pricing, benefit administration, authorizations, value-based payments and policy administration. To achieve straight-through-processing in a componentized architecture, you require the means to integrate and coordinate across all of the components in the claims process, as well as achieve an automated flow within each component. The next few sections speak to the claims processing capabilities of OHI Components. There are two OHI Components that have been designed for claims operations. The first is Oracle Health Insurance Claims Pricing; the second is Oracle Health Insurance Claims Adjudication.» Oracle Health Insurance Claims Pricing takes new claims in a canonical format and selects the appropriate reimbursement, ranging from fee schedule to prospective payment function. During the pricing process the claim may go through adjustments, provider accumulators and replacement rules. The output is a priced claim.» Oracle Health Insurance Claims Adjudication takes a priced claim in a canonical format and retrieves the member s plan ID from the enrollment system. It matches the plan s benefits to the claim and applies the appropriate cost share calculation, based on all the relevant accumulators. The output is an adjudicated claim and a financial transaction that is ready to go to your financial system. Oracle Health Insurance Claims Pricing and Oracle Health Insurance Claims Adjudication are independent components, e.g., the Claims Adjudication component can connect to another vendor s pricing engine, and the Claims Pricing component works with another adjudication engine. Payers that use both the Claims Pricing and the Claims Adjudication components benefit from a pre-integrated combination, referred to as OHI Claims. 3 REDUCE MEDICAL LOSS RATIO BY STRAIGHT-THROUGH-PROCESSING WITH ORACLE HEALTH INSURANCE COMPONENTS

6 Integration OHI Claims offers a wide variety of integration points. These are open web services that include a mix of business operations and data management operations. These include web services to accept (new) claims, send out adjudicated claims, synchronize accumulators with other systems, retrieve enrollment information, load medical codes, load member data, load provider data, send out workflow events and many, many more. Every payer requires its own set of data elements. Most applications can be extended to store additional information, i.e., not native to the system. While this is true for OHI Components as well, our applications go one step further: every integration point is extensible out-of-the-box. That means it can accept, store and pass on any custom field that is passed along through the integration points. In addition, the integration point that takes incoming claims even stores information it cannot match to the information in the system. A typical example is when the claim is submitted with an unknown provider ID. Instead of rejecting the incoming claim at the gates, OHI Claims accepts and stores the claim record; the claim is automatically put on hold and the system sends out a work flow event so that an operator can resolve the situation. Coordination Each claim in OHI Claims keeps track of where it has been and where it is going. This makes it possible to achieve a fully automated process flow, even for complicated claim scenarios that require looping back to earlier steps in the process, e.g. when the automated clinical editing results in a new line on the claim. Apart from where the claim has been, OHI Claims also stores information as to where the claim should go next. The more you collaborate with third party administrators, the more challenging this coordination becomes. For example, if you leverage an external provider network for some specific services, the claim may have to be priced externally. OHI claims provides configurable decision points that determine the path of the claim; submit the claim to the internal pricing engine or send the claim out through one of the integration points, so that it can be priced elsewhere. OHI Claims provides you with the means to configure and control the flow of claims through configurable tags on the claim. These tags tell the system which steps have been completed, as well as which steps to repeat and which steps to skip. In other words, all the tools you need to achieve a fully automated flow. Auto-adjudication Because each OHI Component focuses on one of the core processes of a health care payer, configuration is completely rules-driven. We know the kind of rules that a payer needs to process claims, so all the common settings are available; configuring the system is a matter of setting the right parameters. This means configuration users can quickly set up new benefits, plans and other business rules. In addition to the standard settings that are typical for claims processing, all configuration rules are extensible. This means the configuration user is able to add custom fields and indicators to any rule in the system and define the evaluation logic, all through standard features within the application. It is this design principle that distinguishes our applications: OHI Claims offers the flexibility you need to automate complex claim scenarios while retaining the agility you need to realize automation. 4 REDUCE MEDICAL LOSS RATIO BY STRAIGHT-THROUGH-PROCESSING WITH ORACLE HEALTH INSURANCE COMPONENTS

7 In a componentized architecture, the ability to auto-adjudicate also relies on the capability to exchange information between components while processing a claim, i.e., real time. For example, before a claim s cost share can be calculated, the claims engine needs to know which benefit plan the member is subscribed to. The system of record for this information is the enrollment system (and not the claims engine), so OHI Claims does an online call out to retrieve the information for the serviced member, i.e., while processing the claim. Once it receives a response the calculation engine can continue to select the appropriate benefit. The call out for enrollment information is another example of a standard integration point that is available in OHI Claims. In addition to the standard integration points, OHI Claims has configurable call out rules that allow you to connect to any other system to exchange information, such as a service line bundling system or a clinical editing system. The configuration not only coordinates the exchange of information, it also determines which claims require the call out. This means the system, and not the user, decides whether or not a claim requires clinical editing. In addition to automated benefit selection and calculation, OHI Claims also allows you set up auto-deny rules for claim scenarios that never result in payment. Examples are claims that are submitted beyond the filing limit, claims that are exact duplicates with other claims that have already been processed as well as claims that exceed a benefit limit or for which the authorization has been denied. Pend Only What You Need To Pend OHI Claims offers configurable rules that suspend a claim from the automated process. Each of these rules specifies a particular claim situation. The purpose of these rules is to catch those scenarios that cannot be automated, such as the manual review of high value claims, suspected (but not exact) duplicate claims or the review documents that are attached to the claim. To prevent unnecessary pends, OHI Claims uses highly flexible and granular parameter-driven rules. They evaluate combination of medical codes as well as processing information, such as adjudication results and system messages in order to decide whether (and for what reason) the claim should be pended. When one of these pend rules trigger, the claim is put on hold and a web service event is sent out. This mechanism allows you to connect OHI Claims to your own human workflow system. The content of the event is configurable, so it caters to any queuing logic that may apply. In addition, each workflow event passes along a URL that goes straight to the suspended claim, providing that the user has the proper access privilege, so that the business users have a completely seamless user experience. When a claims operator works a pended claim, the user can reprocess the claim real time. This way the operator knows exactly how the claim will adjudicate once it is resubmitted. In addition, the operator can even override the processing results when an exception needs to be made. For example, the operator might undo or adjust the calculate cost share. Besides risk-based intervention, the pend rules in OHI Claims also allow you to automate specific kinds of holds. For example, you may want to suspend a claim from further processing until the supporting documents arrive, or the appropriate authorization is submitted. OHI Claims is designed to achieve full auto-adjudication; if you do not configure suspension rules, all claims will auto-adjudicate. 5 REDUCE MEDICAL LOSS RATIO BY STRAIGHT-THROUGH-PROCESSING WITH ORACLE HEALTH INSURANCE COMPONENTS

8 Conclusion Health care insurance far exceeds any other insurance business in terms of complexity, claim volume and volatility of business requirements. This makes reducing the cost through operational efficiency all the more challenging. Given that a typical payer s back office is made up out of many different systems, straight-through-processing is about being able to connect those systems that have a stake in the process in order to create a seamless claims flow. On top of that, each application in the flow needs to be both flexible and agile, two system traits that rarely go together. The combination of these two traits is the primary design principle of Oracle Health Insurance Components: offer pre-integrated applications for the health insurance market that are configurable through fit-for-purpose, parameterdriven rules giving you the agility you need to keep up with the constant influx of new market requirements that can be extended with your own settings and logic to meet your specific business requirements giving you the flexibility you require to achieve operational excellence. For more information on Oracle Health Insurance, please visit oracle.com/insurance. Contact us by at insurance_ww@oracle.com or call to speak to an Oracle Insurance representative. 6 REDUCE MEDICAL LOSS RATIO BY STRAIGHT-THROUGH-PROCESSING WITH ORACLE HEALTH INSURANCE COMPONENTS

9 Oracle Corporation, World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065, USA Worldwide Inquiries Phone: Fax: CONNECT WITH US blogs.oracle.com/oracleinsurance facebook.com/oracleinsurance twitter.com/oracleinsurance oracle.com/insurance Copyright 2015, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only, and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document, and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.0715 Reduce Medical Loss Ratio by Straight-Through-Processing with Oracle Health Insurance Components July 2015