SPECIALTY CLINICAL INFORMATION SYSTEM IMPLEMENTATION:
A CASE STUDY IN TRANSPLANTATION

Christy Stepp
John S. McIlwain
Mukesh Dikshit

Overview
This case study is intended to provide an example of how to implement specialty clinical information systems. In this paper,we describe the major components of a transplantation specialty system project, in terms of project scope, system functions, major stages, timetable, personnel needs, vendor attributes and human resources. We then describe the major stages of an implementation project and the critical success factors for each stage. After reading this paper, the reader can expect to have a clear understanding of the general requirements to successfully implement a specialty clinical information system, a “feel” for what’s involved, and a road map for conducting one’s own specialty clinical system implementation project.

The Setting
The setting is the Jewish Hospital Transplant Center in Louisville, Kentucky (“the Center”). Jewish Hospital is the flagship of a regional network of more than 25 healthcare providers throughout Kentucky and Southern Indiana. The Jewish Hospital Transplant Center is an internationally renown, high-tech specialty center located in the heart of the Louisville Medical Center. The Jewish Hospital Transplant Center has made news headlines for many years as a medical pioneer including:

• World’s first totally implantable artificial replacement heart
• Nation’s first hand transplant
• Nation’s first heart transplant following use of a ventricular assist device.

Since inception, Jewish Hospital has performed almost 3,000 organ transplantations. This case study explores the implementation of the Velos Transplant product line for the Heart and Lung program at the Jewish Hospital Transplant Center.

Project Scope
The project scope entailed:

• Review and improve automation and workflow in the current Heart and Lung Transplant Program
• Simplify clinical information capture for these two organs
• Ease accessibility of information for the transplant coordinators
• Develop reporting capabilities specific to the needs of the Heart and Lung Program
• Migrate existing data to the new system platform
• Implement the system, train users, and hand-off the system for ongoing internal management and use.

The major system functional needs were similar to those of other transplant programs at Jewish Hospital, where Velos had been implemented for the kidney, liver, and pancreas programs. An additional project goal was to consolidate the Heart and Lung program onto the same Velos platform used by the other transplant programs. This meant ensuring that all the new Velos systems and reporting functionality were compatible with the existing functionality. Also, by moving to Velos, the Heart and Lung program would be able to take advantage of the real-time lab interface already in production in the other programs and the extensive reporting, communications, and other subsystems already available within Velos Transplant.

The major Heart and Lung functional needs included:

Patient Registration

• Entry of New Patient’s Demographic details
• Insurance Information
• Diagnosis Information
• Patient Lab Transaction Indicator (for automatic downloads)
• Patient History
• Organ names and Attributes
• Reason for transplant
• Previous surgery history (if any)
• Insurance authorization details

Pre-Transplant

• Clinic Visit
• Patient call details (notes)
• Clinic Visit Details
• Clinical Evaluation
• Clinical Evaluation Data Entry
• Changes to Insurance Information
• Selection Committee
• Patient approved/disapproved for transplant detail

Peri-Transplant

• Patient-Donor Match
• Surgery details
• Flowsheet

Post Transplant

• Admission/Discharge details
• Patient Status Update
• Death Information
• Clinic Visit Details
• Schedule biopsies, heart caths, clinics
• Biopsy or Clinic Visit Schedule
• Donor information

A number of additional reports were developed or adapted from Velos’ core reporting capabilities, including:

• Monthly Heart Cath Lab Schedule
• Transplant Recipient Evaluation Report
• VAD Report
• CATH Schedule
• Biopsy Schedule
• Prednisone Dose
• Heart Status List (Heart Call Book)
• Lung Status List (Lung Call Book)
• Clinic Summary – Vital Meds and Notes
• Heart Evaluation Meeting Report

In addition to system installation, the project required migration of all existing, related, electronically available data to the new system prior to installation and go-live. This included over 40 separate source data files, and many thousands of data records--- in all about 7,700 kilobytes of data.

The system platform is Microsoft Windows/NT-based running on a Sybase database with an integrated Crystal Reports reporting engine. The Heart and Lung module was implemented within Velos’ core modules which include a built-in application and form generator; subsystems for labs, medications, patient registration, and database querying and reporting; Velos’ existing transplant-specific applications, or application templates, for care processes such as pre-, peri-, and post-transplantation; Velos’ built-in rules, communications and messaging subsystem; Velos’ built-in security and audit trail subsystem; and Velos’ Interface Engine to support data migration and interfaces to third party systems, such as Jewish Hospital’s Clover Leaf-based system integration platform.

