The benefits in healthcare insurance – calculation algorithm explained

A long time ago in a galaxy far, far away I worked on the business side and was responsible for health claims in an insurance company. For me, as a business key-user, implementation of new software was the right moment to streamline the processes with the focus  – in the area I was accountable for – on limits’ control. It meant to me (to make a long story short) that the system deals with the limits, their consumption and indicates at the end the right amount to be reimbursed. Simple, isn’t it? Just a few digits for the system to calculate – so what’s all the fuss about? What all these man-days for?
Nowadays, when I am on the other, IT side of the force, I understand better the complexity of the health claims that the system has to manage when calculating these „just a few digits”.

Calculation – what is it for?

Depending on the business model, access to the information on the amount to be reimbursed can be demanded on different stages of the business process, e.g.:

• In call center (information about insurance scope – for example percentage of the co-payment when making an appointment for the client, cost estimation, etc.)
• In portal (for the insured or medical provider)
• At the medical provider (in the moment of medical visit – if for example, the insured pays just the co-payment amount and the rest burdens the insurer)
• In back-office processes (for reimbursement calculation and settlements with the insured and/or the medical provider)

First tricky element: management of the creation and releasing of the consumption. When the medical service „blocks” a part of the consumption limit? When the consumption can be called „temporary” and when “permanent”? It doesn’t seem (at least at the first sight) extremely complicated if the insurer keeps the entire cost and claim management inhouse (e.g. all costs are reimbursed ex-post on the basis of an invoice and the insurer doesn’t cooperate with medical providers). But the more possible events on the way to reimbursement may occur, the more stakeholders are involved (like medical providers) – the more complicated it gets. Just a sneak peek of the difficulties lurking on the horizon:

1. The insurer paid a cost of medical service to the insured, this reimbursement consumed the entire limit for the insured. After a while, the insurer gets notification from the bank that the first money transfer didn’t succeed. Should (in this case) the limit be blocked until another attempt to transfer the money is made or rather – should it be “set free” and in this way, the insured should be given the possibility to consume the limit by another medical service?
2. The insurer (or its cooperating TPA) is responsible for making appointments. The insured has booked a medical visit, it will take place in 2 weeks. Should the foreseen medical service block the limit temporarily? If so, then the insurer may refuse to cover the costs of other medical services when they occur. But, on the other hand, what if the booked medical service is cancelled…?

Data for the algorithm – isn’t it too much?

Let’s start to build the basics for the algorithm dealing with the business logic of limits’ management, or – rather – let’s start multiplying difficulties and asking questions.
The process of calculation depends on many variables (connected with and dependent on each other) providing input data for the algorithm, e.g.:

• Claim – gives information about the insured, date of event, medical service and its initial (invoice) price, medical provider, diagnosis
• Policy – indicates dates of coverage, applicable product, list of exclusions associated with the insured
• Product (in Policy) – on the basis of event date: appropriate version of the product should be selected, it should provide information about the scope of insurance including list of covered medical services and limitative elements (limits and the order of their application, additional rules), definition of sharing and period model for limits (e.g. limits for a single insured for calendar year vs. limit for a family for an insurance year)

As said in the previous article – product configuration doesn’t exist for its pleasure of existence – it is a carrier of crucial information necessary to verify, control and calculate, for example in the claims area.

• The medical provider (if applying: in case insurer cooperates with medical providers and makes settlements on the basis of previously negotiated price lists) – on the basis of event date an appropriate version of the price list should be selected
• Previous claims – the calculation doesn’t take place in a void, previous claims can influence the current calculation (e.g. in the terms of limit consumption)

Now it’s time to throw all the data into an algorithm, stir a little while while saying ‘hocus-pocus!’ and expect a nice outcome (a few digits, right?).

Algorithm – an attempt to keep it simple

Let’s put that in some sort of order on the basis of a simple (and simplifying) example.
As a claim adjuster, I’ve received an invoice for medical service with price 100 EUR, date of event 15.07.2018. There are 2 kinds of limits applicable for this medical service:

• general limit (maximal sum of money) 150 EUR per insured person and per insurance year,
• co-payment = 20%

and it’s the first consumption of the limit.

As follows:

1. On the basis of event date (from the invoice) system gets the right policy and following – the right (applicable) product version.
2. From the product version system gets the needed elements of product configuration: definition of limits for the medical service that is indicated on the invoice.
3. The system applies the co-payment (according to the defined order of limit application): 20 EUR – co-payment of the insured, 80 EUR – cost of the insurer.
4. The system applies the general limit: calculated 80 EUR vs. 150 EUR of general limit – seems legit. The “gut feeling” is not enough, system has to check whether there was already a limit consumption. In our simple case, there was none, but the algorithm has to:
   • firstly – create a “storage point”: a place to keep and save information on limit consumption; for the indicated medical service for general limit = 150 EUR applying for insurance year (in the meantime system hast to set the dates, let’s say: 01.08.2017 – 31.07.2018 in this example case) per insured person,
   • secondly – add information about the new consumption = 80 EUR.

The result: 80 EUR of consumption of general limit for the indicated insured per insurance year 01.08.2017 – 31.07.2018.

5. So happily, in the end, we’ve got „a few digits” – 80 EUR to be reimbursed. Of course, system made the entire effort to calculate the amount just to give the user the possibility to overwrite it.
6. If the next analogous invoice has the event date 20.07.2018 the system will have to trim the calculated amount to 70 EUR, as there is only so much space in the „storage point” applying for the period containing this event date. But if the next invoice has the event date 01.08.2018 system won’t find a „storage point” for that date, so a new one should be created to save the information on the limit consumption.

The length of the algorithms dealing with more complex cases (e.g. complicated kind of limits – vide previous article on product configuration, price lists of cooperating medical providers, limits defined on a few layers of the product with different sharing and period models, supplementary rules for limits like age of the insured conditioning the application of the limit), all alternative scenarios (e.g. temporary vs permanent consumption), update of data of the claim (and so on) can be astonishing. The additional question is the configuration of the algorithm: the more elements can be configured (e.g. order of limit application), the more complicated it may get.

So these “just a few digits” mentioned at the beginning of the article may be part of the system that requires much workload in the area of analysis (to understand and describe properly with a few nice examples), development (to make it works) and tests (to make it work properly in accordance to business needs).

Monika Piątosa-Kosiorek
Business Consultant