BI’s Article search uses Boolean search capabilities. If you are not familiar with these principles, here are some quick tips.

To search specifically for more than one word, put the search term in quotation marks. For example, “workers compensation”. This will limit your search to that combination of words.

To search for a combination of terms, use quotations and the & symbol. For example, “hurricane” & “loss”.

Login Register Subscribe



During its problem-riddled conversion of data to a new risk management information system two years ago, the Board of Risk and Insurance Management for the State of West Virginia discovered nearly $2 million of reserving reconciliation problems.

About 80% of the error eventually was traced to claims data mistakes by the board's outgoing third-party administrator, which only grudgingly assisted the board's new RMIS vendor during the transition period, according to Robert L. Ayers, chief financial officer of the board.

Most notably, the TPA, which was owned by the insurer that wrote the state's retrospectively rated coverage, had added to the state's account data from other policyholders' claims, Mr. Ayers said. In addition, the TPA had posted some legitimate claims to the wrong policy years, he said.

In the end, however, the underreserving totaled less than $300,000.

Under the agreement with his current vendor, there is far more up-front checking of data validity.

The agreement also assures Mr. Ayers of a smoother and less costly conversion in the future if he decides to change RMIS vendors.

At Memphis, Tenn.-based Mueller Industries Inc., claims data mistakes have led to a $2.3 million error in incurred claims totals for the company, said Risk Manager Millicent W. Workman. Most of the problem at Mueller involves workers compensation claims in Ohio, where the company self-insures that risk.

Ms. Workman said the problem occurred because Mueller's TPA, which also is the company's insurer and RMIS vendor, has not been capturing all of Mueller's excess insurance recoveries for the past two years. Mueller, it turns out, had not given the TPA the information necessary to properly capture the information.

Even as the current vendor is working on fixing the problem, Ms. Workman is shopping for a new system, though not because of those problems. She is looking for an in-house system.

But, referring to incurred claims, Ms. Workman emphasized, "Believe me, next time around we're going to know how that's picked up."

RMIS consultants and vendors warn that those cases illustrate how even risk managers who do not face the much-publicized Year 2000 computer problem likely are exposed to other information system dangers that are potentially more perilous and even more pressing: a lack of data integrity, or accuracy.

Data integrity is a problem risk managers must dispatch immediately, experts say.

Several trends are beginning to push risk managers to convert their data to new systems. That provides an opportune time to evaluate data integrity, experts say.

But, because of the absence of data standards -- or a consistent method in how data sources collect, maintain and interpret data -- risk managers will have to invest a lot of time in the conversion process to ensure that the converted data is interpreted and laid out in a way that will make the new system an effective tool.

At the same time, risk managers have to be careful they do not set themselves up for problems in future conversions.

While business has a couple years to fix the Year 2000 problem, bad data is coursing through many risk managers' information systems today. As a result, risk managers and their top management may be relying on erroneous information when they make decisions affecting their organizations' future.

A spokesman for the Self-Insurance Institute of America Inc. rejected the notion that the TPA industry may have a widespread problem with ensuring data integrity. As in any other industry, the lower service levels that some individual companies provide should not indict the entire industry, he said.

Information system experts, though, contend the data integrity problem is extensive, regardless of the source.

"The only question is how high of a percentage rate of error there is in data, not whether there is" an error problem, said Mark Dorn, president of RMIS vendor DORN Technology Group Inc. of Livonia, Mich.

Mr. Dorn estimates there is an 8% to 20% error rate in data, spiking as high as 80% in some cases.

The problem is serious, concurs Paul Steinman, sales and product manager of risk management technology for New York-based J&H Marsh & McLennan Inc., which offers RMIS and data auditing products and services.

"One-third of every claim we touch -- a location, a name spelling, the cause of loss -- is incorrect," Mr. Steinman said.

Experts point the finger of blame at risk managers as much as at any other entity -- TPA, insurer, broker, RMIS vendor -- that is handling data.

Many risk managers, after making large investments in systems, fail to take the lead in ensuring the system is working with quality data.

"Risk managers are not providing any level of requirements for that data and are not auditing against any standard. That's not a reasonable way to do business," Mr. Dorn said.

"You can have a great product, but if you're not getting the data in accurately, it's not doing you any good," said Kathy Burns, senior vp with Aon Risk Management Information, a unit of Aon Worldwide Resources in Chicago.

The windows of opportunity for errors to enter data are wide open, and the screens against such infiltrations often have gaping holes, according to experts.

Keystroke errors occur when data is input. TPAs may make mistakes while transferring over data from insurers, especially because different systems code and interpret the same kinds of data differently. TPAs also may introduce the kind of errors that Mr. Ayers uncovered in his system. A file server system crash during data entry may corrupt data. A system bug may introduce additional errors. A vendor that performed an earlier conversion may not have done a good job of squaring -- or mapping -- data fields and data interpretations in the new system with those in the old system.

There may be no more opportune time for the risk management community to tackle the problem en masse, because so many risk managers are likely to convert data to new or upgraded systems soon.

The results of an Internet survey that Deloitte & Touche L.L.P.-Risk Management Consulting Services conducted between April and October show that at least 60% of 130 respondents are planning a system conversion, said David P. Duden, national RMIS practice leader in Hartford, Conn.