The project was executed over a 14-month period that began in January 2002 and went live in March 2003. The project involved the following stages:

• Design, adaptation, and development of Velos core technology for the Heart/Lung subsystem and related reports (approximately six months elapsed time)
• Consolidation, cleansing and mapping of source files for data migration (approximately seven months elapsed time)
• Upgrade hardware and servers
• System installation and migration of source data to Velos Transplant database (two days)
• End-user training and go-live (two days)

It is noteworthy that this project entailed the design and development of the Heart and Lung subsystem as well as data migration and implementation. When module design and development is not required, but a relatively complex data migration is, a reasonable project timeframe is nine to twelve months. In cases where custom data migration is not required, e.g. where the only electronically-loaded source data might be from an existing lab system and perhaps a hospital Admission, Discharge and Transfer (ADT) system, a reasonable timeframe estimate for a well executed project is three to six months.

System design and development

The design and development stage involved the following general steps:

• Define Project Scope vEstimate Budget and Center Approval
• Conduct Requirements Analysis
• Write High-Level Requirement Specification and Center Approval
• Iterative Prototyping, Design and Development with regular Center Feedback
• Fine Tuning and Full Cycle Testing
• Upgrade Version Release

The development process began with identification of needs for the Center’s Heart and Lung coordinators. Velos sent staff onsite to observe the coordinators at work, ask questions, and analyze the workflow. Reports, screens, and data fields were identified and discussed. All coordinators were involved in the process.

Next, Velos designed and developed fields and screens using an iterative process where the Center’s coordinators were given opportunities to observe new screens as they were developed. Many changes were made to accommodate input from coordinators. This work was done over the Internet and through numerous conference calls. Following these extensive communications, Velos presented the working prototype to the Center’s users. Because of the extensive communication and interaction that preceded this presentation, the full product was accepted with great enthusiasm among the users on the first full review cycle. Input from the transplant center staff was the key to successful design.

The reports were conceived and designed concurrently as the Center and Velos finalized the data fields, workflow, and graphical user interface and related screens. The Center’s system administrator designed and implemented some reports and Velos wrote others. Regular communications between the Center and Velos kept work from being duplicated.

As design and development reached late stages, with the data elements relatively finalized and their placement within the Velos database determined, the task of preparing existing data for migration to the new database began. This process involved extracting data from the old system for electronic input into Velos. The task required intimate knowledge of fields from both the old and new systems. Direct mapping of the data files was performed by the Center’s system administrator with much consultation from Velos. As the files were extracted from the source system, Velos staff imported them into the Velos Transplant database. The Center staff then observed the data in Velos and confirmed that the data was migrated correctly. All this work was done using data migration tools already available within Velos, which kept programming and project costs to a minimum and greatly facilitated mapping, migration and testing activities.

A data migration such as the one performed here involves a certain degree of trial and error for both parties. Numerous challenges were encountered such as changing maintenance fields to include HL possible values prior to migration; keeping separate KLP data that had already been migrated; inserting required data into Velos which was not available in the prior system, and reconfiguring certain source data, such as free text fields, to benefit from the search and sort capabilities available in Velos. Close cooperation kept the project on track. Also, keeping the extracted data format relatively similar to the existing table made data verification easier. The data verification was done at several levels --- at the text file level before import; at the database level after import; on the application screens; and finally on searches and reports.

The Center had anticipated that it would upgrade its computers and servers to support the new system. To this end, the hospital’s Information Management Department was consulted regarding upgrading workstations and servers to accommodate the additional data and workload. A plan was developed and money budgeted for new computers and an upgraded server. This upgraded system infrastructure was installed and tested prior to installation of the Heart and Lung module.

The hard work in the data migration is in the preparation of the data prior to go-live. However, what’s also very helpful is to have the tools in place such that when the migration occurs, the Center can begin with data that is current. To do so, Velos conducted a complete, data-loaded system test on the staging database at the Center prior to migrating the data to the production system. (Note: A staging database is a separate test environment where new or upgraded systems are placed for testing prior to being put into production). Velos came in over a long weekend and effected the full data migration including extraction of data that had been processed as of the close of work on Friday. The users stopped entering data into the prior system on Friday and kept track of manually entered data on paper. On Monday, the Center began end-user training and on Tuesday went into full production on the new system. This smooth transition required the extraction of data be largely complete prior to the weekend data migration. It also involved a burst of long workdays on the part of both the customer system administrator and two vendor staff during this four-day period.

