Baseline Magazine - February 2008

delays in care.” Kaiser lost track of patients’ paper records, patients’ complaints and the time they spent on UNOS’ waiting list. California fined

Kaiser Permanente $6 million.

Two years ago, Johns Hopkins replaced the transplant database it had been using, which it declines to name, with a more modern one from TeleResults, a database vendor based in San Francisco. Barshick has supervised the data cleansing—removing mistakes that had crept into the data over the years—and the redesign of clinical processes and retraining of staff. Some 175 members of the abdominal transplant team moved to the new software in June 2006. Other teams--thoracics, for instance—are using the new system, but not fully. “They were focused on paper-based tools,” Barshick says.

The hospital is building interfaces between the database and various in-house and third-party laboratories. Radiology will soon get an interface, and Barshick also will try exporting data electronically from TeleResults to UNOS.

In the mid 1990s, when Barshick joined Johns Hopkins as a clinical nurse on the abdominal transplant floor, the options for transplant-spe-cific IT systems were “pretty sparse,” he says. He thought Johns Hopkins’ system did a good job warehousing data and was useful for hospital administrators, but clinical information was still siloed among the various transplant teams. The thoracic team, for example, used a different tool altogether—Microsoft Access.

In 2000, Barshick went back to school and got a master’s degree in nursing informatics. He’d been working with liver donors and saw how information systems could improve the transplant process. Meanwhile, Ghassan Khabbaz, founder and president of TeleResults, was developing the transplant database, a project that took more than eight years.

Khabbaz, an engineer, got the idea for TeleResults from a conversation he had with a doctor while he was working on an unrelated hospital security project. The doctor was searching desperately for a system to keep track of a transplant patient, he says. But Khabbaz’s first effort to create a database failed because, he says, he was overly focused on the doctor’s way of doing things. The challenge, he discovered, was designing a database to serve data to all the different groups working with transplant patients—doctors, nurses, social workers, clinicians, nutritionists and administrators. Johns Hopkins has a dozen such groups.

When Barshick returned to Johns Hopkins in 2002, the hospital created his current position, which includes determining how the transplant center can best use IT systems. That same year the hospital researched TeleResults and other undisclosed IT systems. It committed to TeleResults in 2005.

Barshick’s first challenge was to get data mapped and cleaned. The hospital’s abdominal database had approximately 4,000 data fields, he says, and some of it was dirty— text had slipped into a date field, or a typo had changed a medical record number. After months of work, Barshick’s

THE CHALLENGE
WAS DESIGNING
A DATABASE
TO SERVE DATA
TO ALL THE
DIFFERENT
GROUPS
WORKING WITH
TRANSPLANT
PATIENTS—
DOCTORS,
NURSES, SOCIAL
WORKERS,
CLINICIANS,
NUTRITIONISTS,
ADMINISTRATORS
AND OTHERS.
JOHNS HOPKINS
HAS A DOZEN
SUCH GROUPS.

team and TeleResults preserved 95 percent of the hospital’s data.

Training staff to use TeleResults took about a year, Barshick says. During 2005, he spent entire days in his office with the door closed, flipping through screens of information to understand how TeleResults stored data and where it was stored, so processes could be developed for everyone who needed to work with the database. He met individually with members of each hospital team— social workers, pharmacists, lab technicians—to ask them what they needed from TeleResults to get their jobs done.

“We had to change the way we talked,” he says, because the terminology TeleResults used differed from the hospital’s system. “Active,” for example, meant the patient was alive and being cared for; “active” on the UNOS waiting list meant the patient was still seeking a transplant candidate.

Getting TeleResults to fill out forms was also an issue. One of the most important forms for transplant teams is a flow sheet, a step-by-step description of the treatment plan for each patient. Until the conversion, all the transplant teams used handwritten forms to map and communicate the care plan. TeleResults worked with the hospital to link memos and other unstructured data to electronic flow sheets, so the information is available with the click of a mouse.

CHANGE: A TOUGH SELL

It’s not easy to sell TeleResults to IT departments, Barshick and Khabbaz say. The hospital has more data on patients now than it ever had, and IT folks tend to see the database as “one more system to maintain.” But they also say TeleResults is better than generic health care IT systems at tracking transplant patients.

Khabbaz sees a bright future for the database at Johns Hopkins. When kidneys become available, qualified patients must be located and notified immediately: Transplants at Johns Hopkins are becoming increasingly elaborate, and hospital mathematicians have developed algorithms to sort and match patients to organs very quickly. In 2003, the hospital performed a three-way transplant, where three patients swapped donors so they could each get a kidney compatible with their blood or tissue type. In 2005, there was a five-way transplant spread across six operating rooms that lasted 10 hours. Four patients traded donors and the fifth got a kidney from an altruistic donor.

When it comes to medical care, transplants are often just the beginning. Transplants are a continuous process of managing disease, Khabbaz says, so he will design TeleResults to enable his customers—which include 20 large hospitals—to keep adding data to the database. Johns Hopkins will eventually use TeleResults to track all its patients who have undergone transplants. 3