By I’m hoping that this sounds somewhat like ‘”lions and tigers and bears, oh my!” from The Wizard of Oz. “Major coverage and coverage and sub-coverage, oh my!” It’s been awhile since I posted anything insurance related. This blog will get into the weeds of a RMIS system when it comes to those 3 terms.
This logic is applicable to Origami Risk software…if I am remembering correctly it should be applicable to Riskonnect as well, unless they changed their foundation since I left there. That is highly unlikely as coverages/major coverages lock in the system in all sorts of ways. If any other RMIS vendors want to give me access, I’m happy to validate if this is RMIS agnostic.
As with your RMIS implementation, your likelihood of success increases infinitely if you know your end game (which is how you want/need to report data out of the system). Bonus points for you is to know what the system does with these elements.
Our first bifurcation in insurance is divide between 1st party (damage to our property) and Casualty (damage to a 3rd party where there could be a cause or liability) and then of course Other insurances (health, life). Following this, we launch into Major Coverages…which at it’s simplest definition of Major Coverage is an overarching grouping of coverages (the major coverages vs the minor coverages)…but within an RMIS, there are ripple effects.
Major Coverage impacts security. As an example, you would want a user to have full access to WC claims and policies but no access to Professional Liability major coverage. The use of Major Coverages allows for easier assignment and maintenance of security. Before you over simplify by setting up only one or two major coverages, keep in mind the other area that Major Coverage impacts, which is your screen design. The RMIS developers logically devised that screens wouldn’t (and really shouldn’t) differ that much within a Major Coverage, so for ease of implementation and maintenance, have screen design set at that Major Coverage level.
Coverages are what you see when you are purchasing insurance policies. I buy each coverage as needed (Property, General Liability, Workers Comp, etc).
Then you have this loosey-goosey term for sub-coverages…which exists within an insurance policy for special instances (typically that have a separate deductible and/or a separate limit tied to them as well as a separate premium). Sub-coverages aren’t always implemented…because some clients don’t like to get that into the details. From a software perspective, sub-coverages have zero impact to security and screens.
I would say…again because you’re my smart reader and want to design your system for your needs today and in the future…that you should go ahead and set up sub-coverages during implementation. The only goofy thing I’ve seen is that sub-coverage doesn’t exist as a field on claims (as of my writing this). Perhaps one day that will change. My recommendation for now is to use Type of Claim or a custom coded field for your sub-coverages on claim. For policies there is a field called sub-coverage on the policycoverages table.
I’ll end with one example
Major Coverage: Property
Coverages: Property, Crime
Sub-coverages: earthquake in California, earthquake in all other states (AOS), flood