The training and go-live process were relatively easy. Because the coordinators and other Center staff were involved throughout the project, they were already well informed about what to expect when it came time for training. Also, less training was required at other Velos modules were already in production outside the Heart and Lung program.

The bulk of the end-user training was conducted on the first day, the Monday following the weekend data migration, and by Tuesday, the users had stopped entering data in the old system and had transitioned to the new system. Velos staff stayed onsite for another day in the event that any questions arose. That time was primarily used to provide additional expert training for the system administrator and to discuss additional reports desires and other future plans and initiatives.

A variety of Center staff was required to accomplish the project objectives. With the exception of the Center system administrator/system analyst, which is a full-time job, all such staff requirements are part-time and secondary, or in addition to, such staff’s full-time responsibilities. On this project, the Center’s five coordinators and two clerical staff were involved during different parts of the design and development phase. The coordinators role was to provide input on requirements, evaluate the system prototype, participate in the training, and then use the system when it went into production. The Center also employed two administrative staff to assist in data entry at certain stages and who perform ongoing, system administrative roles in addition to their other responsibilities.

A liberal amount of time was spent with the Velos staff discussing and reviewing current processes. In addition, one system analyst was required by the Center for migration and report writing, which took approximately two months of dedicated time over an elapsed period of nine months while also performing her usual duties. Two interface analysts and one lab technician were involved for a few days, updating the existing interface to include additional lab tests specific to the heart and lung population. Three Information Management Specialists spent several days planning and installing new computers and upgrading the server.

During the entire project process the Center Director was involved in meetings and discussions. She reviewed all work requirements, drove the budget process, and liaised with Velos management on budget, schedule and other management considerations. The Vice Presidents of the Center and the Information Management Department were involved in some meetings and discussions regarding the project. The leadership and championship of each such senior manager, particularly the Center Director, was essential.

Operationally, in this case, the key person that drove the success of the project was the Center System Administrator or System Analyst. This person had responsibility for all aspects of the project and working with both the Center clinical and administrative personnel and with Velos to achieve project success. Her responsibilities and skills included: working with the vendor and Center staff on the timing for all project phases; understanding the end-user requirements; having a basic understanding of software programming; being very comfortable using information systems and standard tools such as Excel and report writers; knowing when to be firm and when to be more flexible with both Center staff and vendors; and establishing trust among the various constituencies.

Many customer managers and users of information systems have an understandable misconception that the vendor is the key element of a successful project. The vendor is absolutely one key element. However, as the above case study hopefully demonstrates, a vendor is incapable of fulfilling a system project of this kind without extensive customer involvement and leadership. That said, there are significant differences in vendor competencies and some key attributes to look for.

Foremost is the system’s core technology, or the sheer “fire power”, of the product. It would take an entire course in computer programming for the reader to fully understand differences in how various software products are designed. Indeed, many a software vendor, laden as software vendors can be with technical-heavy personnel, has a hard time conveying these differences. This project, however, provides tangible examples of a number of otherwise hard-to-discern product attributes.

For the most part, a specialty clinical information system needs to have the same kinds of core components as large-scale enterprise clinical systems have. Subsystems for labs, orders, medications, patient charts, audit trails, interfaces, communications (alerts, reminders, and messaging), ad hoc reporting, and security features are all necessary for a fully functional specialty clinical information system --- just as they are at the hospital enterprise level. This requires a significant upfront technology investment that most enterprise software vendors make but few specialty clinical system vendors can afford. This is a matter of circumstance and economics. Most specialty systems evolved from departmental initiatives, driven, for example, by a physician disenchanted with the information services otherwise available. This, together with the relatively lower software license prices required to effectively compete in specialties, results in some systems being far less robust than necessary.

In this case study, the vendor happened to have designed its products to support many specialties and even enterprise hospital needs. Its founders had also already developed dozens of commercially marketed, next generation healthcare software products for the very vendors selling products at the enterprise hospital level. This experience and knowledge, together with and an extensive upfront capital investment, enabled the vendor to invest upfront in developing the core technology required to the Center’s needs long before the project began.

