Feature Story

Seeing the light on LIS data conversion

One alternative strategy: cold or hot?

January 2002
Eric Skjei

The once-complex process of converting data is yielding slowly to expertise and experience.

As labs move from one vendor’s system to another’s, upgrade their LISs, and interface with other systems within their organizations, they need to make the data in those systems usable across widely varying database structures and formats. New tools help, but data conversion still demands time, attention, and expertise. And the demand for conversion is growing.

"It’s almost a quarterly need for us," says Michael Becich, MD, PhD, chairman of pathology at the University of Pittsburgh Medical Center Shadyside Hospital. Over the last five years, Dr. Becich has led a process in which 18 hospitals in the medical center system work to merge their anatomic and clinical pathology systems into a common platform. "Every time we retire an old LIS," he says, "we aggressively look at the value of old data and convert anywhere from five to 15 years of that data into the new system."

The need for data-conversion services, some vendors say, has become so commonplace that it has in effect become a basic business service. "At this point, almost every sale we do is a replacement," says Steve Tablak, CEO of Tamtron Corp. "We find that almost every contract we sign now includes a data-conversion service."

Widespread as the need for data conversion has become, there is general agreement that the need is stronger in some areas of the lab—namely anatomic pathology and blood bank services—than others. "There is the expectation in anatomic pathology that clinicians will have the history of AP results indefinitely," says Dov Kaufman, manager of engineering services for Sunquest Information Systems. "If a patient had cancer five years ago, the treatment may be different than if she or he did not, and that’s one reason why physicians want to see all of the data."

Having as much historical data available as possible, says Dr. Becich, means that a physician can factor in information obtained from previous specimens when new tests are ordered. "When a patient comes in with a breast cancer, or we do a repeat biopsy on a breast or a lump on the skin, knowing that 10 years ago this same patient had a breast cancer removed at hospital A means that even if she or he is now at hospital B, we can still quickly and efficiently work our way through the process of deciding what we need to do with that current sample to give the patient and the physician what they need," he says.

While it is generally true that anatomic pathology and blood bank systems evince the clearest need for access to legacy or historical data, and thus require a high level of data conversion as systems are integrated, upgraded, or replaced, some areas of clinical pathology also require this intensive level of data conversion. "In general, clinical pathology testing tends to be oriented toward obtaining a snapshot of where you are today," Dr. Becich says, "and it’s probably not as useful in most respects to have such extensive, immediate access to years and years of past data."

There are, however, exceptions. "In some areas—for example, microbiology, virology, hematology smear interpretations, serial results on liver function tests, some endocrine tests—there is an equally high value in having that depth of data quickly available," Dr. Becich says.

Heterogeneous conversions

Data conversions between different vendors traditionally have been the most challenging. "Understanding the way the fields are defined, at what level they are defined—all that is a very definite challenge," says Sunquest’s Kaufman. "When clients go from our system to another vendor’s, we typically spend many, many hours on the phone with those other vendors trying to map our fields to theirs and vice versa." These types of conversions are time-consuming and people-intensive, likened by some to building interfaces between heterogeneous systems in their degree of complexity.

The reasons such interfaces stir fear in the hearts of even the most seasoned IT pros range from small to large. A relatively minor example: Older LIS databases often stored data in a coded format. "Instead of saying ’This was called to the doctor,’ the field may just have a code in it, like ’12QR47,’" says Hal Weiner, president of Weiner Consulting, Eugene, Ore. Granted, there are almost always ways to decipher these codes and to automate the decoding process in the new system, but doing so represents a speed bump in the conversion.

Another relatively minor example, this one from Gregory Francis, president of the information technology consulting firm Korchek Technologies, about a conversion his firm recently undertook: "The old database had a comment field in which users had been allowed to become very verbose, but the new system had space in its comments field for only 60 bytes of comment." Francis adopted this solution: He analyzed the data being imported from the old system, and when the field contained more than 60 bytes of comment, he included a simple notice that the user should check the old system—still kept online for just this type of need—for the additional content.

