Don’t Put Off Dealing With the ‘Millennium Bug’

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.”

Getting a grip

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.”

Costly problem

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.

Put burden of repair on your software vendors

Doomsayers predicting apocalypse at the millennium have it only partly right. It’s already happening in some industries, and you have only a short time to prepare.

Physicians’ practices are by no means exempt from the “Year 2000” software glitch. From our experience consulting with practices in 36 states, the problem could hit harder in some medical practices than others because they have billing and insurance software that is inadequately supported by the publisher or system vendor.

Here’s a model letter you can send to your software vendor now. Send it by certified mail, “return receipt requested,” to the chief executive officer of your system vendor.

Spend the extra postage to give your letter the dramatic impact it needs to get your vendor’s attention. Tell your vendor you will hold it responsible for problems you encounter as a result of this bug, a known time bomb that has been ticking in systems for years.

Preachers predicting the destruction of the world at the millennium also hold out the prospect of salvation of the righteous. Assure the same for yourself by keeping on good terms with your vendor.

If you haven’t been paying the maintenance and software support fees, your vendor will very likely ignore you. You may not have any right to receive system updates or “fixes” to problems like the Year 2000 bug.

But then, that’s what lawsuits are for. Does the system have a certain base-level warranty of fitness you can rely upon when you buy or license it? Let your vendor know that you will be his worst nightmare if he lets you down.

The author, a practice management consultant in Long Beach, Calif., edits Uncommon Sense, a monthly newsletter for physicians.


Dear Mr. Chandler:

I read that "millennium glitches" in software related to dates falling after 12/31/99 could pose significant problems for businesses, including mine. Because we rely on Cindy's Computer Co. for our billing software support, I wanted to make you aware of my concern now, before any problems are apparent.

I would like to know what problems you have identified with our software and what steps you are taking to resolve them. In addition to our billing and claims processing routines, I am concerned about the ability of our Cindy system to remain compatible with Electronic Data Interchange protocols for on-line claims submission and remittance.

I look forward to hearing from you soon.

What should physicians do?

Medical group managers sometimes believe that the Year 2000 problem won’t affect them–that it only affects the big mainframe computers owned by health plans and claims administration companies.

Physician managers hear a little bit about the so-called “Millennium Bug,” read about how big health plans like Prudential are rewriting vast programs written in the 1970s, and assume that they don’t need to worry about their comparatively simple systems.

That could be a very dangerous mistake, advises Christi Iannuzzi, vice president of marketing for the Atlanta-based practice management system vendor MicroMed Healthcare Information Systems Inc.

Iannuzzi, who spent 12 years as a practice administrator before joining MicroMed, warns that groups could face devastating consequences if their computers and practice management software don’t “understand” that the year 2000 has come.

If practices fail to anticipate these problems, they will be in serious trouble just two years from now.

If a practice’s computers and software aren’t “Year 2000-compliant,” major systems and administrative procedures could begin to function inefficiently, or stop working completely. These include:

Scheduling: Systems “are just going to shut down” if you’re working with one that runs two-digit rather than four-digit years, Iannuzzi says. If the system uses only two digits and staffers enter “00” as the appointment year, most systems will start scheduling appointments in 1900. This will not only cause traffic jams internally, but could generate black marks with managed care organizations if patient flows are thrown into chaos. What group can afford to risk losing control of its schedule?

Reporting: Groups with defunct setups will have trouble putting patient data into the forms payers require. Most HMOs and PPOs will be using a four-digit system. What’s more, the federal National Standard Format, required to transmit Medicare and Medicaid claims electronically, requires four-digit dates. “If you can’t transmit in four digits, the claims won’t be accepted,” Iannuzzi says.

Charge systems: If your system doesn’t use the proper settings for 2000 and beyond, provider charges will show up as having been made in the year 1900. While the error can be caught, someone in the practice will end up having to spend time straightening out the records, and staffers are probably pulled in too many directions with existing administrative work already.

How can physician groups prepare for the inevitable? For one thing, practice managers should make sure that the group uses the most recent version of any software it has–”and most physicians don’t,” she notes.

Groups should make sure all new software or hardware is Year 2000-ready. If your present software is not ready, someone should harass the vendor to make sure it makes the next update 2000-ready–in time to install and debug.

Most of all, Iannuzzi says, don’t underestimate how complex the process can be. Sorting out when and how a practice should upgrade systems, keeping tabs on vendors that haven’t adopted Year 2000 standards and installing new software on multiple desktop computers can be a formidable job.

When in doubt, she suggests, “by all means hire a consultant to fight this battle for you.”

Our most popular topics on