Methodist Hospital of Indiana (Part 1)

Artikel ini akan membahas kembali mengenai integrasi teknologi informasi ke dalam bisnis pada suatu rumah sakit. Silakan disimak studi kasus berikut ini :

Before Clarian Health was formed in January 1997 through the merger of Methodist Hospital of Indiana with Indiana University Hospitals, Methodist Hospital was a stand-alone 1,200-bed tertiary care teaching hospital that was nationally known for its organ transplant program and its Emergency Medicine and Trauma Center. The main hospital complex was located just northwest of downtown Indianapolis, and the hospital had established outpatient clinics throughout central Indiana. In 1990 when the events described below began, Methodist Hospital had about 43,000 patient admissions, served 250,000 outpatients, and received about 80,000 visits to its
emergency room. In the year ending February 28, 1991, Methodist Hospital had a net income of over $23 million on total operating revenue of over $416 million.



In 1988 the longtime head of Methodist Hospital retired, and William J. Loveday was hired away from Long Beach California Memorial Hospital to become the new CEO. Loveday quickly brought in a new management team, including John Fox as chief financial officer. The Information Services (IS) department reported to Fox, and it did not take Fox long to discover that Methodist Hospital had a stagnant IS department. To revitalize IS, Fox brought in Walter C. Zerrenner with the title of
chief information officer (CIO). Prior to joining Methodist Hospital, Zerrenner was vice president of information systems for Evangelical Health Systems of Oak Brook, Illinois, a regional health care system managing five hospitals and an extensive
managed care network in the Chicago area.

Information Systems at Methodist Hospital
Zerrenner found that the IS department was living in the past. In the mid-1970s Methodist Hospital had spent about $20 million to install a then state-of-the-art proprietary patient management system called TDS that maintained the medical records
of admitted hospital patients. TDS allowed the physician to order laboratory tests, X-rays, and other procedures through TDS terminals and to have the results reported through these terminals. This mainframe system also captured admitting information and produced billing information upon discharge of patients from the hospital. Over 500 dumb terminals located throughout the hospital were attached to the TDS system. After that big investment in the mid-1970s, however, the hospital had made only very minimal capital expenditures within the IS department, whose efforts had been primarily devoted to keeping the TDS system working and maintaining other mainframe
administrative systems.



When Zerrenner talked to doctors, nurses, and administrators throughout the hospital, he found that almost everyone was dissatisfied with the services provided by the IS department. As a consequence of this poor reputation, the departments and laboratories of the hospital had been acquiring their own systems, and 40 percent of Methodist Hospital’s information technology expenditures were outside the IS department.

Thus, in addition to a large IBM mainframe, Methodist Hospital had some 700 PCs, about a dozen local area networks, and 13 minicomputers scattered throughout the institution. These departmental minicomputer systems were the best systems available when they were purchased, and they served the departmental needs very well, but, with a few exceptions, none of these systems was capable of communicating with any of the others. Methodist Hospital’s data on patients were trapped in these separate systems and could not be obtained by those who needed the data unless they had access to the
particular system where the needed data were stored. The one major exception to this inability to share data was the TDS patient care system, but this system had serious limitations.

First, it only maintained data on current admitted patients, so it could not be used for the growing long-term requirements of the hospital’s outpatients. Second, it did not connect to systems in nuclear medicine, respiratory therapy, sports medicine,
occupational health, medical research, marketing, and the operating room. Third, it could only be accessed from terminals located in the hospital, so doctors could not use it from the clinics or their offices. Finally, the patient’s record was no longer
available as soon as the patient was billed, so if a discharged patient had unforeseen complications, his hospital records were only available in the paper medical records files.

Zerrenner found that the users were unhappy with the isolated systems that made it impossible for doctors and nurses to obtain data on patients. Surgeons recounted frustrating incidents when patients were already on the operating table, but they
could not start the operation because they could not get lab results. Physicians in the clinics found it very difficult to obtain information on test results, diagnoses, or procedures performed in other clinics or the hospital. And nurses were concerned
because it was very difficult to care for the patients when they lacked information on certain procedures ordered by doctors. The various clinics and departments did not have a standard way to identify patients, which also caused problems. Some of their systems had seven-digit identifiers, some had eight digits, some had alphanumeric identifiers, and so on. In addition, the filing system in medical records did not use the patient numbering system from the registration process. Therefore, when
physicians needed information on a patient’s history, they could not get it from the various computers because the patient was identified differently in each of them.

