An Outpadent Clinic Information System Based on Distributed Database Technology Richard Wilton, M.D. and J. Michael McCoy, M.D.

UCLA School of Medicine, Department of Medicine

Flexibilit. We designed the MAC clinic system to be flexible in four important ways:

This paper describes a clinical information system used in an outpatient teaching clinic at UCLA The system is designed specifically to address the informationprocessing needs of health-care providers in the clinic. The computer system uses distributed-database technology as a means of establishing data links between different applications running concurrently in a local area network as well as between network applications and hospital mainframe and minicomputer systems. The distributed architecture has resulted in a computer system that can evolve in response to anticipated clinical needs and to the introduction of new technology.

- The system can be linked with existing mainfame and minicomputer installations. - The system can incorporate existing standalone microcomputers and microcomputer applications. - The system can be adapted to new hardware and software as they become available. - The system confipration can be reliably modified in response to user needs.

The UCLA Medical Ambulatory Care (MAC) clinic is an adult outpatient clinic where over 15,000 patients are seen each year. It is staffed by 20 attending physicians, 70 house officers (residents and interns), and 6 nurses, as well as many medical students and other health-care providers. We are currently building a clinical information system in the UCLA MAC clinic to support the needs of physicians and nurses in this busy outpatient clinic. This paper describes the design and implementation of this evolving computer system.

The MAC clinic system was designed from its inception to accommodate existing hospital computer resources. In our outpatient setting, patient registration information and laboratory values are maintained on an IBM mainframe computer, patient appointment scheduling is performed on a VAX-based system, and a record of diagnoses, medications, and clinic visits is maintained in a microcomputer database. We wanted to integrate user access to the information in these various resources and without needlessly duplicating the information. We therefore designed the MAC clinic system to provide transparent data links between networked microcomputers and the previously-established computing systems.

Our purpose in developing a clinical computer system in the MAC clinic is to make practical clinical information available to physicians and nurses. This information comprises patient-specific data (registration information, problem lists, laboratory results, and so on) as well as reference information useful to clinicians. The system is designed to present its users with timely and accurate information that is displayed or printed in an easily understandable format. The system also supplements information retrieval with appropriate informationprocessing and educational tools. The underlying assumption is that the computer system ultimately enhances patient care by letting health care providers become more effective users of patient-related information.

We also focused our design efforts on readily-available microcomputer hardware and software. We used IBM PC and PS/2 computers and IBM Token Ring network hardware in our implementation because this hardware was readily available for our use at the UCLA Medical Center. This decision was somewhat arbitrary--other vendors' hardware would have offered better video graphics or faster computational speeds--but it allowed us to exploit existing computer resources more easily. For example, an IBM PC/AT computer has been in use for over two years in the MAC climc to run several standalone clinical applications, including a nutrition analysis program, a database of drug interactions, an interactive case presentation" teaching program, and a wordprocessing application, and a single-user patientinformation database. We integrated this computer into the new system by including it in our local area network in a way that network-based applications could be installed without disrupting the' existing stand-alone applications or duplicating computer hardware.

System Design With this in mind, we are developing an information

system for the MAC clinic that relies on a group of microcomputers linked together with a local area network. These computers access data that is distributed across the network by certain designated computers on the network that act as database servers or as micro-to-mainframe "gateway" machines. This design evolved in response to the need to build a flexible system that provides an integrated set of software applications using reliable, offthe-shelf computer hardware and software.

0195-4210/89/0000/0372$01.00 C 1989 SCAMC, Inc.

372

Off-the-shelf hardware. Our reliance on off-the-shelf computer components contributes to the flexibility of the MAC clinic system in two important ways. Both hardware and software engineering techiques are well established for the components we are using. This is particularly relevant when it becomes necessary to customize our computer installations with application-specific hardware or system software such as device drivers. Because the technology is well-defined, we need not rely on outside vendors for customizations of our system.

Similarly, a micro-to-mainframe connection to the hospital ADT system was established through microcomputer emulation of a 3270 mainframe terminal session, using existing microcomputer hardware and mainframe terminal support. This linkage requires very little support on the mainframe side and uses a clearly-defined application programming interface on the microcomputer side. It therefore makes efficient and cost-effective use of both mainframe and microcomputer resources.