Other complications run deeper, pose more of a challenge to the data-conversion process, and pertain to inevitable differences in how LIS vendors organize their data. One example, Weiner says, arises in conversions from databases that are test-oriented to those that are results-oriented.

Say, for example, a laboratory needs to convert data from a test-oriented system that stores sodium results only or primarily as part of a chemistry profile to a foreign database that, being results-oriented, creates the same profile by assembling individual results—including sodium—as needed. Mapping the sodium result data from one to the other, in this case, could be unusually tricky.

In-house conversions

Data conversions sometimes occur within a vendor’s own user community. A client may want to reorganize its data; may have changed hospital information systems and may, therefore, need to change the format of, for example, the patient ID number; or may simply be upgrading to a newer system from the same vendor.

In some respects, says Kaufman, in-house or internal conversions are easier, as one might expect. "In general the database structures will be quite similar," he says. Not exactly the same—some conversion inevitably is required—but close enough to make the conversion more straightforward. Information stored in the old system at the patient level will, in all likelihood, still be stored at the patient level, rather than, say, at the encounter level. But the process still takes time and attention. "For example, we still need to validate the data as if it were coming from a foreign system," Kaufman says.

Even an otherwise routine installation of a new LIS is increasingly likely to require data-conversion services. "Rather than having to manually enter the names of all your physicians, nursing units, and so on, it can be very beneficial to be able to import that data from an existing system that’s already online," Weiner says. And that process will more likely than not require some level of data conversion.

Effective and affordable new tools are now available to simplify the process. "These new tools basically allow you to define a database schema for just about any kind of file structure out there and then say, ’I want you to convert it from this method to that method,’" Weiner says. "Once you have it all mapped out, the tool does much of the work for you."

Much but not all. Helpful as they are, these tools don’t fully automate the process and probably never will. "I’m running most of those same tools," says Korchek’s Francis, "and the process is still a headache." Tools alone won’t confirm, for example, that the John Smith born in 1932 and seen as an outpatient with no medical record number is the same John Smith born on the same date in 1932 but seen as an inpatient and assigned a medical record number.

Making sure it’s right

Even when the conversion is over, it’s not over. Any translation of clinical data requires intensive error-checking. "Data integrity is more than 50 percent of all the work involved in a conversion," Dr. Becich says. "There will be errors, and that fact alone means that there will also be a need for hours and hours of time spent going over the data to make sure those errors are found and fixed."

Asks Francis, "What happens if you’re off by one byte in a glucose result that was 67 but is now appearing in the chloride field in the new system?" What if that small dislocation means that now your chloride is 67 and your glucose is, say, 6? "That’s one big reason why the data-conversion process is definitely not plug-and-play," he adds.

It is in the related area of what he calls "patient mapping" that Tamtron’s Tablak sees the real challenge of converting data. "Most modern systems have a method to decide if two patients are the same patient and, therefore, if all of their historical records are the same," he says. "But a lot of the older systems didn’t necessarily have a sophisticated means of doing that."

So in the conversion from a less sophisticated to a more sophisticated system, Tablak continues, much time must be spent with the customer to determine the best way to map patient cases reliably and accurately. "Sometimes you have records for a John Smith in which a Social Security number is present in one case but isn’t in another, or a John Smith who was an inpatient in one case and an outpatient in another," he says. "How do you decide when these John Smiths are one and the same?" This requires sitting down with the customer and deciding on a policy for resolving these ambiguous and inexact matches. It may even require manual inspection—no small task when the volume of cases needing to be imported is large and stretches back for years.

Lessons learned

How can laboratories minimize the stress of the data-conversion process? "Right up front, right in the beginning, identify the data elements that you want to get," Francis says. "Base this decision more on what the new system can accept as opposed to what’s in the existing system." Francis recently worked on a conversion in which the importing system was able to import data on the patient reaction—that is, positive or negative—to antigen typing. Although the data existed in the old system, they were extremely difficult to access. In such a case, he says, the key question then becomes, How valuable are these data? Are the data clinically significant? How often does the lab need to access the data? Does the lab need historical data on this topic, or will current results serve its purpose just as well?