Mr. Duden acknowledged the survey's results may be skewed to risk managers who are "visiting the issue." But, he said anecdotal information supports those findings.

Many risk managers will be forced to convert their data soon because technical support is disappearing for their current systems. That is occurring because of the age of those systems and the consolidation in the RMIS vendor industry.

Risk managers can take one of many data auditing approaches, but there is no consensus among information systems experts about which is best.

Some RMIS vendors perform audits.

But, Bob Morrell, vp-research and development, and Jim Gibson, manager-client services for vendor Risk Laboratories L.L.C. of Roswell, Ga., recommends using vendors just to spot logic problems, such as duplicate claims or out-of-sequence dates in a claim's history.

Risk managers and their staffs should be auditing the data to make sure "whether something could possibly happen," like 14 workers comp claims at a two-person sales office in one month, Mr. Gibson said.

J&H/Marsh & McLennan's Mr. Steinman recommended a third-party audit. That approach assures the same objectivity companies seek when they use outside firms to audit their financial statements, he said.

John Raezor, managing director of research and development for client-based technology at Aon Worldwide Resources in New York and Trevose, Pa., cautioned against using the same company to perform a data audit and a conversion.

"I would never have the person doing the audit also doing the conversion," Mr. Raezor said. The conversion firm should follow the data acceptance testing that the auditor establishes, he explained.

Even after a data audit, risk managers still should plan to spend a lot more time looking at their data to complete the data conversion to the new system, experts said.

Risk managers have to be an integral part of the process of mapping the data fields in the older system to those in the new system, experts say. Data interpretation -- determining, for example, whether reserves reflect paid claims -- also is crucial.

Data mapping is necessary because few systems identify and interpret data in the same way. Converting data without mapping could create even more data problems for risk managers. Without mapping, some data may not be captured in the new system. Mapping also should ensure that captured data is treated similarly from system to system.

An abundance of time -- not computer literacy -- is the prerequisite for risk managers to help map data, information systems experts say. Data conversions consume a total of 80 to 160 hours of a risk manager's time, Mr. Dorn said.

An industrywide data standard would largely eliminate the need for data mapping, experts said. Systems experts hope that day is approaching. Several initiatives to create a data standard are under way.

Among those heading initiatives are the Data Standards Task Force of the Risk & Insurance Management Society Inc.; Mr. Dorn, who has developed a standard and offers it free on his Web site at or on computer disk for the cost of shipping; and the Public Entity Risk Data Project, which was created with proceeds from the settlement of the antitrust suit that many state attorneys general filed against the property/casualty insurance industry (BI, Aug. 19, 1996).

Risk managers also could use a healthy dose of good fortune during the conversion. Without it, they could have trouble retrieving some or all of their data from their older systems.

Risk managers with very old systems are most at risk. There is a greater chance that the program language or -- far more important -- the database in those older systems is proprietary, or non-standard. A program language allows the risk manager to create programs and business logic rules and talk to databases. A database format is how data is stored, and documentation on the format allows risk managers to understand and interpret their data even if the program language documentation is missing.

Understanding or getting to that data may be difficult at best -- and perhaps impossible -- if the original programmers cannot be traced and consulted or if they did not leave behind any documentation to help the current programmers understand how the data has been stored and interpreted.

Risk managers going through conversions now can take some protective measures to ensure future conversions go smoother and are less expensive. These include:

Making sure the vendor uses a non-proprietary program language and database format.

As part of the conversion contract, obtaining documentation that will help programmers in future conversions.

Some experts, such as Deloitte & Touche's Mr. Duden, suggest that risk managers insist on obtaining the source codes to the program language used in the mapping process. "You at least have a road map of how that data was converted and the assumptions that were made. Not enough people ask for that."

Source codes are the commands that make the system work.

But, many vendors will refuse to provide that.

"Software companies may ask, 'What protection do I have that you'll use it and not come back to me, or use it incorrectly, introduce a problem and then blame it on me?' " observed Aon Worldwide's Mr. Raezor. "That's a legitimate concern on their part."

Some vendors, though, will escrow the codes.

Other experts said the data mapping document, without the source codes, would be sufficient protection for risk managers. The data mapping document is all West Virginia's Mr. Ayers obtained from his new vendor.

Risk Laboratories' Mr. Gibson said risk managers should obtain from their data conversion vendors a file layout, which shows where each piece of data is stored and if it is in date, numeric or text form; a data dictionary for defining each data item; and translation tables, which interpret data codes used for items such as body parts and causes of loss.

Planning an exit strategy with your current vendor. A new vendor, happy to have won a risk manager's business, likely will agree in writing how it will assist the risk manager in a future conversion with a different vendor, experts say.

Mr. Ayers, for example, extracted guarantees from his current vendor that it will provide a prescribed level of customer support if he decides to switch to another vendor. That support will cost a fraction of what Mr. Ayers had paid his former vendor during his most recent conversion.

While the data problem is a significant one, risk managers can fix it if they follow two pieces of advice, according to experts: Take the lead in fixing data problems and assess the overall cost of ownership when purchasing a system -- including the cost of bad decisions based on bad data.

"Extravagance is always buying the cheapest thing," Mr. Raezor observed.