It's only 1997, but managed care companies have already begun to fear 2000. That's because their big computers, which faithfully serve them by keeping track of virtually everything from appointment scheduling and clinical data to payroll and risk contracting, pose a serious threat to their masters.
It is known as the "Year 2000 Problem" or the "Millennium Bug," even though, as everyone knows or should know, the millennium actually changes at the end of 2000, not the end of 1999.
As with many ills, the bug is relatively simple to describe but difficult — and expensive — to correct.
Computers have long used a two-digit dating system, rendering, for example, this year's Christmas Day as 12/25/97. Back in the 1960s, when many of the systems in use today were developed, programmers chose this method for practical reasons. In those days, data storage was far more expensive than today, while systems' processing power was much more limited.
"People really expected that it would be easy to replace the systems later on," said Joel Ackerman, executive director of the Minneapolis-based Rx2000 Solutions Institute and former vice president of international information systems at United HealthCare Corp. "They assumed that the systems wouldn't be around this long. Nobody expected the software to last this long."
Instead, many companies, including health plans, ended up keeping their major systems for decades. Now, faced with an upgrade nobody expected, they'll have to buy new software, hardware or both, plus pay for data conversion.
If they don't, this seemingly obscure technicality threatens to throw scheduling, patient data, claims processing and even clinical care into chaos.
Consider the date Feb. 2, 2000. It will be written as 02/02/00 or 020200 — and regarded as Feb. 2, 1900 — in a system that isn't up to date. Most systems collect data in a way that does not consider whether a year entered as "00" should be interpreted as 1900 or 2000.
The problems caused by misunderstood dates can be catastrophic. For example, some health plans will find that, come 2000, members' ages aren't accurate.
Most existing systems calculate ages by subtracting birth dates from the current date, Ackerman notes. In 2000, a noncompliant system would subtract 20 from "00" for somebody born in 1920 — interpreting the result as negative 20.
Because there's no such thing as a "negative age" — and computers typically do know that much, at least — the result would be a rather elderly person labeled a sprightly age 20. "With treatment plans, that's a big deal, especially when drug doses are considered," Ackerman notes.
Given the risk of system crashes and perhaps even harm to patients, why don't plans just fix it immediately and be done with it? It's just not that easy. Addressing the issues is far more awkward and expensive than it may seem.
Changing dates from two digits to four digits may not appear complicated to the digitally challenged. But in reality, taking an existing computer or software package and converting it into a 2000-ready system can be a monumental task, say consultants and programmers.
Once a data base stores information, such as a date, in a certain manner, it can take an immense amount of work to change the system. You might as well try to put an egg back into the shell, Ackerman says. But just changing the dates isn't enough.
"Two-digit dates are widespread throughout these huge data bases everybody uses," Ackerman notes. "To correct it, you need to correct not only the data bases but also the programs that use the data. There are no quick, simple answers."
Hoping to fend off disaster, managed care companies are going through systematic processes to define and then address the problem.
Some health insurers are already rewriting large computer programs created in the COBOL computer language many years ago.
Take Prudential Health Care Group, whose divisions include managed care player Prudential Health Care. Prudential contracted with Computer Horizons Group of Mountain Lakes, N.J., to fix more than 13 million lines of software code and review another 8 million to ensure that they are bug-free.
But most companies are just beginning to get a grip on their Year 2000 problem. Before a health plan can bring its information systems up to speed, it must first determine its own vulnerabilities. That process alone is usually a big job.
Some might pity Pat Katterheinrich, who is charged with the mind-boggling task of making the 8,000 desktop computers and local area networks (LANs) owned by Group Health Cooperative of Puget Sound ready for the "millennium."
Before spending money on upgrades, Katterheinrich decided to start with an audit. She had considered looking at individual work stations and personal computers to determine whether each was 2000-ready, but quickly abandoned that idea when her team figured it would cost about $35 per work station — or about $280,000 — just to complete the audit. It would have been too slow and costly.
"It took us about three weeks to realize that a manual process was going to be impossible," Katterheinrich said. "Doing an audit ourselves was cumbersome and was not fast enough to meet our goals."
Instead, she ended up hiring Bellevue, Wash.-based Micropath Inc. to design an automated method of collecting hardware and software data.
"It is going to be an exhausting, expensive proposition," says Katterheinrich. "I would recommended companies begin to address Y2K immediately. The longer companies wait to identify and fix their problems the more costly it is going to be and the greater the risks."
Group Health is not the only health plan to discover that millennial fever can be very expensive to treat.
Though managers at Alliance Blue Cross Blue Shield, which has 1.9 million enrollees throughout Missouri, began planning in 1995, they have yet to pin down how much work remains to make the whole organization Year 2000-ready.
Alliance, which cares for about 1.8 million patients through its preferred-provider organization and 130,000 more in its Blue Choice HMO, began testing its Year 2000 upgrades this year.
Don Clark, manager of business systems services, quickly found that the problem was more slippery than it seemed at first blush.
While Clark expected to spend big bucks retooling programs on Alliance's mainframe, "at first glance it appeared that [the desktop computer] was OK. If you go to a spreadsheet and put in 2000, it comes up correctly. But a lot of data [used on desktop machines] come from mainframe computers. And unless the data they get can be processed successfully, there's still a risk of trouble."
Hoping to solve several problems at once, Clark and his team decided to invest in a Year 2000-ready software package called FACETS — based on a technology known as "client/ server" — which cuts down Alliance's dependence on a mainframe by allowing desktop computers to communicate more readily with each other.
After only a few months of testing the package, Clark found that he would have to boost his cost estimate. He originally projected it would cost Alliance $6 million to make sure that every computer could deal with the problem. That seems inadequate now, he says. "That figure is changing quarterly," he says. "We already see the need to reevaluate our budget."
Whatever the cost, a health plan has no choice but to deal with the problem, and quickly. Any business that depends on computerized data could get into trouble if it neglects the Millennium Bug, but health plans and providers, as in many aspects of their operations, have a special responsibility.