A simple way to manage complex health insurance products. Is it at all possible?

A simple way to manage complex health insurance products. Is it at all possible?

Yes, there is a way to manage the complexity of health insurance as such. In this article, the focus is on product definition and how the real business scenarios may be reflected in the system in an easy way.

 

Why is this difficult?

Health insurers face a lot of market challenges: how to provide value and quality while controlling costs and meeting regulatory requirements. There are some additional issues resulting from the business specifics: complicated products (catalogs of medical services, limits, waiting periods, exclusions, etc.), complexity of claims, greater (in comparison to other insurance areas) claims data volume, long list of stakeholders including cooperating medical providers, service price lists for chains of providers or individual providers.

Nevertheless, the PRODUCT stands at the very beginning of the healthcare insurance value chain. As said before – the product in health insurance appears to be complex and parallelly, it may be created or changed ad hoc in response to consumers’ preferences (e.g. tailor-made products especially for group policies) or streamlined to keep up with the market and competitors.

Flexible solution for product design seems to be a key part of the IT ecosystem of each health insurer.

 

Step 1 what and how – in general?

The first question that needs to be answered is where lies the balance between business requirements for flexibility summarized in „we need a highly configurable tool as anything can change in our product” and some basic configuration options that can limit the creativity of product owners. Parametrization instead of programming sounds good but configurability can become a disadvantage if the system is too complicated and a user cannot foresee all the effects of the prepared parametrization. In extreme case, the configurability becomes a hurdle that cannot be overcome by business users themselves without IT support. There are some additional features that should be considered to make a life of business users nicer and simpler: possibility to prepare product templates that can be easily modified or options of import/export of the configuration. And last but not least, product design requires versions management to reflect the life cycle of product – amendments or changes in general conditions.

 

Step 2 what – in details?

The single medical service is the basic brick, building the scope of health insurance. As there are markets with no imposed reference dictionary of medical services, business users should be able to design it in the system according to the requirements of the product modeling and cooperation with medical providers. Additionally, medical providers don’t have to use consistent nomenclature or coding – the same service may be named in a different way and the system should be able to cope with the problem e.g. by matching name from insurer’s dictionary to the one from the list used by a medical provider. There should be an option of bundling the medical services into bundles/guarantees/modules to make it more manageable. These elements can become blocks that the product will consist of. In the end, the product can build a tree-like hierarchy (e.g. bundle of laboratory tests consisting of 2 packages: blood tests and urine tests. The number of levels may depend on the complexity of the product.

health insurance

 

Step 3 let’s limit it!

Let’s have a closer look at different kinds of limits  – element specific for health insurance that for sure should be a part of product definition in the system. Limits configuration seems not trivial, as there is a need not only for pure limit configuration but also there should be a description of the way the limit is consumed. Below a short overview of aspects that should be taken into consideration in the area of limit configuration:

  • Limit type, e.g.
    • copayment – indicates the amount/percentage of money that the insured is obliged to pay
    • deductible – similar kind of limitation to co-payment, the difference is that for deductible there is an additional limit for the maximum amount of copayment (e.g. deductible of 20% with a maximum of 300€)
    • guarantee – a lump sum, for example, to define the amount to be paid for every day of hospitalization
    • general limit – defines the maximum amount of money/quantity of occurrence that the insurer will pay
  • Limit kind, e.g.
    • value (absolute or relative – depending on another parameter)
    • quantity
    • or more complicated modes, like percent of an arbitrary value defined by authorities; quantity before/after (the insurer reimburses ‘x’ value before a defined quantity of services is reached, ‘y’ value when the defined quantity is exceeded); formulas indicating min/max of the reimbursement
  • Period of validity: insurance year? the calendar year? monthly? or according to some special agreements?
  • Objects consuming the limit – who does the limit concern: single insured, family or the entire policy?

It seems that the more mature is the health insurance market, the more complicated limit modes appear and the customers are used to it.

Examples:

Insured gets reimbursement of 80% of costs of medical services up to 500 EUR per calendar quarter. The limit is valid per insured family.

Insured has the right up to 15 medical consultations per policy year. The limit is valid per each insured person.

When the limit is defined it’s time to point out the level of product structure where the limit applies: does the limit concern the single medical service or maybe one of defined service bundles? More complicated models need the indication of order the limits one by one should be applied.

 

Step 4  – Last but not least

Depending on the product structure there may be a need for additional attributes necessary to reflect the product idea and its crucial features in the system. As the sky is the limit in product development it’s a challenge for the configurator to manage the product’s complexity. Definition of medical providers or their networks, an indication whether the coverage is mandatory, rules describing how the packages may/may not exist together on the policy, managing the ICD coding… – there is a long list of possibly necessary attributes. But the entire product definition is not an art for art’s sake. It is crucial information for algorithms implemented in other system components responsible for verification of the insurance coverage or calculating the benefit. But it’s a whole different story, interesting enough to be a subject of a next article.

Software House Altkom Software & Consulting has years of experience in designing, developing and implementing health insurance systems in Europe and the USA.

Are you looking for a health insurance system or for experts to help you maintain your current system? Do not hesitate and contact us!

 

Author: Monika Piątosa-Kosiorek, Business Consultant

1 gwiazdka2 gwiazdki3 gwiazdki4 gwiazdki5 gwiazdek (1 głosów. Średnia: 5,00 na 5)
Loading... Czy podobał Ci się artykuł? Jeśli tak, udostępnij go w swojej sieci!

Dodaj komentarz

avatar
  Subscribe  
Powiadom o