Second, labs should always consider the possibility that they may be able to store some data offline, in a form that is not live, not tightly integrated with the current database, in what is sometimes referred to as a "cold" solution. Says Weiner, "A cold solution typically archives data on a medium like laser disk or CD and indexes it so the client can quickly find it, view it, and print it in a report format if needed." This solution is good for data that do not need to be available on demand in the lab’s main database. "By contrast," Weiner explains, "hot solutions convert the data so it is directly and immediately usable from within the new LIS, so that, for example, prior results appear on the cumulative report with the current results or so that older data can be used for performing a delta check." (See "One alternative strategy: cold or hot,".)

In either case, cold or hot, storage is rapidly disappearing as a consideration in the process. Says UPMC’s Dr. Becich: "There still exists a perspective that argues that there is so much data generated by clinical pathology systems that it’s impossible to keep it all online for 20 years. That’s hogwash today, with the dropping cost of storage, and, quite frankly, I think we’re losing some very valuable opportunities because of it."

Finally, say many data-conversion specialists, while data conversion can be time-consuming and rigorous, it is still just a process, one like many other IT endeavors, not a mystery or an arcane bit of witchcraft. "You can’t just hook one machine up to another, press a button, and watch the data flow magically from one system to the other," Dr. Becich says. "The data-conversion process is still 90 percent personnel power and only 10 percent computer power." Adds Tamtron’s Tablak, "There are enough of us now in the LIS industry who have spent enough time doing this kind of work that we understand the other vendors’ database structures very well, and that means that the process is not only significantly easier than it was five or 10 years ago but even somewhat routine."

Changing the rules of engagement

What isn’t routine yet is vendors who collaborate.

"We’ve actually been trying to help clients who are leaving Sunquest," says Ken Kark, Sunquest’s director of marketing communications. It’s the professional thing to do, he notes, and it’s also good business. Sunquest has had sufficient experience with clients who move to another vendor’s system, stay with it for a year or two, then decide to return to Sunquest, to see the long-term potential of being helpful when customers want to leave. "We do it because we want to maintain our reputation for excellent customer service and satisfaction," Kark says, "and because we think they’re going to come back."

Tablak takes a similar position. "You want to treat a customer who is leaving as well as possible because you hope they’re going to come back," he says. "We have the attitude that if they’re not choosing us, they may not have fully considered their decision, and that in a few years they may be back."

Enlightened as it is, this practice seems still to be the exception rather than the rule. "The [outgoing] vendor rarely cooperates," reports Korchek’s Francis. "And if they do, they typically want to charge an arm and a leg to do so."

"Vendors still do not want to work with other vendors," concurs Tom Manning, vice president of sales and marketing for Mesa Corp., which specializes in archiving, imaging, and workflow management systems. "That was true 20 years ago and it’s true today," he says. "Vendor A is losing the business, vendor B wants the information that is on vendor A’s system, and vendor A’s attitude is, ’OK, see if you can get it, and don’t call me.’"

Even when the outgoing vendor does cooperate, the value of the help may be minimal. "On one of our recent conversions," recalls Francis, "the date of birth was stored in, packed way in the legacy system, and we had to unpack it." Although the vendor being replaced did supply an algorithm for accomplishing this, Francis quickly discovered its limitations. "It didn’t account for leap years before 1900, which caused a problem that we didn’t notice until we started examining the data and found that some older birth dates weren’t matching up."

Ultimately, the incentive that overrides these differences and drives cooperation is that everyone involved in the process has a fundamental obligation to patient care. "Physicians and patients depend on this data," Dr. Becich says. Agrees Tablak, "We’re in this business because it’s a patient care business, and we certainly don’t want to interfere with the patient care process."

Eric Skjei is a writer in Stinson Beach, Calif.