This drove both doctors and patients crazy, because they sometimes had to repeat tests on a patient when they could not find the previous result. This was costly, wasteful, and sometimes painful, and it also delayed treatment. Patients also were inconvenienced by the lack of integration in the systems. Outpatients had to register at each clinic, and it was not uncommon for patients to have to answer the same
questions four or five times in a day as they visited different clinics and hospital departments. Moreover, patients were irritated because one clinic did not have access to medical records from other clinics or departments. “My son had a problem that was difficult to diagnose,” reported one mother, “and I spent several months going from one Methodist Hospital clinic to another. I soon discovered that they had no access to records, so I had to maintain his record myself. I carried a big folder with me, and made sure that I got copies of everything that was done at each visit and put them in the folder. Then I would give the folder to the next doctor that we visited. It was so frustrating—the only reason that I put up with Methodist Hospital was that they had the best doctors!”

Developing an IS Vision
When Zerrenner arrived at Methodist Hospital he found three IS strategic plans sitting on the shelf gathering dust. These plans had been developed, without user input, by his predecessors. “I do not intend to develop another massive document,”
Zerrenner told CEO Loveday. “Instead, we are going to develop a vision of where we need to go, and then we are going to follow that vision!” This IS vision was driven by the Methodist Hospital Strategic Vision depicted in Exhibit 1.
At Zerrenner’s suggestion, Loveday appointed a 25-member IS planning committee, a short-term task force that would be disbanded after developing an IS vision. This committee had at least one person from every care-giving department in the hospital,
with heavy representation from physicians and nurses and relatively few administrators. It met ten times in the summer and fall of 1990 to formulate its recommendations.

The planning committee recognized that each of the standalone departmental computer systems was outstanding in its field and that these systems contained a lot of useful information. The problem was that this information was not accessible for use where it was needed. The clinics and departments needed to integrate their existing systems so that everyone could share access to the information contained in each computer.
The planning committee also recognized that it was not enough to share this information within the confines of the hospital—they needed to provide access to these data from locations outside the hospital.

Dr. Douglas J. Moeller, an internal medicine specialist with the Aegis Medical Clinic, was an active member of the planning committee and the elected chairman of the 200-physician internal medicine section of the hospital staff. “Our vision,” Moeller reports, “is that our information system will contain complete medical record data for admitted patients, outpatients, and clinical patients. Furthermore, every Methodist Hospital staff physician can have a PC in his office, or even his home, that will provide user-friendly, convenient access to the medical records of
patients and allow the physician to enter orders for patient treatment through the system. We would also like to provide limited access to the system to physicians outside of our immediate medical staff, so that they can have access to data on patients they have referred to Methodist Hospital.”

Having determined the vision and set the direction for the future, the question of how to provide the desired integration and access became paramount. “What we proposed to do,” Zerrenner explains, “was to keep our present systems and technology and to integrate them by means of an intelligent network that will connect them with the various users and also do the translating necessary to allow them to communicate
with each other.” This architecture, which is depicted in Exhibit 2 (page 438), made sense to CEO Loveday, and the development of this Information Exchange Platform (IXP) was endorsed by the Methodist Hospital board and included in the Methodist Hospital foundation strategies, shown in Exhibit 3 (page 439). The IXP also supports the “enhance physician/hospital collaboration” foundation strategy. Having completed its mission, the planning committee was disbanded in the fall of 1990. It was replaced by a ten-person IS steering committee whose mission was to provide policy direction, approve the IS plan, allocate IS resources, and oversee the development of the IXP.

Because the medical staff had the most clout with hospital top management, Zerrenner
stacked the IS steering committee with physicians, including the president of the medical staff, the director of quality assurance, and Moeller as its chairman. Chief Financial Officer Fox and Zerrenner were also members of the steering committee.
This committee quickly exerted its influence on information technology spending throughout Methodist Hospital, and most systems purchased since then by the departments have been approved by the committee to make sure that they conform to
the IXP architecture.

The IXP Project
Zerrenner decided to use a four-stage approach to develop the IXP:
1. Define the basic objectives and scope of the system.
2. Build a prototype to prove the concept and get buy-in from the organization.
3. Build a pilot system and use it to demonstrate the feasibility of the concept.
4. Use the pilot to refine the system and upgrade it to full production status.
Zerrenner had been introduced to this approach by John Donovan of the Cambridge Technology Group and had used it with great success when he was at Evangelical Health Systems. and from remote locations. They planned to enhance this system
incrementally, with each enhancement going through the definition, prototyping, piloting, and rollout process.

