|
Home |
Software Providers |
Consultants |
Articles |
Columns |
Reviews |
Headlines
|
|
|
- |
| - |
|
- |
Entire contents Copyright © 1999 Business Insurance "Ensuring data integrity; Risk managers must be involved in
the conversion process"
by David Tweedy |
|
DATA INTEGRITY IS A problem that plagues everyone involved with a risk management information system. It is dangerously naive to assume that system-generated data is accurate, regardless of its speed of generation or visual appeal. The risk management professional -- and the RMIS vendor -- should take measured steps to ensure data integrity. The first step, as I described in my last column (BI, Nov. 23, 1992), lies completely in the hands of the claim originator. All too often, late, incomplete or totally inaccurate claims reports are made from remote client locations to a central reporting center (usually the corporate risk management or insurance department) and then sent to the claims organization. Many times that means taking initially sparse information that needs to be refined again and again by the claims organization until the final picture is clear. Ensuring quick and accurate transmission of data is a separate issue unto itself, but there are viable and cost-efficient ways of accomplishing this difficult but essential task. For example, line supervisors can be educated about data transmission, and can be given financial incentives for data accuracy. In addition, companies can install a comprehensive claim reporting system or electronic data interchange. These are among the best methods to improve data accuracy on the front end. But what about the next level? How do risk managers confirm that data they receive from third-party administrators, insurers or internal self-administered claim departments are accurate? What steps do the service vendors take to ensure data accuracy? To illustrate, I'll describe how a RMIS vendor typically goes through the process of absorbing data from other sources and converts it to the vendor's data format. It is an important step to evaluate because, after all, the risk manager is depending on the RMIS vendor to ''scrub'' the old data and ensure the accuracy of the new data generated while the RMIS vendor is in place. File format Typically, most data conversion or mapping routines start with the basic file format. Most insurers and third-party administrators' systems capture data in five general categories: general claims information (date of loss, location, description of loss); claimant information (date of birth, Social Security number, etc.); reserve numbers and changes; checklists; and vendors. The categories are usually tied by claimant number but they may also be tied together by other common elements, such as Social Security number. Sometimes they are not linked, and that makes the process extremely difficult when converting to the more advanced data base format that most of the RMIS vendors have today. If the client and client providers cannot suitably break down their historical data in the file format stage, they must go to the next phase. Extensive data review Essentially, every claim record must be checked for consistency. Duplicate claim numbers (some with no information) are sorted out. Claim numbers with no dates, or other obvious problems, are recognized and separated from the data base. A rule of thumb applies here: ''Garbage either settles to the top or the bottom.'' This ''rule'' means that mistakes usually come at the beginning or end of the data run when the files are downloaded to a text file on a spreadsheet or text editor. Most RMIS vendors find that insurers generate the most problems because they have not historically given much information. Many times, the years of skimpy collected data cannot be converted to the new RMIS vendor system because of the expense and the lack of adequate information. The risk manager usually settles for the aggregate claim counts and total incurred dollars, rather than the desired transactional breakdown needed to do solid loss development or forecasting reports based on historical data. Trial input This stage is where the ''rubber meets the road'' for the RMIS vendor. After the data has been scrubbed, the vendor will run through it in an accounting sense to see whether or not the reserves and payments agree. Adjusting transactions are usually performed with a given descriptor attached to the particular claim in question so that the user can research and analyze the accuracy of that particular claim. Unfortunately, many RMIS vendors find that reserve changes resulting in payment alterations are not picked up by the accounting system, leaving variances between the claim system and the accounting system that must be explained. It is crucial that the vendor point out these inconsistencies to the client to avoid a lot of embarrassment. Client analysis After the first three steps are performed, the RMIS vendor brings the data to the client for sign off. This is entirely proper and I recommend that clients be actively involved in all phases, if possible. The client should become very familiar with this process and should be able to explain some of the data inconsistencies that may have occurred prior to the RMIS vendor coming on board. In effect, the RMIS vendor is sort of a ''data auditor,'' which can be a very valuable tool in correcting past mistakes. The risk manager may be able to go back to the former data provider for correction. Ongoing conversion Obviously, once the RMIS vendor has developed a routine for conversion (most RMIS vendors have conversion routines for nearly all data sources, like insurers or third-party claims administrators), the ongoing process is not a problem. The RMIS vendor must still diligently look for the same types of mistakes. The risk manager should oversee this process as well. Following are some recommendations for evaluating a system:
Copyright© 1996 Business Insurance |