Consistent user interface. Most of the users of the MAC clinic computer system are relatively inexperienced computer users. We decided to limit the amount of "computer sawy" required to use our software by presenting its users with a consistent interface. The appearance of applications on the video screen, the use of designated keystrokes for specific functions, and the optional use of a pointing device are consistent aspects of each new application we develop. Our user interface is the one embodied in the Microsoft Windowstm environment. Windows presents the user with a screenful of rectangular windows, each of which represents a program that the user can interact with (see Figure 1). This environment is familiar to users of the Apple Macintosh and other similar microcomputers. In using Windows, we follow the trend embodied in many other commercial computing systems, including Sun workstations, the OS/2 Presentation Manager for 80286- and 80386-based microcomputers, and IBM's anticipated System Application Architecture (SAA) user interface.

The overall maintainability of our system is good because all of the hardware components are readily available and easy to repair or replace. Similarly, all of the system software is well documented either by software vendors or in the computing literature. We are therefore able to expedite the diagnosis and repair of defects in both hardware and system software. The Distributed Database

The notion of distributed database processing is implicit in the hardware architecture of the MAC clinic computer system. Repositories of data as well as data users are distributed on different machines on the local-area network. The distributed-database architecture therefore implies a mechanism for communicating data and computational services between different computers as well as between applications on the same computer.

Inter-ApDlication Communications. All our user application programs run in the Microsoft Windows

environment, so they rely on the Windows mechanism for inter-application communications. This mechanism, called Dynamic Data Exchange (DDE), relies on the messagepassing methodology intrinsic to the Windows environment. A typical inter-application exchange of information occurs when a patient- ormation database application requests the identity of the person running the program from a "user ID" application. The database application initiates the data transfer by sending a DDE message to the "user ID" application requesting the specific information. The "user ID" application responds first by copying the requested information into a shared location in the computer's memory, and then sending the database application a message indicating where the requested information can be found.

Exchange of data between applications running on different computers is also accomplished through DDE. In this situation, DDE messages are translated into network data packets by a special-purpose Windows application. Thus, in any given computer, applications communicate via DDE only with other Windows applications without any special knowledge of the location of remote network resources. This technique of network communication differs from the traditional "file server" network database in that all network data transfers are application-specific. Applications do not access database files directly. instead, each database transaction consists of a specific request for a certain type of data. A "server" application processes the request and returns a specific response. This methodology has several advantages: - It decreases the number of network data transfers.

Figure 1.

The tradeoff in embracing a consistent user interface is that it takes longer to write software that conforms to the interface conventions. We feel, however, that the additional effort expended in software development is worthwhile. Because all Windows applications use the same source-code programming interface, new functions and user-requested changes can be implemented without disrupting an application's accustomed look and feel. Furthermore, the extra time spent in programming is balanced by the time saved by end-users. Rather than learn a different, idiosyncratic style of interaction for each application, users of our system rely on the same methods of interaction--pull-down menus, push-button and slide-bar "controls," and consistent keystroke assignments--for all

applications.

373

-

It allows database files to be processed locally on a rather than across the network by

0ose _its.

single machine

multiple

F4

Fl-Nlel

wer Itt atit- Save di li jid atint- Mew Start Edit -aveChage - - - Chamis ------ eatleut -m- eatit ----- - evr 1-

ole:

machines.

0 Secter:

Ham:_ beft

It makes no distinction between data saved in disk files and data retrieved from other sources such as an emulated mainframe terminal session.

-

Name

(last, first):

villtn

I

Wlechmna.. ichaI L Wiener, Isaac Wilkes. Michael S Wilkins.n. Alan J Villenbucher, lubert Francis William. Adrian Jobn

It permits equivalent access to data stored locally (on the same machine) and data transmitted across the network. -

Vilson, Carl

Wilse.. Linda Wight Richard AllenI William.. Thomas

ate

'911a.m

We have already Micro-to-Mainframe CA mentioned how the MAC clinic network is linked to a mainframe computer at the UCLA Medical Center through an emulated mainfame terminal session. The link between applications in the MAC clinic and the mainframe is straightforward: Requests for patient data are sent to the mainframe, and the data are returned from the mainframe to the requesting application. Also, patient data is always requested on a per-patient basis.

1%

Figure 2.

The physician can then search for patient information using the patient's name, hospital ID, or doctor (Figure 3).

This approach limits the types of transactions that can be performed. For example, all of the recent laboratory results on a particular patient can be requested, but a list of all patients with a specified abnormal test value cannot. This limitation might appear to be a bottleneck in the flow of data from the mainframe to the MAC clinic system. In practice, however, nearly all requests for mainframe iformation pertain only.to one patient, so this approach is satisfactory.

........ . .. . -1 --

-

Ris

5dC

.

Aid --J-potlent --Om -..

-

--

patient

Io 19ITS

