HOW TO BEST IMPLEMENT Year 2000-related data verification practices in risk management information systems can get pretty ugly. The technical staff can make a database approach sound tougher than an insurance renewal after a class-action lawsuit. The legal staff can get so focused on defining "compliance" that you start to develop Year 2000 paranoia even about the cheap green clock in your car radio.

Most risk managers can focus on a few basic topics in reviewing their own RMIS date exposures. These topics include how dates are stored, reported, calculated and processed over in-house systems.

The $64 million question for many RMIS is how the dates are stored or processed in the program to achieve Year 2000 compliance. The ideal situation is when the overall process of planning for four-digit years or Year 2000 issues was anticipated in the core architecture of the program.

Many newer RMIS since 1996 have that potential benefit. Dates and date/times stored using the National Institute of Standards & Technology standard date and time formats YYYYMMDD and YYYYMMDDHHMMSS present the least at-risk Year 2000 scenario. Products and programs that avoided using the "native" date and date/time data types of the underlying database similarly also may have a Year 2000 benefit, assuming all data entry fields that accept dates require that a four-digit year be entered.

However, many older programs that do not store a physical date in the database depend on the database to interpret a stored variable that is used at run time. These older programs often can have a Year 2000 date exposure, as the year is assumed to be 19XX or is calculated as a certain number of days past a 19XX date. Because the database might be the primary vehicle used for processing the dates, it is not likely an application vendor can offer the Year 2000 comfort most individuals might want. My suggestion would be to move to a newer system to avoid the risks.

So how can you implement a Year 2000 system and data verification process for your own RMIS? Begin by defining the Year 2000 threats to your overall data processing. These threats tend to appear in three levels.

Level 1 threat: Desktop systems. The first Millennium Bug threat could easily be the date entry format set up in the Microsoft Windows user-specified system date format found in the Windows control panel. Because you probably set this up on your own personal computer, check it first. If you entered the user-specified two-digit year format, the data entry controls used by your RMIS program might not be Year 2000-compliant. This assumes the legal definition of compliance includes storing four-digit years in the data file.

A similar level-one threat for older PCs could be that the hardware basic input/output system program might not handle dates beyond 1999 unless they were manually reset to 01/01. Some very old BIOS programs are not able to handle 01/01 at all. After making a reassuring backup of your program and data, why not set your PC system date on one workstation to 2/1 and see what happens with your PC? Verify that it meets your Year 2000 and leap-year processing expectations.

I'd also recommend programming your RMIS software to check for the system date format when it starts. This way, if the user has not set a four-digit year, a warning message will alert the user. The software should not run until the four-digit year is properly set. Also, the RMIS program can easily be programmed to check the current BIOS date and time and compare it to the data and time of the last login. Any discrepancy in the dates should trigger a warning.

Level 2 threat: Code review and regression testing. The second threat level involves the technical staff performing a programming code review and some regression testing to ensure that four-digit year and leap-year processing standards are met.

This involves the technical staff sending the company's program code out to a contract information systems shop to troubleshoot your program. Because the staff of the IS shop did not write the program and does not know risk or claims management, the IS shop is not likely to find things other than obvious date format problems. So, you're not really safe yet.

While this is being done or verified, make sure that all date ranges are computed correctly, including date ranges that span 01/01 and 02/29. Don't forget to check the dates you created in user-defined data fields. If these were done in a free-form text field, you might not have a reliable date edit process, and the standard program code review could miss your user-created fields since they were not official date fields in the database.

Find out if your program uses date controls from third-party software companies. These controls programs are embedded in some RMIS programs to save time and development costs. Unfortunately, these same firms are small, they often go out of business and the date controls can contain Year 2000 performance problems.

A few simple RMIS programming tests for dates include:

Date differences

01/01 -- 12/31 = 1 day

03/01 -- 2/28 = 2 days (leap year)

Date add

12/31 + 1 day = 01/01

