A countdown to a big event-a rocket launch, a detonation- doesn't exist just to mark time or create suspense.
An elaborate and sequential preparation usually is riding on that countdown, milking all the time available to execute consecutive steps and check for glitches while there's still a chance to fix them.
Miss an early deadline and it could compress the time available for other essential jobs as the countdown nears zero.
That's just the type of countdown going on right now in healthcare, except that the flash point is at double zero-the year 2000, or 00 in thousands of computer systems across the country.
Those systems log the year in two digits instead of four, which was fine as long as all references to years were safely contained within the 1900s.
For dates beyond 1999 to make any sense in age calculations, date-related information and the proper sequence of medical data, something will have to be done to make clear that the digits belong to the year 2000 and beyond.
If it sounds like an easy problem with plenty of time to solve, think again. The countdown has started, and before it's over, healthcare organizations may be forced to spend countless working hours to run a checklist and coordinate a long list of time-consuming steps.
"It's not a problem that people can wait until the stroke of midnight to do something about," says Ellen Dodson, vice president of strategic planning for HBO & Co., an Atlanta-based information systems company.
Healthcare executives "have to develop a master plan that manages a rather delicate series of events that have to be accomplished in the right order," says Lee Ledbetter, a key troubleshooter on the problem at Shared Medical Systems, a Malvern, Pa.-based information systems company.
Industry experts say the plan can be broken down into four principal consecutive stages: investigating the problem's extent, acquiring necessary products and expertise, implementing it all, and fully testing the result.
As a rough rule of thumb, each of the steps is a six-month process. Consultants strongly advise completing the work before 1999 to avoid last-minute problems and competition for industry resources. That means providers starting today will be working into 1999.
The work will have to be accomplished either by prevailing on a provider's own in-house technical crew or by paying for outside help.
The lucky ones could get by with a modest bill for tinkering here and there to clean up a few conflicts. But hundreds of hospitals and healthcare networks face the prospect of spending millions of dollars on replacement systems, fixing the systems they have or both.
What's the problem? Experts caution that one of the biggest hurdles to solving this "century date" problem is the time and cost of determining just what the problem is.
The programming instructions that dictate the treatment of dates are not in one place. They could be anywhere-duplicated in thousands of lines of computer code, tucked away in individual computer terminals, etched into any number of medical devices with computer chips stamping dates on every digitized reading or image.
"Finding and changing a faulty date code is relatively easy; doing this for thousands or millions of lines of code is not," according to a report on the problem issued by Meta Group, which researches and advises on healthcare information technology.
"The problems are very basic and simple and easy to fix, but it's the ultimate needle in the haystack," says Bob Mars, who's serving as century-date project leader at SMS. "It's not necessarily the difficulty of the work; it's the scope of the work."
So far, it's been difficult to get an estimate of the probable expense involved because a substantial number of providers apparently haven't even gotten to the stage of mapping out a methodical search for century-date complications.
Experts say the urgency to get started has hit home with many chief information officers and their staffs. But these computer pros are the same people who probably besieged senior executives with a host of other urgent information system priorities during the past few years such as emerging imperatives of managed care, physician connections and integration of multiple information sources.
In this climate, the retrofitting of codes to handle dates that are nearly three years away can seem like a B-list item for top executives, says SMS' Ledbetter.
"For whatever reason, this has not gotten their attention to the degree that's necessary," Ledbetter says.
But there's at least one major consequence of the century-date conversion issue just waiting to rise up and bite healthcare executives right in the budget.
Hundreds of hospitals are running venerable but vulnerable information systems in their patient accounting and financial departments that won't be fit to operate in the year 2000. By then, a new or painstakingly upgraded system will have to be planned for, implemented, tested and in working order.
For many, this project is an unexpected and costly surprise. "This is money that they hadn't counted on spending," says Lawrence Pawola, a healthcare consultant with Chicago-based Dorenfest Associates. "But it's coming out of the blue, and it's coming up quick."
Aging inventory. From the 1970s through the mid-1980s, healthcare information systems vendors corralled the computer technology of that era and turned it into automated versions of a hospital's core business operations. Those are patient accounting-billing, accounts receivable, credit and collections-and financial systems, including general ledger, payroll and management of fixed assets.
The patient accounting and financial systems sectors have since moved on to newer software programming techniques running on computers that are smaller, less complicated to program and often just as powerful as the big mainframe processors that once predominated.
Newer hardware and software products also are likely to recognize and defuse problems in the treatment of dates across the century line, although purchasers of new products can't assume they are immune, according to an executive briefing published by SMS.
Nevertheless, century-date problems are much likelier to be prevalent in older software on the mainframe computers that have been around the longest, according to the SMS report.
Many of these systems are still going, especially at smaller hospitals with limited budgets for computer purchases and routine updating.
These older systems may not have the broader range of features that newer versions can offer, and they may not run as fast or as efficiently, but they accomplish the main tasks. Like the 10-year-old MacWrite software that still may be kicking around on some home computers, the program no longer is top-notch, but it's good enough.
At the other extreme, some of the largest healthcare institutions have been loading up turbocharged mainframes with highly customized or "homegrown" software, created and expanded in layer upon layer over many years.
These do-it-yourselfers want the latitude and flexibility to serve complex institutions such as academic medical centers, and they have the personnel and expertise to pull it off, experts say. But those days could be numbered.
Out on a limb. In consultant and vendor circles, "homegrown" information systems are among three species marked for extinction at least partly because of the expense of dealing with the century-date issue.
With internally created and maintained systems, the responsibility for retooling computer code for the year 2000 rests squarely with the institution. By contrast, clients of healthcare software vendors likely can rely on the development source for much of the solution (See related story, p. 106).
But ties to vendors are no guarantee. In fact, vendors such as HBO & Co., which acquired older patient accounting and financial systems from other companies, have decided to stop upgrading and supporting some of them (See chart, p. 106).
That means hospitals using those discontinued products are on their own, just as they would be if their system were internally developed.
In the third scenario, hospitals won't even be assured of century-date revisions in a vendor's current bread-and-butter software lineup unless they are signed up for a service that routinely updates and enhances the software.
Much of the vendor research and development going on, including measures to deal with century-date issues, are keyed to current or relatively recent versions of the vendor's products, which are distributed to customers as periodic software releases.
"No one is safe (just because) they're with a vendor," says Michael Kappel, senior vice president for strategic product planning and marketing at HBO & Co. "They have to make sure they're current with releases."
End of the line? Meta Group doesn't sugarcoat the dilemma for some providers. "Year 2000 conversion will present organizations with difficult cost-justification decisions about whether to upgrade or replace homegrown systems," according to its report.
A large mainframe-based software system could have 100,000 lines of code that have to be checked for faults and either checked off or marked for revision, says Doug O'Boyle, a Meta Group consultant.
The cost of handling each line of code ranges from 50 cents to $2 depending on the type of programming involved, he says. And there could be scores, if not hundreds, of computer application programs in an integrated delivery network, the report adds.
If a major medical center's systems have extensive remaining life, can be upgraded at a reasonable expense and are replete with features that aren't available commercially, a century-date upgrade may be worth it, the report says. But "relatively few homegrown systems meet these criteria," the report concludes.
"We see that this year 2000 problem probably will be the death knell for a lot of the homegrown systems," O'Boyle says.
The same fix-or-replace decision befalls customers of discontinued software lines. At University of Chicago Hospitals, for example, the governing board recently decided to replace a vintage patient accounting system that Unisys Corp. turned over to HBO & Co. in 1994. The system, called PRN 2000, is one of several older models for which HBO & Co. has decided not to invest additional support (See related story, p. 106).
Patricia Becker, CIO of the academic medical center, says the withdrawal of support launched discussion on whether the hospital was equipped with the personnel to assume the responsibility. The conclusion: "We probably could have supported it ourselves if it weren't for the year 2000 problem."
That wasn't the only problem, of course. "It's a 15-year-old system at this point, so the technology was pretty old to start with," Becker says. But a quick estimate set the year 2000 retooling expense at $1.5 million, she says.
Rather than throw that kind of money at an old system, the board chose to buy a new system. That might have happened anyway, but "this made us do it probably a year sooner than we would have," Becker says.
The decision reflects the sudden realization that delays in implementing a new system could threaten such basic operations as getting the bills out. "The lifeblood of your financial system is not something you want to fool around with," she says.
The hospital has made a preliminary decision to switch to a system developed by Seattle-based Phamis, but it must first go through certificate-of-need channels in Illinois.
Final purchase and service agreements are pending, but the total price for a Phamis system, new computer hardware and implementation support is a minimum of $3 million, says Charles Reiling, vice president of client services at Phamis.
The company's product, called LastWord, has additional levels of software encompassing clinical and administrative areas that can make the final bill top out at $7 million for the complete integrated lineup, Reiling says.
That's big money, but the financial pain of being forced to replace outdated systems isn't limited to the provider organizations making multimillion-dollar decisions, he adds. "It's no easier for a small institution to step up to a $250,000 decision than it is for a large institution to step up to a $5 million decision."
But deadlines are overshadowing finances as the prime consideration. "The time to identify work, get it done and get it tested is getting real short, even if you're willing to write the check," Reiling says.
Some providers inadvertently chucked their chance to kick the problem back to their vendor when they decided not to renew contracts for information systems support and updates, says Bob Relph, an executive director with Superior Consultant Co.
"There are places I know that got tired of working with their vendor and decided to do their own maintenance and froze their code three years ago," Relph says. "They don't have a chance."
The larger problem. Although replacement or revision of core information systems can become an expensive project, healthcare executives can't ignore the rest of the picture.
Even the biggest software system is just a section of an interconnected information apparatus in which many independent pieces must be brought together so everything works in unison, industry experts say.
IBM Corp., which is converting a dizzying array of its products for century-date readiness, emphasizes in a 200-page implementation guide that while the problem "is not a technically difficult problem to resolve . . . the degree of complexity is directly related to the inter-relationships between routines and programs and the data passed between them.
"This is not a trivial programming exercise," the guide concludes.
In addition to ensuring that faulty date codes are corrected within each program and computer device-either internally or through vendors-providers will have to make sure the data and instructions exchanged among them are coordinated.
For example, disparate collections of information systems are becoming the norm for diverse health networks, which makes them dependent on translation programs, called interfaces, to iron out the incompatibilities.
Those interfaces must be retooled to accurately reflect changes in the systems they connect, says SMS' Mars. Otherwise two perfectly converted systems may not be getting through to each other even though they see eye to eye on century-date issues.
At the extreme, a receiving system may reject a message or refuse to process an order from another system because it misinterprets the date information, says Superior's Relph.
The patient accounting system that controls date-related details of a patient's stay may be processing dates clearly, but a laboratory system that doesn't mesh with it can end up rejecting transactions it considers out of date or flawed in some other way.
"All of a sudden your lab systems aren't working," Relph says, and the glitch "can potentially bring down systems for a long period of time."
But the most cleanly coordinated internal repair job still may be exposed to problems depending on how dozens of other companies solve their problems-payers, suppliers, outside labs, decision-support vendors and any other third parties that send data.
"This outside data has great potential for introducing date errors into (an integrated delivery system's) information systems, corrupting databases and spreading rapidly like a computer virus," according to the Meta Group report.
Testing, and testing again. The potential to miss a flaw or create unintended consequences makes it essential to save enough time at the end to run everything at once and see how it works, says Meta Group's O'Boyle. And it won't be short or sweet.
"Testing is probably the most time-consuming and costly part of the process," O'Boyle says. In fact, Meta Group's research concludes that testing will constitute as much as 40% of the conversion effort and cost.
Initial tests will uncover problems that were missed and that will require retesting, O'Boyle says. But there's no alternative. "You miss just one and you could have a big problem," he says. "Getting that date wrong can start a cascading effect."
But in the meantime, the testing is being done on an active information system operation that still has to chug along unhindered.
From a personnel standpoint, that adds up to overtime and off-hours shifts, says Becker of University of Chicago Hospitals. She predicts her staff will have to change dates and see what happens to the information systems' performance-on evenings and weekends.
Moving computer clocks forward to simulate the year 2000 may not be as routine as it looks. If not done with a heaping helping of foresight, a test could do permanent damage to the data that a healthcare network needs today, says Ross Fidler, national practice leader of Superior's interdisciplinary practice.
Fidler says he learned that lesson the hard way when he moved the timing clock of his laptop computer to the edge of 1999 to see what would happen when it struck the new year.
The date was properly represented, but when he called up his messages under a Lotus Notes program, they were gone. That's when he remembered they were programmed to be deleted after 90 days.
Luckily there was a backup file, but computer programmers running a test of their handiwork on a crucial hospital database may not be so lucky, he warns.
Some computers may have a hard time recovering from a test for other reasons, says Superior's Relph. "Operating systems (for computers) are really not meant to be turned backward," he says.
In addition to the technical problems, healthcare organizations will have to rely on the promises and delivery dates of vendors before they can ever work up something to test.
Consultants and some vendors are urging providers to get formal letters out immediately to all companies that have a role in fixing any piece of the problem, asking when-or if-a conversion is scheduled. "If it's a nonresponse, assume it's a negative," says SMS' Ledbetter. "You better have an alternative in mind."
The coming crunch. Providers could be waiting in quite a line, both for new-product acquisition and technical assistance.
Vendors figure to have their hands full with support for their own customers, so be prepared to lose more precious time waiting for them to make room for new business, says Roger Allison, a healthcare consultant with Meta Group.
Ledbetter says SMS is mobilizing to handle the load but predicts vendors may not have time to get to all customers. "As more and more people delay taking action, there will be more of a crunch," he says. "It's going to be a very difficult time to get attention from a vendor outside their client base."
Century-date conversion tools and services will be offered by more than 100 firms, up from seven in mid-1994, and healthcare software vendors will move into the market by mid-1997 in partnership with some of these conversion vendors, according to Meta Group.
But the laws of supply and demand are expected to tax the timetables of vendors in this niche, Allison says. "The longer you wait, the more the price will go up," he says.