3hu ----

---

S anam ----

Start----

I

mve

---, Fl-melI

1--

----

I

I

N

1S"t7i

Is:

3 Select

0arl

Name:

F

[^ak J ---I

ky docter

I

l

[r

p

-%

.

. ..

...

.,,

The actual implementation consists of an emulated 3270 terminal session driven by a network-aware "front-end" application. The front-end application responds to requests from other applications running on the network. It extracts requested information from predefined fields in 3270formatted screens and sends the data back across the network to the application that originated the request. In our implementation, the requesting application uses the same message-passing format to get data from the 3270 front-end application as it does to request data from a database file server. Figure 3.

Applications

The retrieved patient information is displayed in a window where it can be optionally updated or printed (Figure 4).

Of course, the end-user is not necessarily aware of the underlying distributed-database implementation. Instead, the user sees only a set of applications running within a consistent user interface. In fact, some users do not even recognize the notion of concurrent yet separate applications. Instead, they see only a single entity ("the computer") that lets them process clinical information in a number of different ways. In other words, users interact with microcomputer workstations that provide integrated access to the distributed clinical information.

lec

Edit

Ild

patint

)If: lik-47-9-5

flw-

0 beter:

atiet

Hape: ati*ent. Is. Typical BOB: R-O-liN lace: See: F

Patient information. This concept is embodied in the following typical interaction with the MAC "patient information application: Imagine that a house officer needs to find a single piece of iformation, such as a patient's telephone number. The physician's interaction with the computer would consist of three steps.

amps start

Sas

war

NHow phone: (212)123-8sl67 Work phone: O Nedicatlo

Problem/liaenosis igraines

napres,s

lose 250 tid

mnxietyldepressim

fieriaal

pro

me

bask

late s-

Pain

Secttr el-

5-2IS-S

EFI-NelL

Wilt.. Rieard

wilt. Svitb

0 ChieF Cemelaint/Coments lIntIal visit; started fwianal to fiwlmal Extended follow-up; responde

.-I

The interaction begins with a "start over" transaction in which the physician establishes an identity for subsequent transactions (Figure 2). Figure

374

4.

I

this straightforward interchange are several Underlying inter-application data requests and

Future Directions

transfers. The initial identification transaction is carried out when the patientinformation program requests and receives the physician's identification from the "user ID" program running concurrently in the same computer. Subsequent requests for patient iformation are transmitted across the network to another computer, where server programs obtain the information from the mainframe or from database files and send it back across the network to the patient-information application, which formats and displays it.

Although we designed the MAC clinic computer system from the top down, we put the working system together from the bottom up. That is, we deferred development of more "glamorous" applications until we were satisfied that the underlying distributed database technology was workable and reliable. Now that we have gained experience with our system in day-to-day use, we are enhancing higher-level system functons, including additional user applications, remote dial-up access, and system security.

These transactions bring up two further points that emphasize the flexibility of the computer system. First, the physician's identity is maintained by an independent, concurrently-executing program that keeps track of who is authorized to use the system. Although the only visible manifestation of this "user ID" program is the physician's name in the lower right corner of the video display, in fact all other applications in the workstation commumcate as necessary with the "user ID" program, both to determine who is using the workstation and to enforce selective access to system resources.

Additional cations. Much of the utility of the MAC clinic system derives from the connectivity of its components. In general, there is less need to maintain redundant information in the MAC clinic system when that information can be obtained throu ata to other hospital computers. The result is that the MAC clinic system becomes increasingly more convenient to use. We anticipate several different applications designed around physician-specific databases. Each database will comprise a list of patients that are followed by a particular physician in the MAC clinic. Although demographic information can be found in the existing patient-registration computer system, it will ultimately be the physician's responsibility to keep each patient's clinical information up

The other important aspect of all workstation transactions is that the physician using an application need not specify the source ofthe information in order to access it. For example, the "patient information" application retrieves some of its information from a relational database maintained as a set of disk files in one computer on the local-area network. However, the same application downloads other information on demand through the emulated 3270 mainframe-terminal session on another computer elsewhere on the network. The end user nevertheless sees only a single response to a single request for information, without explicitly requesting (or even being aware of) the underlying transfers of information from computer to computer across the network.

to date.

Several different applications could then utilize each physician's patient lst. For example, a physician could be notified whenever recent laboratory results are reported for a patient in his or her list, or when a patient followed in the MAC clinic is seen by a different physician in the clinic or in the emergency department. We also foresee a number of logical linkages between the existing patient data applications and static information sources like the "Card File" applications we described. For example, we plan to develop a simple health-maintenance reminder application that displays relevant clinical information based on a patient's age, sex, diagnosis, medications, and so on. For example, a physician canrng for an elderly patient might then receive a reminder from the computer system if the patient had not received an influenza vaccination within the past year.

Reference material. Patient-specific data is supplemented in the workstation by reference material compiled by MAC clinic staff. Reference material is made available in a simple indexed file format using a customized version of the Windows "Card File" application. The example in Figure 5 is one of over 200 patient-management summaries compiled by Dr. Sam Skootsky the director of the Internal Medicine Consult Service (IMCS) in the MAC clinic.

Practice management. As a teaching clinic, one of the primary goals of the MAC clinic is to provide a satisfactory learning environment for the house offcers who see patients there. We therefore intend to use the clinical information in the MAC computer system to monitor the number of outpatients followed by each physician. At the same time we could also study the diversity of diagnoses each house officer is required to manage. his information would help ensure that each house officer has the opportunity to follow a representative distribution of clinic patients. Remote access via modem. We have prototyped an application that connects to our system using a modem over a standard telephone line. Clearly, the same method of requesting and sending information between applications on the local area network can be used to transfer the same information to a remote application. Before dial-up access to the MAC clinic system becomes practical, however, we need to address the problem of mantaining the confidentiality of patient data.

Figure 5.

375

References

Security. We feel that the distribution of data to multiple microcomputers, including computers at remote locations,

does not preclude our ability to maintain the confidentiality ofpatient information. Currently, data security relies primarily on the fact that workstations are located only in patient-care areas, and that access to patient data can be audited on a per-user basis. These measures are sufficient given the current state of development of our system. Nonetheless, we clearly recogmze the need to inhibit inadvertent or malicious access to confidential patient information. The problem is most apparent in regard to dial-up access to C patient information, where the convenience of remote access must be balanced with the need to avoid invasion of patients' privacy. We will almost certainly inco rate additional technical solutions to the problem (such as encrypted data, user access privileges, and limits on user time and- rate of data requests), but we recognize that our system implementation will ultimately be constrained by administrative and medico-legal as well as engineering considerations.

1. BARrr, G.O., r ALCOSTAR--A Computer-BasedMedical Information System for Ambulator Care. Proceedings ofthe IEEE, 1979; 67(9):1226-1237. 2. BLmcH, H.L., ErAL. Clinical Compu in a Teaching Hospital. New England Journal of Medicine, 1985;

312(12):756-764.

3.

CJ., ETkL Reminders to Physicians from an McDoNALw, Introspective Computer Medical Record. Annals of

Internal Medicine, 1984;100(1):130-138.

4. McDoNAw, CJ., Erru The Regenstrief Medical Record and Clinical Support System. Symposium on Computer Alications in Medical Care (Demonstrations Digest), 1988 51-55. 5. TAYLOR, MJ., ErAL. Patient Record Information Handling on a Local Area Network. MEDINFO 86 Proceedings, 1986; 828-830.

6. TOLCIN, S.G., ErAL. Integrating Heterogeneous Systems using Local Network Technologies and Remote Procedure Call Protocols. Symposium on Computer Applications in Medical Care, 1985; 748-749.

User Acceptance

The system described here has been in place since December, 1988; it replaced a single-computer patient database that had served for the previous two years. Actual use of the current MAC clinic system varies among clinic staff. Individual reactions range from bewilderment (a medical resident pointing a mouse at the video screen as if the mouse were a light pen) to matter-of-fact acceptance ("It's pretty much self-explanatory" was one resident's comment). Nevertheless, there are currently over 14,000 patients' records in the system. On their own initiative, about one in five medical residents regularly update information in the system after clinic patient encounters.

Of the various data search-and-retrieval functions provided by the system, the function used most often by house officers is one that prints a formatted list of each physician's patients. Most residents carry this list in a pocket or a clinical notebook, where the information can be quickly referenced or signed out to another physician. Our interpretation of these observations is simply that users of the MAC clinic system expect it to provide a reasonable amount of utility. Like any such tool, physicians and nurses use the computer system only when it provides perceptible benefits in terms of efficiency or improved patient care. Consequently, our goal is to ensure that the MAC computer system evolves in response to the perceived needs of healthcare providers. The MAC computer system is able to evolve in this way because it can be adapted incrementally to changes in hardware and application software. The system demonstrates that the computing needs of health-care providers in an outpatient setting can be met by a microcomputer-based clinical information system that relies on a network of computing resources with distributed sources of information.

376