02/28/2000 + 1 day = 02/29/2000 (leap year)

Level 3 threat: Business rules and standards. This level starts to look familiar to risk managers because business rules and industry standards start to play a part in Year 2000 processing compliance expectations. For example, does your Occupational Safety and Health Administration lost-time calculation default to seven days or five workdays, or do days of lost work include or exclude the day the employee left work and the date the employee returned? Are holidays a part of the calculation? If so, what days, and how do you override these? What happens when you do not know a key date value at the time of date entry? Is the field left blank, is a default value entered, or is the field automatically filled at a later time?

Some key dates in RMIS to evaluate include: date of injury or death; insurer notified date; OSHA or state reported dates; statute of limitations date; payment and reserve dates; diary follow-up dates; claim, loss and events dates; suit and court dates; record updated; time/date stamp; reopen date; and policy expiration dates.

Because it is already late 1998, one might ask, "Do I need to do a second review of the Year 2000 situation at this time if I already did one?" Absolutely. You are at risk due to new hardware changes, new programs you may have loaded that change Windows settings, or dynamic link libraries program versions and the fact that Year 2000-compliant applications have a higher standard. Now the boardroom players and your auditors expect a lot more than just having programs work without defect after Jan. 1, 2000.

The overall benefits to risk managers for investing time in Year 2000 verification are both operational and financial. Operational benefits, such as breezing through a workers compensation check run or getting report results that reliably calculate lag times with compliance dates, are obvious. Perhaps not so clear are the financial benefits. Avoiding IRS Form 1099 errors and OSHA reporting fines and accessing all -- not just some -- claims files in the date selection run you gave your actuary can save a lot of money.

What steps might one take to prove that a RMIS is Year 2000-compliant? Year 2000 remediation and verification requires a multidimensional process. Do not depend solely on sending a legal questionnaire that asks or demands that the software is Year 2000-compliant or -compatible. This is not a bad step; it just does not prove that your systems, programs and practices are being operated in a Year 2000-compliant manner within your processes.

Don't depend on a legal definition for Year 2000 comfort. Definitions for what is Year 2000-compliant can be a good reason to take a closer look. Is the program or technology Year 2000-compliant, or just Year 2000-compatible, certified, ready, resistant, immune, supported, functional, error-free or plain old working? Is the program providing dates on the display screens, reports, derived field calculations, database storage files and in input/output files, all in a four-digit year structure?

For every hour and every dollar spent on questionnaires or legal review, why not spend $5 on a hands-on local technical and application operational review? Do some old-fashioned "show me" testing. Write procedures, enter test data, plan your next equipment upgrade and stay ahead of the baggage of having older technology systems. For example, disk operating system programs running on old Windows 3.1 systems are unlikely to ever be as Year 2000-compatible as you'll need. Why wait any longer to upgrade? Now is a good time to call your RMIS partner and plan your future, even if you need some new software.

How to do you keep improving data quality and dates after the new millennium is here? Create a role for data quality and process verification within your daily and monthly RMIS operations, or add it to your third-party administrator contracts as a funded expectation. Use the free DORN Claim Data Specification and resource exhibits, found on the World Wide Web at dorn.com, to focus on risk management dates that matter. Define who fixes data now and why. How often? What testing of dates, derived fields or financial calculation is occurring? What audit trail for data deletions, database tampering and program upgrades is being managed? Do you plan to test for Year 2000-type date issues after every upgrade or new hardware change? Oops. Time to stop before the Year 2000 paranoia takes over again.

So, let's move the current, limited Year 2000 discussions beyond the obvious nuts and bolts. Let's talk about solutions that work, with dates and other forms of data. In the long run, we'll accomplish a lot more.

The author's comments do not reflect the limitation or expertise of any specific product or vendor in Year 2000 data compliance issues, including that of DORN Technology Group Inc.

Mark Dorn is president of DORN Technology Group Inc., a Livonia, Mich.-based company specializing in risk and claims management information systems.