Development of the Prototype
Because support from the medical staff was crucial to the success of the IXP project, the team decided to demonstrate what could be offered through a physician’s PC workstation. Because he was actively involved and a willing participant, Dr. Moeller
played the user role in the prototyping process. The team that developed the prototype included four persons from IBM and several people from the Methodist Hospital IS department. Computer specialists from the laboratory and radiology departments also helped out. Starting in May 1991, prototype development was scheduled to be completed in four weeks, but it ended up taking five. The prototype cost about $170,000, evenly split between hardware and consulting services.

Although it would not be suitable for the production system, for rapid screen development they used Easel, a screen painting tool that the IBM people had used before. They used a PS/2 with the OS/2 operating system as the server on a small
token ring network.
Moeller reported:
We had to consider issues related to networking, the database, and the physicians’ workstation. We did not attempt to create a production network, but only tried to explore some of the issues we would encounter. Most of our technical problems
were in the communications area. Before we were done we had six different architectural layouts of how we would do the communications. Although our networking was fairly primitive, we did demonstrate the ability to acess all of the systerms and
to be interactive with a couple of them. We agreed to use a graphical user interface and to use a client/server architecture, locating as much of the functionality
as possible in the workstation, with a network database server providing data. This allows us to customize the application for different users.

Moeller demonstrated the completed prototype to more than 150 people, including top hospital management, top physician leadership, and people from the various service areas. “We had overwhelming acceptance of the capabilities of the prototype,” Moeller reports. “Some people were absolutely flabbergasted at what we had been able to do.” With this positive response from the hospital power structure, the team was quickly authorized to proceed with the piloting phase of the IXP project.

Development of the Pilot
The purpose of the piloting process was to prove the feasibility of the concept that was demonstrated by the prototype. With the technical problems in integrating the diverse systems that existed at Methodist Hospital, there was a significant question
as to whether the proposed system would work. The pilot system was a limited production system using real data, including data from all of the 200-odd registrations that take place each day in the hospital and in the clinics served by
the pilot. For these patients it also included data on laboratory and radiology procedures ordered and the test results. The database was large enough to hold up to six months of data on the patients served. It had ten workstations supporting about
30 users at six different locations, including some at nurses’ stations in the hospital, some in clinics, and one in a physician’s office several miles away.

The permanent staff on this project was 10 people, four from Methodist Hospital IS and six from IBM, and IBM specialists from other localities were brought in as needed. In addition to their roles in development, IBM personnel trained Methodist Hospital personnel on the technologies being employed, such as the UNIX operating system and the C++ object-oriented programming language. The development team used the information engineering methodology to develop the pilot and supported it with the Bachman CASE tool. This development process includes the following stages: requirements definition, external design, internal design, coding, testing, and installation. They started work on the pilot in June 1991, and it was scheduled to be installed by April 1, 1992. The pilot project was budgeted at about $1.2 million, including hardware, the fees to IBM, and the cost of Methodist Hospital IS personnel.

The JAD Sessions
In October 1991, the project team refined and augmented the initial set of functional requirements defined by the prototype by using joint application design (JAD) sessions. The JAD approach brings together a carefully selected group of users and systems people, with a facilitator to run the meetings. There is a recorder who captures data on what took place, and technical people and facilities are available to prototype screens in response to suggestions from the group.
Dr. Moeller participated in all three of the JAD groups. “The facilitator must be able to unobtrusively manage the group and prompt active and dynamic input from all the people involved,” Moeller reported. “Our facilitator, who was brought in from
Pennsylvania by IBM, was outstanding.”

The first JAD group consisted of three physicians—a pediatrician, a surgeon, and an internist (Dr. Moeller). The purpose was to refine the procedures and screens of the prototype system to produce the requirements of the initial patient care application that would be used by the doctors in the pilot. They met with project personnel for five four-hour sessions in which they discussed what information they needed and how they would prefer to control its presentation. At the end, the facilitator told Moeller: “That was extremely useful, but I have never been in such an intense session. You guys were beating each other up right and left!” Moeller’s response was: “That was mellow.

I thought we were pretty darn cordial—we weren’t evenfighting.” “What had happened,” Moeller explained, “was that we had deliberately chosen three physicians from different specialties so that they would represent the diverse population of physicians within the hospital. They were chosen because they had different perspectives on how to practice medicine, were leaders in their respective areas, and were committed to developing a system that would enable them to provide improved care
of their patients.” The second JAD group consisted of user representatives from the emergency room, patient accounts, admitting, operating room services, radiology services, the pharmacy, the laboratory,and Dr. Moeller. They met for five four-hour sessions in early November 1991 to define the data and screens for the Master Patient Index (MPI) subsystem. This subsystem matches a client with a unique client identifier (ID) and enables users to access all the records for that client, no matter where or when the patient had been served.

