Reduce Medical Loss Ratio by
Straight-Through-Processing with
Oracle Health Insurance Components
ORACLE WHITE PAPER
|
JULY 2015
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
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
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
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
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
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
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 e-mail at
[email protected] or call +1 800-735-6620 to speak to an Oracle Insurance representative.
6 | REDUCE MEDICAL LOSS RATIO BY STRAIGHT-THROUGH-PROCESSING WITH ORACLE HEALTH INSURANCE COMPONENTS
Oracle Corporation, World Headquarters
Worldwide Inquiries
500 Oracle Parkway
Phone: +1.650.506.7000
Redwood Shores, CA 94065, USA
Fax: +1.650.506.7200
CONNECT W ITH US
blogs.oracle.com/oracleinsurance
twitter.com/oracleinsurance
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.com/insurance
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
facebook.com/oracleinsurance
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