Re: Insurance data models...any tips on good starting point?
Date: Fri, 18 Jul 2008 14:18:25 -0500
Message-ID: <3bGdnZZK074acR3VnZ2dnUVZ_g2dnZ2d_at_comcast.com>
"aai_jj" <jjohnson_at_grafikchaos.com> wrote in message news:7a0a3c99-320c-43c1-8ff1-55acd4b8c4e1_at_26g2000hsk.googlegroups.com...
<snip>
But what if it becomes popular and opens up to 10 or 20 states? Our main concern is that how are we going to manage the details/rates of an Insurance Plan when 2 or more states have the same Carrier and Plan but the Rates are different based upon their attributes (Smoking, Number of Dependents, Single/Family, M/F, etc.). Has anybody dealt with a similar situation?
I have designed and programmed several different types of insurance systems, including group health, which handled multiple states. As you seem to be aware the "rate tables" can get hellishly complex, with exceptions and differences all over the place. And the rules can changes almost daily! It is very difficult to develop and maintain general purpose database schemas and/or programming objects/routines to handle all this.
One of the last insurance systems I developed was for marinas, with property, liability, Crime, Inland Marine, Umbrella, etc. It supported many different states. I essentially had separate "rate tables" for each state, which had differing structures to support the ways each state wanted their marina insurance to be handled. It wasn't quite this bad but each state almost had its own screen for each type of insurance, property, liability, etc.
It is difficult to plan ahead for the next state to incorporate. Each state's insurance board/regulators have their own, unique ideas about the way things should be.
Shooting for a "general" or "universal" solution may be un-maintainable, especially in a small shop.
- David Harper