According to Moeller, Methodist Hospital had a problem of interdepartmental communication:
With some 7,500 employees, we had some aspects of a stovepipe organization where huge departments did not interact effectively with each other. The people at the top were supportive of the system, but the people several layers down who were really doing the work did not see the need to share their information. So one of our objectives was to get them to see the need for a common vision. On the first day most of the participants were wondering what they were doing there, but by the end of the fourth day these people had arrived at a common vision and realized that there were uses of the information generated in their departments that they had never even conceived of. They understood that when this project is successful they will have a tremendously
enhanced way to deliver their department’s data to their users.

In this JAD session the participants discovered that the admitting office was entering the data on patients into the medical records system, but that the medical records office was responsible for the accuracy of these records. The hospital
was depending on medical records to correct any input errors, and there was no feedback to the admitting office, so the people entering the data had no accountability for the data’s accuracy. “We were all startled when we realized the implications of that,” Moeller reported, “and both the medical records and
admitting groups agreed to make admitting responsible for entering and maintaining the Master Patient Index information.”

The third JAD session brought together the computer specialists from the labs and departments whose computers were to be interfaced with the network, together with the IS and IBM people on the project. The purpose was to clarify the technical issues in the project. This session, which was held in mid-November 1991, was only half as long as the other two had been. “We made the assumption that we would not need as much time to obtain consensus among the technical people,”Moeller explained, “but in retrospect this has come back to haunt us because of incomplete buy-in from the IS technical people. If we were to do it again we would make the technical JAD session at least as long as the others.”In addition to developing process definitions and defining all the input and output screens, another result of the JAD sessions was a revision of the data model that was created in the prototyping process.

The entity-relationship diagram from the data model is presented in Exhibit 4, but the data model also includes a table of the business rules that apply to each entity and relationship and a description of the attributes associated with each entity.
“The data model forced us to adopt a broader point of view,” asserted Moeller. “When there are a lot of arrows into a box, you have to come to grips with all the different functions that use it. And it also gave me a radically different way of understanding what is occurring. For example, taking an X-ray film of a patient is a procedure. Understanding that an office visit, an X-ray, a blood draw, and a physical therapy appointment are all examples of procedures that are all handled in the
identical fashion in the data model was quite interesting. It was quite a different way of thinking for me.”

The Design of the Pilot System
Based on the prototype and the JAD sessions, the team designed the IXP pilot system. This pilot system had two components—a computer and communications platform to support access to the different computer systems at Methodist Hospital, and the initial applications to be delivered by this platform.

The IXP Platform
According to a design document produced by the team, The objective of the IXP is to provide the user a single point of access to data that originates on several incompatible systems. Access to the data must be transparent to the user and presented in a readable and meaningful format across applications in the Methodist Health Care System (MHCS). The IXP will achieve this objective by providing an integrating platform of hardware, software, and network components.
The IXP will provide functions which will ultimately interface to systems both internal and external to MHCS, will provide data-base and network services to client applications on a local area network (LAN), and will provide a control point for IXP LAN management and maintaining system integrity.

The pilot platform configuration is shown in Exhibit 5. An Ethernet protocol over untwisted shielded pair was selected as the backbone network, partly because Ethernet skills were already available in the IS department. The software running the communications server was PICSTalk. According to Zerrenner, “At 30-second intervals the communications server polled each of the systems, providing data and reading
any new data they had generated. PICSTalk performed the translations required to translate the data from each system into standard form for transmission to the SYBASE relational database in the database server. PICSTalk also screened this data to eliminate any data not required for our system. For example, the name of the technologist who did a test is generated by the lab system, but it is not of interest to the physicians, so it is eliminated before the data is sent to the IXP database.”

The SYBASE software in the database server was a relational database management system with which some members of the design team were already familiar. The primary function of the database server was to provide data, because most of the application software resided in the applications server. Applications were run directly on the applications server or downloaded into the workstations for execution. Because the
network architecture provided for modularity, other types of workstations and additional servers could be easily added to the system.

The RS/6000 had the power to run both PICSTalk and SYBASE at the same time, but PICSTalk did not run under the UNIX/AIX operating system when the pilot was being designed. Therefore, the team was forced to use a PS/2 to run PICSTalk until a version of PICSTalk that ran under UNIX/AIX became available. Unfortunately, such compatibility problems are not uncommon.