In this case study, the actual programming time was relatively limited. The Velos core technology was leveraged for the Heart and Lung program, just as it had been for the other organ programs. All the Center’s transplant programs are supported through one database and one user interface scheme, which makes product use, reporting, and product maintenance much easier. Marrying such core technology with a workflow-style user interface is a challenging system design proposition. All the subsystems---labs, medications, charting, interface engine, security, reporting, etc.--- and the database design and screen designer/application generator that can bring these components together, have to be able to work in concert. Velos calls this “configurability”. The lack of such robust configurability is the major reason why so many specialty system purchasers, at first enamored with the look and feel of a product, or the idea of developing one’s own product, so often discover, many years and many dollars down the line, that entire initiatives have to be discarded or “lived with.”

There is yet another simple way to understand this challenge that this case study illustrates. Within the Center, there were multiple user perspectives and roles to support---the nurse, the coordinator, the support staff, the administrative manager, and the physician. Within each role, there are individual variances in work style. Good software managers, while mindful of professional standards and procedural consistency, seek to provide individual staff with an environment that enables them to strive in the context of their individual work styles. This entire project was simply another set user perspectives: that of the entire heart and lung program. From a product design perspective, the key to systems success in such multi-perspective settings is for the product to adapt to the needs of each such perspective, in nearly limitless ways, with limited or no programmer intervention. This required a well thought out, comprehensive, and fully engineered system foundation.

A good, well thought out, easy to use product goes a long way towards alleviating service needs. This said, above all else, this case study certainly illustrates that a good product alone is entirely insufficient. Success on this project required the vendor to understand customer needs and configure the product to those needs and show Center how they can do so without vendor intervention. The project also entailed a complex data migration and benefited from the tools, clinical knowledge, planning, system preparation, and close communication that preceded the successful ‘go-live’ event.

Obtaining accurate budget information, and setting appropriate budget expectations is very important to provide success. Persuading staff to change behavior, especially coordinators and other staff with extensive patient interaction, is hard enough. While the Center and Vendor are not publishing specific budget figures for this case study, the authors have conveyed some the manpower and timeframe considerations that went into this project, which will hopefully be of use to reader planning specialty clinical system projects. The authors will note that the vendor portion of the total investment, measured in both dollars and time investment, was far lower than one might imagine.

Velos is a leading designer and developer of next-generation healthcare information systems. Velos develops, markets, and supports an integrated suite of clinical, administrative, and financial products. Velos’ Internet services and turnkey solutions address the information needs of healthcare providers and investigators in clinical research and medical specialties. Velos is privately held with headquarters in Silicon Valley.

Christy Stepp is the System Administrator for the Jewish Hospital Transplant Center in Louisville Kentucky. The Jewish Hospital Transplant Center has conducted almost 3,000 organ transplantations in kidney, liver, pancreas, heart and lung. Ms. Stepp has been with Jewish Hospital for 18 years, the last 8 of which have been in the Transplant Center, where she has supervised the information systems functions. In the prior 10 years, Ms. Stepp held various supervisory, analysis, and administrative positions at Jewish Hospital.

John S. McIlwain is co-founder, President and CEO of Velos. Prior to Velos, Mr. McIlwain served as President and Chief Executive Officer of Aithent, a software development services company focused in part on healthcare, where he led the company through successive years of INC 500 growth rates. Aithent currently employs 250 professionals. Prior to Aithent, Mr. McIlwain held sales, consulting, and software design positions at Sun Microsystems and Price Waterhouse. Mr. McIlwain has also served as Adjunct Professor of Management and Operations Science at Columbia University Graduate School of Business and currently serves on management boards for a number of early stage software and healthcare-related companies. Mr. McIlwain holds an MBA from the Columbia Graduate School of Business, and a BA in English and Economics from Middlebury College.

Mukesh Dikshit is the Director of Renal and Transplant Operations at Velos. Mr. Dikshit has over 15 years experience in managing computer projects and analysis, design and development of computer applications. Prior to Velos he served in Account Manager, Project Manager and Team Leader positions and managed large software projects for Aithent, a software development services company. Mr. Dikshit has a Masters in Computer Applications with honors from Harcourt Butler Technological Institute, Kanpur, India, and a BS degree in Physics, Chemistry and Mathematics.