By Data! Data! Data! For those of you of a certain age, you’ll pick up on my Brady Bunch hint.
Be forewarned! Today’s blog is going to irk some risk managers who are data hoarders. The first step towards dat hoarding recovery is acknowledging the problem. Allow me to opine on all things RMIS data based on my experience implementing and servicing clients for decades.
When implementing, always begin by knowing what your end goal is. What are you trying to do with the data? Aside from regulatory needs, think about what analysis you hope to achieve. As an example, when I worked at a staffing company with a lot of WC claims, we absolutely wanted to capture the job class code and job title at the time of loss to cross check that against the payroll job class code. We caught some heavy construction works coded as office personnel (we did!).
You may feel a lot like being a kid in a candy store when you’re looking at new RMIS systems. There are so many new features and flashy sparkling things that clients would like, no want, no need, no even stronger they REQUIRE more fields, more, more, more! I appreciate the enthusiasm and I certainly want you to get value out of your new purchase, but I can say the best implementations and happiest clients are those that are focused on a few key elements and know the long term plan for growth of a system.
Your sales rep or account rep is going to try to sell you EVERY thing at once, because their commission is based on that. Unless you have a bundle in your budget that is burning a hole, your better bet is to implement initially a small piece of what you want to do. I’d even go so far as to call the entire first phase the Proof of Concept project. Why approach this way? It allows you to implement fast and show success quickly (or prove that the software doesn’t meet your needs before a lot of money and time is wasted). If I were a risk manager, I’d implement an incidents portal first – nothing more, nothing less. Only once your RMIS vendor proves successful in that (which would be a portal to collect incidents and an export/feed to your carriers/TPAs with acknowledgement file back) would I consider expansion to claim feeds, safety, values collection. For those who are WC heavy, yes an employee feed would be beneficial, but I’d see if you can find a way to not include that…because that adds a layer of complexity (privacy rules and regulations; if decentralized then what file format does the data come in; API calls or not, etc.) that will bog you down. An additional benefit from a smaller implementation is less license fee costs until you’re ready to use them. Of course if claims and incidents are not your insurance cost drivers, then it is even more fun to start with values collection of exposure data for insurance renewals.
If you are changing RMIS vendors or you are five years in with your RMIS vendor, that is a GREAT time to scrub your data. I’m working with a client that has contact records with an inactive yes/no field and an active yes/no field. Likely these field were created during implementation and no one came back through to clean up the ‘false starts’. So now we have to figure out 1) which is more consistently populated 2) are there any workflows tied to either field before we can consolidate the data and get rid of a field. The implementation team is in such a rush to get you live that this happens more often than not. And frankly likely to happen more as analysts who aren’t as familiar with the data model will create fields before first checking the existing field choices.
During a transition to a new vendor, one of the first steps is an IDA (initial data analysis) to help sort through the data. This is a great opportunity to cull fields that are no longer used or were used on a one one time project or were never used. I have great news! You can request an IDA of your existing data at any time to go through that same culling exercise. I just recently requested an IDA on policy data to confirm my suspicion that some custom money fields weren’t being used. at all.
I’ve told many many many clients that I’d rather have 5-10 fields consistently populated across all coverages than 100s of fields sparsely populated. I know you can potentially get the data, but will your field users/end users consistently populate the data. If not (and certainly you don’t want to make EVERY field required), then trend towards not capturing.
The advent of AI may actually help in this endeavor because AI can ‘read’ the text fields and narratives and provide a synopsis.
I could go on and on, as I feel as passionately about clean data as I feel about report hygiene (and keeping my house clean). A de-cluttered house (of data) is a much more serene environment and allows better visibility to trending that you can actually act upon.